我当时接手了一个已经迭代三年的App主工程里直接堆了几十个业务库模块之间互相#import、交叉调用改一个支付流程要牵扯到首页、登录态、订单页、埋点组件四个地方每次发版光理依赖关系就要半天。这种阶段如果你也经历过那这篇关于组件化方案的文章就是你需要的。这是我在梳理 iOS 底层原理时整理的第 36 篇内容也是组件化系列的第一篇我打算把这件事讲透组件化不是把代码拆开而是把工程里的依赖关系、通信机制、版本治理重新定义一遍。这篇内容适合两类人一类是主工程已经乱到没法下手的开发者你想知道从哪一刀切进去最安全另一类是听说过组件化但不太理解它到底解决了什么问题的中级开发想从底层原理层面搞清楚为什么业界普遍采用这套做法。我会尽量用大白话把原理讲清楚同时给出一套可以直接落地的拆分路径。1. 组件化到底在解决什么问题从一团乱麻的工程现状说起1.1 一个典型的大泥球工程长什么样先描述一个很多人都不陌生的场景。某个业务模块比如订单详情它表面上是一个独立的目录但你点开它的头文件会发现它引用了首页的一个广告位视图、用户中心的登录弹窗、消息模块的通知回调甚至直接调用了网络层某个私有方法去拼请求参数。反过来首页也引用了订单详情的某个入口类用户中心也引用了首页的某些UI组件。这种互相引用的关系一旦形成网状的环项目就进入了一个非常危险的阶段。我见过一个极端例子主工程的PrefixHeader.pch里放了几百个#import所有类在编译期都能看到所有其他类新人入职第一周基本就是在一层一层解开又绕回引用关系。这种状态下的典型症状有三个第一改任何公共类都要全量回归因为不知道谁在依赖它第二编译时间越来越长因为头文件互相拖拽导致增量编译失效第三团队协作成本指数上升两个人改文件很容易互相覆盖对方的调用逻辑。大泥球工程的本质问题不是代码多或者目录乱而是依赖关系不可控。你没有办法在五分钟内回答一个关键问题如果我想把订单详情单独抽出去做成一个组件到底哪些代码是它的边界哪些依赖必须切断1.2 组件化的本质从毫无约束的依赖走向可治理的边界组件化要做的第一件事其实是重新定义边界。所谓组件我认为最低标准就是一条可以独立编译。一个目录只要不依赖主工程里那些乱七八糟的全局头文件能单独跑通构建它才配叫组件如果只是把代码搬进一个新文件夹但一编译就缺这个缺那个那只是物理上的移动不是逻辑上的拆分。组件化的本质可以从两个层面理解。第一个层面是物理层面也就是把代码按照业务域或基础能力拆分到独立的目录、独立的工程配置里每个组件可以单独编译、单独发布版本。第二个层面是逻辑层面比物理拆分更重要——依赖方向的控制。当你把组件A和组件B拆开之后你要让它们彻底断掉直接的编译期联系转而通过一个大家都认的中间层来通信。这个中间层就是我们后面要讲的中间件它是组件化方案的核心。我用一个特别直白的类比来讲这件事。想象一间办公室以前所有人都在同一个大开间里互相喊一声就能递文件效率挺高但问题是你不知道谁跟谁有关系而且窗外的人随时可能给你扔一沓文件进来。组件化就是给每个人分了独立的办公室门口挂一块牌子所有人找人都必须通过前台转达。前台就是中间件每个人只需要知道前台在哪不需要知道别人坐在哪一间。1.3 什么时候该动手拆三个值得启动组件化的信号很多团队其实拿不准到底工程到什么程度才需要做组件化。我总结了三个信号只要命中两个就说明这件事不能再拖了。第一个信号是编译时间失控。一次全量编译超过十分钟增量编译经常失效改一行代码要等很久才能跑起来。这种情况往往是头文件互相包含引起的说明依赖已经严重纠缠编译器的拓扑排序已经很难做优化了。第二个信号是改代码的恐惧感。修改一个底层基础库的方法签名你不敢动因为你不知道会波及多少个业务模块你只能往里面加新方法、保留老方法导致底层库越来越臃肿。这个不敢动的感觉就是组件化最真实的启动理由。第三个信号是团队开始按业务线分工。当你的团队从小规模变成多条业务线并行时如果所有代码还在同一个工程里互相引用就意味着各团队之间的协作完全靠口头约定和不要动我的代码的自觉这不可持续。组件化之后每个组件有明确的Owner改依赖关系是要过评审和版本管理的冲突从一开始就控制在边界处。2. 动手之前先拍板粒度、通信方案、公共库归属这三个决策必须提前定2.1 组件粒度怎么切按业务域切而不是按功能类型切很多人第一次接触组件化时最容易犯的错误是把组件切得跟分层架构一样UI层、网络层、数据层、工具层各自一个组件。这种切法不能说全错但它解决不了业务耦合的问题——订单详情和首页之间的问题不是UI层和网络层的问题而是两个业务域天然需要互相跳转、互相携带数据。如果你按功能类型切订单详情的UI代码和首页的UI代码还是会被塞进同一个UI组件里等于没拆。实践中最合理的粒度是按业务域切。什么是业务域一个业务域应该满足这样的条件它内部的一堆类天然需要一起变化它们对业务语义的理解是一致的改动频率也大致同步。比如订单是一个业务域它下面可以有自己的列表页、详情页、确认页、收货地址管理这些页面之间相互跳转是常态但它们和支付业务域的交互就应该通过接口而不是直接引用内部类。基础组件也建议按是否关心当前App业务来分。网络请求库、日志库、埋点SDK、图片下载库这些不关心业务语义的属于底层基础组件而像登录态这种虽然服务于业务但几乎所有模块都要用的可以单独作为一个中间层组件不要塞进任何一个业务组件里。2.2 组件间通信方案选型路由、Target-Action、Protocol三种机制背后的底层逻辑这是整个组件化方案里最关键的技术决策。先说结论现在业界主流的做法不外乎三种——URL路由、Target-Action转发、Protocol匹配注册。它们底层原理不同项目里的取舍也不一样我一个个讲清楚。URL路由是最容易理解的一种。它把页面跳转、事件调用都抽象成URL字符串组件A想跳转组件B的某个页面就向路由中心发起一个containervc://order/detail?orderId123这样的URL请求路由中心去匹配预先注册的表找到对应的处理者。这个方案最大的好处是灵活URL可以在远端下发适合配置化运营甚至能做到页面级的动态跳转缺点也很明显——URL是字符串编译期完全查不到错误参数容易拼错查问题时断点追到路由中心就断了可读性差。Target-Action转发是我个人更喜欢的方案它的核心思想是组件对外只暴露一个Target_xxx的模式调用方不直接引用组件的业务类而是通过中间件去动态查找Target并调用Action。它的优点是把字符串的阻力降到了最低——至少Target名和Action名方法名是有固定规则的中间件可以帮你在运行时检查方法是否存在缺点是整个调用链路走的是运行时反射偏离了编译期的类型安全。Protocol匹配的方案有点类似服务注册表。公共层定义好protocol接口组件内部实现这个协议并将实例注册到注册中心调用方通过idXXProtocol拿到实现类的实例再调用方法。它的优点是调用方拿到的还是有类型的对象可读性好、安全性高缺点是需要公共层真的放一套Protocol定义而这个公共层一旦膨胀就又变成了新的重灾区。我的建议是中小型团队优先考虑Target-Action或Protocol不要为了灵活而直接上URL路由因为URL的可追踪性太差出了问题不好查。如果你的业务有大量跨端、跨团队、运营配置诉求再考虑URL路由作为补充而不是唯一方案。这三种机制具体到代码层面的差异我在第3章里会给出完整示例。2.3 公共基础库的归属不把底层当杂货铺第三个拍板决定是公共基础库的治理。我见过一种情况组件化拆了中间件也做了但为了图省事把那些谁都看不懂归属的工具类全部塞进一个叫Common的组件几十个文件躺在里面最后这个Common变成了主工程的新版本。这其实是把原来的大泥球换了个名字继续留在工程里。公共基础库需要分层。最底层是纯工具组件比如日期格式化、字符串加密、颜色转换这种完全无业务语义的它们可以是一个组件往上是一些有技术边界但无业务语义的能力组件比如网络、存储、埋点上报、日志它们是第二层再往上才是登录态、用户画像这种有业务语义但全App共享的中间层组件。每一层只允许依赖更底层的东西同层之间原则上不允许互相依赖如果确实需要那说明这两个应该合并或者其中一方该下沉。3. 中间件的核心设计从代码层面把组件通信机制彻底讲透3.1 中间件的职责边界它是唯一一个所有业务组件都依赖的公共模块先把中间件的地位说清楚。在整套组件化方案里中间件是唯一一个可以被所有业务组件同时依赖的公共模块——注意唯一这个词。业务组件A不能直接依赖业务组件B但A可以依赖中间件B也可以依赖中间件A和B之间想通信路径必须是A→中间件→B。为什么要这样设计因为这会形成一个星形的依赖网络。星形结构有一个特别重要的特性从一个节点到另一个节点路径是固定的、唯一的你一旦确定A和B要通信你只需要审查它们各自跟中间件之间的关系就可以了。如果允许业务组件两两之间直接依赖那关系网就是矩阵式的任何一次新增依赖你都说不清它会不会形成环。我这里说的中间件有两种形态要区分清楚。一种是中间件本身只负责转发不保存具体业务实现另一种是注册中心式的中间件它内部保存了协议名和实例的对应关系。前者是Target-Action方案里的Mediator后者是Protocol方案里的ServiceRegistry。无论哪种形态它都要遵守一条铁律自己不能依赖任何业务组件业务组件的类名到了它这里最多就是字符串或者Protocol。3.2 方案一Target-Action转发的实现思路与关键代码Target-Action的方案核心是把调用某个方法拆成找到某个目标执行某个动作。我的实现思路是这样的中间件维护一个通用的performTarget:action:params:入口调用方把目标名和方法名当成字符串传进来中间件用运行时去构造对象、检查方法、发起调用并把结果返回。// 中间件核心接口对外只暴露这样一个方法 interface Mediator : NSObject (instancetype)sharedInstance; // 参数是字典返回值是id所有跨组件调用都走这个口 - (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params; // 另一个带完成回调的变体非必需但业务上经常用 - (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params completion:(void (^)(id result))completion; end实现里最关键的部分是运行时检查。不能拿到类名就直接performSelector因为Target可能不存在Action可能也传错参数了。我会做两层防护第一层用NSClassFromString判断Target类是否存在不存在就直接返回nil并记录日志第二层用NSInstanceMethodSignatureForSelector拿到方法签名确认参数个数匹配再用NSInvocation发起调用。- (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params { // 第1步拼接Target类名并校验是否存在 NSString *targetClassName [NSString stringWithFormat:Target_%, targetName]; Class targetClass NSClassFromString(targetClassName); if (!targetClass) { NSLog([Mediator] 找不到Target类: %, targetClassName); return nil; } // 第2步创建Target实例 id target [[targetClass alloc] init]; // 第3步拼接Action的方法名 // 约定iOS底层原理第36篇这里使用固定前缀方便统一查找 NSString *actionSelectorName [NSString stringWithFormat:Action_%:, actionName]; SEL actionSelector NSSelectorFromString(actionSelectorName); // 第4步校验Target是否响应 if (![target respondsToSelector:actionSelector]) { NSLog([Mediator] Target % 不响应 Action: %, targetClassName, actionSelectorName); return nil; } // 第5步用NSInvocation调用保证参数能正确传递和释放 NSMethodSignature *signature [target methodSignatureForSelector:actionSelector]; NSInvocation *invocation [NSInvocation invocationWithMethodSignature:signature]; invocation.target target; invocation.selector actionSelector; [invocation setArgument:params atIndex:2]; [invocation invoke]; // 第6步取出返回值可能是任意对象可能是nil id returnValue nil; if (signature.methodReturnLength) { void *buffer malloc(signature.methodReturnLength); [invocation getReturnValue:buffer]; returnValue (__bridge id)buffer; free(buffer); } return returnValue; }对应的在业务组件内部需要按照约定提供一个Target_xxx类以及以Action_开头的方法// 组件B内部提供的Target实现不会暴露给调用方 implementation Target_Order // 组件B的订单详情页跳转能力 - (UIViewController *)Action_OrderDetailVC:(NSDictionary *)params { NSString *orderId params[orderId]; OrderDetailViewController *vc [[OrderDetailViewController alloc] initWithOrderId:orderId]; vc.sourcePage params[sourcePage]; // 可以从参数里带业务上下文 return vc; } // 组件B的刷新订单列表能力 - (void)Action_RefreshOrderList:(NSDictionary *)params { [[NSNotificationCenter defaultCenter] postNotificationName:OrderListShouldRefresh object:nil userInfo:params]; } end调用方在使用时完全不出现组件B的任何类名只依赖中间件// 组件A内跳转到订单详情页 UIViewController *detailVC [[Mediator sharedInstance] performTarget:Order action:OrderDetailVC params:{orderId : 123456}]; if (detailVC) { [self.navigationController pushViewController:detailVC animated:YES]; }这个方案表面上复杂但它带来的一个巨大好处是调用方和目标方彻底解耦。组件A甚至不知道Order这个Target是否存在如果不存在中间件返回nil调用方自己处理兜底逻辑不会编译崩溃。3.3 方案二Protocol匹配的实现思路与注册中心设计Protocol方案跟Target-Action的思路不太一样。它的前提是公共层定义一套Protocol业务组件内部有具体的实现类去实现这套Protocol然后通过一个注册中心把协议名和实例对象关联起来。调用方按协议名去取实例拿到的不再是字典参数和id返回值而是干净的类型化接口。先看公共层接口的定义这个接口就放在所有组件都能依赖的中间层组件里// 中间层组件里的Protocol定义业务组件A和B都依赖这个中间层 protocol OrderDetailServiceProtocol NSObject // 返回订单详情页面实例 - (UIViewController *)orderDetailViewControllerWithOrderId:(NSString *)orderId sourcePage:(NSString *)sourcePage; // 获取某个订单的物流信息 - (NSString *)logisticsInfoForOrderId:(NSString *)orderId; end接着是注册中心的实现它本质上是一个线程安全的字典key是Protocol的字符串名value是实例对象typedef void (^ServiceGetter)(id service); interface ServiceRegistry : NSObject (instancetype)sharedInstance; // 注册组件启动时调用 - (void)registerService:(Protocol *)protocol impl:(id)impl; // 获取调用方在使用时调用 - (id)serviceForProtocol:(Protocol *)protocol; end implementation ServiceRegistry { NSMutableDictionary *_map; NSLock *_lock; } - (instancetype)init { self [super init]; if (self) { _map [NSMutableDictionary dictionary]; _lock [[NSLock alloc] init]; } return self; } (instancetype)sharedInstance { static ServiceRegistry *instance; static dispatch_once_t onceToken; dispatch_once(onceToken, ^{ instance [[ServiceRegistry alloc] init]; }); return instance; } - (void)registerService:(Protocol *)protocol impl:(id)impl { NSString *key NSStringFromProtocol(protocol); [_lock lock]; _map[key] impl; [_lock unlock]; } - (id)serviceForProtocol:(Protocol *)protocol { NSString *key NSStringFromProtocol(protocol); [_lock lock]; id impl _map[key]; [_lock unlock]; return impl; } end组件B既然实现了OrderDetailServiceProtocol它就需要在启动阶段把自己注册进去。这一步一般放在组件自己的加载入口里不要放在主工程里手写注册代码// 组件B内部的文件 implementation OrderDetailServiceImp (void)load { // 把实现类注册到协议对应的服务上 [[ServiceRegistry sharedInstance] registerService:protocol(OrderDetailServiceProtocol) impl:[[OrderDetailServiceImp alloc] init]]; } end调用方拿到的就是带Protocol类型的对象方法名、参数类型全部编译期可见// 组件A内跳转 idOrderDetailServiceProtocol service [[ServiceRegistry sharedInstance] serviceForProtocol:protocol(OrderDetailServiceProtocol)]; UIViewController *vc [service orderDetailViewControllerWithOrderId:123456 sourcePage:home];Protocol方案的优点这里就很明显了——编译器给了一层保险如果你把方法名拼错了编译直接报错如果你传的参数类型不对编译也报错。缺点是需要维护公共层的Protocol文件而且这些文件一多就得按域再拆分否则就变成第二个公共重灾区。3.4 参数传递与返回值设计的几个隐藏问题不管选哪种方案参数和返回值的细节都要格外注意。第一件事是参数规范我建议统一用NSDictionary *作为参数载体里面只能放可序列化的值类型比如字符串、数字、数组、字典禁止直接传业务模型对象跨组件。为什么因为业务模型对象往往携带了组件内部的数据结构你把一个OrderModel通过中间件传给另一个组件就等于把组件B的数据结构泄露给了组件A通信就没解耦。第二件事是返回值的兜底。跨组件调用不像直接调用那样有编译期保证中间件完全可能找不到Target、找不到实现、或者执行中异常退出。调用方必须假设对方大概率是能成功的但也可能失败失败时要给出默认行为不要直接崩溃。第三件事是异步调用的处理。很多跨组件操作是异步的比如获取用户画像、上传日志。我建议在Protocol定义时就显式声明回调参数让调用方一眼看出这个接口是同步返回还是异步回调不要在方法名里含糊。4. 从零拆出第一个组件一套可以在现有工程里直接落地的操作流程4.1 先拆哪个组件拆软柿子还是啃硬骨头选第一个拆的组件直接决定项目组对组件化的信心。我的经验是不要挑核心的高耦合模块也不要挑最边角的小工具而是挑一个中等独立、业务边界清晰、谁都离不开但不是最复杂的模块。比如埋点上报、配置中心、渠道包能力这类模块就非常合适它们业务语义清楚对外暴露的接口不多主要被调用、很少主动调用别人拆起来难度可控而且拆完的效果编译变快、依赖收敛能很快被团队感知到。千万别一上来就啃订单详情这种重度模块它横跨了网络、缓存、支付、物流、售后、评价拆到一半你会崩溃。软化柿子也要有策略——先拆一个小的完整跑通抽代码→加中间件→改调用方→验证编译→发布版本这个闭环团队就有了一套可重复的方法论后面啃硬骨头才有底气。4.2 抽离代码的五个步骤第一步圈定边界。打开现有模块的目录把对外暴露的头文件列出来再逐个检查这些头文件的#import凡是引用了外部业务组件的都标记出来。目标状态是这些对外头文件最终只依赖公共层和中间件不依赖其他业务组件。第二步搬运代码。把模块目录整体挪到新组件目录然后修主工程的project.pbxproj让这个目录脱离主工程的编译范围改为一个新的本地工程或CocoaPods私有源。这一步物理上先独立逻辑上还不能独立编译没关系先挂着一个继续往下走。第三步收敛依赖。把第二步编译报错的地方逐个处理。凡是在移除后不影响组件业务语义的直接删掉凡是属于基础设施的比如网络、日志、分类改成依赖公共层组件凡是因为依赖了其他业务模块的需要用中间件接口替代或者把那段逻辑移到调用方让外部调用方负责做好数据准备再调进来。第四步接管入口。找到这个模块被其他业务模块调用的所有入口把它们统一改成走中间件。如果选的是Target-Action方案就写一个Target_xxx类把所有入口包一遍如果选的是Protocol方案就写一个实现类注册到ServiceRegistry。改完后搜一遍主工程里所有直接#import当前模块文件的调用全部替换成中间件调用。第五步独立验证。新建一个空工程把该组件以源码方式集成进去跑通一次编译、一次启动、一次核心链路测试。如果空工程能编译通过说明这个组件的物理边界和逻辑边界都成立了如果编译不过继续回到第三步收敛依赖。4.3 依赖收敛验证脚本用命令看清import拓扑在收敛依赖的过程中人工查文件太慢我写了一个简单的脚本思路可以帮你在命令行里快速统计每个组件对外依赖的情况#!/bin/bash # 检查指定组件目录中所有import出来的外部引用 # 用法: ./check_dep.sh ComponentA COMPONENT$1 echo $COMPONENT 的依赖列表 grep -r #import $COMPONENT --include*.h --include*.m \ | sed s/.*:#import // \ | sort | uniq -c | sort -rn跑完这个脚本你能一眼看出哪个组件依赖了哪些外部文件。再配合白名单检查把允许依赖的公共层和中间件列进一个allowed_list.txt脚本输出依赖之后自动比对凡是不在白名单里的都标红这一步可以直接进CI做为组件化改造的准入检查。我之前就是靠这个脚本在拆分的时候定期跑一遍确认每个组件的依赖范围没有越界。4.4 拆完之后的坑资源文件命名冲突的教训代码拆完只是第一步拆完之后的资源文件冲突才让人头疼。我印象最深的一次是拆一个通用UI组件里面有一个loading.png的图片资源这个图片文件在另外三个组件里也各有一份同名但样式不同的。源码集成的时候还好因为直接引用各自的Bundle可一旦改成二进制集成资源文件会被全部打包进Assets.car同名资源到底用谁的那一份由编译期的同名覆盖规则决定结果就是某个页面的loading动画变成了别的风格排查了很久才发现是资源重名。这件事之后我把资源管理的两个规则定死了第一所有组件里的图片资源、XIB、Storyboard文件名强制加组件前缀比如订单组件里所有的图片都叫order_xxx第二每个组件使用独立的Bundle目录而不是把资源直接塞进主Bundle读资源时用[NSBundle bundleForClass:...]或专门生成的一个资源Bundle引用。这两条规则写进了团队的组件开发规约后续再也没有踩过同样的坑。还有一个小坑是load方法的使用。如果你像我在Protocol方案示例里那样用load注册实例要小心工程里如果有许多组件一起用load启动时间会变长。我现在的做法是尽量用initialize或者在某个中间层的启动编排器里统一注册不在多个load里各干各的这样启动链路更可控。5. 组件化完成之后的日子集成方式、版本治理与团队协作的长期博弈5.1 源码集成还是二进制集成没有银弹只有场景取舍组件拆完之后集成方式是个绕不开的问题。主工程里引用组件无非两种做法源码方式比如直接依赖Pod本地路径或源码仓库和二进制方式组件先编译成framework再被引用。这两者的取舍不能拍脑袋我对比一下在实际工程里的差异维度源码集成二进制集成编译速度慢尤其组件多时快编译时间明显下降调试体验好断点能直接进组件代码差方法栈只能看到符号名的二进制地址需要额外处理dSYMCrash日志符号化天然可读必须保证dSYM和当前CI打包记录对齐否则全是一堆十六进制地址组件发布门槛低改动推上去就能用高需要合并代码、打Tag、跑CI出framework、再发布模式切换成本低高需要脚本在源码和二进制之间切换很多团队的做法是日常开发用源码保证调试体验CI打包机用二进制保证分发链路的速度和稳定。这听起来理想但实现时有个关键点源码和二进制的切换必须靠Podfile里的一个开关控制而且切换后一定要全量重编一次因为两种模式下编译宏和头文件搜索路径是有差异的混合切换容易浪费半天在莫名其妙的编译错误上。5.2 版本治理组件必须固定版本禁止最新版就完事组件化后期最大的敌人不是技术而是版本管理的随意性。很多组件刚拆出来的时候还老老实实打Tag用着用着就开始偷懒主工程里直接写成依赖~ 1.0或者干脆用latest这种裸奔方式。这种做法短期省事长期就是一个灾难——某个组件发了一个新版本中间件某个行为变了主工程下一次打包时悄悄把依赖升上来线上就出现了一个你完全不知道为什么会出现的问题。我建议组件版本策略学习需要时才更新的原则。主工程里所有组件的依赖版本一律写死为具体版本号例如pod OrderComponent, 1.2.3不写~浮动范围。每次升级组件版本都当作一次独立的发布行为更新完毕后要跑全量链路测试确认组件行为没有发生不可控变化再提交版本变更。依赖锁定不是为了限制更新而是为了让你在升级时清楚地知道自己改了谁、影响面是什么避免被意外升级。这里还有一个小技巧组件的CI流水线里加上版本变更记录校验每次发版时必须生成一条ChangeLog让团队所有人在更新组件时第一眼看到的就是行为变化摘要而不是自己去比对代码差异。5.3 组件Owner机制与Code Review边界的转移组件化不仅是工程结构变了团队的协作模式也必须跟着变。以前所有代码都在一个工程里代码Review的边界是不要让别人的改动破坏我编译过的代码。组件化之后跨组件的改动边界变成了任何触及组件间依赖关系的改动都要双方组件Owner共同确认。我给这套机制定的规则是这样的。每个组件必须有一个明确OwnerOwner对组件的接口稳定性、版本节奏、依赖方向负责凡是组件A想新增对组件B的依赖或者想让中间件增加一个新入口都必须由A的Owner提出B的Owner和中间件Owner分别评审确认没有形成循环依赖、没有破坏既有调用约定才允许合并。如果团队很小Owner可以是一个人兼任多个但这个机制不能省因为它是防止组件化倒退成另一种大泥球的护栏。另外跨组件查问题的协作方式也变了。以前通过全局搜索一个类名就能找到调用方组件化之后搜索会断在中间件那一层你不知道谁在真正调用、谁传的参数不合法。所以我在中间件的日志里加了一个调用方上下文标识——记录是哪个组件通过哪个入口调用了哪个Target或哪个Protocol这样在追问题时能顺着日志链路快速定位是哪条业务线触发的。5.4 组件化之后还能往哪走动态化、灰度路由与按需加载组件化不是终点它更像一个地基。当地基打平之后你才有条件去做很多以前不敢做的事。我个人在推进组件化时最大的体会是它给后续演进铺了两条路。第一条路是页面的动态化基础。因为所有跨组件的页面跳转都走中间件了你可以在中间件里加一层路由匹配规则让某些环境下组件A跳组件B的入口可以被替换为另一个远端页面或H5页面。这对运营活动和AB实验非常有用但前提是通信链路必须统一否则你没法在统一入口处做切换。第二条路是按需加载和启动优化。组件拆完之后每个组件都有了独立的二进制产物和生命周期你可以把非核心组件改成用到时才加载减少启动时的链接负担和初始化开销。这是二进制集成的隐藏红利但工程量不小需要组件化稳定运行一段时间之后再逐步推进不要并行开工。我自己的建议是组件化的第一阶段先把依赖关系理顺、中间件落地、前两三个组件拆出去并稳定运行团队形成一套版本治理的共识当你发现新需求不用再翻遍整个工程、跨组件改动一个月也出现不了几次的时候再考虑往动态化和按需加载走顺序不能乱。最后说一点我个人的实战感受。组件化改造这件事技术选型排第二改造的决心和过程管理排第一。你会发现真正难的不是写中间件那几行代码而是把团队过去几年习惯直接import一下顺手调用的惯性扳回来以及在拆分过程中忍受一段时期编译报错、依赖解不开的混乱。但只要挺过第一个组件团队建立起了边界感整个工程的可维护性会有质的飞跃。拆完第一个组件那天下班我们几个做这个项目的同事都觉得原来脑子里绕来绕去的那些不要动我代码、但是你得调我接口的默契终于变成了一条条看得见的墙虽然推门要绕路了但心里踏实多了。