聊聊"ObjC"的故事

&＃8220;民之失德，乾糇以愆；他山之石，可以攻玉。&＃8221; &＃8211; 《诗经》

在开发 iOS 应用时，可能遇见这样的情况：你想实现的某种功能（比如崩溃收集），已经有成熟的产品提供，可行的方案就是集成这个使用了很久，且有专业人员维护，最重要的是“免费”的产品。一番折腾之后，运行时有可能出现&＃8221;selector not recognized&＃8221;错误，最后发现是少了如下的配置(Build Settings -> &＃8220;-ObjC&＃8221;):

那么这个&＃8221;–ObjC&＃8221; 到底是个什么鬼？ 我们来扒一扒。

据坊间说：如果你集成了有 category 的静态库，有可能出现上述错误。原因就是：
Technical Q&A QA1490
&＃8220;An impedance mismatch between UNIX static libraries and the dynamic nature of Objective-C can cause category methods in static libraries to not be linked into an app, resulting in &＃8220;selector not recognized&＃8221; exceptions when the methods aren&＃8217;t found at runtime.&＃8221;

这段话的意思就是：链接器在处理包含Category方法的UNIX的静态库时，没有将Category的方法链接到APP中，造成这个错误。具体的细节在本文的补充部分展开。
可以看出，解决这个错误的方法就是：将Category的方法链接到APP中，这样APP运行时，就能够找到对应的selector。而 –ObjC就可以完成这个任务。&＃8221;-ObjC&＃8221;的作用是：将静态库中任何Objective-C代码都链接到APP中。任何Objective-C代码当然也包括Category的方法。可以看出，使用-ObjC可能会链接很多静态库中未被使用的Objective-C代码，极大的增加APP的代码体积。

&＃8220;-ObjC&＃8221; 的兄弟

和 &＃8220;-ObjC&＃8221;作用类似的有以上的五种方案。可以看出，从增加APP代码体积来看，伪符号方案增加得最少&＃8221;Perform Single-Object Prelink&＃8221;、 &＃8220;-force_load&＃8221; 和 &＃8220;–ObjC&＃8221; 次之，&＃8221;-all_load&＃8221; 增加得最多。在开发iOS SDK时，为了方便使用者手动集成，最好是减少使用者需要配置的信息，所以&＃8221;伪符号&＃8221;方案和 &＃8220;Perform Single-Object Prelink&＃8221;方案是推荐的。另外，第三方SDK常常是闭源的，对于使用者来说，伪符号是透明的，所以从简便性角度看，推荐&＃8221;Perform Single-Object Prelink&＃8221;方案。

&＃8220;selector not recognized&＃8221;错误的产生根源

iOS工程，从源文件到生成最终的APP文件，通常要经过如下步骤：

源文件经过编译和优化后，会生成目标代码。目标代码中包括符号表，标示了此代码中的全局符号和静态符号，还标示了导入符号等，链接器会根据符号表分析各个目标代码之间的调用关系，然后将使用到的代码进行链接和重定位，最后生成可执行文件。在编译Objective-C源文件到目标文件时，编译器并不知道方法的对应实现，只能在运行时才知道，所以编译器只会为类生成链接符号，对类中的方法不会生成链接符号。由于Category方法并不对应一个新类，所以不会生成链接符号，链接器也不会将Category方法合并到原始的类中，最终导致链接器忽略了Category方法，不会将其链接到可执行文件中。

更多资讯请关注查看网易云捕官方博客