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