前言
目前我们所开发SDK的目的是为了流程简化的同时,保证数据逻辑安全;说到底,我们就是为了要让流程变简洁而已。但随着这些年所开发出来的SDK,不断的经由客户的考验和反馈;越发觉得开发SDK的工作前期设计部分非常重要,因为每一版所发布的SDK,在接口上不能产生太大的变化,为了让SDK有更好的兼容性,我大概总结了下面的一些方法。
1、提供全能类型的初始化方式
这个方法是我在Objective-c的一些优化语言中找到的,因为我们所设计的接口是基于开发者的角度,所以初始化最好提供全面的初始化方法。
需要尽量提供可能会用到的所有接口,这样有助于二次开发(当然这些事情是不可以一步到位的)
- (instancetype) init {
if (self = [super init]) {
[self commonInit:6];
}
return self;
}
- (instancetype) initWithFrame:(CGRect)frame {
if (self = [super initWithFrame:frame]) {
[self commonInit:6];
}
return self;
}
-(instancetype)initWithFrame:(CGRect)frame withCount:(int)index{
self = [super initWithFrame:frame];
if (self) {
[self commonInit:index];
}
return self;
}
-(instancetype)initWithFrame:(CGRect)frame withCount:(int)index withType:(int)type{
self = [super initWithFrame:frame];
if (self) {
[self commonInt:index with:type];
}
return self;
}
2、对象多使用不可变对象
这个是需要看情况而定的,但是对于封装的类对象,尤其是用于数据操作类的,建议尽量创建使用不可变的对象,如果想支持可操作的属性,可以提供方法来实现修改属性。
3、使用前缀命名来避免冲突
在使用到更多的类库以后,就更容易出现名字相同的冲突,尤其是在一些功能性相仿的类,我们之前写过的DV12的类库和DFUnit还有最新的DV16的库就存在过冲突,通常这类冲突在编译的时候就能检索出来。
为了避免这种情况,我们可以通过以下的方法来实现:
- 命名的引申义:通过类的功能可以使用驼峰法来命名,但功能总有相似性,于是我们可以使用公司前缀或者简称等来命名类以及类方法
- 第三方库的引用:对于我们引用的第三方库的引用,我们通常也能发现他们具备了自己独特的类命名方式,而这个时候,我们要做的就是保留他们原有的名字,这不仅仅是避免命名冲突的问题,更多的是对原作者的尊重。
- 为私有类提供前缀:对于私有不开放的类,我们也可以通过前缀的方式来做区分,这样有利于我们在发布或者打包的时候有效区分那些是私有的,那些是应该公布出去的。
4、API的层级处理
SDK是应该具备层级架构的,这不仅仅是功能性的体现,更是一个库的核心所在,如果层级架构做得好,那么在二次开发的时候就能避免很多的问题,逻辑也变得更加的清晰,每个层级关系的嵌套要清晰。
- 通过类别或功能来进行层级划分
- 关于内部流程的控制
因为SDK的工作本来就是需要将复杂的流程封装起来,让二次调用的人更简单、更方便的去使用,但是我们的SDK并不是一次开发不需要后期维护的,所以为了以后的维护和方便些,我们需要对涉及业务流程的流程图和相关逻辑记录下来,可以通过类内部的注释或者流程图的方式来记录。
另外流程也需要独立性高一点,尽量提高一些简单流程的复用性,避免整个SDK的库非常臃肿。
5、错误结果的处理
由于SDK是给开发者二次开发的,所以log记录很重要,它可以在第一时间替我们找到问题的发生点,为此我在SDK中添加了Log打印的等级控制,方便控制打印,还有一个就是需要对这些打印内容保存,保存在文件里,当出现问题的时候就可以翻出来查找问题所在了。
错误内容的反馈还不局限体现在打印上,也可以通过增加错误码列表,来分析定位问题。
6、SDK中消息的传递
我们的SDK涉及到较多的数据交互,这些是不能局限于库的内部,还要通过协议上传给上层,让二次开发更加清晰、简单的获取到所需的数据,目前iOS上的消息传递大概分为以下几种,我们可以根据他们的优缺点来进行选择,当然最好在设计接口的时候能够考虑到都用上。
传递方式 | 优点 | 缺点 |
---|---|---|
Delegate:代理 | 数据回调属于类对象拥有内容,数据回调高效可靠,可实现多个函数来回调不同数据内容 | 局限于当前类,如果要多个类之间传递,实现起来的代码会非常臃肿 |
block:代码块 | 轻量级的回调,代码简洁,逻辑清晰 | 容易造成循环引用,临时性;代码块存放在堆栈上,容易造成内存泄露 |
KVO:观察者 | 提供了简单的实现两个对象同步属性的方法,能对非我们创建的对象进行状态监听,不需要高边内部对象 | 观察属性比较单一,适用的场景较少 |
NSNotification:通知 | 整个APP内都可以监听这个通知消息,属于ARC,不用管理内存问题 | 需要配对remove使用,会导致多处接收,多处处理,代码整体架构处理很混乱 |
整体的脑图如下: