sdk接口设计
sdk接口设计应该遵循单一职责原则、迪米特（最少了解）法则、开闭原则（对扩展开发、对修改关闭）等。
1.1 对外接口类只有一个，使用Facade设计模式，通常是单例类，命名可以是xxxApi.java
1.2 接口方法参数不宜过多，超过5个应该封装成类对象传递
较典型的是sdk初始化方法，参数较多时，封装的参数类应使用Builder设计模式，既防止外部传入后再修改，也便于扩展
1.3 接口参数应进行有效性校验，尽量把问题暴露在接口方法执行入口
1.4 接口方法应尽可能少
1.5 每个方法应该只做一件事情。这个要求和1.4有时会产生冲突，需要衡量抉择。
1.5 接口方法之间应尽可能减少依赖，比如调用B接口前，要调用者保证已经调用过A接口。对sdk.init方法的依赖，可以除外。
如必须有，应加以详细注释，并尽可能早地暴露问题。
1.6 不能出现这样的调用次序依赖：Facade接口类方法，必须在sdk内部某个事件被触发（或内部方法被调用）后，才能调用，否则报错。
1.7 应减少对接口方法的调用要求，并详细注释调用要求。比如某个方法必须在UI线程执行
1.8 如有监听回调，应详细注明回调的线程是UI线程还是子线程，或者让调用者可选执行线程
1.9 所有接口方法，应检查其执行耗时，确保高效
1.10 新版本的接口要尽可能地兼容旧版本

sdk框架设计
框架设计主要考虑几个点：
2.1 通常要3层设计：界面、业务逻辑、数据管理，3者要分开，降低耦合
2.2 数据存储：
要考虑是否要求多进程数据共享
尽可能不要在UI线程执行IO
JSON数据不能存储在sharepreference里，应每个JSON单独存文件
share preference提交数据，优先使用apply方法，而不是commit。
2.3 使用通用线程库管理线程

性能等相关
3.1 尽量不要持有客户端传入的Actvity，使用ApplicationContext
3.2 一般情况下，客户端设置的监听，应该有配套的注销监听接口。
如业务要求随时可发送事件给客户端，可以使用广播
3.3 灭屏时，如非必要，不应唤醒屏幕或后台进行业务处理
3.4 sdk发送广播，其Action应该加上应用包名，以区分接入同一sdk的不同应用。
3.5 sdk内声明provider，其authorities应该加上应用包名，以区分接入同一sdk的不同应用。

<pre style="margin: 10px 0px 0px;"> android:authorities="com.gto.zero.zboost.commerce.MPSharedPreferences"</pre>

sdk权限
应尽可能少用权限，尤其是敏感权限。只有以下权限是无需考虑的：

<pre style="margin: 10px 0px 0px;"><uses-permission android:name="android.permission.GET_TASKS" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.MOUNT_UNMOUNT_FILESYSTEMS" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" /></pre>

代码规范
5.1 sdk代码应都在同一个package之下，除了引入的第3方sdk
5.2 res/下的所有资源文件，应统一名称前缀
5.3 res/values目录下文件内定义的value名称，应统一名称前缀。包括string、dimes、color、style、attr、integer等
5.4 Java代码规范，遵循代码编写规范-Java

sdk调试及查错
sdk接入客户端后，出现问题查错比较麻烦。应照以下指引去做：
6.1 要先界定是客户端调用错误（参数传错、不按照注释说明调用等）还是sdk内部错误。
6.2 关键路径要打印详细Log，通过Log即可以定位大部分的问题
6.3 Log应规范，相关人一看即清楚其要义，而不能只有Log打印者才看得懂
6.4 建议对Log进行分级，通常情况只需关注information及以上级别。log级别说明：
verbose:
debug：调试信息
info：关键信息，用语关键路径打印
warn：警告，在预期之内出现的问题，可以接受。要关注
error：错误，不应出现的问题。必须解决
6.5 Facade接口类的所有方法，都应在入口处打印log，log里应有所有关键参数的值。如进行参数校验，也要打印校验结果。

sdk打包及测试
7.1 sdk打包后应该提供这些内容：
demo：包含所有重要对外接口的调用示例代码
demo.apk：demo工程的apk包，用于提交测试
接入文档说明：含重要接口List、AndroidManfest配置、代码混淆配置、微信压缩方案白名单配置
Facade接口类文档：从Java文件导出为html
7.2 demo.apk的打包，要配置签名、代码混淆，形如正式发布包

sdk版本管理
分为beta版本和release版本。
一个需求版本开发完后，需要先上一个产品去验证效果，这时是beta版本。效果验证ok，可以正式发布让所有产品接入时，就成为release版本。
版本命名规范为“项目名称-beta/release-版本号-版本名称”
beta版本命名形如：chargelocker-beta-v19-5.3.1，简称5.3.1
release版本命名形如：chargelocker-release-v19-5.3.2，简称5.3.2

sdk包体
sdk要注意包体大小
9.1 所有大于10kb的图片，都要考虑能否压缩
9.2 使用第3方库时，不能选择包体大的（除了fb、admob等广告库）