前言

今天在重温《程序员的自我修养》中关于符号表的章节时，突然脑子灵光一现，想到了这个知识的一个应用场景，所以便有了这篇文章。

若对 iOS 组件化不太了解，可以看笔者的另一篇文章：解读 iOS 组件化与路由的本质，本文主要是谈一下如何利用弱符号来实现 iOS 组件化解耦。

强弱符号简述

函数和全局变量编译后需要有唯一的符号名，在链接时才不会混淆。程序员所写代码中的变量名会经过修饰后作为符号名，比如 C 中fun会被修饰为_fun。而符号分为弱符号与强符号，对于 C/C++ 来说，编译器默认函数和已初始化的全局变量为强符号，未初始化的全局变量为弱符号，可以使用__attribute__ ((weak))定义一个弱符号，编译器决议符号时有如下规则：

• 不允许强符号被多次定义。
• 多个符号名重复且只有一个强符号时，选择强符号。
• 多个符号名重复且都是弱符号时，选择占用空间最大的一个。

也就是说，符号名是可以重复的，只要保证最多一个强符号。

核心思路

谈到这里可能很多人都明白笔者要做什么了。iOS 组件化核心的问题是解耦，需要在不导入目标业务模块的情况下通过一些方式调用到目标业务，那么只需要在目标业务模块中定义一个强符号，在使用方定义一个弱符号就能轻易解决。

具体实施

虽然思路是明确了，但是大家都是很懒的，总是想方设法减小一些实施成本。笔者简单设计了一下，非常容易理解，代码见 DEMO。

比如EAim业务模块，建一个文件EAimRouter.m专门放置相关路由方法：

void ERouterGotoEAimController(NSString *name, void(^callBack)(void)) {
    EAimController *vc = [EAimController new];
    vc.name = name;
    vc.callBack = callBack;
    [UIViewController.yb_top.navigationController pushViewController:vc animated:YES];
}

这些路由 C 语言方法和EAim业务模块是一个 repo 的，它们也就是解耦所需的强符号。为了让弱符号相关代码统统由EAim业务方来维护，所以有必要额外建立一个 repo，这里叫做EAimMediator.h，仅仅是一个头文件：

__attribute__ ((weak)) void ERouterGotoEAimController(NSString *name, void(^callBack)(void)) {
    ERouterNotFound(name, callBack, nil);
}

EAimMediator.h repo 是由调用方去导入的，很明显这个文件是和具体业务解耦的。这些 C 方法也就是解耦所需的弱符号。若当前业务模块导入了EAim模块，则这个方法会被EAim中定义的同名方法ERouterGotoEAimController覆盖；若没有导入EAim模块，就会走ERouterNotFound进行容错处理。

ERouterNotFound是放在EMediator.h/.m中的，统一处理路由未找到的情况：

void ERouterNotFound(id params, ...) {
    if (params) {
        va_list argList;
        va_start(argList, params);
        id arg = params;
        do {
            NSLog(@"cur arg: %@", arg);
        } while ((arg = va_arg(argList, id)));
        va_end(argList);
    }
    NSLog(@"router not found");
}

EMediator.h/.m的存在是有意义的，专门放路由相关的处理算法逻辑，作为公共业务组件，由所有需要的业务模块导入。

优劣分析

实现组件化解耦一般有三种方式：Protocol、Block、Runtime 动态调用，它们的优劣具体可参考 解读 iOS 组件化与路由的本质。

弱符号方式和使用 Protocol 方式一样，没有一个统一的拦截地方，所以若要实现所有路由的拦截将需要手动调用一次拦截方法，这是不及 Block 和 Runtime 方式的缺点。

弱符号方式比 Block 和 Runtime 方式优越的地方是不需要很多的硬编码，为什么说很多？因为弱符号的那个声明编译器是不会检查是否与对应的强符号一模一样，所以这个可以说是硬编码，只是可以通过复制粘贴简单处理，并且由于弱符号维护方也是相应的业务团队，所以这个成本算比较低。

弱符号方式比 Protocol 和 Block 优越的地方是不需要注册，编译器会自动的根据前面提到的规则静态决议符号引用的地址。

弱符号方式还有一个优点是代码很简洁，几乎只有强符号和对应的一个弱符号，没有大量的中间层处理代码。不过它有一个问题需要注意，就是当项目包含 Swift 时可能需要进行一些复杂的转换，或许纯 Swift 项目可以通过 Swift 语言本身的特性进行设计。

后语

目前来看，这似乎是一个可行的 iOS 组件化解耦的方案。不过整个过程只是笔者今天的一个小灵感，方案实施可能有一些隐患，场景也没有完全实践过，所以欢迎各位大佬批评指正 😁。