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