在开发Android应用时，我们需要用到Google提供的SDK。当我们的开发的某一个模块足够通用也可以封装成SDK给其他业务方使用。什么是一个良好的SDK类产品？站在开发者和接入方的角度我认为应该满足以下几点：

对于开发者 #

• 良好的可维护性
• 设计合理、可扩展性强
• 代码逻辑清晰合理
• 监控及数据打点完备

对于接入方 #

• 集成简单，最好一行代码搞定
• 接入文档，接入实例详细
• 崩溃率低、内存占用小、SDK尽量小
• 出现问题及时响应解决

以上总结起来就是对开发者友好、对接入方友好。当别人接手代码没有砸键盘的冲动甚至想和你干一杯82年的雪碧。当业务方接入你的SDK时感到神清气爽。下面总结一下本人在开发过程中总结的一些点，抛砖引玉，共同探讨。

注意点 #

1、熟悉你的代码 #

这个放在第一条，是每个人要对自己的代码逻辑负责。

2、合理的接口设计 #

接口设计尽量简单，尤其是对业务方来说，没有那么多时间研究你的方法。接入越简单对业务方成本越低。

3、内存分配与回收 #

申请合适的内存，如果数组只放10个数据，就没必要申请20个空间大小。不用的资源及时回收。对于有多个进程的应用，要考虑是否有必要在每个进程都初始化SDK。

4、慎重选择第三方库 #

本身我们要做的就是一个SDK类的产品，尽量不使用第三方库。因为它会增大我们SDK包的大小。如果必须要使用，要选择稳定的第三方库，同时需要注意第三方库冲突的问题。你的接入方可能也依赖了这个第三方库，甚至和你的版本不一样。这时有两种选择，在你的SDK中以provided的方式依赖。二是修改第三方库的包名以解决冲突（这样会增大最终应用的大小）。关于修改包名可以使用jarjar.jar。可参考 这篇文章

5、ContentProvider authorities 冲突导致应用无法安装 #

<provider
    android:name="com.democome.SPContentProvider"
    android:authorities="com.democome.sdk.sp"
    android:exported="false"
    android:process=":push" />

像上面这样，如果多个应用接入了我们的SDK，那么第二个安装就会出问题“应用组件的命名与已安装应用有冲突”，导致第二个应用无法安装，正确的做法是authorities和包名相关，如下：

<provider
    android:name="com.democome.SPContentProvider"
    android:authorities="${applicationId}.sdk.sp"
    android:exported="false"
    android:process=":push" />

6、异常处理和日志 #

什么样的异常自己处理，什么样的异常抛给业务方。我认为如果是业务方接入问题导致的异常，可以给业务方抛出异常。某些流程的关键环节打印出日志，当然这个日志是个可以开关的。

7、多进程操作SharedPreferences #

多进程操作SharedPreferences是有问题的，尽管SharedPreferences有一个MODE_MULTI_PROCESS模式，但这个模式也是不靠谱的，在一个进程中修改SharedPreferences中的值，另一个进程不会同步更新。解决办法是可以通过ContentProvider进行进程的同步操作。

8、安全问题 #

本地拒绝服务漏洞，getIntent()的intent附带空数据、异常或畸形数据，会导致应用崩溃。解决办法需要加try catch。

9、打包管理 #

规范的打包管理系统，版本的管理，发布的管理等。

10、aar资源名称 #

aar中资源的名字加上一个前缀避免引用错误。

11、混淆 #

这个仁者见仁，有些大名鼎鼎的SDK都没有混淆。

12、内存泄漏 #

用leakcanary检测，不要有内存泄漏。

13、打点统计 #

SDK有良好的运行时监控机制，在某些关键地方以及崩溃打点上报，及时获取SDK运行状态，保证运行时稳定。但是打点也不能太频繁，避免对业务方业务造成影响。

14、特定机型适配 #

这点没什么好说的，其实也是最坑的，各种乱七八糟的坑需要填。