iOS开发——组件化及去Mode化方案
1.组件化的目的是什么？
最近一两年很多人都想在项目里面搞组件化，觉得搞组件化好，却鲜有人知道组件化好在哪里？组件化的目的是什么？个人觉得组件化主要有两个目的：
1.实现项目代码的高内聚低耦合；
2.方便多人多团队开发（这就是大团队为什么那么热衷于组件化的原因，对开发的效率的提升是十分显著的）。
1499663080372188.png
2.我的项目组件化应该做到什么程度？
个人认为组件化的程度取决于项目的大小，当一个项目一个人可以轻松开发和维护时，只需要项目架构保持如下图即可：
1503560345783827.jpeg
把基础层的部分抽成组件，用cocoapods来维护，实现基础层与表现层，业务层去耦合，业务层与表现层依然耦合。
当项目变的越来越大，功能模块越来越多，需要五到十几个人维护的时候，就需要明确组织里的每个人负责的功能模块，在代码层面也需要业务层和表现层区分开来，业务层和业务层之间也要区分开来，表现层与表现层之间也要区分开来，要想做到这些，需要做很多的工作，首先要划分好功能模块，保证一个模块的表现层和业务层代码在一个文件夹；然后一个模块下的表现层和业务层逻辑要有一个明显的区分；再引入一个中间件比如CTMediator，作者自己写的中间件基于CTMediator的ZZRouter，中间件用cocoapods来维护；每个模块根据中间件提供外部调用的接口，本模块调用外部模块，一律使用中间件来调，实现模块间的去耦合。中型项目的理想架构应该如下图：
1503560385634435.jpg
中型项目理想架构
当一个app成为超级app需要多个团队共同协作开发的时候，对组件化的要求又更高了，这个时候需要实现模块的独立编译，以及在主项目中的静态和动态加载，同时又要保证模块间的通信，正在完善的BeeHive就是奔着这个目标去的。
为什么要组件化？而代码在慢慢堆积起来之后，许多类之间都存在着“你离不开我，我离不开你”的情况，这就会导致开发效率低下，且容易造成代码冲突。其实说白了就是耦合度太高。这样揉成一坨对测试/编译/开发效率/后续扩展都有一些坏处
每个模块都离不开其他模块，互相依赖粘在一起成为一坨
「组件化」顾名思义就是把一个大的 App 拆成一个个小的组件，相互之间不直接引用。那如何做呢？
组件化
实现方式
理想设计图，源于微信读书照理想设计图所示，Mediator作为一个中间件起着调度各个模块的作用，那么Mediator 怎么去转发组件间调用？本文将以 JLRoutes 作为Mediator。在使用JLRoutes之前，请配置scheme，详见http://blog.csdn.net/u010127917/article/details/50451251
JLRoutes本质可以理解为:保存一个全局的Map，key是url，value是对应的block。这样在下面的代码中:
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation { return [JLRoutes routeURL:url];}
如果自己被打开:
NSURL *viewUserURL = [NSURL URLWithString:@"myapp://user/view/joeldev"];[[UIApplication sharedApplication] openURL:viewUserURL];
JLRoutes就可以遍历这个全局的map，通过url来执行对应的block。
废话不多说，直接上代码吧！appdelegate中设置好匹配规则然后根据传递过来的参数进行跳转
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // navigationPush规则 [JLRoutes addRoute:@"/NaviPush/:controller" handler:^BOOL(NSDictionary<NSString *,NSString *> * _Nonnull parameters) {// 获取当前控制器 UIViewController *currentVc = [self currentViewController]; UIViewController *v = [[NSClassFromString(parameters[@"controller"]) alloc] init]; [self paramToVc:v param:parameters]; currentVc.hidesBottomBarWhenPushed = YES; [currentVc.navigationController pushViewController:v animated:YES]; currentVc.hidesBottomBarWhenPushed = NO; return YES; }]; // StoryBoardPush规则 [JLRoutes addRoute:@"/StoryBoardPush" handler:^BOOL(NSDictionary<NSString *,NSString *> * _Nonnull parameters) { // 获取当前控制器 UIViewController *currentVc = [self currentViewController]; UIStoryboard *storyboard = [UIStoryboard storyboardWithName:parameters[@"sbname"] bundle:nil]; UIViewController *v = [storyboard instantiateViewControllerWithIdentifier:parameters[@"bundleid"]]; [self paramToVc:v param:parameters]; currentVc.hidesBottomBarWhenPushed = YES; [currentVc.navigationController pushViewController:v animated:YES]; currentVc.hidesBottomBarWhenPushed = NO; return YES; }];return YES;}
其实在这个环境下不引用任何需要跳转的控制器来进行参数传递是个麻烦的问题，所以使用runtime来进行参数的传递
-(void)paramToVc:(UIViewController *) v param:(NSDictionary<NSString *,NSString *> *)parameters{ // runtime将参数传递至需要跳转的控制器 unsigned int outCount = 0; objc_property_t * properties = class_copyPropertyList(v.class , &outCount); for (int i = 0; i < outCount; i++) { objc_property_t property = properties[i]; NSString *key = [NSString stringWithUTF8String:property_getName(property)]; NSString *param = parameters[key]; if (param != nil) { [v setValue:param forKey:key]; } }}
控制器发送跳转规则及参数
-(void)btnClick:(UIButton *) sender{ if (sender.tag == 0) { NSString *customURL = @"TESTDEMO://NaviPush/SecondViewController?userId=99999&age=18"; [[UIApplication sharedApplication] openURL:[NSURL URLWithString:customURL]]; }else{ NSString *customURL = @"TESTDEMO://StoryBoardPush?sbname=Main&bundleid=SBVC"; [[UIApplication sharedApplication] openURL:[NSURL URLWithString:customURL]]; }}
干货来了！！！https://github.com/sthyuhao/JLRDemo
组件化的过程之前根据蘑菇街的组件化方案，limboy和casa等人做了深入的讨论，并根据各自的观点给出了方案实施的理由以及利弊关系，然后又有人改进了他们的组件化方案，我总结了一下，大致有三种，下面分别介绍各自的实现过程：
方案一、url-block这是蘑菇街中应用的一种页面间调用的方式，通过在启动时注册组件提供的服务，把调用组件使用的url和组件提供的服务block对应起来，保存到内存中。在使用组件的服务时，通过url找到对应的block，然后获取服务。下图是url-block的架构图：
iOS组件化方案的几种实现
注册：
[MGJRouter registerURLPattern:@"mgj://detail?id=:id" toHandler:^(NSDictionary *routerParameters) { NSNumber *id = routerParameters[@"id"]; // create view controller with id // push view controller}];
调用：[MGJRouter openURL:@"mgj://detail?id=404"]蘑菇街为了统一iOS和Android的平台差异性，专门用后台来管理url，然后针对不同的平台，生成不同类型的文件，来方便使用。使用url-block的方案的确可以组建间的解耦，但是还是存在其它明显的问题，比如：需要在内存中维护url-block的表，组件多了可能会有内存问题 url的参数传递受到限制，只能传递常规的字符串参数，无法传递非常规参数，如UIImage、NSData等类型 没有区分本地调用和远程调用的情况，尤其是远程调用，会因为url
参数受限，导致一些功能受限 组件本身依赖了中间件，且分散注册使的耦合较多 方案二、protocol-class针对方案一的问题，蘑菇街又提出了另一种组件化的方案，就是通过protocol定义服务接口，组件通过实现该接口来提供接口定义的服务，具体实现就是把protocol和class做一个映射，同时在内存中保存一张映射表，使用的时候，就通过protocol找到对应的class来获取需要的服务。
下图是protocol-class的架构图：
iOS组件化方案的几种实现
注册：
[ModuleManager registerClass:ClassA forProtocol:ProtocolA]
调用：
[ModuleManager classForProtocol:ProtocolA]
蘑菇街的这种方案确实解决了方案一中无法传递非常规参数的问题，使得组件间的调用更为方便，但是它依然没有解决组件依赖中间件的问题、内存中维护映射表的问题、组件的分散调用的问题。设计思想和方案一类似，都是通过给组件加了一层wrapper，然后给使用者调用。同时，另一种方案是url-controller，这是LDBusMediator的组件化方案，我认为和方案二的实现原理类似。它是通过组件实现公共协议的服务，来对外提供服务。具体就是通过单例来维护url-controller的映射关系表，根据调用者的url，以及提供的参数（字典类型，所以参数类型不受约束）来返回对应的controller来提供服务；同时，为了增强组件提供服务的多样性，又通过服务协议定义了其它的服务。整体来看，LDBusMediator解决了蘑菇街的这两种组件化方案的不足，比如：通过注册封装件connector而不是block来降低了内存占用；通过字典传递参数，解决了url参数的限制性。但是，由于使用了connector来提供服务而不是组件本身，把connector作为组件的一部分，依然有组件依赖中间件的问题。
下图是LDBusMediator的组件化架构图：
iOS组件化方案的几种实现
方案三、target-actioncasa的方案是通过给组件包装一层wrapper来给外界提供服务，然后调用者通过依赖中间件来使用服务；其中，中间件是通过runtime来调用组件的服务，是真正意义上的解耦，也是该方案最核心的地方。具体实施过程是给组件封装一层target对象来对外提供服务，不会对原来组件造成入侵；然后，通过实现中间件的category来提供服务给调用者，这样使用者只需要依赖中间件，而组件则不需要依赖中间件。
下图是casa的组件化方案架构图：
iOS组件化方案的几种实现
以下代码来自casa的组件化demotargetA组件
// TargetA.h- (UIViewController *)Action_nativeFetchDetailViewController:(NSDictionary *)params;
CTMediator分类
// CTMediator+CTMediatorModuleAActions.h- (UIViewController *)CTMediator_viewControllerForDetail;// CTMediator+CTMediatorModuleAActions.m- (UIViewController *)CTMediator_viewControllerForDetail{ return [self performTarget:kCTMediatorTargetA action:kCTMediatorActionNativFetchDetailViewController params:@{@"key":@"value"} shouldCacheTarget:NO];}
调用
// ViewController.h#import "CTMediator+CTMediatorModuleAActions.h"[self presentViewController:[[CTMediator sharedInstance] CTMediator_viewControllerForDetail] animated:YES completion:nil];
从以上代码可以看出，使用者只需要依赖中间件，而中间件又不依赖组件，这是真正意义上的解耦。但是casa的这个方案有个问题就是hardcode，在中间件的category里有hardcode，casa的解释是在组件间调用时，最好是去model化，所以不可避免的引入了hardcode，并且所有的hardcode只存在于分类中。针对这个问题，有人提议，把所有的model做成组件化下沉，然后让所有的组件都可以自由的访问model，不过在我看来，这种方案虽然解决了组件间传递model的依赖问题，但是为了解决这个小问题，直接把整个model层组件化后暴露给所有组件，容易造成数据泄露，付出的代价有点大。针对这个问题，经过和网友讨论，一致觉得组件间调用时用字典传递数据，组件内调用时用model传递数据，这样即减少组件间数据对model的耦合，又方便了组件内使用model传递数据的便捷性。组件化实施的方式组件化可以利用git的源代码管理工具的便利性来实施，具体就是建立一个项目工程的私有化仓库，然后把各个组件的podspec上传到私有仓库，在需要用到组件时，直接从仓库里面取。
1.封装公共库和基础UI库在具体的项目开发过程中，我们常会用到三方库和自己封装的UI库，我们可以把这些库封装成组件，然后在项目里用pod进行管理。其中，针对三方库，最好再封装一层，使我们的项目部直接依赖三方库，方便后续开发过程中的更换。
2.独立业务模块化在开发过程中，对一些独立的模块，如：登录模块、账户模块等等，也可以封装成组件，因为这些组件是项目强依赖的，调用的频次比较多。另外，在拆分组件化的过程中，拆分的粒度要合适，尽量做到组件的独立性。同时，组件化是一个渐进的过程，不可能把一个完整的工程一下子全部组件化，要分步进行，通过不停的迭代，来最终实现项目的组件化。
3.服务接口最小化在前两步都完成的情况下，我们可以根据组件被调用的需求来抽象出组件对外的最小化接口。这时，就可以选择具体应用哪种组件化方案来实施组件化了。
总结组件化是项目架构层面的技术，不是所有项目都适合组件化，组件化一般针对的是大中型的项目，并且是多人开发。如果，项目比较小，开发人员比较少，确实不太适合组件化，因为这时的组件化可能带来的不是便捷，而是增加了开发的工作量。另外，组件化过程也要考虑团队的情况，总之，根据目前项目的情况作出最合适的技术选型。我一直尊崇，没有最好的技术，只有最合适的技术。
第一版 App 架构 早在 2010 年 58 同城诞生第一版 iOS 客户端，按照传统的 MVC 模式去设计，纯 Native 页面，这时的功能较为简单，架构也是如此，从上至下分为 UI 展现、业务逻辑、数据访问三层，如图 1 所示。和同期其他公司一样，App 的出发点是为了快速抢占市场，采取“短平快”的方式开发。纯 Native 的 App 在早期业务量不是太大的情况下，能满足业务的需求。
图 1 App 早期架构
第二版架构 Hybrid 框架需求 由于苹果审核周期较长，业务需求不断增大，有些业务如果用 Native 进行开发，工作量大投入人员较多，也不能动态更新，如 58 App 的大类、列表、详情页面。这种情况下，用 HTML5 是比较流行的解决方式，由此产生了第二版架构，如图 2 所示，在 UI 层添加了 HTML5 页面及 Hybrid 交互框架。
图 2 带 Hybrid 的架构
当时 58 App 设计时用于加载 HTML5 的组件是 UIWebView，也只能使用这个（彼时还没有 WKWebView），但实现起来有几个问题是需要解决的： 怎么解决 Hybrid 中 Web 和 Native 交互问题，如用户点击一个类别，能调起 Native 的一些方法去执行相关页面跳转或写日志。
如何提高 HTML5 页面的加载速度，HTML5 页面加载时要下载一些 JavaScript、CSS 及图片资源，是比较耗时的。
设置缓存 为了方便描述，本文先介绍如何提高 HTML5 页面加载速度的问题。 对于一些访问比较频繁的页面，如大类列表详情，我们早期采用的都是 HTML5 页面。要加速这些页面的渲染，就要想办法提升资源的加载。那么如何实现呢？首先想到的是使用缓存，我们可以把这些页面的资源内置到 App 中随版本发布。 由于 UIWebView 在发请求的时候都会走 NSURLCache 的这个方法： Html代码
- (nullable NSCachedURLResponse*)cachedResponseForRequest:(NSURLRequest *)request;
图 3 缓存处理流程其中，H5ViewController 为 HTML5 载体页面，WBCacheHandler 为专门处理内置资源类，用于加载、查找、下载、保存内置资源。URL 的 query 中设置版本号参数 cachevers 作为资源缓存的标识，其值为数字类型，假设 cachev1，其与内置资源中的版本号如为 cachev2 进行对比，若 cachev2>= cachev1，表示内置资源中是最新数据，直接给请求返回数据；否则下载新的内置资源，同时根据 cachev1- cachev2 的差值进行判断，如设置一个临界值 x，若差值大于 x，则说明内置资源为旧，给请求返回 nil，否则返回内置数据，让请求先用缓存数据，下次启动时再用新数据。 内置数据采用的是一个 bundle 包，如图 4 所示，CacheResources.bundle 为内置包名，里面包含了一个索引文件和若干个内置数据文件，其中索引文件中每项 item 格式为 key、版本号和文件名。
图 4 缓存包结构
想要使用自定义的 NSURLCache，必须在 App 启动时初始化 WBHybridComponent，并进行设置，替换默认的 Cache，注意：这个设置必须在所有请求之前进行，否则设置失效，而是采用默认的 NSURLCache 实例，我们曾经踩过这个坑。 Urlcache初始化代码
// URLCache初始化
WBHybridComponent *hybridComp = [[WBHybridComponent alloc] initWithMemoryCapacity:MEM_CAPACITY diskCapacity:DISK_CAPACITY diskPatch:nil];
[NSURLCache setSharedURLCache:hybridComp]
基于 AJAX 的 Hybrid 框架 对于前面所列的第一个问题，我们是要设计一个 Web/Native 的 Hybrid 框架。交互主要包括两部分内容，一是 Native 调用 Web，这个比较简单，直接通过 UIWebView 的 stringByEvaluatingJavaScriptFromString:执行一段 JS 脚本，并返回执行结果，本文主要分享 Web 调 Native 的方法。 对于 Web 调 Native 交互的方式，我们采用异步 AJAX 进行，创建一个 Web代码 XMLHttpRequest 对象，执行 send()进行异步请求，Native 拦截。
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
// 处理返回数据
}
};
xmlhttp.open("GET", "nativechannel://?paras=...”, true);
xmlhttp.send();
由于 XMLHttpRequest 的方式是进行页面局部刷新，并不能被 UIWebViewDelegate 代理的 - (BOOL)webView:(UIWebView )webView shouldStartLoadWithRequest:(NSURLRequest )request navigationType:(UIWebViewNavigationType)navigationType 方法拦截到，设计到这里又出现了新问题，如何让 Native 能拦截到 AJAX 请求呢？ 经过一番调研，我们找到了用于缓存的 NSURLCache，对于 UIWebView 中的所有请求（包括 AJAX 请求）都会走 NSURLCache。因此，我们决定采用复用缓存中的 WBHybridComponent 拦截 AJAX 请求，具体 Web 调 Native 的交互设计如图 5 所示。
图 5 Hybrid 框架处理流程图
其中，H5ViewController 为 HTML5 的载体页，WBWebView 是 UIWebView 派生类。WBWebView 中通过 AJAX 发出的异步请求，在 WBHybridComponent 中被拦截，再通过 WBHybridJSHandler 中的 dic 表找到对应的 WBActionAnalysis 对象，然后在 WBActionAnalysis 中分析异步请求传过来的协议，取出 action 字段，再根据 action 值找到 delegate 即 H5ViewController 中对应的方法。 AJAX 发出的请求我们约定为:nativechannel://?paras=<json 协议>，WBHybridComponent 在拦截时判断 URL 中是否为 nativechannel 的协议头，如果是则为 Web 调起 Native 操作，需要进行后续 Native 处理；否则放过进行其他处理。<json 协议> 的简化格式如图 6 所示，这是二手车大类页点击二手车类目 Web 调 Native 时 AJAX 传过来的协议。
图 6 Web 调 Native 传输协议
改进的 Hybrid 框架 前面我们设计的 Hybrid 框架，通过创建 XMLHttpRequest 对象发送 AJAX 请求的方式能达到 Web 调 Native 的目的，也可以满足业务上的需求，在一段内发挥了重要作用。但随着时间的推移，这个 Hybrid 框架暴露出了一些问题，如下所示。 [list]我们发现 App 中存在大量的内存泄露，经查罪魁祸首竟是 UIWebView。调研发现 UIWebView 中执行 XMLHttpRequest 异步请求时会有内存泄露，网上也有人探讨过这个问题，参考博文：http://blog.techno-barje.fr//post/2010/10/04/UIWebView-secrets-part1-memory-leaks-on-xmlhttprequest/。
Hybrid 交互方式与缓存都使用 NSURLCache 的派生类 WBHybridComponent 执行拦截，其初衷也是用于缓存。我们的 Hybrid 框架将两者耦合在一起，这对于后期的开发和性能优化工作会带来不少隐患。
我们在 Hybrid 交互的时候维护了一个Html代码
//创建iFrame元素
variFrame= document.createElement("iframe");
//设置iFrame加载的页面链接
iFrame.src= "nativechannel://?paras=<json协议>";
//向dom tree中添加iFrame元素，以触发请求
document.body.AppendChild(iFrame);
//请求触发后，移除iFrame
iFrame.parentNode.removeChild(iFrame);
iFrame = null;</json协议>
[/list] 由于 iframe 方式是整个页面刷新，所以能执行 UIWebViewDelegate 的回调方法 - (BOOL)webView:(UIWebView )webView shouldStartLoadWithRequest:(NSURLRequest )request navigationType:(UIWebViewNavigationType)navigationType。我们可以直接在这个方法中拦截 Web 的调起，iframe 方式处理流程如图 7 所示。
图 7 iframe 的 Hybrid 交互方式
通过 iframe 的方式，我们 App 极大地简化了 Hybrid 框架的交互流程，同时也解决了内存泄露、与缓存功能耦合、消耗不必要的内存空间等问题。 第三个版本架构 随着业务的进行，一些新的技术需求来了，比如有些基础模块可以从 App 中独立出来进行多应用间的复用；需要为转转 App 提供一个日志 SDK；为违章查询等 App 提供登录的 Passport SDK；为其他 App 提供一个可定制化的分享组件等等。 App 拆分组件 这时我们迫切地需要在工程代码层面对原来的 App 进行拆分、组件化开发，如图 8 所示。
图 8 第三版架构
我们将 App 拆分成三层，从下至上依次是基础服务层、基础业务层、主业务层： 基础服务层里的组件是与业务无关的，供上层调用，每个组件为一个工程，如网络、数据库、日志等。这里面有些组件是整个公司的其他 App 也在使用，如乐高日志，我们对外提供一个 SDK，与文档一起放在代码服务器上供其他团队使用。并将 58 App 中用到的所有第三方库都集中起来存放到一个专门的工程中，也便于更新维护。
基础业务层里的组件是与业务相关的，供主业务层使用，每个组件是一个工程，如登录、分享、推送、IM 等，我们把 Hybrid 框架也归在业务层。其中登录组件我们做成 Passport SDK，供公司其他 App 集成调用。
主业务包括 App 首页、个人中心、各业务线业务和第三方接入业务，业务线业务主要包括发布、大类、列表、详情。
集成管理组件 工程拆分完后，就是工程集成了，我们用 Cocoapods 将各工程集成到一起编译运行和打包，对于每一个工程配置好.podspec 文件。在配置 podfile 文件时，当用于本地开发时，我们通过 path 的方式进行集成，不用临时下载工程代码，如下所示。 Path代码
pod proj, :path => '~/58_ios_libs/proj’
在进行 Jenkins 打包时，我们通过 Git 方式将代码实时下载： Git 代码
pod proj, :git => 'git@gitlab.58corp.com:58_ios_team/proj.git',:branch => '1.0.0'。
GitLab 服务进行代码管理 我们在局域网搭建一个 GitLab 服务，用于管理所有工程代码，并设置好开发组及相应的权限。通过 GitLab 还可以实现提交代码审核、代码合并请求及工程分支保护。 第四版架构 随着 58 App 用户量的剧增，各业务线业务迅速增长，对 58 App 又提出了新需求，如为加快大类列表详情页面的渲染速度，需要将原来这些 HTML5 页面 Native 化；再如各业务线要定制列表详情和筛选样式。面对如此众多需求，显然原来的架构已经满足不了，那就需要我们进一步改进客户端架构，将主业务层进一步拆分。 主业务层拆分 我们对主业务层进行一个拆分，拆分后的整体架构如图 9 所示，其中每一个模块为一个工程，也是一个组件。
图 9 第四版架构
我们将首页、发布、发现、消息中心、个人中心及第三方业务等都从主业务层拆分出来成为独立工程。同样将房产、二手、二手车、黄页、招聘等业务线的代码从原工程里面剥离出来，每个业务线独立一工程，将列表和详情分别剥离出来并进行 Native 化，为上层业务线定制功能提供接口。 业务线拆分的时候我们遵循以下几个原则： 各业务线之间不能有依赖关系，因为我们的业务线在开发的整个过程中都是独立运行的，不会含有其他业务线代码。
非业务线工程不能对各业务线有依赖关系，即所有业务线都不集成进 App 也要能正常编译。
各业务线对非业务线工程可以保留必要的依赖，如业务线对列表组件的依赖。
在拆分过程中我们也采取了一些策略，如在拆分招聘业务线时，先把招聘业务线从集成后的工程中删除，进行编译，会出现各种编译错误，说明是有工程对招聘业务线代码进行依赖。如何解决这些依赖关系呢？我们主要是解决相互依赖关系，招聘业务线对非业务线工程肯定是有一定的依赖关系，这个先保留，我们要解决的是其他组件甚至可能是其他业务线对招聘的依赖。我们总结了下，主要用了以下几种方式： 将依赖的文件或方法下沉，如有些文件并不是招聘业务线专用的，可以从招聘中下沉到其他工程，同样有些方法也可以下沉。
Runtime，这种方式比较普遍，但也不需要所有地方都用，毕竟其维护成本还是比较高的。
Category 方式，如个人中心组件中方法 funA 要调用招聘组件中的方法 funB，但 funB 的实现是要依赖招聘内部代码，这种情况下个人中心是依赖招聘业务线的，理论上招聘可以依赖个人中心，而不应该反过来依赖。解决办法是可以在个人中心添加一个类，如 ClassA，里面添加方法 funB，但实现为空，如果带返回值可以返回一个默认值，再在招聘中添加一个 ClassA 的类别 ClassA+XX，将原来招聘中的方法 funB 放入 ClassA+XX，这样如果招聘集成进来，就会执行 ClassA+XX 中的 funB 方法，否则执行个人中心自己的 funB 方法。
跳转总线 总线包括 UI 总线和服务总线，前者主要处理组件间页面间的跳转，尤其是在主业务层，UI 总线用得比较频繁。服务总线主要处理组件间的服务调用，这里主要讲跳转总线。在主业务层，被封装成的各个组件需要通过 UI 总线进行页面跳转，我们设计了一个总分发中心和子分发中心的模式进行处理，如图 10 所示。
图 10 UI 跳转总线主业务层每个组件内都有一个子分发中心，它的处理逻辑由各组件内来进行，但必须实现一些共同的接口，且这个子分发中心需要进行注册。当组件内需要进行 UI 跳转时，调用总分发中心，将跳转协议传入总分发中心，总分发中心根据协议中组件标识（如业务线标识）找到对应的目标组件子分发中心，将跳转协议透传到对应的子分发中心。接下来的跳转由子分发中心去完成。这样的方式极大降低了组件间的耦合度。 UI 总线中的跳转协议我们原来用 JSON 形式，后来统一调整为 URL 的方式，将 m 调起、浏览器调起、push 调起、外部 App 调起和 App 内跳转统一处理。 新统跳协议 URL 格式如下： Url 格式代码
wbmain://jump/job/list? ABMark＝markID¶ms=
其中，wbmain 为 58 App 的 scheme，job 为招聘业务线标识，list 为到列表页，ABMark 为 AB 测跳转用的标识 ID，后面会细讲，params 为传过来的一些参数，如是否需要动画，push 还 present 方式入栈等。为了兼容老协议，我们将原来协议中的一部分内容直接透传到 params 中。 AB 测跳转 对于指定跳转 URL，有时跳转的目标页面是不固定的，如我们的发布页面，有 HTML5 和 React Native 两套页面，如果 React Native 页面出了问题，可以将 URL 做修改跳到 HTML5 页面。具体方案是服务器下发一个路由表，每个表项有一个 ID 和对应新的跳转 URL，每个表项设置有过期时间。跳转的 URL 可以带有 AB 测跳转用的标识 ID，即 markID。如果有这个标识，跳转时就去与路由表中的表项匹配，如果命中就改用路由表中的 URL 跳转，否则还用原来的 URL 执行跳转，大概流程如图 11 所示。
图 11 AB 测跳转流程图
静态库方案 为了提高整个 App 的编译速度，我们为每个工程配置一个对应的库工程，里面预先由源码工程编译出来一个对应的静态库，如图 12 所示。
点击查看原始大小图片
图12 源码库与静态库对应关系
开发人员可以将权限内的源码和静态下载到本地，按需进行源码和库混合集成，如对于招聘业务线 RD，我们只需关心招聘业务线源码工程，不需要其他业务线的源码或静态库，剩下的工程可以选择全部用静态库进行集成。对于 Jenkins 打包平台，我们也可以根据需求适当在源码和静态库之间做选择。对于一些特殊的工程，如第三方库工程 ThirdComponent，一般也不会变，可以直接接入对应的静态库工程 ThirdComponentLib。 总结 业务在不断变化，需求持续增多，技术也在不断地更新，我们的架构也需要不断进行调整和升级，架构的演进是一项长期的任务。
一：项目中存在的问题
1：当公司里面有多个项目同时进行，并且有可能是多个人分别不同项目时，就会存在如上图出现的情况，其实每个APP中都是有很多共同的模块，当然有可能你会把相同功能模块代码复制一份在新项目中，但这其实并不是最好的方式，在后期不断迭代过程中，不同的人会往里面增加很多带有个人色彩的代码；这样就像相同的模块项目后期对于多个项目统一管理也是灾难性，有可能会失控，哪怕项目转移别人接手也会无形中浪费很多时间，增加维护成本，所以实例中更注重对于一些相同模块进行提取，求同存异；而模块化结合私有Pods进行管理，对于常用功能的封装，只要开放出一些简单开关配置方式，就可以实现一个功能，比如日志记录、网络请求模块、网络状态变化提示等；
1475118858296891.png
2：对于页面之间相互耦合，而页面之间的传参也各不相同，由于不同的开发人员或者简便方式等原因，传参的类型都有差异，包含如实体、简单基本类型等，先前项目对于路由方式也不支持，导致要实现收到消息推送进行不同的页面跳转存在硬编码情况，对于功能扩展存在相当大的问题；而右边则是模块化后页面之间的交互方式；页面之间也不存在耦合关系，都只跟JiaMediator这个中介者相依赖；而传参都统一成以字典的形式；虽然可能牺牲一些方便跟随意，却可以解耦模块化；并且加入对路由方式的处理；约定好相关的协议进行交互；用这种路由方式代替那些第三方的路由插件则是因为它的灵活性，最主要还是省去了第三方路由插件在启动时要注册路由的问题；
1475118906669398.png
二：解决方案实现之模块化
1：JiaCore(基础功能封装)
JiaCore是整个APP最基础模块，所有的模块化都要依赖，主要包含一些全局的功能模块，比如JiaBaseViewController、JiaAppDelegate等；目前已经把一些默认的功能进行集成在里面，包含网络状态变化判断及提示、日志记录功能等；并把一些相关配置的内容用JiaCoreConfigManager这个管理类进行统一设置，比如是否打开日志记录功能；JiaCoreConfigManager类则是开放给具体APP设置全局的相关配置；下面就以其中一个日志记录功能进行讲解:
//JiaCore基础模块相关配置JiaCoreConfigManager *jiaCoreConfig=[JiaCoreConfigManager sharedInstance];jiaCoreConfig.recordlogger=YES;
然后具体APP的PrefixHeader.pch引入命名空间并进行设置记录日志的等级：
import "JiaCocoaLumberjack.h"//DDLog等级static const int ddLogLevel = DDLogLevelVerbose;
这样就完成的一个APP对于日志记录模块的引入，JiaCore已经帮你完成的关于日志记录的相关配置，并且错误内容以一种可读性较好的格式记录到file文件中，而且这些file文件生成规则也都定义好了，当然如何时你要是在Xcode控制台显示不同等级色彩，只要安装XcodeColors插件并简单进行设置就可以了，对于不同等级不同色彩都已经在JiaCore配置完成；
2：JSPatch热更新功能
在JiaCore里面也默认集成了热更新的功能，只要传入简单的对象数组就会启动热更新；其中JiaPathchModel已经是定义好的模型，在APP中把接口请求转化成模型数组，其中patchId是唯一值名称、md5则是JS文件的MD5值、url是JS的下载路径、ver则是对哪个版本起作用；因为一般我们在外面的APP都是多版本共存，热更新也要进行版本区分，只下载与本版本相对应的热更新JS文件加载；而MD5值则是为了增加安全性，避免JS文件被别人进行修改而影响APP的运行，在JiaCore会对下载后的JS文件进行MD5计算并比较；对于没有在jSPatchMutableArray以前的JS文件会被删除；
//热更新内容JiaPathchModel *sample=[[JiaPathchModel alloc]init];sample.patchId = @"patchId_sample1";sample.md5 = @"2cf1c6f6c5632dc21224bf42c698706b";sample.url = @"http://test.qshmall.net:9090/demo1.js";sample.ver = @"1";JiaPathchModel *sample1=[[JiaPathchModel alloc]init];sample1.patchId = @"patchId_sample2";sample1.md5 = @"e8a4eaeadce5a4598fb9a868e09c75fd";sample1.url = @"http://test.qshmall.net:9090/demo2.js";sample1.ver = @"1";//JiaCore基础模块相关配置JiaCoreConfigManager *jiaCoreConfig=[JiaCoreConfigManager sharedInstance];jiaCoreConfig.jSPatchMutableArray=[@[sample,sample1] mutableCopy];
3：JiaGT模块(个推封装)
消息推送对于一个APP是相当重要性，一般是采用第三方的SDK进行集成，其实大部分的SDK处理代码都是差不多，在这实例中对差异化的内容进行提取，实例中将以个推进行模块化，因为消息推送的大部分代码都集中在AppDelegate中，造成的一大堆杂乱代码，当然也有一部分人对AppDelegate进行扩展分类进行移除代码，实例中将采用另外一种解决方案进行抽取，可以达到完全解耦，在具体的APP里面将不会再出现个推SDK相关内容，只要简单进行配置跟处理消息就可以，下面只是简单的列出部分代码，其它封装代码见源代码；
//设置个推模块的配置jiaGTConfigManager *gtConfig=[jiaGTConfigManager sharedInstance];gtConfig.jiaGTAppId=@"0uuwznWonIANoK07JeRWgAs";gtConfig.jiaGTAppKey=@"26LeO4stbrA7TeyMUJdXlx3";gtConfig.jiaGTAppSecret=@"2282vl0IwZd9KL3ZpDyoUL7";
JiaAnalytics模块是在友盟统计SDK跟Aspect相结合基础上完成，对于页面的进出统计采用Aop切面方式进行，把原本应该在每个页面生命周期的统计代码移除，App运用只要简单配置友盟相对应的信息，也可以设置要统计页面的过滤条件，目前已经有三种如要统计的开头页面的前缀字符串数组、要统计的页面名称字符串数组、不统计的页面名称字符串数组；可以结合使用，达到精确统计页面的目的；而且把统计的代码放在异步线程进行，不会影响主线程的响应；
三：解决方案实现之页面解耦
JiaMediator起到一个中介的作用，所有的模块间响应交互都是通过它进行，每个模块都会对它进行扩展分类（例如：JiaMediator+模块A），分类主要是为了用于本地间调用而又不想用路由的方式，若要用路由的方式则要注意关于路由约束准确编写，它将会直接影响到能否正确响应到目标；实例中也有关于使用通知的方式进行回调参数的回传问题；这部发页面解耦也是参照网络上大部分的实现方式，并对它进行修改；基本上满足我们平时开发的要求；
四：模块化结合私有Pods方案
实例中只是把相关模块化的提取都在一个工程进行体现，最后还是要落实结合Pods进行管理，把每个模块分开管理，不同的APP可以简单通过Pods指令就可以达到引入模块的效果，对于一些相同模块可以在不同的APP重复引用，减小重复开发成本；
1475119280170360.png
项目中已经引入的Pod来管理目前开发的几个模块，并导入在我目前的Github的一个库里Spec进行统一管理，首先要引入Pod来管理则要增加jiaModule.podspec文件；
标准组件化架构设计
这个章节叫做“标准组件化架构设计”，对于项目架构来说并没有绝对意义的标准之说。这里说到的“标准组件化架构设计”只是因为采取这样的方式的人比较多，且这种方式相比而言较合理。
在上面文章中提到了casatwy方案的CTMediator，蘑菇街方案的MGJRouter和ModuleManager，下面统称为中间件。整体架构组件化架构中，首先有一个主工程，主工程负责集成所有组件。每个组件都是一个单独的工程，创建不同的git私有仓库来管理，每个组件都有对应的开发人员负责开发。开发人员只需要关注与其相关组件的代码，其他业务代码和其无关，来新人也好上手。
组件的划分需要注意组件粒度，粒度根据业务可大可小。组件划分后属于业务组件，对于一些多个组件共同的东西，例如网络、数据库之类的，应该划分到单独的组件或基础组件中。对于图片或配置表这样的资源文件，应该再单独划分一个资源组件，这样避免资源的重复性。
服务方组件对外提供服务，由中间件调用或发现服务，服务对当前组件无侵入性，只负责对传递过来的数据进行解析和组件内调用的功能。需要被其他组件调用的组件都是服务方，服务方也可以调用其他组件的服务。
通过这样的组件划分，组件的开发进度不会受其他业务的影响，可以多个组件单独的并行开发。组件间的通信都交给中间件来进行，需要通信的类只需要接触中间件，而中间件不需要耦合其他组件，这就实现了组件间的解耦。中间件负责处理所有组件之间的调度，在所有组件之间起到控制核心的作用。
这套框架清晰的划分了不同组件，从整体架构上来约束开发人员进行组件化开发，避免某个开发人员偷懒直接引用头文件，产生组件间的耦合，破坏整体架构。假设以后某个业务发生大的改变，需要对相关代码进行重构，可以在单个组件进行重构。组件化架构降低了重构的风险，保证了代码的健壮性。
组件集成
组件化架构图
每个组件都是一个单独的工程，在组件开发完成后上传到git仓库。主工程通过Cocoapods集成各个组件，集成和更新组件时只需要pod update即可。这样就是把每个组件当做第三方来管理，管理起来非常方便。
Cocoapods可以控制每个组件的版本，例如在主项目中回滚某个组件到特定版本，就可以通过修改podfile文件实现。选择Cocoapods主要因为其本身功能很强大，可以很方便的集成整个项目，也有利于代码的复用。通过这种集成方式，可以很好的避免在传统项目中代码冲突的问题。
集成方式对于组件化架构的集成方式，我在看完bang的博客后专门请教了一下bang。根据在微博上和bang的聊天以及其他博客中的学习，在主项目中集成组件主要分为两种方式——源码和framework，但都是通过CocoaPods来集成。无论是用CocoaPods管理源码，还是直接管理framework，效果都是一样的，都是可以直接进行pod update之类的操作的。这两种组件集成方案，实践中也是各有利弊。直接在主工程中集成代码文件，可以在主工程中进行调试。集成framework的方式，可以加快编译速度，而且对每个组件的代码有很好的保密性。如果公司对代码安全比较看重，可以考虑framework的形式，但framework不利于主工程中的调试。
例如手机QQ或者支付宝这样的大型程序，一般都会采取framework
的形式。而且一般这样的大公司，都会有自己的组件库，这个组件库往往可以代表一个大的功能或业务组件，直接添加项目中就可以使用。关于组件化库在后面讲淘宝组件化架构的时候会提到。
不推荐的集成方式之前有些项目是直接用workspace的方式集成的，或者直接在原有项目中建立子项目，直接做文件引用。但这两点都是不建议做的，因为没有真正意义上实现业务组件的剥离，只是像之前的项目一样从文件目录结构上进行了划分。
组件化开发总结对于项目架构来说，一定要建立于业务之上来设计架构。不同的项目业务不同，组件化方案的设计也会不同，应该设计最适合公司业务的架构。
架构对比在除蘑菇街Protocol方案外，其他两种方案都或多或少的存在硬编码问题，硬编码如果量比较大的话挺麻烦的。在casatwy的CTMediator方案中需要硬编码Target、Action字符串，只不过这个缺陷被封闭在中间件里面了，将这些字符串都统一定义为常量，外界使用不需要接触到硬编码。蘑菇街的MGJRouter的方案也是一样的，也有硬编码URL的问题，蘑菇街可能也做了类似的处理。
casatwy和蘑菇街提出的两套组件化方案，大体结构是类似的，三套方案都分为调用方、中间件、服务方，只是在具体实现过程中有些不同。例如Protocol
方案在中间件中加入了Protocol
文件，casatwy的方案在中间件中加入了Category
。三种方案内部都有容错处理，所以三种方案的稳定性都是比较好的，而且都可以拿出来单独运行，在服务方不存在的情况下也不会有问题。
在三套方案中，服务方都对外提供一个供外界调用的接口类，这个类中实现组件对外提供的服务，中间件通过接口类来实现组件间的通信。在此类中统一定义对外提供的服务，外界调用时就知道服务方可以做什么。
调用流程也不大一样，蘑菇街的两套方案都需要注册操作，无论是Block
还是Protocol
都需要注册后才可以提供服务。而casatwy的方案则不需要，直接通过runtime
调用。casatwy的方案实现了真正的对服务方解耦，而蘑菇街的两套方案则没有，对服务方和调用方都造成了耦合。
我认为三套方案中，Protocol方案是调用和维护最麻烦的一套方案。维护时需要同时维护Protocol、接口类两部分。而且调用时需要将服务方的接口类返回给调用方，并由调用方执行一系列调用逻辑，调用一个服务的逻辑非常复杂，这在开发中是非常影响开发效率的。
总结
下面是组件化开发中的一个小总结，也是开发过程中的一些注意点。在MGJRouter方案中，是通过调用OpenURL:方法并传入URL来发起调用。鉴于URL协议名等固定格式，可以通过判断协议名的方式，使用配置表控制H5和native的切换，配置表可以从后台更新，只需要将协议名更改一下即可。
mgj://detail?id=123456
http://www.mogujie.com/detail?id=123456
假设现在线上的native组件出现严重bug，在后台将配置文件中原有的本地URL换成H5的URL，并更新客户端配置文件。在调用MGJRouter时传入这个H5的URL即可完成切换，MGJRouter判断如果传进来的是一个H5的URL就直接跳转webView。而且URL可以传递参数给MGJRouter，只需要MGJRouter内部做参数截取即可。
casatwy方案和蘑菇街Protocol方案，都提供了传递明确类型参数的方法。在MGJRouter方案中，传递参数主要是通过类似GET请求一样在URL后面拼接参数，和在字典中传递参数两种方式组成。这两种方式会造成传递参数类型不明确，传递参数类型受限(GET请求不能传递对象)等问题，后来使用Protocol方案弥补这个问题。
组件化开发可以很好的提升代码复用性，组件可以直接拿到其他项目中使用，这个优点在下面淘宝架构中会着重讲一下。
对于调试工作，应该放在每个组件中完成。单独的业务组件可以直接提交给测试提测，这样测试起来也比较方便。最后组件开发完成并测试通过后，再将所有组件更新到主项目，提交给测试进行集成测试即可。
使用组件化架构开发，组件间的通信都是有成本的。所以尽量将业务封装在组件内部，对外只提供简单的接口。即“高内聚、低耦合”原则。
把握好划分粒度的细化程度，太细则项目过于分散，太大则项目组件臃肿。但是项目都是从小到大的一个发展过程，所以不断进行重构是掌握这个组件的细化程度最好的方式。
我公司架构
下面就简单说说我公司项目架构，公司项目是一个地图导航应用，业务层之下的基础组件占比较大。且基础组件相对比较独立，对外提供了很多调用接口。刚开始想的是采用MGJRouter
的方案，但如果这些调用都通过Router
进行，开发起来比较复杂，反而会适得其反。最主要我们项目也并不是非常大，没必要都用Router
转发。
对于这个问题，公司项目的架构设计是：层级架构+组件化架构，组件化架构处于层级架构的最上层，也就是业务层。采取这种结构混合的方式进行整体架构，这个对于公共组件的管理和层级划分比较有利，符合公司业务需求。
公司组件化架构
对于业务层级依然采用组件化架构的设计，这样可以充分利用组件化架构的优势，对项目组件间进行解耦。在上层和下层的调用中，下层的功能组件应该对外开放一个接口类，在接口类中声明所有的服务，实现上层调用当前组件的一个中转，上层直接调用接口类。这样做的好处在于，如果下层发生改变不会对上层造成影响，而且也省去了部分Router
转发的工作。
在设计层级架构时，需要注意只能上层对下层依赖，下层对上层不能有依赖，下层中不要包含上层业务逻辑。对于项目中存在的公共资源和代码，应该将其下沉到下层中。
为什么这么做？
首先就像我刚才说的，我公司项目并不是很大，根本没必要拆分的那么彻底。
因为组件化开发有一个很重要的原因就是解耦合，如果我做到了底层不对上层依赖，这样就已经解除了上下层的相互耦合。而且上层对下层进行调用的时候，也不是直接调用下层，通过一个接口类进行中转，实现了下层的改变对上层无影响，这也是上层对下层解耦的表现。
所以对于第三方就不用说了，上层直接调用下层的第三方也是没问题的，这都是解耦的。
模型类怎么办，放在哪合适？
casatwy对模型类的观点是去Model化，简单来说就是用字典代替Model
存储数据。这对于组件化架构来说，是解决组件之间数据传递的一个很好的方法。
因为模型类是关乎业务的，理论上必须放在业务层也就是业务组件这一层。但是要把模型对象从一个组件中当做参数传递到另一个组件中，模型类放在调用方和服务方的哪个组件都不太合适，而且有可能不只两个组件使用到这个模型对象。这样的话在其他组件使用模型对象，必然会造成引用和耦合。
那么如果把模型类放在Router中，这样会造成Router耦合了业务，造成业务的侵入性。如果在用到这个模型对象的所有组件中，都分别维护一份相同的模型类，这样之后业务发生改变模型类就会很麻烦。
那应该怎么办呢？
如果将模型类单独拉出来，定义一个模型组件呢？这个看起来比较可行，将这个定义模型的组件下沉到下层，模型组件不包含业务，只声明模型对象的类。但是一般组件的模型对象都是当前组件内使用的，将模型对象传递给其他组件的需求非常少，那所有的模型类都定义到模型组件吗？
对于这个问题，我建议在项目开发中将模型类还定义在当前业务组件中，在组件间传递模型对象时进行去Model化，传递字典类型的参数。上面只是思考，恰巧我公司持久化方案用的是CoreData，所有模型的定义都在CoreData组件中，这样就避免了业务层组件之间因为模型类的耦合。滴滴组件化架构之前看过滴滴iOS负责人李贤辉的技术分享，分享的是滴滴iOS客户端的架构发展历程，下面简单总结一下。
发展历程滴滴在最开始的时候架构较混乱。然后在2.0时期重构为MVC架构，使项目划分更加清晰。在3.0时期上线了新的业务线，这时采用的游戏开发中的状态机机制，暂时可以满足现有业务。
然而在后期不断上线顺风车、代驾、巴士等多条业务线的情况下，现有架构变得非常臃肿，代码耦合严重。从而在2015年开始了代号为“The One”的方案，这套方案就是滴滴的组件化方案。
架构设计滴滴的组件化方案，和蘑菇街方案类似，也是通过私有CocoaPods来管理各个组件。将整个项目拆分为业务部分和技术部分，业务部分包括专车、拼车、巴士等业务模块，每个业务模块就是一个单独的组件，使用一个pods管理。技术部分则分为登录分享、网络、缓存这样的一些基础组件，分别使用不同的pods管理。
组件间通信通过ONERouter中间件进行通信，ONERouter类似于MGJRouter，担负起协调和调用各个组件的作用。组件间通信通过OpenURL方法，来进行对应的调用。ONERouter内部保存一份Class-URL的映射表，通过URL找到Class并发起调用，Class的注册放在+load方法中进行。
滴滴在组件内部的业务模块中，模块内部使用MVVM+MVCS混合架构，两种架构都是MVC的衍生版本。其中MVCS中的Store负责数据相关逻辑，例如订单状态、地址管理等数据处理。通过MVVM中的VM给控制器瘦身，最后Controller的代码量就很少了。
滴滴首页分析
滴滴文章中说道首页只能有一个地图实例，这在很多地图导航相关应用中都是这样做的。滴滴首页主控制器持有导航栏和地图，每个业务线首页控制器都添加在主控制器上，并且业务线控制器背景都设置为透明，将透明部分响应事件传递到下面的地图中，只响应属于自己的响应事件。
由主控制器来切换各个业务线首页，切换页面后根据不同的业务线来更新地图数据。
淘宝组件化架构
客户端初期是单工程的普通项目，但随着业务的飞速发展，现有架构并不能承载越来越多的业务需求，导致代码间耦合很严重。后期开发团队对其不断进行重构，淘宝iOS和Android两个平台，除了某个平台特有的一些特性或某些方案不便实施之外，大体架构都是差不多的。发展历程：刚开始是普通的单工程项目，以传统的MVC架构进行开发。随着业务不断的增加，导致项目非常臃肿、耦合严重。
2013年淘宝开启"all in 无线"计划，计划将淘宝变为一个大的平台，将阿里系大多数业务都集成到这个平台上，造成了业务的大爆发。淘宝开始实行插件化架构，将每个业务模块划分为一个组件，将组件以framework二方库的形式集成到主工程**。但这种方式并没有做到真正的拆分，还是在一个工程中使用git进行merge，这样还会造成合并冲突、不好回退等问题。迎来淘宝移动端有史以来最大的重构，将其重构为组件化架构。将每个模当做一个组件，每个组件都是一个单独的项目，并且将组件打包成framework。主工程通过podfile集成所有组件framework，实现业务之间真正的隔离，通过CocoaPods实现组件化架构。
架构优势
淘宝是使用git来做源码管理的，在插件化架构时需要尽可能避免merge操作，否则在大团队中协作成本是很大的。而使用CocoaPods进行组件化开发，则避免了这个问题。在CocoaPods中可以通过podfile很好的配置各个组件，包括组件的增加和删除，以及控制某个组件的版本。使用CocoaPods的原因，很大程度是为了解决大型项目中，代码管理工具merge代码导致的冲突。并且可以通过配置podfile文件，轻松配置项目。每个组件工程有两个target，一个负责编译当前组件和运行调试，另一个负责打包framework。先在组件工程做测试，测试完成后再集成到主工程中集成测试。每个组件都是一个独立app，可以独立开发、测试，使得业务组件更加独立，所有组件可以并行开发。下层为上层提供能满足需求的底层库，保证上层业务层可以正常开发，并将底层库封装成framework集成到项目中。使用CocoaPods进行组件集成的好处在于，在集成测试自己组件时，可以直接将本地主工程podfile文件中的当前组件指向本地**，就可以直接进行集成测试，不需要提交到服务器仓库。
淘宝四层架构
淘宝四层架构(图片来自淘宝技术分享)
淘宝架构的核心思想是一切皆组件，将工程中所有代码都抽象为组件。淘宝架构主要分为四层，最上层是组件Bundle(业务组件)，依次往下是容器(核心层)，中间件Bundle(功能封装)，基础库Bundle(底层库)。容器层为整个架构的核心，负责组件间的调度和消息派发。
总线设计：URL
路由+服务+消息。统一所有组件的通信标准，各个业务间通过总线进行通信。
总线设计(图片来自淘宝技术分享)
URL可以请求也可以接受返回值，和MGJRouter差不多。URL路由请求可以被解析就直接拿来使用，如果不能被解析就跳转H5页面。这样就完成了一个对不存在组件调用的兼容，使用户手中比较老版本依然可以显示新的组件。服务提供一些公共服务，由服务方组件负责实现，通过Protocol实现。消息负责统一发送消息，类似于通知也需要注册。
Bundle App
Bundle App(图片来自淘宝技术分享)
淘宝提出Bundle App的概念，可以通过已有组件，进行简单配置后就可以组成一个新的app出来。解决了多个应用业务复用的问题，防止重复开发同一业务或功能。Bundle即App，容器即OS，所有Bundle App被集成到OS上，使每个组件的开发就像app开发一样简单。这样就做到了从巨型app回归普通app的轻盈，使大型项目的开发问题彻底得到了解决。
去model化这个说法其实有点儿难听，model化就是使用数据对象，去model化就是不使用数据对象。所以这篇文章主要讨论的问题就是：数据传递时，是否要采用数据对象？这里的数据传递并不是说类似RPC的场景，而是在单个工程内部，各对象之间、各组件之间、各层之间的数据传递。
所谓数据对象，就是把不同类型的数据映射到不同类型的对象上，这个对象仅用于表达数据，数据通过对象的property来体现。瘦Model、贫血模型就属于这一类。
去Model化，就是不使用特定对象迎合特定数据的映射的方式，来表达数据。比如我们可以使用NSDictionary，或者其他手段例如reformer、virtual record，来避免这种数据映射对象。
关于这个问题的讨论涉及以下内容：
如何理解面向对象思想
为什么不使用数据对象
去Model化都有哪些手段
通过以上三点，我希望能够帮助大家建立对面向对象的正确理解，让大家明白如何权衡是否要采用对象化的设计。以及最终当你决定不采用对象化思想而采用非对象化思想时，应该如何进行架构设计。
如何理解面向对象思想
面向对象的思想简单总结一下就是：将一个或多个复杂功能封装成为一个聚合体，这个聚合体经过抽象后，仅暴露少部分方法，这些方法向外部获取实现功能所需要的条件后，就能完成对应功能。传统的面向过程只针对功能的实现做了封装，也就是函数。经过这层封装后，仅暴露参数列表和函数名，用于外部调用者调用并完成功能。
我们可以推导出：函数封装了实现功能所需要的代码，因此对象实质上就是再次对函数进行了封装。将函数集合在一起，形成一个函数集合，面向对象思想的提出者把这个函数集合称之为对象，把对象的概念从理论映射到实际的工程领域，我们也可以叫它类。
然而我们很快就能发觉，只是单纯地把函数集合在一起是不够的，这些函数集有可能互相之间需要共用参数或共享状态。因此面向对象的理论设计者让对象自己也能够提供属性（property），来满足函数集间共用参数和共享状态的需求。这个函数集现在有了更贴切的说法：领域。因此当这个领域中的个别函数不需要共用参数或共享状态，仅仅是提供功能时，这些相关函数就可以体现为类方法。当领域里的函数需要共用参数或共享状态时，这些函数的体现就是实例方法。
这里补充一下，领域的概念我们更多会把它理解得比较大，比如多个相关对象形成一个领域。但一个对象自身所包含的所有函数也是一个领域，是大领域里的一个子领域。
以上就是一个对面向对象思想的朴素理解。在这个理解的基础上，还衍生出了非常多的概念，不过这并不在本文的讨论范围中。
总之，一个对象事实上是对一个较小领域的一种封装。对应到本文要讨论的问题来看，如果拿一个对象去表达一套数据而非一个领域，这在一定程度上是违背面向对象的设计初衷的。你看着好像是把数据对象化了，就是面向对象编程了，然而事实上并非如此。Martin Fowler早年也在他的《Anemic Domain Model》中提出了一样的看法：
The fundamental horror of this anti-pattern is that it’s so contrary to the basic idea of object-oriented design; which is to combine data and process together. The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk. What’s worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.
为什么不使用数据对象
根据上一小节的内容，我们可以把对象抽象地理解为一个函数集，一个领域。在这一节里，我们再进一步推导：如果这些函数集里的所有函数，并不都是处在同一个问题领域内，那么面向对象的这种实践是否依旧成立？
答案是成立的，但显然我们并不建议这么做。不同领域的函数集如果被封装在了一起，在实际工程中，这种做法至少会带来以下问题：
当需要维护某个问题领域内的函数时，如果修改到某个需要被共用的参数或者需要被共享的对象，那么其他问题领域也存在被影响的可能。牵一发而动全身，这是我们不希望看到的。
当需要解决某个问题时，如果引入了某个充满了各种不同问题领域的函数集，这实质就是引入了对不同问题领域解决方案的依赖。当需要做代码迁移或复用时，就也要把不相关的解决方案一并引入。拔出萝卜带出泥，这也是我们不希望看到的。
当需要维护某个问题领域内的函数时，如果修改到某个需要被共用的参数或者需要被共享的对象，那么其他问题领域也存在被影响的可能。牵一发而动全身，这是我们不希望看到的。
我们在进行对象化设计时，必须要分割好问题域，才能保证设计出良好的架构。
业界所谓的各种XX建模、XX驱动设计、XXP，大部分其实都是在强调合理分割
这一点，他们提供不同的方法论去告诉你应该如何去做分割的事情，以及如何把分割出来的部分再进一步做封装。然而这些XX概念要成立的话，就都一定需要具备这样一个前提条件：一个被封装出来的对象的活动领域，必须要小于等于当前被分割出来的子问题领域。如果不符合这个前提条件的话，一个大的问题领域即使被强行分割成各种小的问题领域，这些小的问题领域还是依旧难以被封装成为对象，因为对象的跨领域活动势必就要引入其它领域的问题解决方案，这就使得分割名不副实。
然而，一个被封装出来的对象的活动领域，必须要小于等于当前被分割出来的子问题领域这个前提在实际业务场景实践中，是否一定成立呢？如果一定成立的话，那么这种做法和这些方法论就是没问题的。如果在某些场景中不成立，对象化设计在这些场景就有问题了。
事实上，这个前提在实际业务场景中，是不一定成立的。在实际业务场景中，一个数据对象被多个业务领域使用是非常常见的。一个数据对象在不同层、不同模块中被使用也是非常常见的。所以，如果两个业务对象之间需要传递的仅是数据，在这个场景下就不适合传递对象化的数据。
当需要解决某个问题时，如果引入了某个充满了各种不同问题领域的函数集，这实质就是引入了对不同问题领域解决方案的依赖。当需要做代码迁移或复用时，就也要把不相关的解决方案一并引入。拔出萝卜带出泥，这也是我们不希望看到的。
这种场景其实就很好理解了。实际工程中，对象化数据往往不是一个独立存在的对象，而是依附于某一个领域。例如持久层提供的对象化数据，往往依附于持久层。网络层提供的对象化数据往往依附于网络层。当你的业务层某个模块使用来自这些层的对象化数据时，将来要迁移这个模块，就必须不得不把持久层或者网络层也跟着迁移过去。迁移发生的场景之一就是大型工程的组件化拆分，实施组件化时遇到这种问题是一件非常伤脑筋的事情。
去model化是一种框架设计上的做法，其中的model并不是指架构中的model层，套用Casa大神博客中的原文就是：model化就是使用数据对象，去model化就是不使用数据对象。
常见的去model化做法是使用字典保存数据信息，然后提供一个reformer负责将这些字典数据转换成View层可展示的信息，其流程图如下：
更详细的理论知识可以看Casa大神的去model化和数据对象。本文基于Casa大神的实践基础使用另外一种去model化的实现方式。
此外，优惠信息属于第一个和第二个独有的。现在这一需求存在的问题主要有这么三点：
三种数据对象在服务器返回的属性字段中命名差别大这是大部分的应用都存在的一个问题，但是本文中的数据对象有一个显著的特点是它们对应显示的cell
存在很大的相似度，可以被转换成相似的展示数据三种cell可以封装成一种，却分别对应着不同的数据对象这里涉及cell和数据对象的对接问题，如果cell在以后发生改变了，那么原有的数据对象是否还能适用控制器需要在数据源方法中调配不同的cell和model，耦合过大**这个也是常见的问题之一，通常可以考虑适用工厂模式将调配的业务分离出去，但在本文中采用去model
的方式实现
这些问题都有可能导致项目后期维护的过程中变得难以修改，小小的需求改动都会导致代码的大改。笔者的解决方式是制定cell和model之间对应的两个协议，从而控制器无需理会两者的具体类型。实现M层的业务逻辑放在model中，虽然本文要去model化，但只是去除属性对象，自身的逻辑处理还保留着。下面是笔者去model化的协议图以及协议声明属性：
对于本文之中这种存在共同显示效果的model，可以声明一个包含多个readonly属性的协议，让这些模型对象在协议的getter方法中执行数据->展示这一过程的业务逻辑，而model自身只需简单的持有字典数据即可：
字典数据->展示数据
通过让三个数据对象实现这个协议，将要展示的数据结果进行统一。在这种情况下，封装成单个的cell也无需关心model的具体类型是什么，只需实现针对单元格配置的协议方法获取展示的数据即可：
三个问题前两个已经解决了：通过协议统一数据对象的展示效果，这时候并不需要model保存多个属性对象，只需要在适当的时候直接从字典中获取数据并执行数据可视化这一逻辑即可。cell也不会受限于传入的参数类型，只需要简单的调用协议方法获取需要的数据即可。那么最后一个控制器的协调问题就变得简单了：
当cell和model共同通过协议的方式实现交流的时候，控制器存储的数据源也就可以不关心这些对象的具体类型了。通过泛型声明多个数据源，控制器此时的职责仅仅是根据状态机的改变决定使用哪个数据源来展示而已。当然，虽然笔者统一了这三个数据源的类型，但是归根到底总要根据服务器返回的json创建不同的数据对象存放到这些数据源中。如果把这个业务放在控制器中原本就达不到松耦合的作用，因此引入一个中间人Helper来完成这个业务：
去model化之后整个项目的业务流程大致可以用下图表示：
这种方式最大的好处在于控制器和视图不再依赖于model的具体类型，这样在服务器返回的json中修改了模型对象字段的时候，修改ModelProtocol的对应实现即可。甚至在以后的版本再添加现金券各种其他票券的时候，只需要在Helper这一环节添加相应的工厂即可完成改动。
