滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈

分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友 微信微信
查看查看483 回复回复8 收藏收藏2 分享淘帖 转播转播 分享分享1 微信
查看: 483|回复: 8
收起左侧

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈

[复制链接]
cocoaswift 发表于 2016-10-11 20:31:30 | 显示全部楼层 |阅读模式
快来登录
获取最新的苹果动态资讯
收藏热门的iOS等技术干货
拷贝下载Swift Demo源代码
前段时间公司项目打算重构,准确来说应该是按之前的产品逻辑重写一个项目 。在重构项目之前涉及到架构选型的问题,我和组里小伙伴一起研究了一下组件化架构,打算将项目重构为组件化架构。当然不是直接拿来照搬,还是要根据公司具体的业务需求设计架构。

在学习组件化架构的过程中,从很多高质量的博客中学到不少东西,例如蘑菇街李忠、casatwy、bang的博客。在学习过程中也遇到一些问题,在微博和QQ上和一些做iOS的朋友进行了交流,非常感谢这些朋友的帮助。

本篇文章主要针对于之前蘑菇街提出的组件化方案,以及casatwy提出的组件化方案进行分析,后面还会简单提到滴滴、淘宝、微信的组件化架构,最后会简单说一下我公司设计的组件化架构。




1、组件化架构的由来

随着移动互联网的不断发展,很多程序代码量和业务越来越多,现有架构已经不适合公司业务的发展速度了,很多都面临着重构的问题。

在公司项目开发中,如果项目比较小,普通的单工程+MVC架构就可以满足大多数需求了。但是像淘宝、蘑菇街、微信这样的大型项目,原有的单工程架构就不足以满足架构需求了。

就拿淘宝来说,淘宝在13年开启的“All in 无线”战略中,就将阿里系大多数业务都加入到手机淘宝中,使客户端出现了业务的爆发。在这种情况下,单工程架构则已经远远不能满足现有业务需求了。所以在这种情况下,淘宝在13年开启了插件化架构的重构,后来在14年迎来了手机淘宝有史以来最大规模的重构,将其彻底重构为组件化架构




2、蘑菇街的组件化架构



2.1、原因

在一个项目越来越大,开发人员越来越多的情况下,项目会遇到很多问题。

  • 业务模块间划分不清晰,模块之间耦合度很大,非常难维护。
  • 所有模块代码都编写在一个项目中,测试某个模块或功能,需要编译运行整个项目。


蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 1

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 1

耦合严重的工程

为了解决上面的问题,可以考虑加一个中间层来协调模块间的调用,所有的模块间的调用都会经过中间层中转。(注意看两张图的箭头方向)

蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 2

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 2

添加中间层

但是发现增加这个中间层后,耦合还是存在的。中间层对被调用模块存在耦合,其他模块也需要耦合中间层才能发起调用。这样还是存在之前的相互耦合的问题,而且本质上比之前更麻烦了。



2.2、大体结构

所以应该做的是,只让其他模块对中间层产生耦合关系,中间层不对其他模块发生耦合。

对于这个问题,可以采用组件化的架构,将每个模块作为一个组件。并且建立一个主项目,这个主项目负责集成所有组件。这样带来的好处是很多的:

  • 业务划分更佳清晰,新人接手更佳容易,可以按组件分配开发任务。
  • 项目可维护性更强,提高开发效率。
  • 更好排查问题,某个组件出现问题,直接对组件进行处理。
  • 开发测试过程中,可以只编译自己那部分代码,不需要编译整个项目代码。


蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 3

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 3

组件化结构

进行组件化开发后,可以把每个组件当做一个独立的app,每个组件甚至可以采取不同的架构,例如分别使用MVVM、MVC、MVCS等架构。



2.3、MGJRouter方案

蘑菇街通过MGJRouter实现中间层,通过MGJRouter进行组件间的消息转发,从名字上来说更像是路由器。实现方式大致是,在提供服务的组件中提前注册block,然后在调用方组件中通过URL调用block,下面是调用方式。


2.3.1、架构设计

蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 4

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 4

MGJRouter组件化架构

MGJRouter是一个单例对象,在其内部维护着一个“URL -> block”格式的注册表,通过这个注册表来保存服务方注册的block,以及使调用方可以通过URL映射出block,并通过MGJRouter对服务方发起调用。

在服务方组件中都对外提供一个接口类,在接口类内部实现block的注册工作,以及block对外提供服务的代码实现。每一个block都对应着一个URL,调用方可以通过URL对block发起调用。

在程序开始运行时,需要将所有服务方的接口类实例化,以完成这个注册工作,使MGJRouter中所有服务方的block可以正常提供服务。在这个服务注册完成后,就可以被调用方调起并提供服务。

蘑菇街项目使用git作为版本控制工具将每个组件都当做一个独立工程,并建立主项目来集成所有组件。集成方式是在主项目中通过CocoaPods来集成,将所有组件当做二方库集成到项目中。详细的集成技术点在下面“标准组件化架构设计”章节中会讲到。


