关于A/BTest的相关实践以及架构

A/Btest 也称之为灰度发布，一般应用在大的改版，当然小的也可以。也就是app中一部分用户使用的旧版功能或者页面一部分用户使用的新版功能或者新版页面，当然这个比例是由后台程序控制的。产品通过看用户的反馈，以及用户的使用，等情况决定是否使用新版。是一种更安全的方式吧。

1. 先说说后台接口问题
   首先我们采用了专门请求“新版/旧版”的接口，其次我们采用了一个开关接口，用于控制abtest是否打开。开关接口，其实返回“开关名字”：“状态1/2/3”;下面我们称abtest的接口为1接口，开关为2接口
   也就是对应三种状态1关闭，2全部旧版，3全部新版，也是为了方便控制吧，其实我认为是有点多余了。只需要一个请求是新版还是旧版就完全可以控制。也就是1接口不用关闭，当需要全量切换的时候改变比例就好了。当然那是大家讨论的结果需要2接口，我就不说了。
2. 说说架构
   1.首先我们创建一个plist，plist的结构为

/// 以abtestId为主导
 "528":{
        "default":YES(or NO), // 默认是A旧版为NO， 新版为YES
        "func":[ // 方法列表
        "+class/function",//  程序中将通过规则取数据，然后进行方法交换
        "-class/function" // 实例方法
        ],
        "Class":[// 类列表
        "class",
        "class1"
        ]
        },
    "682":{…}

其实这个结构是核心，我们每次请求完数据或者开始处理数据都是以plist的数据来处理。

2. 代码实现
   创建一个manager类，ABTestManager单利类，单利类的好处在于，这个类在应用未杀死之前不会，释放，方便处理异步请求。

ABTestManager{
+ (instancetype)shareManager;
- (void)requestData;
//私有属性
NSDictionary *plistDictionary;                                  NSMutablleDictionary *abtest;
}

在requestData里1.我们先进行默认处理，即如果默认是新版，我们先进行一次方法交换，如果是旧版我们不错处理2. 我们先请求开关，如果开关返回全部新版，如果已经做过方法交换不做处理，如果没有做过我们交换方法，如果开关是其他状态，我们请求1接口，通过1返回的数据我们再做处理，细节的东西就不说了，也不上代码了，主要想记录一下，对于架构的理解。
Plist结构+ClassMethodSwizz的一个基本处理。