三方SDK准入标准
三方SDK准入规范
- 三方SDK准入规范
- 背景
- 准入规范
- 原理
- 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机型是基本都会沿用的，如果是同方案机型，那么也大概率会沿用，因此需要关注该功能模块的可移植性。
-
尽量将模块改动放在一个package内，并对外暴露统一的接口，如果start/stop/debug等，在暴露的接口内部才执行各种逻辑，例如付费才可以运行，例如只有开启了XXX功能的前提才可以运行等。应尽量减少对其他模块的改动。即——解耦
-
如果存在对内核的依赖，需要用KERNEL_VERSION的宏包裹，最直接的办法，就是将该模块，在不同的内核上编译，验证功能是否正常，以解决内核版本不同导致的各种编译问题
-
如果有的底层调用和芯片方案强相关，则可以用以下的宏包裹：
ifeq ($(CONFIG_IPF_PLATFORM_BCM), y) EXTRA_CFLAGS += -I$(LINUX_DIR)/../bcmkernel/include EXTRA_CFLAGS += -DCONFIG_PLATFORM_BCM=1 endif -
必须删除代码中和TP-Link/Archer/Deco等强相关的代码，也应当尽量避免和机型强相关的代码，这种代码，换个机型则可能无法运行。以下为错误示例：
local model=`get_MODEL` case $model in "MODEL_A") ... ;; "MODEL_B") ... ;;如果实在无法避免，则应该在机型目录下新增代码，如profile中加一个标志，如果有则新增XXX功能，否则即默认不支持等。这里应结合新旧功能的关系来考虑，不再赘述。