2.3.2、MGJRouter调用

代码模拟对详情页的注册、调用,在调用过程中传递id参数。下面是注册的示例代码:

[Objective-C] 纯文本查看 复制代码
 [MGJRouter registerURLPattern:@"mgj://detail?id=id" toHandler:^(NSDictionary *routerParameters) {
     // 下面可以在拿到参数后,为其他组件提供对应的服务
     NSString uid = routerParameters[@"id"];
 }];


通过openURL:方法传入的URL参数,对详情页已经注册的block方法发起调用。调用方式类似于GET请求,URL地址后面拼接参数。

[Objective-C] 纯文本查看 复制代码
[MGJRouter openURL:@"mgj://detail?id=404"];


也可以通过字典方式传参,MGJRouter提供了带有字典参数的方法,这样就可以传递非字符串之外的其他类型参数。

[Objective-C] 纯文本查看 复制代码
[MGJRouter openURL:@"mgj://detail?" withParam:@{@"id" : @"404"}];



2.3.3、组件间传值

有的时候组件间调用过程中,需要服务方在完成调用后返回相应的参数。蘑菇街提供了另外的方法,专门来完成这个操作。

[Objective-C] 纯文本查看 复制代码
 [MGJRouter registerURLPattern:@"mgj://cart/ordercount" toObjectHandler:^id(NSDictionary *routerParamters){
     return @42;
 }];


通过下面的方式发起调用,并获取服务方返回的返回值,要做的就是传递正确的URL和参数即可。

[Objective-C] 纯文本查看 复制代码
NSNumber *orderCount = [MGJRouter objectForURL:@"mgj://cart/ordercount"];



2.3.4、短链管理

这时候会发现一个问题,在蘑菇街组件化架构中,存在了很多硬编码的URL和参数。在代码实现过程中URL编写出错会导致调用失败,而且参数是一个字典类型,调用方不知道服务方需要哪些参数,这些都是个问题。

对于这些数据的管理,蘑菇街开发了一个web页面,这个web页面统一来管理所有的URL和参数,Android和iOS都使用这一套URL,可以保持统一性。


2.3.5、基础组件

在项目中存在很多公共部分的东西,例如封装的网络请求、缓存、数据处理等功能,以及项目中所用到的资源文件。

蘑菇街将这些部分也当做组件,划分为基础组件,位于业务组件下层。所有业务组件都使用同一个基础组件,也可以保证公共部分的统一性。



2.4、Protocol方案


2.4.1、整体架构

蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 5

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 5

Protocol方案的中间件

为了解决MGJRouter方案中URL硬编码,以及字典参数类型不明确等问题,蘑菇街在原有组件化方案的基础上推出了Protocol方案。Protocol方案由两部分组成,进行组件间通信的ModuleManager类以及MGJComponentProtocol协议类。

通过中间件ModuleManager进行消息的调用转发,在ModuleManager内部维护一张映射表,映射表由之前的“URL -> block”变成“Protocol -> Class”。

在中间件中创建MGJComponentProtocol文件,服务方组件将可以用来调用的方法都定义在Protocol中,将所有服务方的Protocol都分别定义到MGJComponentProtocol文件中,如果协议比较多也可以分开几个文件定义。这样所有调用方依然是只依赖中间件,不需要依赖除中间件之外的其他组件。

Protocol方案中每个组件也需要一个“接口类”,此类负责实现当前组件对应的协议方法,也就是对外提供服务的实现。在程序开始运行时将自身的Class注册到ModuleManager中,并将Protocol反射出字符串当做key。这个注册过程和MGJRouter是类似的,都需要提前注册服务


2.4.2、示例代码

创建MGJUserImpl类当做User模块的服务类,并在MGJComponentProtocol.h中定义MGJUserProtocol协议,由MGJUserImpl类实现协议中定义的方法,完成对外提供服务的过程。下面是协议定义:

[Objective-C] 纯文本查看 复制代码
@protocol MGJUserProtocol <NSObject>
- (NSString *)getUserName;
@end


Class遵守协议并实现定义的方法,外界通过Protocol获取的Class实例化为对象,调用服务方实现的协议方法。

ModuleManager的协议注册方法,注册时将Protocol反射为字符串当做存储的key,将实现协议的Class当做值存储。通过Protocol取Class的时候,就是通过Protocol从ModuleManager中将Class映射出来。

[Objective-C] 纯文本查看 复制代码
[ModuleManager registerClass:MGJUserImpl forProtocol:@protocol(MGJUserProtocol)];


调用时通过Protocol从ModuleManager中映射出注册的Class,将获取到的Class实例化,并调用Class实现的协议方法完成服务调用。

