SDK开发设计原则

遵循的几个基本原则
接口隔离
设计应当小而精简；
开闭原则。
对于扩展开放，对于内部修改封闭。对外交互部分尽量面向接口编程，实现抽象。
接口的易用性
设计符合“人性”的接口，面向“大众”的接口，减少奇技淫巧的使用。
不属于自己sdk业务的事情，尽量不去设置状态调用，以补丁方式调用。例如单独调用生命周期函数来完成sdk功能。
向后兼容
不能让用户升级你的sdk后原有功能不可用了。对于自动化打包的sdk，接口的停用一定是要废弃至少两个sdk大版本，才能去掉。因为sdk的升级完成需要一定的时间。
编写文档
最后，完成sdk编码工作后，一需要编写文档。一份好的文档能让用户事半功倍，快速接入使用sdk，并减少后续bug。
另外如果sdk不需要大部分接口不需要游戏重新接入的话，可以增加升级文档给到接入方，以便能够实现游戏的快速更新sdk。

接口设计的原则
设计原则
1、接口名称、参数名称要足够清晰
一个好的接口名称，可以替代无数的注释，应尽量涵盖接口功能。比如在注册监听的时候，全局只有一个使用setXXX + DeleteXXX；如果有多个的话使用addXXX + removeXXX；
2、一个接口只做一件事
一个接口只做一件事。如果有两个比较接近的功能，但是用一个接口实现有点麻烦，那就用两个接口，不要为了减少接口而生硬的把两个接口合为一个。
3、接口参数要尽可能少
接口调用的参数要尽可能少，SDK能自身获取的就不要让开发者继续传递，尽可能少的在一个接口中使用同一数据类型的参数，如果确实很多，建议封装Object作为参数。
接口参数要一定要校验、需要转义或者转换的一定要尽可能早的处理：

所有接口参数必须要做合法性校验。不要让别的接口去保证调用接口的参数一定是合法的。
所有接口做的第一件事就应该是对参数做合法性校验。不要等到逻辑最后，校验参数不合法，调用失败。
对于需要转义、需要类型转换等的参数，一定要处理，而且尽量尽早的去处理。
4、通用的名称要统一
即使再小的系统，也会有一些通用名词，对于一些通用名词或者模块的叫法、写法一定要统一。
接口命名，尽量要有语义并且全面。这样可以让调用者一目了然知道该接口的功能。
变量的命名，应尽量的统一，具体可参见java命名规范，杜绝出现一个项目多个命名规范，不伦不类的现象。
资源命名如果是sdk自身使用的文档，需要加前缀，避免在自动化打包时与其他sdk资源冲突。例如 lnetwork_security_config.xml 应改为laohu_network_security_config.xml。
5、关于同步和异步接口
可以同步的接口，一定不要异步，但如果功能的实现既有同步也有异步，一定要设计成异步。
能不用全局回调就一定不要用全局的回调
一定要用全局回调最好按照模块分开，一个模块一个回调，开发者只需实现他关心模块的回调即可。无关模块的回调设置是否对SDK的正常使用没有影响。
6、多线程处理
UI线程处理
SDK除非必须，不要使用应用的主线程，就算使用也只能是简单操作，不能长时间占用。
SDK应该有一个专门的线程来处理SDK相关的耗时操作。
怎么使用handle
所有耗时、异步操作都通过handle扔给SDK的线程去处理。处理结束以后再把结果通过handle发给主线程。
任何时候主线程只作一件事，UI调整。所有的耗时操作：读取文件、读取DB、网络数据读取、网络请求发起等全部都要不要用UI线程去处理。
AsyncTask sdk中不要使用AsyncTask ，应为在app接入过程中，如果也使用AsyncTask ，会与sdk争抢资源，造成AsyncTask 阻塞，影响用户体验。

7、三方库的引用
尽量不要引用第三方库，要尽量使用android系统自带的功能，然后在其基础上进行封装。如果一定要用到第三方库，最好能够修改源码的包名进行使用，这样可以减少与游戏的冲突。
8、基础模块的修改
对于基础模块的修改，如网络模块，文件读取，数据库操作等，需要特别慎重，在不能完全和熟悉项目的情况下，建议采用子类复写或者重载来满足新开发的功能需求，待日后再进行优化合并操作。
9.牵扯大内存分配的，应当尽量使用复用，小内存需要使用内存池

10.配置设计要考虑到扩展，不能写死，比如区域码，我们采用服务器可配置形式，区别于app

11.关于使用数据库升级数据库版本号时，增加扩展字段的话，需要多增加几个空字段，这样的话避免数据库频繁升级，造成风险