注意事项
解耦 业务逻辑多分层，模块化，某一个功能点是一个小模块
命名空间 类名和工程名加前缀，通知名和全局变量也要加前缀，避免发送通知混乱执行。
-
引入开源库，不要直接引入开源库，并把开源库编译进SDK中。
有两种解决办法：
可以修改开源库的前缀和命名空间，改成自己的库；
编译自己的SDK,在别人引用时,一并引入需要的开源库。
易用性 不要一个接口传十几个参数
不要直接将第三方库打进SDK，或者将第三方库重命名，以免冲突
-
做基本的检查和测试
SDK 对外公布前应该进行基本的编译检查，不应该有编译器警告存在。
-
文档完整并且正确
文档要跟随着SDK及时修改和完善。示例代码不要出现错误。
-
支持最新的CPU版本和新特性
CPU版本：SDK需要支持真机(armv7 arm64)、模拟器(i386 x86_64)
编译特性：像Xcode10 iOS12发布的时候，苹果不支持GCC编译，需要SDK一定要支持clang编译
像这次必须clang编译，应该一开始就紧跟技术更新，及时更新，而不是让集成库的开发者去找临时解决方案。
优秀的SDK标准
- 针对开发者用户的标准
- 完备的功能
- 良好的接口规范
- 完备且及时更新的文档
- 良好的技术支持
- 所用即所得，没有小动作
- 及时适配和支持新特性
- 针对厂商开发者的标准
-
完善的日志上报功能
- 大数据上报和Crash上报功能便于发布者及时改善。
-
较好的架构和顶层设计
- 在设计SDK时需要对用户场景做一定的假设，保护和规避，从而也对SDK开发者提出了更高的要求。
- 开发模式方面，不能像app一样快速迭代发版，快速的迭代改进。SDK产品的受众是公司开发者，他们更重视功能实用性和稳定性，没有很大对已集成SDK做持续升级-这将消耗大量的时间回归已稳定功能；在SDK开发阶段，一定要进行很好的设计规划，不然的话各版本功能间接口兼容性问题会凸显。
- SDK的文档在引导用户集成的重要性。
没有内存泄漏
常见的SDK冲突和错误
重复引用
- 引入相同的开源库，导致重复引入；
在使用我们在使用 AFNetworking 的时候遇到了许多依赖方面的问题。因为有些第三方库也使用了 AFNetworking 的静态库，如果两个三方库都使用了AFNetworking，并且集成到一个工程中时，他们之间就会发生冲突。
解决办法有
- 修改命名空间和一些参数，可以带前缀等方式
- 不将AFNetworking引入到sdk中。
- 将自己的sdk打成动态库。
架构
- sdk架构问题，是否同时支持真机(armv7 arm64)、模拟器(i386 x86_64)；
路径引入
- 报.h文件找不到，是因为路径引入不对，朝这个方向努力。
以上是我集成移动端第三方库和自己写SDK的感想，哪里写的有出入的，欢迎评论交流！
