TYPESDK手游聚合SDK客户端设计思路与架构之六:SDK配置文件设计思路

 

　　做为一个聚合sdk的客户端，势必针对每个不一样渠道sdk有一套本身的配置文件。同时，做为聚合sdk客户端自己也会有相关的功能配置需求。加上部分的游戏开服和登陆等等在线应急功能的需求，也最好是须要有一套配置文件。同时这些配置文件有些须要放在本地，有些则须要放在资源服上读取，有些则要放在聚合sdk服务器上读取。
零零总总的说了这么多，那么让咱们来理一下思路，看看到底要有那些配置文件。
　　从功能分类来讲
　　　　1. 针对单个渠道sdk的相关配置
　　　　2. 针对聚合sdk额外功能的相关配置
　　从读取难易来讲
　　　　1. 放在本地的配置（读取速度快且一定成功，可是有被修改风险，很难作更新）
　　　　2. 放在服务器的配置（读取成功存在失败因素，几乎没有被修改风险，很容易作更新）
　　　　3. 写在代码里文件的配置（读取速度快，被修改难度大，可是很难作更新）

鉴于上述的这些分析，那么咱们作了如下的这些规划
　　1. 存放本地的配置的文件：localConfig
其中包含了如下几点内容：
　　　　a. 单个渠道sdk的非关键性配置：例如appid，渠道编号，等
　　　　b. 单个游戏包的sdk额外功能；是否加载广告检测，是否使用热更新等

　　2. 存放在服务器的配置文件：serverConfig
其中包含了如下几点内容
　　　　a. 渠道的回调地址，appkey等关键性参数
　　　　b. 游戏登陆的白名单列表等
　　　　c. 游戏log的是否开启
　　　　d. 游戏的sdk辅助功能是否开启使用的开关等
　　3. 写在代码文件里的配置:codeConfig
其中包含了如下几点内容
　　　　a. 从服务器读取文件的下载地址列表，须要有多个下载地址
　　　　b. 解析本地配置文件的相关算法（本地配置文件可能加密）
　　　　c. 其余和sdk聚合服通讯的地址和接口。

接下来咱们来讲说，这三类配置文件分别在何时读取和使用。

存放本地的配置的文件
　　这种建议直接在游戏启动时读取，由于从本地文件转换成内存中的数据，仍然是须要一个输入／输出流的操做，存在异常的捕获和处理。
本地配置文件应该在sdk功能正式启用前就被加载，换言之，在sdk的初始化以前，须要将本地配置文件读取出来而且存到内存中。在接下来的sdk初始化过程当中，将会用到本地配置文件的appid这些渠道sdk配置参数。

存放在服务器的配置文件
这些数据建议先在每一个具体的逻辑接口调用前读取一次。这些配置文件中的数据，有如下这些的相关设计
　　a. 这些数据自己须要有一个默认值，防止在网络很差的状况下无数据可用，形成逻辑上的卡死。
　　b. 这些数据每次使用的时候，都须要刷新从新读取一遍，由于这些数据存在的最大用处就是动态的后台更新相关配置
　　c. 这些数据每次读取到之后，都须要缓存进内存中。若是下次从服务器没有读到相关配置，则使用缓存在内存中的数据
　　d. 这些数据须要在获取到／超时后再调用后面的逻辑，不要作异步的接口调用。

写在代码文件里的配置:codeConfig
这些配置文件由于是写在代码中的，因此不须要缓存进内存中，它们自己应该是静态常量，能够每次须要使用的时候，直接读取就行。

接下来特意说下有关代码里的配置：coneConfig
由于移动设备自己固有问题，以前作项目的时候，有遇到过ip地址解析不了的状况，因此在读取相关的服务器配置地址时候，咱们作了如下的相关设置
　　a. 配置文件最好有域名的配置。
　　b. 同一个接口，有多套的备选地址，以防有一台服务器没法访问到，而形成逻辑上的中断
　　c. 自己要有相关的超时机制，当第一个ip访问不到时，才开始访问第二个，而且全部接口应该都遵循这套逻辑

有关配置文件的数据格式，这里咱们说起一些项目中遇到的实际状况
咱们当初使用的数据格式是json，而在http协议中，”:\”这两个符号是不能使用的，必须进行URLEncode，在服务端和客户端通讯中，这个小问题经常被忽视。
有关配置文件的一些设计思路，咱们就先暂时讲到这里。同时也欢迎广大看客联系咱们typesdk的技术，提出宝贵的意见和建议。

 

这个项目已开源，你们有兴趣能够本身研究或者参照项目编写本身的聚合SDK
项目地址：https://code.csdn.net/typesdk_code
项目地址：https://github.com/typesdk