iOS架构组件化

前言

本文简书地址:http://www.jianshu.com/p/2d89f55fc2c4

当一个App只有几个人开发的时候,很容易就会在一个单项目中开发。但当App开发人数越来越多,甚至几百人,十几个不同BU都在协调开发同一个App的时候,就必须对架构进行组件化,才能方便开发。本文主要基于手机淘宝的一次架构探索:手机淘宝客户端架构探索实践,基于此文进行的一些学习和探索,写一篇文章给自己梳理一下。

组件化的目的

首先,第一个问题,为何需要组件化?

如果依旧是单工程项目,或者是多工程引入同一个项目的开发,会有以下的问题:

1. 严重的代码耦合

比如a模块要跳转b模块的页面,就要在a模块的代码中耦合b模块的页面代码

2. 协同工作困难

开发工程中需要去编译别的模块的代码,还容易出现冲突问题,引发别的问题

3. 测试效率低下

不仅测试某一个功能可能需要耦合别的模块代码,做回归测试的时候业务也太多时分麻烦

4. 发布不够灵活

出现问题定位麻烦,线上热更新也困难

为了解决这些问题,所以需要重构代码,达到组件化的目的。

组件化的方式

手机淘宝组件化两大核心:

1. 分而治之

2. 一些皆组件

拿一张ppt里的图:

可以看到,手机淘宝将业务都进行细粒度的拆分,拆分出的每一个部分都作为一个组件。每个组件可以单独进行测试与调试,并且确保了单一的功能性,方便在新业务接入的时候,可以按照需求选择相应的组件来进行添加。

对于bundle如何组合,这里用的是CocoaPods

CocoaPods是一个著名的iOS类库管理工具。这里就不详细介绍如何安装与用CocoaPods了,感兴趣的可以自己去CocoaPods Guide去看一下。

通过CocoaPods可以十分方便的选择需要的bundle包进入项目,并且最关键的是可以控制bundle包的版本号,选择稳定的旧版本或者新功能的老版本,避免了协同开发的时候,可能出现的外部问题,方便开发与测试。

组件化核心层

从前面“手机淘宝组件化”的图可以看出,组件化的核心层其实是容器层。

容器层主要分为两大块

1. 应用生命周期

2. 总线

而总线,就是核心组件之间的解耦的关键。

总线主要分为三块:

1. URL

2. 服务

3. 消息

URL

URL应该是整个总线传输的核心。

模块通过URL跳转的的方式,来进行模块之间的消息传递。URL的用处是最多的,比如获取相应对象,跳转相应页面,或者发起请求,都可以使用URL来进行。

这里拿蘑菇街URL跳转的demo:MGJRouter,来进行举例子。

MGJRouter主要就是通过各个模块注册相应的URL跳转block,建立起一层URL与block的映射关系,然后调用方通过URL去访问block,获得结果。

通过URL的方式,调用方不需要去依赖其他模块代码,只需要直接调用,或者获取相应的结果进行处理。

比如常见的页面跳转问题,通过URL路由,就可以直接跳转到相应的页面。

首先是注册相应的URL内容,这里是详情页的内容。

