共计 3174 个字符，预计需要花费 8 分钟才能阅读完成。
一、前言
从事 Android 研发的工作有五年多的工夫了，最近两年多的工夫始终参加开发和保护神策数据 Android SDK[1]。两年工夫，从懵懵懂懂到略有心得，心愿通过本文介绍下 SDK 开发过程中的一些教训。期待对大家有所帮忙，更期待可能失去大家的领导。
正式介绍 SDK 开发教训之前，咱们先来答复两个问题：
1. 什么是 SDK？
置信做过 Android 研发的同学，对很多第三方的 SDK 应该不会生疏，例如：极光 SDK、支付宝 SDK、微博 SDK 等。SDK 的全称是 Software Development Kit，翻译过去是软件开发工具包，通常是为辅助开发某类软件而编写的特定软件包。
2. App 开发与 SDK 开发有什么区别呢？
App 开发偏差于用户层面，从 UI 展现到业务逻辑解决，全程解决用户的行为。而 SDK 开发偏差于性能方面，重视性能的开发实现，对于 UI 的设计与开发占比很少。
基于上述两个事实，咱们来看下 SDK 开发中的一些开发准则。
二、开发准则
2.1 根本准则
开发 SDK 中，最重要的一条根本准则是要尽可能的稳固，不能影响集成方的性能（例如：不能呈现 crash、不能呈现性能问题等）。
随着越来越多的客户应用 SDK，对于 SDK 的要求越来越高。一旦 SDK 引起了解体等问题，会对许多 App 造成灾难性的影响。因而，对于 Android SDK 的开发来说，要留神 try…catch 的应用、对象的查看等。
2.2 设计准则
在保障根本准则的前提下，开发 SDK 还存在一些通用的设计准则，上面咱们来具体介绍下。
首先，须要明确 SDK 的作用是为集成方提供一些性能。因而，要致力升高用户的上手难度，并且要易于了解。其次，要使 SDK 代码易于保护。
具体而言，次要概括为上面几点：
2.2.1. 接口易用性
对于接口次要留神两点：
1. 管制接口数量
置信大家在做 App 开发时，都已经埋怨过某个 SDK 真难用。一个 SDK 好不好用，要害就看接口的设计是否简略易用。对于集成方来说，并不会关注 SDK 的实现细节，能用一个接口实现的业务，坚定不必两个。
2. 留神接口命名
一个好的接口命名可能让调用者见名知意。如果可能做到不须要借助帮忙文档就能应用的水平，就阐明这个接口命名是胜利的。例如，对于 Android 中设置点击事件的接口 setOnClickListener。
2.2.2. 编码标准
对于 SDK 开发来说，对立编码标准很重要，最好的状态是集成方看到代码就能晓得是哪家厂商的 SDK。换句话说就是 SDK 的编码标准对立，造成本人公司的品牌效应，同时也不便集成方的应用。
对于编码标准，网上有泛滥厂商的标准模板。能够抉择其中一个或者自定义编码标准，尽早对立代码格调。
2.2.3. 跨端一致性
对于同一套 SDK，尽量放弃各端接口命名、实现逻辑的统一。在咱们的开发过程中，也呈现过因为跨端之间的逻辑有差别，导致客户在 Android 和 iOS 上体验不统一的问题，这会带来额定的反对工作。因而，对于波及到多个端的需要设计，肯定要进行具体的沟通和确认，防止出现接口命名和实现不统一的状况。
2.2.4. 防止依赖三方库
随着开源的遍及，GitHub 上有很多经典的三方库供开发者应用。对于开发者，会常常应用到三方库。例如：网络申请 OkHttp、图片加载 Glide 等。然而，在 SDK 的开发中，个别的准则是尽量避免应用三方库。次要有以下几点起因：
- 防止与集成方因为应用雷同的三方库引起的抵触，减少集成方的集成难度；
- 三方库会不断更新。如果引入三方库，则 SDK 须要及时放弃更新，会减少额定的保护工作量；
- 因为引入三方库，呈现问题时导致排查艰难。
2.2.5.“小”而“精”
SDK 尽量要做到“小”而“精”：
- “小”是指 SDK 的体积要尽可能的小。防止造成集成方的 App 体积减少较大，不然会引起集成方的不满，甚至下架 SDK；
- “精”是指性能要专一。例如：咱们的 SDK 是用于埋点，如果提供很多常见的工具类显然是不适合的。
2.2.6. 兼容性
兼容性是每个开发者都会遇到的问题。在 SDK 开发中更要保障新版本对于旧版本的兼容，常见的兼容性问题分为两类：
1. 新老接口兼容性
个别呈现接口兼容性的问题次要是因为最后需要思考不欠缺，导致前面进行计划优化时引起接口的变更，使之前的接口成为历史的难题，最终造成删除难度大。因而，性能接口设计要思考扩展性。
2. 新性能兼容性
这里的兼容性分为两个方面：接入新性能的 App 和未接入新性能的 App。
例如，当初咱们 SDK 适配 OAID 的计划时，因为须要应用 MSA 提供的集成包能力获取，然而在 SDK 中个别是不轻易集成一个三方库的。
因而，在设计这个计划时，就须要让集成方本人集成三方库，SDK 中提供获取的代码逻辑。最终在确定开发计划时，就须要思考到一部分集成方应用了该性能，须要保障该性能失常读取。一部分集成方没有应用到该性能，要确保无异样呈现。个别这种兼容性问题会决定开发计划的技术实现。
三、欠缺的文档阐明
3.1 接入指南
对于 SDK 的集成和应用、版本更新和接口介绍，肯定要筹备比较完善的用户接入指南。例如，咱们的 SDK 接入指南 [2] 分为：
- 根本应用 (Android)[3]
- 全埋点 (Android)[4]
- SDK API (Android)[5]
只管依据教训来看，有些开发者没有看文档的习惯。然而一份残缺的领导文档还是十分有必要，它能够节俭很多集成的老本和工夫。
同时，文档要留神正当的规划设计。防止一份文档内容太多，造成浏览艰难。对于应用性的局部，最好有示例代码进行展现。
3.2 测试报告
在理论的接入过程中，有很多集成方须要提供相干的性能测试阐明，这部分的内容须要及早准备。测试报告能够通过研发帮助测试进行输入，不便后续的反对工作，升高保护老本。
四、踩过的坑
4.1 不做臆想需要
在最后开发 SDK 时，常常会由客户的一个简略需要扩大为很多需要，导致最终减少了多个接口。只管看似 SDK 非常灵活，然而多进去的接口减少了很多保护老本。
例如，咱们做过一个开启 Fragment 名称采集的需要。客户提出的需要是通过文件配置，而后 SDK 进行读取，在施行的过程中就呈现很多臆想需要：
- 如果有别的客户不想通过配置文件，想应用接口怎么办；
- 如果用户想删除配置文件中已配置项怎么办；
- 如果客户想复原疏忽的配置怎么办。
这些臆想的需要，会减少很多额定的工作和交付老本，并且没有理论的意义。因而，在 SDK 开发中肯定要防止臆想的需要。
4.2 过多的接口
在 SDK 中常常会有很多初始化开关配置接口，这类接口个别是裸露 set 办法让用户去设置。通常在初始化时一次性配置，因而这类配置项个别就不须要提供 get 办法，防止接口太多。过多的接口会造成代码的保护成本增加，包含前期须要兼容的老本都会减少。
4.3 跨端一致性
对于 SDK 研发来说，常会遇到同一个需要须要在 Android、iOS 和 Web 三端同步实现，这就须要三端的研发和测试同学可能互相沟通，确保三端的逻辑实现统一。在这个过程中，最难把控的就是细节点的一致性。呈现细节不统一的问题，通常是因为测试 case 很难笼罩到，研发同学没有针对细节流程进行沟通交流而导致的。
因而，为了防止这类问题，对于细节点的计划实现能够让三端的研发同学互相进行沟通交流，争取在研发阶段把不统一的细节裸露进去，防止出现线上不统一的问题。
五、总结
本文是对 Android SDK 的设计准则和开发教训的一些总结，心愿通过本文可能抛砖引玉，和大家一起交换相干的开发教训。
参考文献：
[1]github.com/sensorsdata…
[2]manual.sensorsdata.cn/sa/latest/t…
[3]manual.sensorsdata.cn/sa/latest/t…
[4]manual.sensorsdata.cn/sa/latest/t…
[5]manual.sensorsdata.cn/sa/latest/t…
