Android SDK 设计规范与心得

从事 Andorid 八点多的开发，回想起来主要是以开发 SDK 为主，目前主要开发各种 APP 给公司各业务提供服务。想起之前分配给未毕业的同事开发语音交互 SDK 时他问的“SDK 设计有哪些规范”的问题，感觉有必要做一些整理。

SDK 开发规范肯定离不开设计模式和设计规范，还有一些是 SDK 通用的方法，以及 Android 平台特有的注意点。

设计原则

Android 应用程序的开发使用 Java 编写，在架构上使用 MVC，鼓励组件之间的弱耦合。开发出编写可重用、可扩展、可维护、灵活性高的代码需要遵循以下原则。

• “开—闭”原则（OCP）：一个软件实体应当对扩展开放，对修改关闭。这个原则说的是，在设计一个模块时，应当使这个模块可以在不被修改的前提下被扩展。换言之，应当允许在不必修改源代码的情况下改变这个模块的行为。

• 里氏代换原则（LSP）：一个软件实体如果使用的是一个基类的话，那么一定使用于其子类，而且它根本不能察觉出基类对象和子类对象的区别。

• 依赖倒转原则（DIP）：要依赖于抽象，不要依赖于具体。

• 接口隔离原则（ISP）：使用多个专门的接口比使用单一的总接口要好。一个类对另外一个类的依赖性应当是建立在最小的接口上的。

• 合成/聚合复用原则（CARP）：又称合成复用原则（CRP），就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。简而言之就是：要尽量使用合成/聚合，尽量不使用继承。

• 迪米特法则（LoD）：又称最少知识原则（LKP），是说一个对象应当对其他对象尽可能少的了解。狭义的迪米特法则是指如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类，可以通过第三者转发这个调用。广义的迪米特法则是指一个模块设计得好坏的一个重要的标志就是该模块在多大的程度上将自己的内部数据与实现有关的细节隐藏起来。信息的隐藏非常重要的原因在于，它可以使各个子系统之间脱耦，从而允许它们独立地被开发、优化、使用、阅读及修改。

SDK 通用规范

高内聚低耦合

参数合法性检测

对输入参数做合法性检测，保证健壮性。

接口向后兼容

有个比较痛苦的经历，是当时使用了腾讯的 ilivesdk，后面腾讯不在维护这个 SDK，升级了一个 TRTC SDK，但是呢，这两个 SDK 的多媒体通道不互通。这就让人恶心，我不升级吧，新功能以及旧问题怎么搞？升级把我还得依赖你两个 SDK，还要设计协商协议，而且你本身一个 SDK 就好几兆。这是一个需要引起我们重视的反面教材。

健壮性保证

健壮性是 SDK 的核心能力，要是你的 SDK 不稳定，经常崩溃或者出错，会给业务带来损失。

线程设计

要考虑到业务方多线程调用你方法的问题，所以要设计线程安全方法或者接口层的方法调用统一交给固定线程。

Android SDK 特有

sdk 资源统一前缀

上面提到的同事在开发过程中遇到一个问题，自己写的模块在自己的 Demo 程序中跑完全没有问题，但是集成到业务方的 APP 中，UI 页面的背景图就出错了，和自己设置的完全不一样。但是以为是什么兼容性问题，又有点忙，没有来的接帮忙看，他通过和业务方一起定位发现是资源重名了，导致使用了业务方的图片。这下找到问题了，赶紧把”SDK 中资源名要统一加前缀避免冲突“的原则讲解了一下。

最小化依赖

移动端开发对包体积的要求还是比较高的，包体积大了影响用户下载和体验。我们作为一个 SDK 提供服务，要尽量少的依赖第三方 SDK，因为这样不仅会增大包体积，而且会引发和业务 APP 依赖冲突等问题，所以我们尽量做最小依赖。