iOS SDK的API接口设计

前言

目前我们所开发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是应该具备层级架构的，这不仅仅是功能性的体现，更是一个库的核心所在，如果层级架构做得好，那么在二次开发的时候就能避免很多的问题，逻辑也变得更加的清晰，每个层级关系的嵌套要清晰。

• 通过类别或功能来进行层级划分

API的层级处理.png

• 关于内部流程的控制

因为SDK的工作本来就是需要将复杂的流程封装起来，让二次调用的人更简单、更方便的去使用，但是我们的SDK并不是一次开发不需要后期维护的，所以为了以后的维护和方便些，我们需要对涉及业务流程的流程图和相关逻辑记录下来，可以通过类内部的注释或者流程图的方式来记录。

另外流程也需要独立性高一点，尽量提高一些简单流程的复用性，避免整个SDK的库非常臃肿。

5、错误结果的处理

由于SDK是给开发者二次开发的，所以log记录很重要，它可以在第一时间替我们找到问题的发生点，为此我在SDK中添加了Log打印的等级控制，方便控制打印，还有一个就是需要对这些打印内容保存，保存在文件里，当出现问题的时候就可以翻出来查找问题所在了。

错误内容的反馈还不局限体现在打印上，也可以通过增加错误码列表，来分析定位问题。

6、SDK中消息的传递

我们的SDK涉及到较多的数据交互，这些是不能局限于库的内部，还要通过协议上传给上层，让二次开发更加清晰、简单的获取到所需的数据，目前iOS上的消息传递大概分为以下几种，我们可以根据他们的优缺点来进行选择，当然最好在设计接口的时候能够考虑到都用上。

传递方式	优点	缺点
Delegate：代理	数据回调属于类对象拥有内容，数据回调高效可靠，可实现多个函数来回调不同数据内容	局限于当前类，如果要多个类之间传递，实现起来的代码会非常臃肿
block：代码块	轻量级的回调，代码简洁，逻辑清晰	容易造成循环引用，临时性；代码块存放在堆栈上，容易造成内存泄露
KVO：观察者	提供了简单的实现两个对象同步属性的方法，能对非我们创建的对象进行状态监听，不需要高边内部对象	观察属性比较单一，适用的场景较少
NSNotification：通知	整个APP内都可以监听这个通知消息，属于ARC，不用管理内存问题	需要配对remove使用，会导致多处接收，多处处理，代码整体架构处理很混乱

整体的脑图如下：

iOS SDK的API接口设计.png