对 Android SDK 开发的一些个人心得

自从工作以后，大部分时间都是参与 Android SDK 方面的开发工作，满打满算也有两年时间了，多多少少有点心得体会。之前偶然在脉脉上回答了一个“APP 开发和 SDK 开发有什么区别”的问题，前几天又有朋友问到了类似的问题，所以我总结了一下，算是个人心得吧。不过，毕竟我工龄不长，可能理解有不到位的地方，还请谅解！

对 SDK 开发的看法

SDK 开发和 APP 开发的区别还是很大的。APP 更倾向于用户体验、功能更偏于特定业务、讲究的是快速迭代、快速占领市场。而 SDK 是为 APP 服务的，提供的大多是公共基础服务，如网络请求、打点统计、帐号服务等。下面从几个点说说我的看法。

体积和功能

可以用三个字形容：小而精。 小 是指包的体积要尽可能的小，因为业务方接入的时候可能会有这样的抱怨：怎么接了你们的 SDK 后 APP 的包体积涨了好几 M 啊？会降低下载率的...（嘤嘤嘤...）。 精 针对的就是 SDK 的功能了，一定要专注于特定功能，舍弃那些自以为是的需求。要相信多变的业务方一定会反馈新需求的，到时候再对 SDK 的功能进行补充即可。

简短总洁一下：

体积上：小！小！小！

1. 去除无用资源（主要是图片和 so 库）和代码；
2. 不要依赖第三方库，至少大体积的库是不可以的，可以考虑移植开源代码（只需移植关键代码，有必要的话根据 SDK 特性做适当修改）；
3. 优化代码结构，去除冗余的代码逻辑（考虑各种 设计模式 和分包策略）；
4. 打包时进行混淆优化；

功能上：

1. SDK 讲究功能专一，去除那些花里胡哨的东西；
2. 基本功能完善，适用于所有的业务线；
3. 根据业务方的需求反馈，考虑优化或者丰富 SDK 功能；

兼容性

SDK 的兼容性主要考虑几个方面：

1. 对外接口（ API ）的兼容性：每次版本更新后，对外接口要尽可能保持不变。对于更改较大的接口，可以使用 @Deprecated 注解对老接口进行标记，并且做新接口调用的兼容，而不是直接删除老接口。
2. 功能的兼容性：在不影响整体功能和项目结构的基础上提供部分业务的需求定制化，可以形成配置项（相信我，业务方肯定会提一些乱七八糟的需求的，咱惹不起，只好提供配置项了...）。
3. 如果部分业务较难适配，那只能新开 SDK 分支，做业务的定制化版本（尽量不要这么干，可以和业务商量，因为分支太多后期很难维护）。
4. SDK 支持的 Android 版本的兼容性：minSdkVersion 的值应该尽可能的小，当然现在市场上基本都是 4.4 以上的手机了。这也从侧面要求不要随便依赖第三方库。

稳定性

SDK 极其注重 稳定性 ，要保证在不同 APP 环境下都能正常工作。如果出现问题就会导致发新版本，一方面要通知所有业务方做版本更新（这是一件很麻烦的事），另一方面会打乱业务方 APP 的版本更新安排（这个锅背定了...）。

所以：

1. 版本迭代要稳定：一般版本号都采用 x.y.z 模式，对于小功能或者是小的修复，增加 z 值即可，不能影响已经上线的服务。
2. 对于大版本的改动，增加 y 值甚至 x 值后，需要让 PM 告知业务方下次发版时使用最新版本的 SDK （如果是大 BUG 的修复，那就必须强制要求业务方更新了）。
3. SDK 上线前必须经过完整的测试流程，保证功能正确、性能达到要求、对不同机型进行适配、对不同 Android 版本进行适配。业务方接入后，可以让业务方也走一遍测试，提供反馈报告。
4. SDK 的结构设计应该要有好的扩展性，比如接入一个新功能，就不能影响整体的代码框架，否则可能造成一些潜在的威胁，也会增加测试的工作量。

安全性

不光是 APP 需要一些安全措施，SDK 也是有必要保证安全性的。

1. SDK 混淆、加固、安全审核，这个一般是公司级别的安全管控。针对安全报告做对应修复即可。
2. 隐私数据的保护，必须进行加密或者掩码处理。比如：本地保存用户的登录态，手机号的掩码显示等。
3. 网络请求时的数据加密保护，部门一般都有自己的加密机制，大部分都是模仿 ssl 握手协议，采用非对称加密和对称加密结合的方式。更严格的话，可以增加自定义证书校验，不过这个成本较高。
4. 对于 SDK 中接入的部分第三方功能或者服务需要提供云控机制。因为第三方服务存在不稳定性和弱安全性。

文档规范

这个是被广泛忽视的一点，文档真的很重要！文档真的很重要！文档真的很重要！

1. SDK 的最终形态中一定要包含接入文档和演示 Demo 。虽然大部分业务方都不看文档，但你一定要写（至少甩锅的时候好甩...）。至于演示 Demo ，一定要考虑尽可能多的场景，把 SDK 的功能都展示出来。
2. 文档要尽可能详细，但最好不要把所有内容都集中在一个文档里面，这样导致文档过长，业务方更加反感阅读。可以对文档做细划，比如：如何接入（jar、aar？或者是离线包还是 maven 库？）、基本功能如何使用（大部分业务只需要基本功能）、定制化功能如何使用、接入中可能遇到什么问题、怎么解决这些问题等等。
3. 最好能有个 Web 页面的服务平台（类似开放平台），业务方可以直接在平台上进行应用的注册、管理、文档阅读等。服务平台也可以做一些数据统计的可视化，方便 SDK 的后续发展。

总结

以上就是我目前对 SDK 开发的一些心得体会了，大家有其他想法可以交流交流。至于 APP 开发，本人经验不足就不献丑了。

总的来说，SDK 有自己的生命系统，但它依旧服务于业务、生存于业务、发展于业务，它是业务不可或缺的一部分。