[Objective-C] 纯文本查看 复制代码
Class cls = [[ModuleManager sharedInstance] classForProtocol:@protocol(MGJUserProtocol)];
id userComponent = [[cls alloc] init];
NSString *userName = [userComponent getUserName];




2.5、整体调用流程

蘑菇街是OpenURL和Protocol混用的方式,两种实现的调用方式不同,但大体调用逻辑和实现思路类似,所以下面的调用流程二者差不多。在OpenURL不能满足需求或调用不方便时,就可以通过Protocol的方式调用。

  • 在进入程序后,先使用MGJRouter对服务方组件进行注册。每个URL对应一个block的实现,block中的代码就是服务方对外提供的服务,调用方可以通过URL调用这个服务。
  • 调用方通过MGJRouter调用openURL:方法,并将被调用代码对应的URL传入,MGJRouter会根据URL查找对应的block实现,从而调用服务方组件的代码进行通信。
  • 调用和注册block时,block有一个字典用来传递参数。这样的优势就是参数类型和数量理论上是不受限制的,但是需要很多硬编码的key名在项目中。




2.6、内存管理

蘑菇街组件化方案有两种,Protocol和MGJRouter的方式,但都需要进行register操作。Protocol注册的是Class,MGJRouter注册的是Block,注册表是一个NSMutableDictionary类型的字典,而字典的拥有者又是一个单例对象,这样会造成内存的常驻

下面是对两种实现方式内存消耗的分析:

  • 首先说一下block实现方式可能导致的内存问题,block如果使用不当,很容易造成循环引用的问题。
    经过暴力测试,证明并不会导致内存问题。被保存在字典中是一个block对象,而block对象本身并不会占用多少内存。在调用block后会对block体中的方法进行执行,执行完成后block体中的对象释放。
    而block自身的实现只是一个结构体,也就相当于字典中存放的是很多结构体,所以内存的占用并不是很大。
  • 对于协议这种实现方式,和block内存常驻方式差不多。只是将存储的block对象换成Class对象,如果不是已经实例化的对象,内存占用还是比较小的。





3、casatwy组件化方案



3.1、整体架构

casatwy组件化方案分为两种调用方式,远程调用本地调用,对于两个不同的调用方式分别对应两个接口。

  • 远程调用通过AppDelegate代理方法传递到当前应用后,调用远程接口并在内部做一些处理,处理完成后会在远程接口内部调用本地接口,以实现本地调用为远程调用服务
  • 本地调用由performTarget: action: params:方法负责,但调用方一般不直接调用performTarget:方法。CTMediator会对外提供明确参数和方法名的方法,在方法内部调用performTarget:方法和参数的转换。


蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 6

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 6

casatwy提出的组件化架构



3.2、架构设计思路

casatwy是通过CTMediator类实现组件化的,在此类中对外提供明确参数类型的接口,接口内部通过performTarget方法调用服务方组件的Target、Action。由于CTMediator类的调用是通过runtime主动发现服务的,所以服务方对此类是完全解耦的。

但如果CTMediator类对外提供的方法都放在此类中,将会对CTMediator造成极大的负担和代码量。解决方法就是对每个服务方组件创建一个CTMediator的Category,并将对服务方的performTarget调用放在对应的Category中,这些Category都属于CTMediator中间件,从而实现了感官上的接口分离。

蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 7

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 7

casatwy组件化实现细节

对于服务方的组件来说,每个组件都提供一个或多个Target类,在Target类中声明Action方法。Target类是当前组件对外提供的一个“服务类”,Target将当前组件中所有的服务都定义在里面,CTMediator通过runtime主动发现服务

在Target中的所有Action方法,都只有一个字典参数,所以可以传递的参数很灵活,这也是casatwy提出的去Model化的概念。在Action的方法实现中,对传进来的字典参数进行解析,再调用组件内部的类和方法。



3.3、架构分析

casatwy为我们提供了一个Demo,通过这个Demo可以很好的理解casatwy的设计思路,下面按照我的理解讲解一下这个Demo。

蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 8

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 8

文件目录

打开Demo后可以看到文件目录非常清楚,在上图中用蓝框框出来的就是中间件部分,红框框出来的就是业务组件部分。我对每个文件夹做了一个简单的注释,包含了其在架构中的职责。

在CTMediator中定义远程调用和本地调用的两个方法,其他业务相关的调用由Category完成。

