Android SDK开发4之心得体会

目录

一、 前言

二、SDK分类

1.SDK简介

2.SDK 分类

三、SDK 设计

1 .核心原则

2.SDK 设计原则

3.接口易用性

4.命名规范要统一

5.跨端接口尽量保持一致

6.尽量不依赖第三方库

7.SDK 包尽量小

8.兼容性

9.混淆与加密

四、集成

1.SDK 集成

2.集成指南

3.完备的测试报告

五、SDK合并

六、SDK维护

最近做了一年左右的sdk开发，感觉很有意思，遇到了很多问题，也学到很多知识，设计模式和代码构架思想有一定提高，所以在此总结一下。

一、 前言

主要想通过这篇总结简要介绍下 SDK 开发过程中的一些经验

二、SDK分类

1.SDK简介

什么是 SDK相信做 Android 开发的同学，肯定使用过很多第三方的 SDK， 比如极光 SDK、支付宝 SDK、shareSDK等等。所谓SDK 就是一个开发工具包，全称是 Software Development Kit，翻译过来是软件开发工具包。SDK 通常是为辅助开发某类软件而编写的特定软件包。

App 开发与 SDK 开发的工作有什么区别呢？App开发更偏向于用户层面， 从UI展示到业务逻辑处理，全程处理用户的行为。 而SDK开发更偏向于功能方面，注重功能的开发实现，轻 UI。

2.SDK 分类

目前来说，并没有统一的、官方的文档定义 Android 应用开发中常见的 Library、API、SDK 以及 Framework 这些概念。我们基于其字面意思以及日常使用习惯做如下的解释：

Library 

Library 是一组或几组类的集合，可以直接调用，使得开发更高效。Library往往是对系统已有功能的增强或是对应用程序架构中功能模块的具体实现。比如 Android SDK 中提供的 Support Library，著名的开源项目如 Volley 、Picasso、Android-Universal-Image-Loader 。 

API 

API即 Application Programming Interface，也就是软件系统不同组成部分（模块）衔接的约定。由于软件的规模日趋庞大，常常需要把复杂的系统划分成小的组成部分，API 的设计就显示尤为更要。良好的程序设计实践中，API 的设计首先要使软件系统的职责得到合理的划分，降低系统各组成部分的相互依赖，并提升组成单元的内聚性，从而提高系统的可维护性以及扩展性。

 SDK SDK即 Software Development Kit，广泛意义上的 SDK 一般都是为特定的软件包、软件框架、硬件平台、操作系统等建立应用程序时所使用的开发工具的集合（系统 SDK）。而狭义上的 SDK（应用 SDK） 则是基于系统 SDK 进行开发的新的、独立于具体业务且完成特定功能的一组工具的集合。例如友盟统计 SDK、极光推送 SDK、Share分享SDK。 

Framework

 Framework 是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法。另一种定义认为，Framework是被应用开发者定制的应用骨架。可以说，一个 Framework 是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类（或接口）以及其实例之间的协作方法，它为构件复用提供了上下文（Context）关系。

三、SDK 设计

1 .核心原则

核心原则：稳定、简洁、高效、灵活。

一旦 SDK 的出现引起崩溃的 bug，这将对众多 App 造成灾难性的影响，如果出现这种情况，是非常致命的. 以对于 Android SDK 开发来说，要注意 try...catch 的使用、对象的检查等等。

2.SDK 设计原则

首先需要明确，一方面，SDK的价值是给调用者带来价值。 要努力降低用户的上手难度，易于理解。另一方面要时 SDK 代码易于维护。

3.接口易用性

3.1做 App 开发时，我也抱怨过XX 的 SDK 真难用。一个 SDK 好不好用，关键就看接口的设计是否简单易用， 对于接入方来说他不会关注你的实现细节，能用一个 API 接口搞定的业务，坚决不用两个。注意控制接口的数量。

3.2另一方面，注意接口的命名。 一个好的 API 接口的命名能够让调用者见名思意，做到不需要借助帮助文档就能使用的程度就说明这个接口命名是成功的。 比如对于 Android 中设置点击事件的接口 setOnClickListener。

4.命名规范要统一

对于 SDK 开发来说，统一命名规范很重要，最好的状态是

接入方看到接口命名就能知道是哪家厂商的 SDK。 换句话说就是 SDK 的命名规范统一，形成自己公司的品牌效应。 同时也方便接入方使用。

对于编码规范，网上都有各个大厂的规范模板， 可以选择其中一个或自定义自己团队的规范，尽早统一代码风格。

5.跨端接口尽量保持一致

