写sdk的心得

背景：由于公司需求，需要把公司各部门做到互联互通，于是作为支付部门的我们便被推到了风口浪尖之上，需要把我们的收银台sdk嵌入其他部门的app中；除了给自己公司部门，还为别的公司提供了支付这提服务。

编写：sdk的编写一般都是以一个单例 manger 来提供服务接口，然后不同的功能设置不同的类，以组合关系的模式互相调用完成交互。如下图：

简单的草图

典型的例子可以参考afnetworking。上图是涉及到架构层面的，架构的能力需要考虑到应用场景，以及拥有丰富的经验才能设计的妥当。我也只是班门弄斧了，多阅读源码，体会那些成熟框架，从大到分析它的架构，细到分析一次调用的数据流向，数据就像是血液，流经每一个节点，每一个节点或是对其进行封装，或是对其的处理进行回调。前辈们的代码有些稳扎稳打，有些也却是点睛之笔。站在巨人的肩膀上成长，才会成长的更快。

sdk应该注意的点：

1 . 千万注意类命名，作为sdk首要保证的是不要与人家的库有类名冲突，每次看到 duplicate  class 这个就头疼，因为我们的sdk代码是从app里扒出来的，这也是没办法的事，毕竟没给那时间去重新写，sdk还是提供UI界面的，在这第三方横行的iOS 应用中，重复的概率太高了。所以记得要给引用的第三方类库加个用不会冲突的前缀。

2.  类冲突 还是算小事，毕竟导入app中编译都过不去，最怕的是 分类（category），iOS分类是个语言特性，在编译的时候分类中的方法是要被编译到类的方法列表中的。想起恶心的来了。。。  marsory 这个库是很多写UI的人都要用的，其中可以通过两个宏 来控制属性和方法简写.mas_top ----->.top，刚好还是UIView的分类里，sdk里刚好有一个 UIView的分类，为了方便fram的设置，也加入了top bottom  width 等属性，然后就出现了方法冲突。当app调用top的时候，会从UIView的方法列中查找该方法，调用查到的第一个实现。

3.当涉及到UI界面的sdk的时候，像是导航栏字体  按钮风格 （颜色，圆角）这些都要去从plis中读取会不较好，因为这样 第三方调用就可以根据自己app的风格去配置。

4. 还有第三方的使用。。。这绝对是所有写sdk人最愁的问题，像网络请求 json处理等几乎都像是约定好了的都是 AFNetworking JSONKit。人家app里几乎都会用到，所以 sdk最好是在这里的每个类之前加一个前缀，所以 sdk最好是在这里的每个类之前加一个前缀，所以 sdk最好是在这里的每个类之前加一个前缀，这将是一个浩大的工程。。。。这也是由于objective-c语言特性决定的，没有命名空间这一说法。

还有一个 最后的办法，但是也不推荐，毕竟sdk不是只为一家而做。在上一篇文章最后有提到。。传送门