多渠道接入系統總結

在業務系統中會出現對接外部服務的場景，可能需要對接不同公司的介面，而且功能相似。比如：

在這類渠道接入服務中需要對接的外部服務功能、協議、引數是相似的，如何最大化的復用**，快速接入是這類服務的設計難點。

一般的流程：

在**實現上一般放在乙個map裡，然後根據請求去執行相對應的 handler 邏輯。

//

初始化mapcallbackhandlermap = new
hashmap();
//具體執行
callbackhandlermap.get("channela").callback();

實現大致可分為三種模式：

這種模式簡單粗暴，直接根據外部服務提供的介面文件實現對用的 channelhandler 即可。

// 實現

class channelahandler extends channelhandler 
}// 註冊
callbackhandlermap.put("channela", channelahandler);
// 呼叫
callbackhandlermap.get("channela").callback();

- 渠道商測試環境和線上環境不一致

- 渠道介面公升級

- 新增渠道

這些都需要重新修改**，然後發布，效率相對較低。

外掛程式模式就是在服務中嵌入指令碼執行器如lua，處理函式呼叫直譯器執行配置的指令碼，直譯器返回固定格式的資料，處理完成後返回資料給呼叫方。

流程如下：

外掛程式模式解決了暴力模式的上述三個缺點，隨時可以更新指令碼，新增渠道只需重新配置乙個即可。缺點是通用的指令碼直譯器過重，大部分的功能是用不到的，針對這個問題可用下面一種方式解決。

外掛程式模式內建的一般使用的 gpl(general purpose language) 通用程式語言，而 dsl 相對的就是，而是 dsl (domain specific language) 領域特定語言：通過在表達能力上做的妥協換取在某一領域內的高效執行，如正則/html等。顯然 dsl 完美的符合我們的需求。

其流程圖和外掛程式模式是一樣的，唯一的區別在內建的直譯器替換成我們自己開發的 dsl 直譯器。

在實際的業務場景中我們可以根據需求來選擇一種合適的模式。

如果專案剛開始，業務場景不明朗，那麼暴力合適是合適的，可以快速的實現需求，實現業務試錯。

如果對接的渠道逐漸增多，而且場景複雜，需要負責的流程控制和計算，那麼外掛程式模式合適的。

如果對接的渠道多，但是回傳不複雜，那麼自己實現乙個 dsl 直譯器是合適的。

沒有絕對的優劣，只要合適的。

Android多渠道打包

度娘能搜到很多種多渠道打包方式，我這裡簡單說下我們目前正在使用的打包方法。首先背景情況 我們不同渠道，除了渠道號 vendorid 不一樣外，還有功能上的稍許不同，所以還有幾個開關控制專案。方法原理 專案 中在res raw 下增加config.dat檔案，裡面有渠道號，和功能開關 apk包，其實是...

Git多渠道配置

因為有github gitee，gitlab賬號並且需要向三個渠道提交 所以git需要配置多個賬號的的資訊。進入c users x.ssh目錄右鍵git進入c users x.ssh目錄右鍵git ssh keygen t rsa c 你的郵箱emall com f id rsa github ss...

Gradle多渠道打包

廢話不多說，以友盟統計為例，在androidmanifest.xml裡面會有這麼一段 meta data android name umeng channel android value channel id 裡面的channel id就是渠道標示。我們的目標就是在編譯的時候這個值能夠自動變化。或者...