对于同一套 SDK，尽量保持各端接口命名、实现逻辑要一致。 在我们的开发过程中，也出现由于跨端之间的逻辑有差异导致客户在 Android 和 iOS 上体验不一致的问题，同时也会带来额外的支持工作。所以对于涉及到多个端的需求设计，一定要进行详细的沟通和确认，

防止出现接口命名和实现不一致的情况。

6.尽量不依赖第三方库

随着开源的普及，GitHub 上有很多经典的开源项目供开发者使用。 对于App开发者，会经常使用到开源项目，比如网络请求 OkHttp、图片加载 Glide 等等。

但是在 SDK 的开发中，一般的原则是尽量避免使用开源项目库。主要有以下几点原因：

原因是为了避免与调用方由于使用相同的库引起的冲突， 增加调用方集成的工作量，降低集成方的体验。 开源库的不断更新，所以 SDK 需要及时保持更新，会增加额外的维护的工作量。 由于引入开源库，出现问题排查困难。

7.SDK 包尽量小

SDK包一定要小而精。

小是指包的体积要尽可能的小。 避免造成接入方的 App 增加很大，不然会引起接入方的不满，甚至下架。

精是指功能要专注。 比如我们的 SDK 是用于埋点的，那里面设计提供很多常见的工具类显然是不合适的。

8.兼容性

兼容性是每个开发者都会遇到的问题。在 SDK 开发中更要保证新版本对于旧版本的兼容。常见的兼容性问题分为两类。

新老接口兼容

一般出现接口兼容性的问题主要是由于最初需求考虑不完善，导致后面进行方案优化时引起接口的变更，使之前的接口成为历史的老大难问题，最终造成删除难度大。

新功能兼容性

这里的兼容性问题分为两个方面：

a.系统版本的兼容：比如AndroidX和Android support

b.功能接口的兼容：当接口发送变更或接入新的api功能接口时，要保留原有的功能和逻辑，不用引起崩溃，在接到一个新功能需求时更换一个新的框架或方案。

9.混淆与加密

9.1 混淆

sdk混淆和app混淆规则类似，如果没有第三方类库，只需要混淆一些基本的类、方法即可.

9.2 sdk加密

加密方式有MD5、Base64、AES、RES等，app负责加解密接口，服务器验证加密的内容，

添加用户鉴权机制，定义加密规则等。

9.3 so加密

这种方式把加密的key、密钥、规则都放到so里面，动态校验，这种方式比较麻烦，目前还没深入接触。

四、集成

1.SDK 集成

集成方式要多样同时灵活方便。比如对于 Android 来说，我们提供通过 maven、gradle 依赖引入等方式，也是推荐的集成方式。但是对于一些接入方由于网络的限制，无法直接依赖 maven，这里就需要提供 aar 包或源码来集成。

2.集成指南

对于 SDK 的集成和使用，以及版本更新内容和 API 接口介绍，一定要准备比较完善的用户接入指南。比如我们的 SDK 接入指南分为：

基本使用 常见问题 高级应用 插件配置 ...... 尽管根据经验来看，有些开发者没有看文档的习惯，但是一份完整的指导文档还是非常有必要，它可以节省很多集成的成本和时间。

同时文档要注意合理的规划设计，避免一份文档内容太多，造成阅读困难。对于使用性的部分，最好有示例代码进行展示。

3.完备的测试报告

在实际的接入过程中，有很多接入方需要提供相关的性能测试说明，这部分的内容需要及早准备。测试报告的工作可以研发和测试一起协助进行输出，最终方便后续的支持工作，降低维护成本。

五、SDK合并

当接入一个新sdk,然而公司也有自己的sdk,如果需要把两个业务合并成一个，这时就需要aar合并，目前有fataar、gradle、命令行、手动合并四种方式。

六、SDK维护

1. 开发接口需要灵活动态配置，易于扩展

1.在最初开发SDK时,经常会由客户的一个简单需求扩展很多需求，导致最终增加了多个接口,尽管看似SDK非常灵活，但是多出来的接口增加了很多维护成本。

2.如果有别的客户不想通过配置文件，想使用接口怎么办？ 如果用户想删除配置文件中已配置项怎么办？ 如果客户想恢复忽略的配置怎么办？ 这些想太多的需求，会增加很多额外的工作和交付成本，所以在 SDK 开发中一定要避免想太多的需求。

3. 配置项不提倡提供读取方法

在 SDK 中经常会有很多初始化开关配置接口，这类接口一般是暴露 set 方法让用户去设置，常见在初始化一次性配置，所以这类配置项一般就不需要提供 get 方法，防止接口太多。

4.总结：以上就是今天的sdk开发心得，其实sdk开发涉及的东西很多，这里只是冰山一角，后面会陆续出一列的文章，如有问题，及时提出，一起改正。