526互联

三方SDK准入标准

发布时间 2023-08-24 17:31:07作者: 付时凡

三方SDK准入规范

目录

背景

描述引入第三方SDK时，应该关注的功能点。

三方SDK泛指：可执行文件、动态库、静态库等一切产物或者源码、文档等。

准入规范

原理

在源码可见的情况下，必须了解其工作流程。最起码到接口+参数这个量级，同时要输出第三方SDK的工作流程说明文档（如果功能和平台强相关，可结合具体的平台来描述）。

同时应该覆盖接口的边界值。

此时，应该输出其内部关键的处理逻辑、核心数据结构的说明文档，方便其他同事理解。文档输出也是模块移植非常重要的一部分。并不是移植后，功能模块run起来ok就万事大吉，各种维护的文档，亦是优秀程序的一部分。

在源码不可见的情况下，必须在职权范围内尽可能多的理请第三方SDK的工作原理，避免出现致命的盲点。

例如SDK的使用限制条件等，例如是否需要license，以及license的使用时长限定，验证license有效性的频率，验证失败的表现等。

将第三方视为一个黑盒去做开发，可能会造成难以预估的问题。

SDK功能

在基本功能可用的情况下，更应该关注稳定性和流畅体验。

  • 功能模块的稳定性（UES多客户端多数据流的场景下，长时间运行）

    是否会导致kernel panic，或者其他的异常，例如无线；如果是应用层进程，其内存占用是否有异常的波动？或者进程异常退出等；也可能频繁start/stop进程，查看进程是否正常运行

  • 功能模块的准确性

    如何判断其识别结果的准确性，需要有衡量标准。例如在UES高压环境中，如果再增加客户端，表现如何？

    如果是安全模块，对攻击事件是否准确？

  • 功能模块的时效性

    例如涉及数据处理，是否及时，是否会导致用户上网体验变差，例如上网卡顿等，用户体验需要摆在首位。

资源占用

至少包括但不限于以下条目。

  • CPU

    无运行时的CPU占用，以及UES的占用情况

  • DDR

    需分清是堆还是栈占用多，并结合场景来看，例如某些场景下的包会比较多？还是所有的场景都是一样的内存占用？且需关注是否有内存泄漏，这里需以UES的场景来说明。

    注意：DDR往往有波动，需留有一定的余量，例如供APP通信使用等。需结合机型表现具体判断。

  • Flash

    需考虑分区的现有大小，以及后续是否有增长的可能性。

    若有可能增长，增长的上限值亦需要关注，否则，Flash写入失败的场景，应有应对策略

  • 总线

    例如I2C、I2S、UART等。总线资源通常和SoC强相关。但是部分总线，例如SPI，可以扩展多个从设备。

  • 所需数据包

    例如如果获取数据包、如何拦截数据包，如果处理数据包并输出何种数据，都需要清楚；以及数据包的类型（TCP或者UDP），数据包的个数，取连接中的哪个方向的第几条数据流

性能影响

至少包括但不限于以下几个场景。

  • 对启动时长的影响
  • 对客户端数量的影响
  • 对创建连接数量的影响
  • 对有线/无线吞吐量的影响

安全性

  • 是否需要隐私协议，需要设备端和APP端及云端判断
  • 是否收集用户隐私数据，例如访问网站、APP等
  • 是否会周期性向外发包，如果有，发包类型是什么？频率如何？需评估其具体的影响
  • 底层SDK更新频率，是否对某些安全事件CVE的紧急响应等

模块耦合

  • 对系统层面的要求，例如内核版本，内核需要开启或者关闭某些feature，建议一并评估这部分的内存占用。
  • 是否和现有功能有耦合？例如对NFQUEUE的共同使用，CT的mark等公共资源，必须考虑和现有模块的共存
  • 如果是替代功能，则需要考虑和现有方案的切换逻辑，从现有的A方案切换到新的B方案，并且，后续可能还有C、D方案，需一并考虑
  • 对某些opensource工具的版本，如curl版本等

可移植性

多数情况下，三方功能都不会只在某一款特定机型上开发，起码remodel机型是基本都会沿用的，如果是同方案机型，那么也大概率会沿用，因此需要关注该功能模块的可移植性。

  1. 尽量将模块改动放在一个package内，并对外暴露统一的接口，如果start/stop/debug等，在暴露的接口内部才执行各种逻辑，例如付费才可以运行，例如只有开启了XXX功能的前提才可以运行等。应尽量减少对其他模块的改动。即——解耦

  2. 如果存在对内核的依赖，需要用KERNEL_VERSION的宏包裹，最直接的办法，就是将该模块，在不同的内核上编译，验证功能是否正常，以解决内核版本不同导致的各种编译问题

  3. 如果有的底层调用和芯片方案强相关，则可以用以下的宏包裹：

    ifeq ($(CONFIG_IPF_PLATFORM_BCM), y)
EXTRA_CFLAGS += -I$(LINUX_DIR)/../bcmkernel/include
EXTRA_CFLAGS += -DCONFIG_PLATFORM_BCM=1
endif

  4. 必须删除代码中和TP-Link/Archer/Deco等强相关的代码，也应当尽量避免和机型强相关的代码，这种代码，换个机型则可能无法运行。以下为错误示例：

    local model=`get_MODEL`
	case $model in
    "MODEL_A")
		...
		;;
	"MODEL_B")
		...
		;;

    如果实在无法避免，则应该在机型目录下新增代码，如profile中加一个标志，如果有则新增XXX功能，否则即默认不支持等。这里应结合新旧功能的关系来考虑，不再赘述。