前言
最近用到了一些 SDK，本来是为了 A 功能引入的，没想到它依赖了 B、C、D 等不相干的 SDK，B、C、D 又依赖了 E、F、G……前前后后总共引入了将近 20 个 Framework，简直就是个“全家桶”。
本文打算从我个人的角度谈一下，一个合格的 iOS SDK 应该是什么样的。
一、依赖
1. 不要大量依赖其他的第三方 SDK
首先，现在的移动 APP 普遍有包体积过大的困扰，如果只是为了省几行代码就贸然地引入第三方 SDK，会导致包越来越大。
其次，如果是商业项目，当以稳定为先。多一个依赖就多一份风险，尤其是那些没有经过严格测试过的。
2. 不要把依赖写在 podspec 里
Cocoapod 虽然很方便，但是很容易引发“依赖地狱”问题。
假设有一个第三方库 A，团队根据自己的业务定制了一个本地版本。但是在引入第三方库 B 时，podspec 写了对 A 的依赖。pod install 后，很有可能就混乱了。
这时，不如在文档里写清楚，让使用者根据自己的情况自己在 Podfile 里添加依赖。
3. 不要强制依赖，留有余地
比如，你的 SDK 需要实现网络连接，不要在代码里写死了用 AFNetworking 之类的库，万一使用者不想用呢？
相反，我觉得以下方案是比较靠谱的：
- 根据场景，留下接口，让使用者自己实现相关功能。比如，很多场景下，上传的数据需要加密、或者使用一些特殊的上传格式，没办法在 SDK 里写死。
- 分割功能，做好替代方案。比如，把上传功能分割开，独立放在一个库中，并提供多种实现方式，加密的、不加密的等等，使用者可以根据自己的情况灵活选择。
4. 合理拆分，每个 SDK 只干一件事
比如某著名“统计分析 SDK”，在提供打点功能的同时还顺便做了 Crash 收集。做的好也就罢了，就收集了那么点的崩溃信息还好意思拿出来？
二、SDK 加载
1. 不要滥用 +load、+initialize 等所谓的“黑魔法”
几乎没有什么操作是非得用“黑魔法”实现的，那些方法除了拖慢启动速度、搞出一些莫名其妙的问题，没有其他的作用。
2. 让使用者自己决定 SDK 的加载时机
比如 [XXXSDK start]; 就很好。
3. 提供 SDK 卸载的方式
启动之后，不要逼着用户用黑科技的方式才能让你的 SDK 停下来。
4. 三行代码之内完成 SDK 初始化
争取在三行代码之内完成最常用、最基本的 SDK 功能初始化，不要拖泥带水。
5. 提供丰富的配置
这点见仁见智，我是觉得越丰富越好，给高级用户足够多的选择。
三、代码
1. 不要存在 Warning
原本以为这是个人人皆知的准则，然而并不是。。。
2. 命名加前缀
同上。
3. 不要滥用 method swizzling
很多人对自己的实力过于自信了，swizzle 系统库的时候完全没想到自己的代码有多烂。
4. 不要滥用“黑科技”
作为 SDK，当以稳定为主。不要为了炫技，或者是为了达到某种不可告人的目的，而滥用各种所谓的“黑科技”。
5. 要正规
比如：
- 规范一下头文件里的文档、说明、作者、Copyright 等。
- 如果 SDK 比较高级，提供了证书啥的，不能草率地弄一个就放在里面，比如某微博 SDK。
- 如果只提供二进制的 SDK，把静态库里面的调试信息给删掉吧。
6. 提供除了 Cocoapods 以外的安装方式
比如，提供一个打包好的 Framework，使用者拖进来就能用。