静态库扩展NSString后在Swift项目中运行崩溃的问题排查

嘿，我来帮你拆解这个崩溃的问题，其实核心原因和静态库的链接机制有关，咱们一步步说：

问题到底出在哪？ #

你看到的崩溃日志：

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[Swift._NSContiguousString isContainsEmoji]: unrecognized selector sent to instance 0x60400084b340'

本质是静态库中的Objective-C分类方法没有被App的运行时环境加载。

虽然你在桥接头文件里引入了分类头文件，编译也顺利通过，但静态库的链接器有个“偷懒”的特性：它会默认忽略那些没有被静态库内部直接引用的分类方法。你的isContainsEmoji方法只在外部的Swift代码里通过类型转换调用，链接器觉得这个方法没被用到，就把它从最终的二进制里优化掉了。

至于Swift._NSContiguousString，这只是Swift String在底层的一种实现类（它是NSString的子类），只要分类方法被正确加载，它本来应该能继承到这个方法——所以问题的核心还是分类方法没被保留下来。

两种靠谱的修复方案 #

方案一：给静态库添加链接器标记，强制加载所有分类 #

这是最常用的解决办法，步骤很简单：

• 打开你的CommonLib静态库项目
• 选中库的Target，进入Build Settings页面
• 搜索Other Linker Flags，添加-ObjC（注意是大写的O和C，中间没有空格）
• 如果你的库同时混编了Swift和Objective-C，偶尔会遇到-ObjC不生效的情况，这时候可以换成-all_load（不过这个会加载静态库中所有对象文件，可能有重复符号的风险，优先用-ObjC）

方案二：在静态库内部“主动引用”分类方法，避免被优化 #

如果不想改链接器参数，可以在静态库内部随便调用一次分类方法，让链接器认为这个方法是被使用的：
比如在静态库的某个Objective-C文件里添加：

#import "NSString+ext.h"

// 随便写个空函数，内部调用分类方法
void _forceLoadNSStringExtCategory() {
    [@"" isContainsEmoji];
}

然后在静态库的初始化逻辑里调用这个函数（比如库的didFinishLaunching方法，或者某个单例的初始化里）。如果是Swift文件，也可以直接加一行无用调用：

_ = "".isContainsEmoji()

额外的代码优化 #

其实你不需要把Swift String转成NSString再调用方法，只要桥接头文件正确引入了分类，Swift String会自动桥接NSString的分类方法，把Node.swift的代码改成这样更简洁：

import Foundation
import CommonLib
class Node{
    var name:String!
    var isBadName:Bool{
        // 直接调用，无需类型转换
        return name.isContainsEmoji()
    }
}

验证修复 #

做完上面的操作后，重新编译静态库和App，运行时就不会再崩溃了，isContainsEmoji方法会被正确加载并执行。

内容的提问来源于stack exchange，提问作者hopy