[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"];

就可以打开相应的界面。

不仅可以通过openURL的方式去打开一个URL,也可以通过objectForUrl去通过URL获取一个对象,然后进行操作。

服务

服务用来弥补URL无法处理或者难以处理的功能。

服务的作用主要体现在一些组件之间的功能调用,会比URL更佳通用。比如登陆,购物车等模块的常用功能。

服务主要通过ModuleManager,去注册Protocol->Class的关系,获得相应的对象,进行Protocol的方法调用。

比如登陆组件可以提供这样的一个Protocol

@protocol User <NSObject>
+ (NSString *)getUserName;
@end

可以看到通过协议可以直接指定返回的数据类型。然后在登陆组件内再新建个类实现这个协议,假设这个类名为UserImp,接着就可以把它与协议关联起来

[ModuleManager registerClass:UserImp forProtocol:@protocol(User)];

对于使用方来说,要拿到这个 UserImp,需要调用

Class cls = [ModuleManager classForProtocol:@protocol(User)];

拿到之后再调用

id<User> userComponent = [[cls alloc] init];
NSString *userName = [userComponent getUserName];

就可以获得用户的用户名了。

消息

消息就是常见的NSNotification相关的消息转发机制,在这里做一个消息的统一管理和分发给各个模块,各个模块自己去处理响应的消息。

总线总结

总线的主要目的就是组件与组件之间的消息传输的解耦。

URL是总线中最主要的使用场景,包括页面调用与发起请求等功能。

服务是组件间的调用方式。需要服务提供方提供与维护稳定的服务接口。

消息是在总线中进行统一管理与分发。

对于URL为核心的总线机制有以下好处:

1. 平台统一

iOS,Android通过同一个URL总线在后台进行管理与配置。

2. 自动降级

老版本解析不了URL,走老的逻辑依旧可用。新版本可以解析URL,走新的逻辑。

3. 中心分发

业务方分别注册自己的URL拦截规则,配置在自己的模块中。通过总线来中心分发响应能够响应的模块进行处理。

结束语

本文主要还是根据手机淘宝客户端架构探索实践和视频,借鉴了蘑菇街 App 的组件化之路一些具体的实现思路,自己整理一下思路的总结和学习。

参考资料

1.手机淘宝客户端架构探索实践

2.组件化架构漫谈

3.蘑菇街 App 的组件化之路

4.iOS应用架构谈 组件化方案

时间: 2024-12-18 10:32:47

iOS架构组件化的相关文章

iOS代码组件化--利用cocoaPods创建私有库

如果项目模块多,模块间逻辑复杂,我们发现多个人同时维护一个代码仓库需要十分小心,一不小心,造成冲突,解决起来很烦,相信很多人都遇到手工删除合并的冲突的文件的经历. 如果利用组件化思想,每个人维护自己的模块对应的代码库,将会大大降低冲突的风险,而且组件化能够很好的给工程解耦. 组件化的第一步就是创建自己的仓库,公司的话需要搭建并维护私有库. 1.查看本地索引库 我们用cocoaPods 的时候,默认使用的是cocoaPods自带的索引库 终端中使用命令 $ pod repo 查看有哪些索引库,这里

iOS开发之组件化架构漫谈

前段时间公司项目打算重构,准确来说应该是按之前的产品逻辑重写一个项目.在重构项目之前涉及到架构选型的问题,我和组里小伙伴一起研究了一下组件化架构,打算将项目重构为组件化架构.当然不是直接拿来照搬,还是要根据公司具体的业务需求设计架构. 在学习组件化架构的过程中,从很多高质量的博客中学到不少东西,例如蘑菇街李忠.casatwy.bang的博客.在学习过程中也遇到一些问题,在微博和QQ上和一些做iOS的朋友进行了交流,非常感谢这些朋友的帮助. 本篇文章主要针对于之前蘑菇街提出的组件化方案,以及cas

iOS 组件化架构漫谈

组件化架构漫谈 前段时间公司项目打算重构,准确来说应该是按之前的产品逻辑重写一个项目.在重构项目之前涉及到架构选型的问题,我和组里小伙伴一起研究了一下组件化架构,打算将项目重构为组件化架构.当然不是直接拿来照搬,还是要根据公司具体的业务需求设计架构. 在学习组件化架构的过程中,从很多高质量的博客中学到不少东西,例如蘑菇街李忠.casatwy.bang的博客.在学习过程中也遇到一些问题,在微博和QQ上和一些做iOS的朋友进行了交流,非常感谢这些朋友的帮助. 本篇文章主要针对于之前蘑菇街提出的组件化

组件化架构[转]

转自:https://www.jianshu.com/p/67a6004f6930 这两天更新了一下文章,并且做了一个PDF版的<组件化架构漫谈>,放在我Github上了.PDF上有文章目录,方便阅读,下面是地址. 如果你觉得不错,请把PDF帮忙转到其他群里,或者你的朋友,让更多的人了解组件化架构,衷心感谢!?? 组件化架构PDF Github地址 : https://github.com/DeveloperErenLiu/ComponentArchitectureBook 前段时间公司项目打

iOS组件化相关资料

// 基于 CocoaPods 和 Git 的 iOS 工程组件化实践 1)https://skyline75489.github.io/index.html // 模块与解藕 2)https://blog.cnbluebox.com/blog/archives/ // iOS组件化思想 3)http://casatwy.com/ // iOS组件化相关资料 4)http://www.jianshu.com/p/34f23b694412 // AOP 技术 5)https://github.co

iOS-Swift 面向协议编程/组件化(模块化)编程思想

转载注明出处:http://blog.csdn.net/qxuewei/article/details/53945445 因为OC 的局限性, 使得iOS 开发组件化编程变得不可能,得益于面向对象语言的特性 (封装,继承,多态) 在我们熟悉的设计模式中渐渐形成统一的软件开发思想. 在抽取某些功能作为基类的不断运用中,代码的可移植性逐渐减弱. 就如同一棵树,从主干到各个分支,每个分支再长成细枝末叶.代码的耦合性也相应增加. 随着苹果 swift 语言的推出, 对于传统OC 语言取其精华,弃其糟粕.

iOS 组件化方案

概述 近一年iOS业界讨论组件化方案甚多,大体来说有3种. Protocol注册方案 URL注册方案 Target-Action runtime调用方案 URL注册方案据我了解很多大公司都在采用,蘑菇街 App 的组件化之路(http://limboy.me/tech/2016/03/10/mgj-components.html)蘑菇街的Limboy在这篇博客中做了很详尽的阐述 Target-Action runtime调用方案Casa在 iOS应用架构谈 组件化方案(http://casatw

iOS 从零到一搭建组件化项目框架

随着公司业务需求的不断迭代发展,工程的代码量和业务逻辑也越来越多,原始的开发模式和架构已经无法满足我们的业务发展速度了,这时我们就需要将原始项目进行一次重构大手术了.这时我们应该很清晰这次手术的动刀口在哪,就是之前的高度耦合的业务组件和功能组件,手术的目的就是将这些耦合拆分成互相独立的各个组件. 工程效果预览 组件化工程示例项目地址 组件化开源项目Git仓库地址 下面我们围绕这几个问题来展开讲解 为什么要用组件化,它给我们带来哪些优势 各个组件该如何进行拆分,拆分的颗粒度该如何控制 如何从零到一

Category 特性在 iOS 组件化中的应用与管控

背景 iOS Category功能简介 Category 是 Objective-C 2.0之后添加的语言特性. Category 就是对装饰模式的一种具体实现.它的主要作用是在不改变原有类的前提下,动态地给这个类添加一些方法.在 Objective-C(iOS 的开发语言,下文用 OC 代替)中的具体体现为:实例(类)方法.属性和协议. 除了引用中提到的添加方法,Category 还有很多优势,比如将一个类的实现拆分开放在不同的文件内,以及可以声明私有方法,甚至可以模拟多继承等操作,具体可参考