iOS获取类的所有子类/所有实现协议的类的最佳实践
最近遇到个需求，在APP加载的时候，动态获取所有实现了XXXListener协议的类，初始化并添加到listenerArray中，这样，每次有新的业务模块需要监听的时候，就不需要手动addListener了。
当然，除了这种方案，还有很多其他的方案可选，但其他方案都需要手动添加listener。
确定了方案，开始实现功能，实现思路比较简单，用runtime动态获取所有的类，再根据自己的需求进行筛选，代码大致如下：
- (NSArray<Class> *)classesConformsToProtocol:(Protocol *)protocol{
//注册类的总数
int count = objc_getClassList(NULL,0);
NSMutableArray *array = [NSMutableArray arrayWithCapacity:0];
//获取所有已注册的类
Class *classes = (Class *)malloc(sizeof(Class) * count);
count = objc_getClassList(classes, count);
for (int i = 0; i < count; i++) {
Class clazz = classes[i];
if (class_conformsToProtocol(clazz, protocol)) {
[array addObject:clazz];
}
}
free(classes);
return array;
}
//调用
NSArray *array = [self classesConformsToProtocol:@protocol(UITableViewDataSource)];
如果是想获取某个类的所有子类，只需要修改下筛选逻辑即可：
if (superClass == class_getSuperclass(clazz)) {
[array addObject: clazz];
}
好了，功能实现了，看上去很完美，但作为一个优秀的程序员，我们要将眼光放远，不能只满足于功能实现。
发现问题
话不多说，先运行下程序，看看方法的执行时间：
20毫秒，怎么说呢，虽然不算很长，但我这只是个Demo啊，所有的类加起来也不到10个，需要执行这么久么？
但是我突然想到，虽然Demo里只定义了几个类，但我们获取的是所有已加载的类，系统的类也是类啊！
于是我打印了下count：
emmm....两万多个类，怪不得要执行这么久...
然后我顺便看了下我们公司的项目，将近5.6万个类，这么查可不太合适啊...
我觉得，优化的方法肯定是有的，可是不论是百度还是google，都没有发现更好的写法，没办法，只能自己研究了。
我想，如果有优化的方法，那一定是在runtime.h文件中，果然，我找到了这三个方法：
Image是Executable（可执行文件），Dylib或Bundle中的一种，所以同一个库中的所有类的image都相同。
先针对Demo的情况，因为实际需要遍历的类都是我们在项目中创建的，所以我们只需要遍历当前类的image中的所有类即可，大致代码如下：
const char *imageName = class_getImageName(self.class);
unsigned int count;
const char **classNames = objc_copyClassNamesForImage(imageName, &count);
for (int i = 0; i < count; i++) {
Class clazz = objc_getClass(classNames[i]);
if (class_conformsToProtocol(clazz, protocol)) {
[array addObject:clazz];
}
}
运行时间如下：
可以看到，查找效率提升了30倍左右，非常nice。
顺便贴一下image的信息：
/private/var/containers/Bundle/Application/60C80966-7B72-42BB-A441-A906DDE8DECB/CycleListenerDemo.app/CycleListenerDemo
更加复杂的情况
上边只是针对Demo，但实际的使用场景中，需要实现的Protocol可能在其他的库中，需要实现Protocol的类可能也在不同的库中，这样，我们就没办法只在当前的image中寻找了。
但我们肯定也不需要遍历所有的image，于是我打印了一下项目中的image，发现有551个之多！我随便截了一部分，如下图所示：
经过分析发现，/System/Library/Frameworks/，/System/Library/PrivateFrameworks/，/usr/lib/路径下的image都是系统的库，可以不用去遍历。
去掉这些之后的内容如下：
剩下的image已经不多了，进一步分析后发现，我们需要处理的image全部都在/private/var/containers/Bundle/Application/Your Application ID/xxx.app/目录下，其他的image均为系统的。
这个目录下有一个xxx可执行文件和一个Frameworks目录，目录下的image是项目中引入的第三方或我们自己的framework。
但是仔细观察会发现，并不是项目中所有的framework都会对应一个单独的image，比如我们常用的Bugly，就没有出现在剩余的image列表里：
经过分析，我猜测，Frameworks目录下的，应该都是动态库，而所有的静态库，应该都在xxx可执行文件中。
下面我们来验证下，我从列表中随机找了一个framework，然后进入到对应目录：
cd .../.../Flutter.framework
然后查看文件信息：
file Flutter
打印的信息如下：
可以看到，这个库确实动态库
然后我们再看看Bugly的信息：
果然是静态库，看来我们猜的没错，接下来我们打印下可执行文件
image里所有的类，看看bugly在不在里边：
验证完毕，Frameworks目录下确实都是动态库的image。
一般来说，会封装成动态库的都不会耦合业务逻辑，所以，Frameworks目录下的image我们也不需要遍历了~
那么我们需要遍历的image，就只有一个了，就是APP可执行文件的image，就是当前类的image~
如果真的那么巧，Protocol放到了动态库里了，那么就遍历当前和APP这两个image就好了~
如果特别特别巧，别的动态库里也有实现了协议的，那么我们只好将APP和Frameworks目录全都遍历了...
iOS 16新增加的API
在runtime.h文件中，我又找到了这个方法：
估摸着是苹果看到开发者遍历所有类的需求比较多，但是遍历的效率又太差，所以提供了一个官方的遍历方法。
不过，这个方法是iOS 16才加的，之前的版本是用不了这个api的，我们用这个最新的api，查找一下可执行文件image中的类，看看使用这个方法能提高多少效率（image参数传null代表在调用者的image中查找）：
0.3毫秒，比我们自己写的查找快了1倍多，不得不说，系统的方法就是棒~
接下来我们再测试一下在所有image中查找：
54毫秒，反而比我们最开始的方法还要久，经过分析发现，这个新的api的入参image，是需要用dlopen()这个函数将imageName进行转化的，并不能直接传入image的字符串，而多出的时间就是消耗在dlopen()这个方法上的。
而直接在当前image中查找，并不需要转化image，只需要传入null即可，所以，新增加的这个api，只适合在当前的image中查找的情况。
到这里，我们可能会想到，既然新api适合在当前的image中查找，那么我们可以做个版本判断，iOS 16之前用老方法，之后用新方法，代码大概如下：
- (NSArray<Class> *)classesConformsToProtocol:(Protocol *)protocol{
NSMutableArray *array = [NSMutableArray arrayWithCapacity:0];
if (@available(iOS 16.0, *)) {
objc_enumerateClasses(nil, nil, protocol, nil, ^(Class _Nonnull aClass, BOOL * _Nonnull stop){
[array addObject:aClass];
});
return array;
}
const char *imageName = class_getImageName(self.class);
unsigned int count;
const char **classNames = objc_copyClassNamesForImage(imageName, &count);
for (int i = 0; i < count; i++) {
Class clazz = objc_getClass(classNames[i]);
if (class_conformsToProtocol(clazz, protocol)) {
[array addObject:clazz];
}
}
return array;
}
运行了一下，结果如下：
我运行的系统确实是iOS 16+，但为什么这次的运行时间是之前的4倍之多呢？
答案其实不难猜，因为@available(iOS 16.0, *)这个判断，也相对比较耗时，多出来的时间是在这里的。
结论&&最终方案
结论就是，新的api目前不适合在任何场景使用。
最终代码：
- (NSArray<Class> *)classesConformsToProtocol:(Protocol *)protocol forImage:(const char *)imageName{
NSMutableArray *array = [NSMutableArray arrayWithCapacity:0];
if (!imageName) {
imageName = class_getImageName(self.class);
}
unsigned int count;
const char **classNames = objc_copyClassNamesForImage(imageName, &count);
for (int i = 0; i < count; i++) {
Class clazz = objc_getClass(classNames[i]);
if (class_conformsToProtocol(clazz, protocol)) {
[array addObject:clazz];
}
}
return array;
}
//调用
[self classesConformsToProtocol:@protocol(UITableViewDataSource) forImage:nil];
