iOS开发之SDK开发
最近工作需求都是开发SDK提供给Unity游戏端使用，由于很长一段时间没有进行SDK开发，很多细节都已经忘记了，此次又重新拾起来，并记录一下流程要点。
既然我们已经从零到一完成了 App 的开发工作，那这次不妨来看看 FinClip 移动端工程师整理的如何编写属于我们的第一个 SDK 吧！大家也可以回顾下 iOS 开发 App 的教程。
App 的开发更偏向于用户层面，从 UI 展示到业务逻辑处理，全程处理用户的行为。而 SDK 面向的是开发者，开发更偏向于功能方面，注重功能的开发实现。在今天的文章中，我们一起来聊聊设计 SDK 的那些事。
一、什么是 SDK?
SDK 全称 Software Development Kit，广义上的 SDK 是为特定的软件包、软件框架、硬件平台、操作系统等建立应用程序时所使用的开发工具的集合（在 iOS 项目中，SDK 也被称为库）。
在 iOS 开发或 Android 开发中，不可避免会需要使用第三方工具提升产品的开发效率，比如用于消息推送的极光，用于第三方支付与登录的支付宝，微信等等。但大多数商用产品都不会直接给出源码（可能只有为爱发电的开源项目才会无私提供源码），而我们在开发 App 时就需要将这些第三方 SDK 集成在我们的项目之中。简单来说SDK就是提供开开发者的一个工具，使其实现所需的功能。
二、SDK 设计的基本原则
一款好用且设计充分的 SDK 必须要遵循以下 4 条基本原则，即：
1、SDK 安全，稳定
2、统一的开发规范
3、Library 小而精
4、不依赖第三方 SDK
安全，稳定：考虑到 SDK 是需要嵌入到 App 里面去的，所以 SDK 最重要的特性就是安全性，不会因为乱开放接口而导致 App 数据泄露；其次重要的是 SDK 的稳定性， SDK 的 Crash 如果没有被捕获进行处理，则会导致应用彻底崩溃（这样就会导致第三方接入的 App 体验性非常差），甚至会直接导致接入方的用户流失；
统一的开发规范：对于 SDK 开发规范来说，统一的命名规范很重要，最好的状态是“接入方看到接口命名就能知道是哪家厂商的 SDK”，换句话说就是 SDK 的命名规范统一，形成自己公司的品牌效应，此外也方便开发者进行接入使用。此外也需要具有自己的编码规范，你可以在网上找到大厂的规范模板，并通过借鉴整理出属于自己的规范，从而尽早统一代码风格；
Library 小而精：小是指要避免造成接入方的App增加很大，不然会引起接入方的不满，甚至下架。精是指功能要专注，比如极光推送，就是专注推送相关的功能；
不依赖第三方 SDK：这个也很好理解，SDK 中如果又依赖其他第三方 SDK， 不仅会导致 SDK 的体积变大，也会影响接入方集成 SDK 的相关成本。
三、在 iOS 环境下开发 SDK
1. iOS 环境下的 SDK
如同上文所说，在 iOS 开发中，我们将 SDK 称为“库”，我们是这样对其定义的：
一般是给应用提供通用服务的，非独立运行的程序集合；
一般都是编译过的，方便使用。
我们会根据库的调用方法分为“静态库”和“动态库”两种：
静态连接：一般是指在创建应用程序的时候，将库集成进去，这样做的好处就是应用程序包自身可以独立运行，而不好的地方就是包会略显臃肿，库不能共享（静态库经常以 .a 结尾）；
动态连接：创建应用的时候只约定好与库之间的调用关系，而不彻底将库包集成进应用。这样在应用运行时，需要运行环境中提供库，并且连接装载。优劣与静态库相反，动态链接库需要库环境，但由于本身不集成库内容，会比较小，同时也为和其他应用共享库的使用提供了可能（常见的动态库是 Windows 下的 .dll，Linux 下的 .so，Mac 下的 .dylib/.tbd）。
特别注意：平时我们经常说的 Framework (in Apple) 是 Cocoa/Cocoa Touch 程序中使用的一种资源打包方式，可以将代码文件、头文件、资源文件、说明文档等集中在一起，方便开发者使用。也就是说我们的 Framework 其实是资源打包的方式，和静态库动态库的本质是没有什么关系。
2. 静态库和动态库的区别
如果说要找出静态库与动态库的区别，那可以从文件链接（每个源代码模块独立编译，然后按照需要将他们组装起来，这个组装模块的过程，就是链接）的角度进行解释：
静态库：链接时会被完整的复制到可执行文件中，所以如果两个程序都用了某个静态库，那么每个二进制可执行文件里面，都会含有这份静态库的代码；
动态库：链接时不复制，而是在程序启动后动态加载，然后再进行符号决议（符号绑定）。理论上动态库只存在一份就可以了。其他的程序都可以动态链接到这个动态库上面，从而节省内存（内存中只有一份动态库）。另外一个好处是，由于动态库并不绑定到可执行程序上，所以我们想升级这个动态库就很容易，windows和linux上面一般插件和模块机制都是这样实现的。
具体的优劣势可以看这张表：
image.png
3. 了解 iOS 的动态库（即被阉割的动态库）
有一个背景知识需要注意，iOS 官方规定不允许存在动态库，并且所有的 IPA 都需要经过 Apple 的私钥加密后才能用，即使你用了动态库也会因为签名错误而无法加载（越狱和非 App Store 除外）。于是这就把开发者自己开发动态库这件事变成为了天方夜谭。
iOS8 之前的 iOS 应用都是运行在沙盒当中的，不同程序之间不能共享代码，并且 iOS 又是单进程运行的（也就是某一时刻只有一个进程在运行），那么即使你写个共享库也无法共享给他人。
而动态下载代码又是被苹果官方明令禁止的，也就是说动态库的优势完全无法发挥，所以动态库也就没有存在的必要了。
但是这一切问题都随着 iOS8 发布之后的 App Extesion 特性， Swift 的诞生发生了奇妙的改变。
由于 iOS 主 App 需要和 Extension 共享代码，Swift 语言机制也需要动态库，于是苹果后来提出了 Embedded Framework，这种动态库允许 APP 和 App Extension 共享代码（动态库的生命被限定在一个APP进程内）。
更简单的解释：虽然提供了动态库，但这是被阉割的动态库。
尽管如此，这种动态库（Embedded Framework） 和系统的 UIKit.Framework 还是有很大区别的。传统的动态库是给多个进程使用的，而这里的动态库（Embedded Framework）是给单个进程里面多个可执行文件用的。
系统的 Framework 不再需要拷贝到目标程序中，我们自己做出来的动态库（Embedded Framework） 哪怕是动态的，最后也还是要拷贝到 App 中（App 和 Extension 的 Bundle 是共享的）。所以苹果没有直接把这种 Embedded Framework称作动态库而是叫 Embedded Framework。
上面提到的 Swift 也有原因，在 Swift 的项目中如果要在项目中使用外部代码，可选的方式只有两种，一种是把代码拷贝到工程中，另一种是用动态 Framework。使用静态库是不支持的。
这个问题的根本原因是， Swift 的运行库没有被包含在 iOS 系统中，反而会被打包进 App 中（这也是造成 Swift App 体积大的原因），静态库会导致最终的目标程序中包含重复的运行库。
4. 以动态库为例，开始制作SDK
第一步：创建 App 工程，命名为 WaterWold
image.png
第二步：关闭 WaterWold 工程，然后在 WaterWold 目录下创建 Framework 工程，命名为 WatherWoldSDK
image.png
第三步：设置 Framework 工程的 Build Settings
image.png
第四步：关闭WatherWoldSDK工程，创建 WorkSpace，命名为 WaterWold，或者直接pod，也会生成工作区间WorkSpace
image.png
第五步：连接 Framework 工程和 App 工程
我们需要先打开 WaterWold.xcworkspace，打开后你会发现这里空空如也。
然后我们直接把需要连接的 Framework 工程（WatherWoldSDK.xcodeproj）和 App 工程（WaterWold.xcodeproj）拖进来就可以了！
image.png
image.png
第六步：把 Framework 添加到 App 工程中
image.png
image.png
有过 SDK 开发经验的同学到这里应该已经看明白了，所谓实时联调说白了就是用 WorkSpace 把两个工程连接起来而已，跟 Pod 的原理有几分相似。
第七步：给 Framework 加点功能
我们需要增加一个 WatherWoldManger 类，定义一个 test 方法，实现里面打印一句话“吃饭了吗”。然后修改 WatherWoldManger.h 的 Target Membership 为 Public，意思为公开头文件。
image.png
WatherWoldManger的实现如下：
- (void)test {
NSLog(@"----吃饭了吗-----");
}
第八步：在 App 的 ViewController 调用一下 SDK 的方法
image.png
第九步：运行一下，可以发现App工程成功调用了SDK的方法
image.png
-
使用脚本合并真机、模拟器等多种架构的 Framework
第一步：添加一个 Aggregate Target
image.png
第二步：将 Aggregate Target 命名为“ WatherWoldSDK-Script”
image.png
第三步：依赖 WatherWoldSDK
image.png
image.png
第四步：添加脚本
image.png
image.png
这个脚本是通用的，各位同学直接复制粘贴即可：
# Type a script or drag a script file from your workspace to insert its path.
UNIVERSAL_OUTPUTFOLDER=../Framework/
# 创建输出目录，并删除之前的framework文件
mkdir -p "${UNIVERSAL_OUTPUTFOLDER}"
rm -rf "${UNIVERSAL_OUTPUTFOLDER}/${PROJECT_NAME}.framework"
# 分别编译模拟器和真机的Framework
xcodebuild -target "${PROJECT_NAME}" ONLY_ACTIVE_ARCH=NO -configuration ${CONFIGURATION} -sdk iphoneos BUILD_DIR="${BUILD_DIR}" BUILD_ROOT="${BUILD_ROOT}" clean build
xcodebuild -target "${PROJECT_NAME}" ONLY_ACTIVE_ARCH=NO -configuration ${CONFIGURATION} -sdk iphonesimulator BUILD_DIR="${BUILD_DIR}" BUILD_ROOT="${BUILD_ROOT}" clean build
# 定义真机、模拟器Build文件夹路径变量
IPHONE_BUILD=${BUILD_DIR}/${CONFIGURATION}-iphoneos/${PROJECT_NAME}.framework
SIMULATOR_BUILD=${BUILD_DIR}/${CONFIGURATION}-iphonesimulator/${PROJECT_NAME}.framework
# 拷贝framework到univer目录
cp -R "${IPHONE_BUILD}" "${UNIVERSAL_OUTPUTFOLDER}/"
#cp -R "${SIMULATOR_BUILD}" "${UNIVERSAL_OUTPUTFOLDER}/"
# 定义输出路径变量
OUTPUT_PATH=${UNIVERSAL_OUTPUTFOLDER}/${PROJECT_NAME}.framework
# 合并framework，输出最终的framework到build目录
lipo -create "${IPHONE_BUILD}/${PROJECT_NAME}" "${SIMULATOR_BUILD}/${PROJECT_NAME}" -output "${OUTPUT_PATH}/${PROJECT_NAME}"
第五步：运行脚本
image.png
第六步：查看结果
image.png
本人在开发过程中实验过，“5. 使用脚本合并真机、模拟器等多种架构的 Framework”这一步可直接省略，可直接选择真机运行SDK，可直接生成Framework
6. 小贴士
- Framework 中使用 Category
在 Framework 工程的 Build Setting 中添加 -ObjC。另外，使用我们 SDK 的 App 的 Build Setting 中也要添加 -ObjC。 - Framework 支持 bitcode
如果正确按照教程，那相信你已经成功的做出了属于自己的第一个 iOS SDK，本期教程依然基于 mac 电脑进行实现，如果你的电脑是 Windows 或者其他操作系统，还需要进行一些其他的灵活配置。
