对 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 有本身的生命系统，但它依旧服务于业务、生存于业务、发展于业务，它是业务不可或缺的一部分。