先拋出需求：
?????? 自己的SDK中集成了很多第三方的支付SDK，比如微信支付，支付寶支付，京東錢包支付，百度錢包支付，銀聯(lián)支付，以及各個(gè)大銀行自己獨(dú)有的支付SDK,那么我是不是應(yīng)該把這些SDK都放到你自己的SDK中集成，那真的要瘋了，你的SDK包該多大了，看著都不敢用，不過(guò)這還不是最無(wú)法接受的問(wèn)題，我們可以在我們的SDK中不添加第三發(fā)的支付SDK資源包，僅僅引用，讓APP工程自己將這些第三發(fā)的支付SDK資源包添加到工程中。
?????? 那么問(wèn)題又來(lái)了，如果你的通道太多了可能幾十上百個(gè)個(gè)，你不可能說(shuō)讓別人接入的APP把這些第三發(fā)的支付SDK資源包都添加到工程吧，要是你會(huì)不會(huì)瘋了，肯定的，而且對(duì)于不同的APP可能需要的支付通道也不一樣，我們能否實(shí)現(xiàn)可配置化？
解決辦法：
1.首先需要針對(duì)不同支付通道封裝一個(gè)對(duì)應(yīng)的支付管理工具類，如AliPayManagerTool, WXPayManagerTool, UnionPayManagerTool.......（為什么要對(duì)應(yīng)每個(gè)支付通道提過(guò)一個(gè)工具類，那要是有100個(gè)通道就要寫(xiě)100個(gè)工具類多麻煩？確實(shí)有點(diǎn)麻煩，但是如果僅僅只提供一個(gè)工具類，那么你支付方法要么就對(duì)應(yīng)需要100個(gè)或者提供100種對(duì)應(yīng)的支付通道枚舉來(lái)區(qū)分，相應(yīng)的工具類支付方法的實(shí)現(xiàn)該多龐大，估計(jì)都有上萬(wàn)行了，所以還是一個(gè)通道一個(gè)工具類，這樣代碼更簡(jiǎn)潔也好維護(hù)，當(dāng)然這僅僅是原因之一，其他原因后面介紹）；
2.所有的支付工具類最好提供的支付方法API是相同的，因?yàn)椴徽撟吣欠N第三方支付，其實(shí)所需要的參數(shù)都是差不多的，差別很小，所以API可以盡可能的封裝為同一個(gè)；（那么基于這個(gè)要求首先想到的是通過(guò)繼承的方式，先定義一個(gè)公共的基類，基類提供一組API,然后支付工具類繼承這個(gè)基類，并實(shí)現(xiàn)這組API,這種方式肯定是可以的；其實(shí)通過(guò)面向協(xié)議的思想來(lái)處理我個(gè)人感覺(jué)更優(yōu)，聲明一個(gè)協(xié)議，提供一組協(xié)議API,然后所有的支付工具類遵守這個(gè)協(xié)議，并實(shí)現(xiàn)相應(yīng)的協(xié)議方法）
3.遵守這個(gè)協(xié)議
4.實(shí)現(xiàn)相關(guān)的協(xié)議方法
5.在build setting ->Preprocessr Macros中定義一個(gè)預(yù)編譯宏，我定義了一個(gè)__CSYSDK_LOCK__宏，如圖:
6.在支付管理類的實(shí)現(xiàn)文件中使用這個(gè)宏進(jìn)行條件編譯，如圖：這樣寫(xiě)就相當(dāng)于是如果有定義宏__CSYSDK_LOCK__那么#ifdef中間的那段代碼就會(huì)被編譯，沒(méi)有定義這個(gè)宏就不會(huì)編譯這段代碼，那么我們SDK里面就可以通過(guò)配置這種宏來(lái)決定哪些支付工具類的實(shí)現(xiàn)能夠被編譯，也就可以做到區(qū)分哪些通道能夠調(diào)用，然后APP工程中相應(yīng)的引入這些通道的第三方SDK資源包即可。
