sdk就是把你的app代码抽出来，形成一个依赖库
以aar或者jar形式提供给app依赖用
涉及到插件化的时候 依赖会比较复杂
其它和app开发没什么区别了
抽离代码的时候注意业务抽象
比如游戏SDK 业务抽象后，大致就三个接口
初始化 登录 支付
最后就是依赖库和app的接口通讯
一般有两种方式通讯
一个是用activity的result 回调
二是用接口callback
涉及activity的尽可能用activity去回调
不涉及界面的一般都用接口回调
用callback的好处是可以控制app的逻辑
app在任何场景收到callback都会执行既定逻辑
比如SDK要切换账号，直接用callback就能打破app的运行逻辑 强行切换账号
用activity的result就不行了，不能保证那个activity还活着
用全局callback的坏处是 内存全局占用一个或多个callback，消耗内存，还有一个问题是何时finish sdk的activity，何时用callback触发回调
手动处理内存回收
容易导致很多情况收不到callback 比如某些动作取消却没回调，导致app一直处于被动状态
遇到跨进程的可能会更麻烦点，这种场景一般就需要两个sdk,把跨进程的逻辑封装掉 降低接入方的接入成本
接口易用性，业务解耦性
所有的目的都是易用性
要简单好用，app和sdk业务解耦
使用者不需要关心sdk到底做了啥，只管输入输出
而且一定要非常简单的接入 用起来很简单
开发人员不需要管SDK内部干了啥，只需要接入
以及提供什么参数给SDK，剩下的SDK处理
大部分情况 无非就是各种callback
一个静态类作为接口类，或者单例作为接口类
做的复杂点 就是我这种插件化 多SDK 公用一个接口
接口设计还有一些小技巧
不能直接给人家一个demo 让人家拷贝什么的
要封装成baseActivity 暴露抽象方法 让app继承这个BaseActivty实现抽象方法 SDK的业务流程都写在base里面
SDK的使用者实现的activity只有寥寥数个抽象方法的实现，其它业务流程一概不管
遇到复杂的业务，在BaseActivty中提供一个被代理过的callback给实现者，让实现者用callback回调
实现者回调时，callback的代理代码会执行后续动作
简单说就是callback的嵌套了
想套几层套几层 一般业内规范是不超过两层
多了后面接手的人看不懂
然后结合一些设计模式 让代码优秀一点
其它的和app一样了
什么性能优化、内存泄露
耗时任务优化，耗时的 mearuase draw layout什么的
windows的背景叠层什么的
一般SDK 应该责任单一 ，性能方面，影响很小
责任不单一的SDK就该分成两个SDK
以上情况不涉及NDK。。
记录下来
避免白说这些 将来作为博客素材
其实SDK开发更应该关注的是会遇到什么坑
这才是和APP开发有本质区别的地方
我经常被坑折磨的死去活来
最后发现什么技术也没学到
可能就是学到这些坑
将来换工作 也就这些坑有点竞争力吧