[Objective-C] 纯文本查看 复制代码
// 远程App调用入口
- (id)performActionWithUrl:(NSURL *)url completion:(void(^)(NSDictionary *info))completion;
// 本地组件调用入口
- (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params;


在CTMediator中定义的ModuleA的Category,对外提供了一个获取控制器并跳转的功能,下面是代码实现。由于casatwy的方案中使用performTarget的方式进行调用,所以涉及到很多硬编码字符串的问题,casatwy采取定义常量字符串来解决这个问题,这样管理也更方便。

[Objective-C] 纯文本查看 复制代码
#import "CTMediator+CTMediatorModuleAActions.h"

NSString * const kCTMediatorTargetA = @"A";
NSString * const kCTMediatorActionNativFetchDetailViewController = @"nativeFetchDetailViewController";

@implementation CTMediator (CTMediatorModuleAActions)

- (UIViewController *)CTMediator_viewControllerForDetail {
    UIViewController *viewController = [self performTarget:kCTMediatorTargetA
                                                    action:kCTMediatorActionNativFetchDetailViewController
                                                    params:@{@"key":@"value"}];
    if ([viewController isKindOfClass:[UIViewController class]]) {
        // view controller 交付出去之后,可以由外界选择是push还是present
        return viewController;
    } else {
        // 这里处理异常场景,具体如何处理取决于产品
        return [[UIViewController alloc] init];
    }
}


下面是ModuleA组件中提供的服务,被定义在Target_A类中,这些服务可以被CTMediator通过runtime的方式调用,这个过程就叫做发现服务

我们发现,在这个方法中其实做了参数处理和内部调用的功能,这样就可以保证组件内部的业务不受外部影响,对内部业务没有侵入性

[Objective-C] 纯文本查看 复制代码
- (UIViewController *)Action_nativeFetchDetailViewController:(NSDictionary *)params {
    // 对传过来的字典参数进行解析,并调用ModuleA内部的代码
    DemoModuleADetailViewController *viewController = [[DemoModuleADetailViewController alloc] init];
    viewController.valueLabel.text = params[@"key"];
    return viewController;
}




3.4、命名规范

在大型项目中代码量比较大,需要避免命名冲突的问题。对于这个问题casatwy采取的是加前缀的方式,从casatwy的Demo中也可以看出,其组件ModuleA的Target命名为Target_A,被调用的Action命名为Action_nativeFetchDetailViewController:。

casatwy将类和方法的命名,都统一按照其功能做区分当做前缀,这样很好的将组件相关和组件内部代码进行了划分。




4、标准组件化架构设计

这个章节叫做“标准组件化架构设计”,对于项目架构来说并没有绝对意义的标准之说。这里说到的“标准组件化架构设计”只是因为采取这样的方式的人比较多,且这种方式相比而言较合理。

在上面文章中提到了casatwy方案的CTMediator,蘑菇街方案的MGJRouter和ModuleManager,下面统称为中间件。



4.1、整体架构

组件化架构中,首先有一个主工程,主工程负责集成所有组件。每个组件都是一个单独的工程,创建不同的git私有仓库来管理,每个组件都有对应的开发人员负责开发。开发人员只需要关注与其相关组件的代码,其他业务代码和其无关,来新人也好上手。

组件的划分需要注意组件粒度,粒度根据业务可大可小。组件划分后属于业务组件,对于一些多个组件共同的东西,例如网络、数据库之类的,应该划分到单独的组件或基础组件中。对于图片或配置表这样的资源文件,应该再单独划分一个资源组件,这样避免资源的重复性。

服务方组件对外提供服务,由中间件调用或发现服务,服务对当前组件无侵入性,只负责对传递过来的数据进行解析和组件内调用的功能。需要被其他组件调用的组件都是服务方,服务方也可以调用其他组件的服务。

通过这样的组件划分,组件的开发进度不会受其他业务的影响,可以多个组件单独的并行开发。组件间的通信都交给中间件来进行,需要通信的类只需要接触中间件,而中间件不需要耦合其他组件,这就实现了组件间的解耦。中间件负责处理所有组件之间的调度,在所有组件之间起到控制核心的作用。

这套框架清晰的划分了不同组件,从整体架构上来约束开发人员进行组件化开发,避免某个开发人员偷懒直接引用头文件,产生组件间的耦合,破坏整体架构。假设以后某个业务发生大的改变,需要对相关代码进行重构,可以在单个组件进行重构。组件化架构降低了重构的风险,保证了代码的健壮性。



4.2、组件集成

蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 9

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 9

组件化架构图

每个组件都是一个单独的工程,在组件开发完成后上传到git仓库。主工程通过Cocoapods集成各个组件,集成和更新组件时只需要pod update即可。这样就是把每个组件当做第三方来管理,管理起来非常方便。

Cocoapods可以控制每个组件的版本,例如在主项目中回滚某个组件到特定版本,就可以通过修改podfile文件实现。选择Cocoapods主要因为其本身功能很强大,可以很方便的集成整个项目,也有利于代码的复用。通过这种集成方式,可以很好的避免在传统项目中代码冲突的问题。



4.3、集成方式

对于组件化架构的集成方式,我在看完bang的博客后专门请教了一下bang。根据在微博上和bang的聊天以及其他博客中的学习,在主项目中集成组件主要分为两种方式——源码和framework,但都是通过CocoaPods来集成。

无论是用CocoaPods管理源码,还是直接管理framework,效果都是一样的,都是可以直接进行pod update之类的操作的。

这两种组件集成方案,实践中也是各有利弊。直接在主工程中集成代码文件,可以在主工程中进行调试。集成framework的方式,可以加快编译速度,而且对每个组件的代码有很好的保密性。如果公司对代码安全比较看重,可以考虑framework的形式,但framework不利于主工程中的调试。

例如手机QQ或者支付宝这样的大型程序,一般都会采取framework的形式。而且一般这样的大公司,都会有自己的组件库,这个组件库往往可以代表一个大的功能或业务组件,直接添加项目中就可以使用。关于组件化库在后面讲淘宝组件化架构的时候会提到。


4.3.1、不推荐的集成方式

之前有些项目是直接用workspace的方式集成的,或者直接在原有项目中建立子项目,直接做文件引用。但这两点都是不建议做的,因为没有真正意义上实现业务组件的剥离,只是像之前的项目一样从文件目录结构上进行了划分。




5、组件化开发总结

对于项目架构来说,一定要建立于业务之上来设计架构。不同的项目业务不同,组件化方案的设计也会不同,应该设计最适合公司业务的架构。



5.1、架构对比

在除蘑菇街Protocol方案外,其他两种方案都或多或少的存在硬编码问题,硬编码如果量比较大的话挺麻烦的。

在casatwy的CTMediator方案中需要硬编码Target、Action字符串,只不过这个缺陷被封闭在中间件里面了,将这些字符串都统一定义为常量,外界使用不需要接触到硬编码。蘑菇街的MGJRouter的方案也是一样的,也有硬编码URL的问题,蘑菇街可能也做了类似的处理。

casatwy和蘑菇街提出的两套组件化方案,大体结构是类似的,三套方案都分为调用方、中间件、服务方,只是在具体实现过程中有些不同。例如Protocol方案在中间件中加入了Protocol文件,casatwy的方案在中间件中加入了Category。

三种方案内部都有容错处理,所以三种方案的稳定性都是比较好的,而且都可以拿出来单独运行,在服务方不存在的情况下也不会有问题。

在三套方案中,服务方都对外提供一个供外界调用的接口类,这个类中实现组件对外提供的服务,中间件通过接口类来实现组件间的通信。在此类中统一定义对外提供的服务,外界调用时就知道服务方可以做什么。

调用流程也不大一样,蘑菇街的两套方案都需要注册操作,无论是Block还是Protocol都需要注册后才可以提供服务。而casatwy的方案则不需要,直接通过runtime调用。casatwy的方案实现了真正的对服务方解耦,而蘑菇街的两套方案则没有,对服务方和调用方都造成了耦合。

我认为三套方案中,Protocol方案是调用和维护最麻烦的一套方案。维护时需要同时维护Protocol、接口类两部分。而且调用时需要将服务方的接口类返回给调用方,并由调用方执行一系列调用逻辑,调用一个服务的逻辑非常复杂,这在开发中是非常影响开发效率的。



5.2、总结

下面是组件化开发中的一个小总结,也是开发过程中的一些注意点。


5.2.1、在MGJRouter方案中,是通过调用OpenURL:方法并传入URL来发起调用。鉴于URL协议名等固定格式,可以通过判断协议名的方式,使用配置表控制H5和native的切换,配置表可以从后台更新,只需要将协议名更改一下即可。

[Swift] 纯文本查看 复制代码
mgj://detail?id=123456
[url=http://www.mogujie.com/detail?id=123456]http://www.mogujie.com/detail?id=123456[/url]


假设现在线上的native组件出现严重bug,在后台将配置文件中原有的本地URL换成H5的URL,并更新客户端配置文件。在调用MGJRouter时传入这个H5的URL即可完成切换,MGJRouter判断如果传进来的是一个H5的URL就直接跳转webView。而且URL可以传递参数给MGJRouter,只需要MGJRouter内部做参数截取即可。


5.2.2、casatwy方案和蘑菇街Protocol方案,都提供了传递明确类型参数的方法。在MGJRouter方案中,传递参数主要是通过类似GET请求一样在URL后面拼接参数,和在字典中传递参数两种方式组成。这两种方式会造成传递参数类型不明确,传递参数类型受限(GET请求不能传递对象)等问题,后来使用Protocol方案弥补这个问题。


5.2.3、组件化开发可以很好的提升代码复用性,组件可以直接拿到其他项目中使用,这个优点在下面淘宝架构中会着重讲一下。


5.2.4、对于调试工作,应该放在每个组件中完成。单独的业务组件可以直接提交给测试提测,这样测试起来也比较方便。最后组件开发完成并测试通过后,再将所有组件更新到主项目,提交给测试进行集成测试即可。


5.2.5、使用组件化架构开发,组件间的通信都是有成本的。所以尽量将业务封装在组件内部,对外只提供简单的接口。即“高内聚、低耦合”原则


5.2.6、把握好划分粒度的细化程度,太细则项目过于分散,太大则项目组件臃肿。但是项目都是从小到大的一个发展过程,所以不断进行重构是掌握这个组件的细化程度最好的方式。




6、我公司架构

下面就简单说说我公司项目架构,公司项目是一个地图导航应用,业务层之下的基础组件占比较大。且基础组件相对比较独立,对外提供了很多调用接口。刚开始想的是采用MGJRouter的方案,但如果这些调用都通过Router进行,开发起来比较复杂,反而会适得其反。最主要我们项目也并不是非常大,没必要都用Router转发。

对于这个问题,公司项目的架构设计是:层级架构+组件化架构,组件化架构处于层级架构的最上层,也就是业务层。采取这种结构混合的方式进行整体架构,这个对于公共组件的管理和层级划分比较有利,符合公司业务需求。

蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 10

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 10

公司组件化架构

对于业务层级依然采用组件化架构的设计,这样可以充分利用组件化架构的优势,对项目组件间进行解耦。在上层和下层的调用中,下层的功能组件应该对外开放一个接口类,在接口类中声明所有的服务,实现上层调用当前组件的一个中转,上层直接调用接口类。这样做的好处在于,如果下层发生改变不会对上层造成影响,而且也省去了部分Router转发的工作。

在设计层级架构时,需要注意只能上层对下层依赖,下层对上层不能有依赖,下层中不要包含上层业务逻辑。对于项目中存在的公共资源和代码,应该将其下沉到下层中。



6.1、为什么这么做?

首先就像我刚才说的,我公司项目并不是很大,根本没必要拆分的那么彻底。

因为组件化开发有一个很重要的原因就是解耦合,如果我做到了底层不对上层依赖,这样就已经解除了上下层的相互耦合。而且上层对下层进行调用的时候,也不是直接调用下层,通过一个接口类进行中转,实现了下层的改变对上层无影响,这也是上层对下层解耦的表现。

所以对于第三方就不用说了,上层直接调用下层的第三方也是没问题的,这都是解耦的。



6.2、模型类怎么办,放在哪合适?

casatwy对模型类的观点是去Model化,简单来说就是用字典代替Model存储数据。这对于组件化架构来说,是解决组件之间数据传递的一个很好的方法。

因为模型类是关乎业务的,理论上必须放在业务层也就是业务组件这一层。但是要把模型对象从一个组件中当做参数传递到另一个组件中,模型类放在调用方和服务方的哪个组件都不太合适,而且有可能不只两个组件使用到这个模型对象。这样的话在其他组件使用模型对象,必然会造成引用和耦合

那么如果把模型类放在Router中,这样会造成Router耦合了业务,造成业务的侵入性。如果在用到这个模型对象的所有组件中,都分别维护一份相同的模型类,这样之后业务发生改变模型类就会很麻烦。


6.2.1、那应该怎么办呢?

如果将模型类单独拉出来,定义一个模型组件呢?这个看起来比较可行,将这个定义模型的组件下沉到下层,模型组件不包含业务,只声明模型对象的类。但是一般组件的模型对象都是当前组件内使用的,将模型对象传递给其他组件的需求非常少,那所有的模型类都定义到模型组件吗?

对于这个问题,我建议在项目开发中将模型类还定义在当前业务组件中,在组件间传递模型对象时进行去Model化,传递字典类型的参数。

上面只是思考,恰巧我公司持久化方案用的是CoreData,所有模型的定义都在CoreData组件中,这样就避免了业务层组件之间因为模型类的耦合。




7、滴滴组件化架构

之前看过滴滴iOS负责人李贤辉的技术分享,详见iOS开发社区敏捷大拇指Swifthumb.com)帖子《滴滴打车 iOS App的组件化实践与优化》,分享的是滴滴iOS客户端的架构发展历程,下面简单总结一下。



7.1、发展历程

滴滴在最开始的时候架构较混乱。然后在2.0时期重构为MVC架构,使项目划分更加清晰。在3.0时期上线了新的业务线,这时采用的游戏开发中的状态机机制,暂时可以满足现有业务。

然而在后期不断上线顺风车、代驾、巴士等多条业务线的情况下,现有架构变得非常臃肿,代码耦合严重。从而在2015年开始了代号为“The One”的方案,这套方案就是滴滴的组件化方案。



7.2、架构设计

滴滴的组件化方案,和蘑菇街方案类似,也是通过私有CocoaPods来管理各个组件。将整个项目拆分为业务部分和技术部分,业务部分包括专车、拼车、巴士等业务模块,每个业务模块就是一个单独的组件,使用一个pods管理。技术部分则分为登录分享、网络、缓存这样的一些基础组件,分别使用不同的pods管理。

组件间通信通过ONERouter中间件进行通信,ONERouter类似于MGJRouter,担负起协调和调用各个组件的作用。组件间通信通过OpenURL方法,来进行对应的调用。ONERouter内部保存一份Class-URL的映射表,通过URL找到Class并发起调用,Class的注册放在+load方法中进行。

滴滴在组件内部的业务模块中,模块内部使用MVVM+MVCS混合架构,两种架构都是MVC的衍生版本。其中MVCS中的Store负责数据相关逻辑,例如订单状态、地址管理等数据处理。通过MVVM中的VM给控制器瘦身,最后Controller的代码量就很少了。



7.3、滴滴首页分析

滴滴文章中说道首页只能有一个地图实例,这在很多地图导航相关应用中都是这样做的。滴滴首页主控制器持有导航栏和地图,每个业务线首页控制器都添加在主控制器上,并且业务线控制器背景都设置为透明,将透明部分响应事件传递到下面的地图中,只响应属于自己的响应事件。

由主控制器来切换各个业务线首页,切换页面后根据不同的业务线来更新地图数据。




8、淘宝组件化架构

本章节源自于宗心在阿里技术沙龙上的一次分享



8.1、架构发展

淘宝iOS客户端初期是单工程的普通项目,但随着业务的飞速发展,现有架构并不能承载越来越多的业务需求,导致代码间耦合很严重。后期开发团队对其不断进行重构,淘宝iOS和Android两个平台,除了某个平台特有的一些特性或某些方案不便实施之外,大体架构都是差不多的。


8.1.1、发展历程:

  • 刚开始是普通的单工程项目,以传统的MVC架构进行开发。随着业务不断的增加,导致项目非常臃肿、耦合严重。
  • 2013年淘宝开启"all in 无线"计划,计划将淘宝变为一个大的平台,将阿里系大多数业务都集成到这个平台上,造成了业务的大爆发
    淘宝开始实行插件化架构,将每个业务模块划分为一个组件,将组件以framework二方库的形式集成到主工程。但这种方式并没有做到真正的拆分,还是在一个工程中使用git进行merge,这样还会造成合并冲突、不好回退等问题。
  • 迎来淘宝移动端有史以来最大的重构,将其重构为组件化架构。将每个模块当做一个组件,每个组件都是一个单独的项目,并且将组件打包成framework。主工程通过podfile集成所有组件framework,实现业务之间真正的隔离,通过CocoaPods实现组件化架构。




8.2、架构优势

淘宝是使用git来做源码管理的,在插件化架构时需要尽可能避免merge操作,否则在大团队中协作成本是很大的。而使用CocoaPods进行组件化开发,则避免了这个问题。

在CocoaPods中可以通过podfile很好的配置各个组件,包括组件的增加和删除,以及控制某个组件的版本。使用CocoaPods的原因,很大程度是为了解决大型项目中,代码管理工具merge代码导致的冲突。并且可以通过配置podfile文件,轻松配置项目。

每个组件工程有两个target,一个负责编译当前组件和运行调试,另一个负责打包framework。先在组件工程做测试,测试完成后再集成到主工程中集成测试。

每个组件都是一个独立app,可以独立开发、测试,使得业务组件更加独立,所有组件可以并行开发。下层为上层提供能满足需求的底层库,保证上层业务层可以正常开发,并将底层库封装成framework集成到项目中。

使用CocoaPods进行组件集成的好处在于,在集成测试自己组件时,可以直接将本地主工程podfile文件中的当前组件指向本地,就可以直接进行集成测试,不需要提交到服务器仓库。



8.3、淘宝四层架构

蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 11

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 11

淘宝四层架构(图片来自淘宝技术分享)

淘宝架构的核心思想是一切皆组件,将工程中所有代码都抽象为组件。

淘宝架构主要分为四层,最上层是组件Bundle(业务组件),依次往下是容器(核心层),中间件Bundle(功能封装),基础库Bundle(底层库)。容器层为整个架构的核心,负责组件间的调度和消息派发。



8.4、总线设计

总线设计:URL路由+服务+消息。统一所有组件的通信标准,各个业务间通过总线进行通信。

蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 12

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 12

总线设计(图片来自淘宝技术分享)

URL可以请求也可以接受返回值,和MGJRouter差不多。URL路由请求可以被解析就直接拿来使用,如果不能被解析就跳转H5页面。这样就完成了一个对不存在组件调用的兼容,使用户手中比较老的版本依然可以显示新的组件。

服务提供一些公共服务,由服务方组件负责实现,通过Protocol实现。消息负责统一发送消息,类似于通知也需要注册。



8.5、Bundle App

蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 13

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈 - 敏捷大拇指 - 蘑菇街/滴滴/淘宝等 iOS App的组件化架构漫谈 13

Bundle App(图片来自淘宝技术分享)

淘宝提出Bundle App的概念,可以通过已有组件,进行简单配置后就可以组成一个新的app出来。解决了多个应用业务复用的问题,防止重复开发同一业务或功能。

Bundle即App,容器即OS,所有Bundle App被集成到OS上,使每个组件的开发就像app开发一样简单。这样就做到了从巨型app回归普通app的轻盈,使大型项目的开发问题彻底得到了解决。




9、总结



9.1、留个小思考

到目前为止组件化架构文章就写完了,文章确实挺长的,看到这里真是辛苦你了 。下面留个小思考,把下面字符串复制到微信输入框随便发给一个好友,然后点击下面链接大概也能猜到微信的组件化方案

[Swift] 纯文本查看 复制代码
weixin://dl/profile




9.2、总结

各位可以来我博客评论区讨论,可以讨论文中提到的技术细节,也可以讨论自己公司架构所遇到的问题,或自己独到的见解等等。无论是不是架构师或新入行的iOS开发,欢迎各位以一个讨论技术的心态来讨论。在评论区你的问题可以被其他人看到,这样可能会给其他人带来一些启发。


现在H5技术比较火,好多应用都用H5来完成一些页面的开发,H5的跨平台和实时更新等是非常大的优点,但其性能和交互也是缺点。如果以后客户端能够发展到可以动态部署线上代码,不用打包上线应用市场,直接就可以做到原生应用更新,这样就可以解决原生应用最大的痛点。这段时间公司项目比较忙,有时间我打算研究一下这个技术点

Demo地址:蘑菇街和casatwy组件化方案,其Github上都给出了Demo,这里就贴出其Github地址了。


蘑菇街:
游客,如果您要查看本帖隐藏内容请回复


casatwy:
游客,如果您要查看本帖隐藏内容请回复



欢迎订阅全球最大的Swift开发者社区敏捷大拇指Swifthumb.com)上的淘帖“iOS App 组件化架构”。




