前言

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

对 SDK 开发的看法

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

体积和功能

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

简短总洁一下：

体积上：小！小！小！

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

功能上：

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

兼容性

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

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

稳定性

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

所以：

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

安全性

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

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

文档规范

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

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

总结

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

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