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