相关内容

滴滴/淘宝/微信/蘑菇街/casatwy等 iOS App的组件化架构漫谈

滴滴 iOS App的组件化实践与优化

纳斯达克上市公司 iOS App组件化开发实践

纳斯达克上市公司 CocoaPods组件平滑二进制化解决方案

iOS CocoaPods组件平滑二进制化解决方案及详细教程1

iOS CocoaPods组件平滑二进制化解决方案及详细教程2之subspecs篇




游客,如果您要查看本帖隐藏内容请回复



都看到这里了,就把这篇资料推荐给您的好朋友吧,让他们也感受一下。

回帖是一种美德,也是对楼主发帖的尊重和支持。

*声明:敏捷大拇指是全球最大的Swift开发者社区、苹果粉丝家园、智能移动门户,所载内容仅限于传递更多最新信息,并不意味赞同其观点或证实其描述;内容仅供参考,并非绝对正确的建议。本站不对上述信息的真实性、合法性、完整性做出保证;转载请注明来源并加上本站链接,敏捷大拇指将保留所有法律权益。如有疑问或建议,邮件至marketing@swifthumb.com

*联系:微信公众平台:“swifthumb” / 腾讯微博:@swifthumb / 新浪微博:@swifthumb / 官方QQ一群:343549891(满) / 官方QQ二群:245285613 ,需要报上用户名才会被同意进群,请先注册敏捷大拇指

