一、关于SDK目录层级
三个工程相互引用，如下：
- SDK工程
- API
- Module
- Framework
- SDKDemo工程
- SDK资源工程
此时的目录结构下，最终交付给游戏的内容将会包括：一个包含了SDK的Framework以及bundle资源文件和一个Demo工程。
二、关于SDK架构
就简单介绍下。其实SDK的架构都差不多，类似于系统架构。一般：
大体上可以分为三层。API层、Framework层、Module层。
- API层最容易理解，他是对整个SDK的对外封装，经过这一层以后仅仅把需要暴露给外部的接口、回调暴漏出来，向开发者隐藏具体实现。
- Framework层是核心层也是最底层，完成SDK的初始化、模块管理以及一些公共基础工具，例如数据模型转换、网络请求处理、数据上报、获取设备相关信息方法等。
- Module层严格意义上应该称中间层，这一层一般是具体模块的业务逻辑，主要是具体的功能实现，例如不同的广告类型的封装、评星、带量广告、排行榜等。
一般对于Module也又按照上面的三层结构来划分，做到各个模块之间的功能独立。
三、关于资源
所有的资源都放在bundle资源文件中，包含引用的第三方广告SDK，图片资源等
四、关于接口设计
设计原则
1.接口名称、参数名称要足够清晰
- 一个牛逼的接口名称可以替代无数的注释
2.一个接口只做一件事
- 一个接口只做一件事。如果有两个比较接近的功能，但是用一个接口实现有点麻烦，那就用两个接口，不要为了减少接口而生硬的把两个接口合为一个。
3.接口参数要尽可能少
- 接口调用的参数要尽可能少，SDK能自身获取的就不要让开发者继续传递，尽可能少的在一个接口中使用同一数据类型的参数，如果确实很多，建议封装为Object作为参数。
4.接口参数要一定要校验、需要转义或者转换的一定要尽可能早的处理
- 所有接口参数必须要做合法性校验。不要让别的接口去保证调用你接口的参数一定是合法的。
- 所有接口做的第一件事就应该是对参数做合法性校验。不要等到逻辑跑完大半了再告诉参数不合法，调用失败。
- 对于需要转义、需要类型转换等的参数，一定要处理，而且尽量尽早的去处理，虽然客户端没有XSS或者SQL注入什么的，不代表你就可以不用考虑
5.通用的名称要统一
- 即使再小的系统，也会有一些通用名词，对于一些通用名词或者模块的叫法、写法一定要统一。
五、关于多线程
关于UI线程
- SDK除非必须，不要使用应用的主线程，就算使用也只能是简单操作，不能长时间占用。
- 任何时候主线程只做一件事，UI调整。所有的耗时操作：读取文件、读取DB、网络数据读取、网络请求发起等全部都要不要用UI线程去处理。
- SDK应该有一个专门的线程来处理SDK相关的操作。
- 所有耗时、异步操作都扔给SDK的线程去处理
这样做最主要的目的就是尽可能的减少SDK对应用本身的影响。
这里就说下目前个人比较常用的一个可能有耗时操作的函数的处理流程吧。
1、调用方调用接口
2、接口参数校验，校验合法，发给SDK的线程
3、SDK的线程收到消息开始处理内部逻辑，处理结束发起回调
4、对返回结果进行二次处理，发给UI线程
5、UI线程通过回调接口回调游戏
六、关于第三方平台
关于因第三方平台的限制引起的失败
- 对于非SDK内部逻辑的限制引起的接口不可用，不要直接判定为失败，而是让规则制定方去判定。而SDK本身可以加个Log提示，方便问题定位。原因有俩：
- 平台的规则可能会调整，到时候平台支持了，你不支持，就是你的问题
- 如果按照上面的方法操作，即使平台调整了，你也不用专门调整，尤其如果是客户端SDK，你不用专门出版本，游戏也不需要更新。因此我们就在违反规范以后打个错误日志，只要平台支持，接口还是可以用。
关于第三方平台的常量
- 对于第三方平台的常量例如错误码等，最好是自己封装一层提供给开发者。不要直接将第三方平台暴漏给开发者
- 避免开发者还需要了解其他平台SDK，也不需要跟着第三方的进行调整
关于第三方平台的配置
- 对于第三方平台的各种配置，比如appid等，最好是仅仅用于第三方平台的逻辑中，不要为了省事把第三方平台的配置用于自己的业务逻辑
七、关于配置
配置通过什么形式下发
不管是模块的开关还是接口的权限，都应该可以后台控制。当然前台最好也要有配置文件，可以减少一些无用的请求。而且在后台不能控制的时候，前台的开关还是很有必要的。
在同时有前后台的开关或者配置的时候，优先使用后台的配置。
网友评论