先抛出需求：
自己的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资源包即可。
