背景
当类 TestObject有两个Category TestObject+V1,TestObject+V2 ,并且它们三个都实现了函数：whoami 。 那么，在TestObject调用 [self whoami] 。实际调用的是哪个category的whoami函数？
研究这个问题，主要分为六步：
- Category 是如何生成的
- 类的方法列表与Category的关系
- Category 加载顺序
- Category “覆盖”的风险
- 使用工具查找category方法“覆盖”的问题
- 利用今日头条和QQ浏览器，测试一下工具
Category 是如何生成的
Demo code 如下：
- TestObject
#import "TestObject.h"
#import "TestObject+V1.h"
#import "TestObject+V2.h"
@implementation TestObject
- (void)whoami
{
NSLog(@"TestObject");
}
@end
- TestObject+V1
#import "TestObject+V1.h"
@implementation TestObject (V1)
- (void)whoami
{
NSLog(@"V1");
}
@end
- TestObject+V2
#import "TestObject+V2.h"
@implementation TestObject (V2)
- (void)whoami
{
NSLog(@"V2");
}
@end
另外在TestObject+V2 头文件声明了property name.
@interface TestObject (V2)
@property (strong,nonatomic) NSString *name;
@end
使用Clang 命令生成TestObject.cpp ，里面包含了整个类的结构。
clang -rewrite-objc TestObject.m TestObject+V1.m TestObject+V2.m
执行完后，本地会生成：
TestObject.cpp
TestObject+V1.cpp
TestObject+V2.cpp
- TestObject.cpp
- TestObject+V1.cpp
使用MachOView 看一下TestObject+V1是否会在catlist段写入 OBJC$CATEGORY_TestObject$_V1 。
- TestObject+V2.cpp
这三个文件会首先生成对应的 XXX.o 文件，最后link 成一个可执行文件。但是在最终的文件（Mach-O）的catlist段，找不到对应的定义，里面是空白的。但是如果是写了系统类的category ，最终生成的MachO文件是可以在catlist段找到对应的声明。怀疑是编译器的优化，把自定义的类和该类的category合并了。
类的方法列表如何受categories加载的影响
研究category 的加载，就需要查看一下runtime 的源码了。下面是runtime加载category的时序图：
通过_read_images 把在Mach-O文件各段的数据都加载进来。我们关注的attachCategories函数：
static void
attachCategories(Class cls, category_list *cats, bool flush_caches)
{
if (!cats) return;
if (PrintReplacedMethods) printReplacements(cls, cats);
bool isMeta = cls->isMetaClass();
// fixme rearrange to remove these intermediate allocations
method_list_t **mlists = (method_list_t **)
malloc(cats->count * sizeof(*mlists));
property_list_t **proplists = (property_list_t **)
malloc(cats->count * sizeof(*proplists));
protocol_list_t **protolists = (protocol_list_t **)
malloc(cats->count * sizeof(*protolists));
// Count backwards through cats to get newest categories first
int mcount = 0;
int propcount = 0;
int protocount = 0;
int i = cats->count;
bool fromBundle = NO;
while (i--) {
auto& entry = cats->list[i];
method_list_t *mlist = entry.cat->methodsForMeta(isMeta);
if (mlist) {
mlists[mcount++] = mlist;
fromBundle |= entry.hi->isBundle();
}
property_list_t *proplist =
entry.cat->propertiesForMeta(isMeta, entry.hi);
if (proplist) {
proplists[propcount++] = proplist;
}
protocol_list_t *protolist = entry.cat->protocols;
if (protolist) {
protolists[protocount++] = protolist;
}
}
auto rw = cls->data();
prepareMethodLists(cls, mlists, mcount, NO, fromBundle);
// 把category 方法添加到类的方法列表中
rw->methods.attachLists(mlists, mcount);
free(mlists);
if (flush_caches && mcount > 0) flushCaches(cls);
rw->properties.attachLists(proplists, propcount);
free(proplists);
rw->protocols.attachLists(protolists, protocount);
free(protolists);
}
attachCategories把category 中的方法列表，属性，协议添加到类上。我们关注的方法列表的改变，注意到attachLists 函数：
void attachLists(List* const * addedLists, uint32_t addedCount) {
if (addedCount == 0) return;
// 把原来类的方法列表往后移，并把category放到类方法列表的最前面
if (hasArray()) {
// many lists -> many lists
uint32_t oldCount = array()->count;
uint32_t newCount = oldCount + addedCount;
setArray((array_t *)realloc(array(), array_t::byteSize(newCount)));
array()->count = newCount;
memmove(array()->lists + addedCount, array()->lists,
oldCount * sizeof(array()->lists[0]));
memcpy(array()->lists, addedLists,
addedCount * sizeof(array()->lists[0]));
}
else if (!list && addedCount == 1) {
// 0 lists -> 1 list
list = addedLists[0];
}
else {
// 1 list -> many lists
List* oldList = list;
uint32_t oldCount = oldList ? 1 : 0;
uint32_t newCount = oldCount + addedCount;
setArray((array_t *)malloc(array_t::byteSize(newCount)));
array()->count = newCount;
if (oldList) array()->lists[addedCount] = oldList;
memcpy(array()->lists, addedLists,
addedCount * sizeof(array()->lists[0]));
}
}
attachLists 后，TestObject的方法列表就添加了TestObject+V1和TestObject+V2的方法，而且从categories添加的方法会在插在原本类方法的前面。
如下图所示：
另外也可以用hopper看一下，发现是有两个一样的函数。
到这里问题应该很明显了，有三个函数签名一样的函数！那么运行的时候，是不是就按照你的意愿用了你想要的那个whoami 函数呢？
*** 运气好的时候，是的！***
Categories 加载顺序
没运气也没关系，来分析一下到底程序是如何选择运行哪个whoami 函数。运行时相关的事情，还是问runtime。class_getInstanceMethod ,这个函数大家熟悉吧，通过传入类和sel 来定位具体实现方法的地方。
static method_t *
getMethodNoSuper_nolock(Class cls, SEL sel)
{
runtimeLock.assertLocked();
assert(cls->isRealized());
for (auto mlists = cls->data()->methods.beginLists(),
end = cls->data()->methods.endLists();
mlists != end;
++mlists)
{
method_t *m = search_method_list(*mlists, sel);
if (m) return m;
}
return nil;
}
static method_t *search_method_list(const method_list_t *mlist, SEL sel)
{
int methodListIsFixedUp = mlist->isFixedUp();
int methodListHasExpectedSize = mlist->entsize() == sizeof(method_t);
if (__builtin_expect(methodListIsFixedUp && methodListHasExpectedSize, 1)) {
return findMethodInSortedMethodList(sel, mlist);
} else {
// Linear search of unsorted method list
for (auto& meth : *mlist) {
if (meth.name == sel) return &meth;
}
}
return nil;
}
struct method_t {
SEL name;
const char *types;
IMP imp;
};
从表头开始搜索与传进去的sel 名字匹配的method。这个列表也就是刚说的：
三个whoami 函数都是method_t类型，其name 和 types 是一样的，唯一不同的是imp 。这一点可以通过hopper来确定一下：
由于sel 名字是一样的，并且由于搜索列表是从头到尾，那么就会首先匹配到category中的 whoami 方法。现在关键点就落在如何确定category 里面方法的加载顺序。灵机一动，这顺序是否和编译顺序有关呀！？
OK，我们回到Xcode 的build log ,看一下编译的顺序是怎样的。
把TestObject+V1 和 TestObject+V2在build phases 的顺序换一下：
果然，category的编译顺序决定了该类的方法列表中，category方法的顺序。
Category “覆盖”的风险
风险是显而易见的，就是你实现的方法可能莫名其妙“被修改了”，导致程序无法正常执行。
使用工具查找category方法“覆盖”的问题
要分析程序是否存在Category 方法“覆盖”的问题，办法很简单。假设拿到安装包 CategoryOverrideTest.ipa ，依次执行如下方法。
- 解压CategoryOverrideTest.ipa
- 右键选中CategoryOverrideTest, Show package contents
- 找到CategoryOverrideTest
工具目前还在完善中，点击下载后zip包后，解压：
然后执行脚本：
部分同学会有报错：
/usr/local/Cellar/ruby/2.4.1_1/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- colored2 (LoadError)
from /usr/local/Cellar/ruby/2.4.1_1/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from ./Colored.sh:4:in `<main>'
这是因为缺少Ruby的colored2库，可以用以下命令
区别就是有没有颜色高亮。如何定位查找出来的函数所在的文件呢？
- 有源码的，可以直接定位到相应的category
- 没有源码的（静态库等），在Xcode 中就无法定位到方法所在的文件。可以使用
grep -r xxx 工程目录
举个例子,查找TBSDKGZIP 这个category所在的文件：
grep -r TBSDKGZIP ./
结果如下：
grep: .//BrandNew/Classes/UCFoundations/headers/YYMemoryCache.h: No such file or directory
grep: .//BrandNew/Classes/UCFoundations/headers/YYWebImage.h: No such file or directory
grep: .//BrandNew/Classes/UCFoundations/headers/YYWebImageManager.h: No such file or directory
grep: .//BrandNew/Classes/UCFoundations/headers/YYWebImageOperation.h: No such file or directory
grep: .//BrandNew/Classes/UCFoundations/headers/zip.h: No such file or directory
Binary file .//Build/Products/Debug-iphoneos/UCWEB.app/UCWEB matches
Binary file .//Build/Products/Debug-iphoneos/UCWEB.app.dSYM/Contents/Resources/DWARF/UCWEB matches
Binary file .//Build/Products/Debug-iphonesimulator/UCWEB.app/UCWEB matches
Binary file .//Build/Products/Debug-iphonesimulator/UCWEB.app.dSYM/Contents/Resources/DWARF/UCWEB matches
Binary file .//Library/framework/MtopSDK.framework/MtopSDK matches
Binary file .//Library/framework/MtopSDK.framework/Versions/A/MtopSDK matches
Binary file .//Library/framework/MtopSDK.framework/Versions/Current/MtopSDK matches
好了，激动时刻来了，在PP助手上下面几个已经砸壳后的app 来测试一下吧。(扫描结果太长，截图部分显示)
今日头条
QQ 浏览器
大家不妨下载工具扫描一下，针对已经在category中重复定义的方法检查一下，函数调用是否正确，说不定有意外收获。
