设计API时遇到的挑战
API是对外的接口，在开发中，请求参数的增减无法避免，这必然导致不同版本之间的兼容性问题，这时有两种策略：
- 参数设计为
参数对象，通过组合对象来避免调用方法的变更。 - 声明一个
新函数，名称与原函数相同，只是加上新添参数。
两种方法各有缺点：
参数对象 中引用的对象如果是SDK内部对象，就必须公开内部类，而内部类又可能引用其它内部类，这样容易形成一棵类树，势必导致暴露过多的内部类，简单的想法是定义参数专用类来避免，但专门用于传输参数的类与相同功能的内部类会导致一定的信息冗余，需要新的编程技巧来纠正。
声明新函数可以有限的避免参数对象的问题，也会导致API数量增加，而这些名字类似的方法名，在集成时会导致误用，毕竟，即使在文档明确说明的情况下，大部分开发者是选择忽略的。
集成第三方SDK遇到的挑战
开发自己的SDK，应该尽量避免使用第三方SDK，但随着SDK功能越来越复杂，特别是一些业务性的SDK，全部重新造轮子就有些得不偿失了。引用第三方SDK会遇到两种集成方式：
- 源码方式。
- 二进制方式，包括framework和静态库。
对于源码方式的引入，如果集成方引用了相同的库，会导致符号重定义（duplicate symbol），可以通过约定版本的方式，指定集成方引入，也可以使用符号表混淆的方法避免。
当引入了二进制方式的SDK时，可用的选择就变少了，二进制无法进行符号表混淆，只能剥离一些不必要的静态库。
分类导致的命名错误
分类名相同导致的问题，我在如何使用类别 一文中已经详细说明，这个问题应该在开发开始时就引起重视，因为集成后报错的位置只和编译顺序有关，既可能在集成方，也可能在发布的SDK中，故障现象轻者编译出错，重者导致数据错误，都很难定位到分类本身。
资源问题
图片等资源，会导致文件重名和找不到路径两类问题，前者可以同分类一样，加上前缀解决，后者需要分开发和发布两种情况处理。
合并静态库版本
在终端输入：
lipo -info xxxx.a
就可以看到当前.a文件支持的架构了
发布的SDK必须同时支持debug模拟器，debug真机，release模拟器，release真机，因此需要进行合并，在终端输入指令
lipo -create 静态库1 静态库2 -output 新静态库名称.a
做好版本管理
SDK的版本管理比发布APP更有功能性作用，由于SDK更新频繁，面向开发者，所以也更具挑战，除了常规大小版本定义外，在API设计时设计一个打印当前版本的方法是个很实用的实践。
网友评论