iOS组件化思路－大神博客研读和思考

2401_84103903

于 2024-04-19 11:21:51 发布

阅读量681

点赞数 27

分类专栏：程序员文章标签： ios cocoa macos

本文链接：https://blog.csdn.net/2401_84103903/article/details/137958579

版权

程序员专栏收录该内容

180 篇文章 0 订阅

订阅专栏

[MGJRouter registerURLPattern:@“mgj://cart/ordercount” toObjectHandler:^id(NSDictionary *routerParamters){

// do some calculation

return @42;

}]

NSNumber *orderCount = [MGJRouter objectForURL:@"mgj://cart/ordercount”]

方法二：通过protocol－class对应的方式

把公共协议文件统一放到PublicProtocolDomain.h中，所有业务组件只依赖这个文件；protocol只能通过类方法提供？

@protocol MGJCart

(NSInteger)orderCount;

@end

[ModuleManager registerClass:MGJCartImpl forProtocol:@protocol(MGJCart)]

[ModuleManager classForProtocol:@protocol(MGJCart)]

组件生命周期的管理：（组件管理）

启动初始化时，实例APP中所有组件的module实例，让每个组件的module实例执行一遍didFinishLaunchingWithOptions方法：在这方法中每个组件注册自己的URL，使用class注册；每个组件可以自行监控系统的通知，如UIApplicationDidBecomeActiveNotification, 对于没有系统通知消息则将此方法写入module的protocol中，依次执行实例的这些protocol方法；

[[ModuleManager sharedInstance] loadModuleFromPlist:[[NSBundle mainBundle] pathForResource:@“modules” ofType:@“plist”]];

NSArray *modules = [[ModuleManager sharedInstance] allModules];

for (id module in modules) {

if ([module respondsToSelector:_cmd]) {

[module application:application didFinishLaunchingWithOptions:launchOptions];

}

组件化版本管理的问题

版本同步问题： API接口改动升级（旧接口不存在了，不向下兼容），版本的中位号发生改变；需要所有依赖其的调用都发生改变，才能保证壳工程和主工程能够同步编译通过；
pod update之后编译太长：考虑通过framework的方式进行修改；
持续集成问题：不能只是把podspec直接扔到private repo里完事，需要扔到主工程进行打包编译，编译通过允许提供版本升级，不通过扔回去进行处理；CI编译检查，通过之后再将版本号升级到private repo中，同时修改主工程中Podfile的版本依赖号；但如果是其它工程呢，被多个业务工程所依赖，如何办？

蘑菇街开源组件：

MGJRouter： https://github.com/mogujie/MGJRouter.git

JLRoutes 的问题主要在于查找 URL 的实现不够高效，通过遍历而不是匹配。还有就是功能偏多。
HHRouter 的 URL 查找是基于匹配，所以会更高效，MGJRouter 也是采用的这种方法，但它跟 ViewController 绑定地过于紧密，一定程度上降低了灵活性。

（2）反革命的组件化方案

文章来源：

2016.03.13 iOS应用架构谈组件化方案http://casatwy.com/iOS-Modulization.html
2016.03.14 iOS应用架构谈组件化方案(补充)

蘑菇街的方案为什么不好？

url注册对于实施组件化是完全没有必要的，拓展性和可维护性都降低；
基于openURL的方案的话，有一个致命缺陷：非常规对象无法参与本地组件间调度；但是可以通过传递params来解决，但是这样区分了远程调用和本地调用的入口；
模块内部是否仍然需要使用URL去完成调度？是没有必要的，为啥要复杂化？

反革命的组件化方案：

基于Mediator模式和Target－Action模式：

[CTMediator sharedInstance]

openUrl:url] //call from other app with url

parseUrl

performTarget:action:params //call form Native Module

runtime

[TargetA action1], [TargetA action2]

[TargetB action1], [TargetB action2]

反革命组件化方案的调用方式：

本地跨组件间调用：

[[CTMediator sharedInstance] performTarget:targetName action:actionName params:@{…}]

远程应用调用：

openUrl + parseUrl的方式；针对请求的路由操作，直接将Target和Action的名字封装到url中；

反革命组件化方案的好处：

将远程调用和本地调用做了拆分，而且由本地应用调用位远程应用调用提供服务；
组件仅通过Action暴露可调用接口；
组件化方案必需去Model设计：只有调用方依赖Mediator，响应方依赖是没有必要的；
调用方如何知道接收方需要哪些Key的参数，如何知道有哪些target可被调用？：在mediator中维护针对Mediator的Category，每个category对应一个target，categroy中的方法对应Action场景；

category为组合模式，根据不同的分类提供不同的方法，每个组件对应一个category分类；
参数验证和补救入口；
轻松的请求转发；
统一了所有组件间调用入口；
param的hardcode在整个app的作用域仅仅存在于category中，跟调用宏差不多；
安全保证，对url中进行native前缀验证；
保证动态调度考虑；

反革命组件化方案开源Demo：

代码Git地址：https://github.com/casatwy/CTMediator.git

二、实际项目中的组件化问题

（1）为什么要组件化？

解决人多（更好的协作）、需求多（更好的功能模块划分）的问题；
解决项目模块间的代码耦合问题；（坚决抵制业务组件间代码直接引用）

（2）如何拆分组件？（神仙们讨论的主要是产品业务组件化的问题）

基础功能组件：（类似于性能统计、Networking、Patch、网络诊断等）
按功能分库，不涉及产品业务需求，跟库Library类似
通过良好的接口拱上层业务组件调用；
不写入产品定制逻辑，通过扩展接口完成定制；
基础UI组件：（例如下拉刷新组件、iCausel类似的组件）
产品内通用UI组件；（各个业务模块依赖使用，但需要保持好定制扩展的设计）
公共通用UI组件；（不涉及具体产品的视觉设计，目前较少）
产品业务组件：（例如圈子、1元购、登录、客服MM等）
业务功能间相对独立，相互间没有Model共享的依赖；
业务之间的页面调用只能通过UIBus进行跳转；
业务之间的逻辑Action调用只能通过服务提供；

（3）组件化工程需要解决的问题？

组件化页面跳转（UIBus）方案要求：
能够传递普通参数（系统基础数据类型）和复杂参数（url无法负载的对象），不负责CustomModel的传递处理；
能够获取url对应的controller进行TabController的动态配置；
能够对controller的present方式进行定制；
url的注册须用代码完成，必需去中心化处理；
组件服务化（ServiceBus）方案要求：
能够传递普通参数和复杂参数，尽量不使用CustomModel的传递；
通过接口文件的统一基础库进行依赖；（业务开发方开发阶段只需要依赖接口文件依赖库，在主项目集成测试阶段依赖所有业务组件进行测试）
接口和实现类的的对应注册须用代码完成，由中间件去控制服务实现类的生成；

（通用问题：复杂参数传递 key值的硬编码问题）

（4）组件维护问题？

组件服务接口的设计：
最小化原则；
命名规范；
版本发布：
版本号规范：http://semver.org/
持续集成，通过脚本完成：https://github.com/fastlane/fastlane

三、关于组件化的思考和总结

MGJRouter＋ModuleManager方案（蘑菇街方案）

CTMediator+Target-Action方案（反革命方案）

（1）主要解决本地业务组件之间的通信问题

组件化主要还是解决本地业务组件间的调用，至于跨App或者Hybrid页面通过openUrl方式调用页面和服务的方式其实是可以拆分成两个步骤的问题：特定模块解析处理＋中间件调用。跨App通过info.plist配置的scheme跳转进入，hybrid页面通过JSBridge框架跳转进入，这部分都有特定的模块去解析完成。在特定的模块中是否要调用其它业务组件的页面或者服务由特定模块自行决定，这不是组件化中间件要去完成的事情。

（2）从工程代码层面来说，组件化就是通过中间件解决组件间头文件直接引用、依赖混乱的问题；

从实际开发来说，组件之间最大的需求就是页面跳转，需要从组件A的pageA1页面跳转到组件B的pageB1页面，避免对组件B页面ViewController头文件的直接依赖。其次就是服务的调用，服务调用模块绝不是为了解决url跳转的问题，只是服务调用方式可以用来解决页面跳转的需求，但是没有url跳转方案成本低。所以才有了蘑菇街方案的MGJRouter和ModuleManager的class－protocol方案的区别；而反革命的方案仍然用Target-Action方案来解决页面跳转问题，成本稍大；而且url跳转和服务调用是两种不同的组件间通信需求，用两种不同的方式来完成更有区分度。

（3）纯中间件只负责挂接节点的通信问题，不应涉及挂接点具体业务的任何逻辑。

中间件如果涉及到具体的业务逻辑，势必造成中间件对业务模块的直接依赖，所以中间件只需要抽象出业务通信的基本职责，规定好协议接口，完成调度功能即可。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

最后

技术是没有终点的，也是学不完的，最重要的是活着、不秃。零基础入门的时候看书还是看视频，我觉得成年人，何必做选择题呢，两个都要。喜欢看书就看书，喜欢看视频就看视频。最重要的是在自学的过程中，一定不要眼高手低，要实战，把学到的技术投入到项目当中，解决问题，之后进一步锤炼自己的技术。

技术学到手后，就要开始准备面试了，找工作的时候一定要好好准备简历，毕竟简历是找工作的敲门砖，还有就是要多做面试题，复习巩固。有需要面试题资料的朋友点击这里可以免费领取。

注：前端）**

[外链图片转存中…(img-MKHWJurg-1713496845523)]

最后

技术学到手后，就要开始准备面试了，找工作的时候一定要好好准备简历，毕竟简历是找工作的敲门砖，还有就是要多做面试题，复习巩固。有需要面试题资料的朋友点击这里可以免费领取。

[外链图片转存中…(img-NOPsKdoB-1713496845523)]

2401_84103903

关注

27
点赞
踩
16

收藏

觉得还不错? 一键收藏
0
评论
iOS组件化思路－大神博客研读和思考

技术是没有终点的，也是学不完的，最重要的是活着、不秃。零基础入门的时候看书还是看视频，我觉得成年人，何必做选择题呢，两个都要。喜欢看书就看书，喜欢看视频就看视频。最重要的是在自学的过程中，一定不要眼高手低，要实战，把学到的技术投入到项目当中，解决问题，之后进一步锤炼自己的技术。技术学到手后，就要开始准备面试了，找工作的时候一定要好好准备简历，毕竟简历是找工作的敲门砖，还有就是要多做面试题，复习巩固。有需要面试题资料的朋友点击这里可以免费领取。注：前端）**
复制链接

扫一扫