Sdk开发设计与Apk开发不同的地方还是有些明显的不同之处，明显的区别是使用对象不一样，Sdk是基于开发者使用的，都是有一定的开发水平，相对于Apk用户而言基本是大众用户，做得好不好不仅仅是运行起来性能、稳定行以及功能，还需要顾忌开发者调用是否方便、嵌入成本、更新维护成本，因为Sdk是作为一个库给对方使用，但又不是开源的，还得注意保护知识产权，个人认为一个不错优秀的sdk开发需要注意如下方面：
Sdk架构设计-模块化、组件化、插件化
便于层次分清，避免代码臃肿，提高代码阅读性以及单元测试。可以参考下《Android彻底组件化方案实践》如何组件化的思路，但是实际下来顾及到各自的项目大小，可以先从抽离、独立各个业务层做起，尽量分清层次，来提高项目层次感，降低维护难度。
Sdk更新修复能力
一个成熟的热更新框架对降低使用者嵌入成本、快速应用业务发展以及及时修复bug很有必要，但是目前市场开源的框架都是针对Apk热修复的，其实要针对sdk只要从中抽离出核心思想即可，目前见到具有自动更新能力的sdk实现思路有
1、在PathClassLoader中把更新下载下来的dex文件插入到pathList中的dexElements中
这种方式适配起来麻烦，且会有品牌机型问题，且只能更新逻辑功能，对资源不能修改
2、使用DroidPlugin、VirtualApk等开源框架
每个开源框架都有一些特点，需要结合起来使用，并最新这些开源的使用范围以及问题性
3、定义DexClassLoader来实现动态加载，判断版本号选择加载最新版本
下面图片来自滴滴开源插件框架一文中：VirtualAPK和其他主流开源方案的对比：
Sdk接口Api设计统一、简单
有统一接口设计避免使用继承方式来调用sdk的api，Api接口设计简单方便使用，命名让使用者一目了然。参数设计要利于扩展，避免sdk升级时发生找不到方法的异常。
在需要调整SDK API时,优先选择添加新方法,而不是在原方法上修改.对于实现相同功能的新方法,尽可能的要兼容原始方法，这样避免升级时找到不方法或者使用者更新时候避免重新改写接口；在需要废除某些方法时,需要在正式版发版前使用@deprecated标识,并给出替代方案和废弃的时间(通常是SDK版本号)
迭代时接口不统一，往往是因为参数变化而需要拓展，当然还有需要新功能的时候，对应参数设计觉得很有必要统一起来，如用Map封装参数，就很容易扩展参数，需要什么就直接包装进来，而不用修改接口的参数列表，在调用的时候也方便统一管理。Sdk资源内容组成设计-接入和维护更新便利性
做过很多sdk,也接触过不少，最头疼的是那种资源特别多，文件命名混乱，类路径简单，这些都会导致开发者在接入时候麻烦，更新版本时候分不清对应内容归属者，尤其是一些资源文件，甚至还遇见过命名空间一样情况。故结构一定要清晰简单，命名清楚，对于有res资源的Sdk可以通过库文件（aar,lib）导入，而不是零散的给与。
Sdk接口回调设计
要对任何情况下考虑到有回调响应，避免出现使用者调用之后阻塞没有反应情况，例如网络异常，超时处理，调用过快，异常等情况下要有回调。
同时必须提供明确的错误信息回馈给使用者，方便接入者自己就能解决接入中问题，而不是什么问题都需要开发者亲身去维护，回调错误中采用errorCode+errorMsg组合，最好不宜使用通过调试日志形式显示错误信息，这样一旦忘记关了调试模式，泄漏了信息就止这样。Sdk日志设计
日志：用户行为日志（埋点）、调试日志、运行异常日志
用户行为日志（埋点）
作为开发者都希望了解自己的sdk使用中表现，运营都希望得到业务相关数据，这时开发一套完整数据统计就很必要，包括sdk运行稳定性，兼容性数据，异常数据，同时上传用户相关行为数据。做到这些的同时还要注意如下：
1、日志服务能够记录有效的信息,在SDK要关键位置进行打点，避免浪费用户流量，减少上传不必要的数据。
2、日志服务上传日志信息到服务器时,要保证最大的可靠性,不能发生上传失败后抛弃日志的情况，避免数据分析时数据不完整，缺乏可靠性。做到不论当前网络情况如何，都要保证数据完整性上传
3、日志服务不能影响对正常的操作流程有过多的性能影响，SDK产生的日志信息往往是非常多的,因此必须考虑日志IO操作所带来的开销。调试日志设计：在维护中分析问题，经常需要结合日志来分析问题，这时候如果Apk已经发布没有日志、或者如何避免使用者忘记了关掉日志而导致泄漏敏感数据。所以要设计可以不论是否发布状态都能强制打开（强制改成调试状态），发布之后统一关闭日志（服务端控制）
Sdk运行稳定性捕获自身异常
不要出现未捕获的异常，应该在接口内部进行统一的全局对未捕获异常进行捕获，并上报日志供分析改善Sdk，同时也帮助调试中分析问题
Sdk自身内容安全性
sdk的安全性用来对抗外界的反编译，保护内容不被窥探，详见我的另一篇文章：谈Android接入Sdk开发的安全性方案
Sdk性能高效
（1） 减少内存占用
在不使用多进程的情况下,SDK服务和宿主程序运行在同一进程中,这种情况下必须要求限制SDK内存的占用,不能因为说因为我们SDK占用太多的内存资源,导致应用的存活时间变短，但是这种抢资源必然会总宿主内存使用造成影响，从而会影响apk运行性能。
（2）减少内存抖动
在占用更少内存的前提下,SDK设计者必须刻意的减少反复GC造成的内存抖动问题，避免同一时间创建和回收对象，做到正确时刻正确创建对象。
（3）减少电量消耗
尽管很多时候无法对电量消耗做一个很好的权衡,但是仍然有一些可以参考的做法,比如减少使用耗电模块的时间.比如在使用定位服务时,不要求非常高的精度下优先使用网络定位而不是GPS定位.
（4）减少流量消耗
这里就是对Sdk内部网络请求尽量规范，充分利用每一次网络请求发起，复用资源，多次发起都会带来消耗。对数据内容不宜原始数据，尽量能够做到压缩上传。同时要减少后台进程频繁唤醒，做到有效控制。
（5）减少同步阻塞主线程操作
这样提高程序运行效率，避免阻塞主线程，导致app启动变慢或交互响应不及时。尽量提高程序执行效率，使用更高效的方法或api，以及异步初始化.细节事项
1）Sdk开发生成的体积不要过大，尽量能够压缩库或文件，在加载时候解压出来，避免增加使用者Apk的体积大小。
2）Sdk中的方法数不要过大，给Apk带来方法数超限额的问题尽量避免。同时结合运行高效来说以及安全性，过多的方法不安全且增加运行成本，影响应能。
3）Sdk接入帮助文档要详细清晰，要做到接入者看文档就可以成功接入，并且有问题可以根据文档接入，而不是总要联系维护人员。Sdk打包工具开发
结合Android Stuido中Gradle强大的自定义功能，可以开发插件动态打包，组件化动态集成打包、动态修改字节码。
