1. 包体是否足够小
App 的包体大小，对获取用户有着至关重要的作用，特别是在线下的推广活动中，包体太大，下载费时费流量，很多用户会失去耐心，从而直接导致 App 的推广效果大打折扣。
而 App 的包体大小，除了自身的代码量，也会受到第三方库的包体影响，因此，短视频 SDK 包体越小，对于减小 App 包体大小越有帮助，开发者才会越喜欢。
那么，如何做到尽可能的减小 SDK 的包体呢 ？
- 尽一切努力使用 Android/iOS 系统原生的 API，不怕难用，不怕踩坑
- 良好的模块划分，不同的功能生成不同的动态库，客户可选择性的拆卸和裁剪
- 所使用的第三方库，充分配置编译选项和功能裁剪，只打包必须的功能、单独抽离所需的模块.
2. SDK 是否开放
使用第三方的 SDK，最怕的是像个黑盒，过于封闭，想配置的参数无法配置，需要的状态也没有回调，直接导致产品经理给出的 UI 和交互方案无法实现。因此，SDK 的开放性，越来越成为开发者选型的关键因素。
那么，SDK 如何做到尽可能的开放呢 ？
- 凡可配置的参数，一律提供配置，比如：摄像头参数、编解码参数、美颜参数、混音参数等等
- 凡可回调的数据，一律提供回调，比如：摄像头采集的视频帧、纹理 ID，麦克风采集的音频帧等等
- 凡运行过程中的状态，一律提供通知，比如：拍摄状态、转码进度、取消事件等等
另外，还需要尽可能地跟 SDK 上下游厂商建立良好的合作关系，比如 美颜、滤镜、人脸贴纸特效、大眼瘦脸等供应商，让客户可以随时快速接入和替换任意一家厂商，从而加快产品迭代和上线的速度。
3. 性能是否足够好
虽然手机的性能越来越强大，但 CPU 使用率居高不下、发热厉害、内存消耗大、运行速度慢的 App 非常影响用户体验，因此，无论是 App 本身，而是第三方 SDK，性能永远是值得关注的重点。
SDK 如何做到更好的性能呢 ？
其实就一条：充分地利用 GPU，尽一切可能减少 CPU 消耗，对于短视频 SDK 的开发，具体有哪些值得关注的点呢 ？
- 音视频编解码尽可能地使用硬编/硬解
- 视频/图像的处理，尽可能使用 OpenGL，包括：美颜、滤镜、水印、剪裁、旋转等等
- 尽可能更高效地编写 OpenGL 代码，使用一些提高效果的特性，包括：VBO, VAO, FBO, PBO 等等
- 动态管理 so，没有用到的不加载；动态管理内存，使用时再分配
- 合并处理流程，各种音视频特效和处理，依次记录状态，待保存的时候，再调用算法处理
4. UI 和 SDK 逻辑是否彻底分离
优秀的 SDK，一定要尽可能避免把 UI 的界面和逻辑包含进去，不然 SDK 的使用者，很难满足产品经理的 UI 和交互设计要求，做出差异化的效果。
那么，SDK 如何做到与 UI 逻辑彻底地分离呢 ？
需要充分分解每一个短视频的功能需求，搞清楚每一个需求的实现原理，哪部分是 UI 的，哪部分是核心的，前者写到 Demo 上，而后者则写入 SDK 里面。就拿短视频剪辑这个功能点来举个例子，下图所示是短视频的一个热点功能，对短视频截取中间某一段片段。
5. 是否有良好的可支持性
优秀的 App 和 SDK，首先一点就是要稳定可靠，不会动不动就奔溃。具备良好的可支持性的产品，往往更容易受到青睐。
什么是可支持性 ？
举个例子，就像家里买的某些品牌的洗衣机或者空调，在出故障的时候，液晶屏幕上会打出一些错误码，当你给售后打电话的时候，售后往往能够根据描述的信息以及错误代码很快地定位到问题或者给出临时的解决方案。
如何让短视频 SDK 具有更好的可支持性呢 ？
关键在于一套健全而规范的日志系统，可以有效提高技术支持和开发者排查问题的速度和效率，那么，设计这样一套完善的日志系统，有哪些关键点呢 ？
支持配置 SDK 的输出日志级别，如：ERROR, WARN, INFO, DEBUG, VERBOSE
SDK 初始化的时候输出关键的排障信息，如：应用包名，SDK 版本，设备机型，系统 OS 版本，关键配置等
规范的日志格式，如：<SDK TAG>:<Module TAG>:<Class TAG>:<Message>，可以快速方便地过滤出各个模块的运行状态
健全的问题排查手册/文档，让每一个错误码都有文档可依，开发者可以完成简单初步的问题分析