嗯,不错!期待更多好内容,支持一把:
支持敏捷大拇指,用支付宝支付10.24元 支持敏捷大拇指,用微信支付10.24元

评分

参与人数 1金钱 +20 贡献 +20 专家分 +20 收起 理由
Anewczs + 20 + 20 + 20 32个赞!专家给力!

查看全部评分

本帖被以下淘专辑推荐:

流量王 发表于 2016-10-12 00:17:24 | 显示全部楼层
苏格拉没有底 发表于 2016-10-12 18:38:28 | 显示全部楼层
我能说我看累了吗?

晚上来好好仔细阅读
女汉子 发表于 2016-10-15 23:51:36 | 显示全部楼层
精品!!!!
攻城狮 发表于 2016-10-17 17:32:55 | 显示全部楼层
经典,值得收藏!
c87091823 发表于 2016-10-27 18:02:55 | 显示全部楼层
很好很强大
baddy 发表于 2016-10-28 10:03:22 | 显示全部楼层

很棒很牛掰
乔大爷 发表于 2016-11-24 13:18:59 | 显示全部楼层
太详细了!!32个赞!
jswift 发表于 前天 01:20 | 显示全部楼层

很屌很逼格
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

做任务,领红包。
我要发帖

分享扩散

都看到这里了,就把这资料推荐给您的好朋友吧,让他们也感受一下。
您的每一位朋友访问此永久链接后,您都将获得相应的金钱积分奖励
热门推荐

合作伙伴

Swift小苹果

  • 北京治世天下科技有限公司
  • ©2014-2016 敏捷大拇指
  • 京ICP备14029482号
  • Powered by Discuz! X3.1 Licensed
  • swifthumb Wechat Code
  •   
快速回复 返回顶部 返回列表