最近遇到个需求，在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的信息：

验证完毕，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中查找）：

接下来我们再测试一下在所有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];