理论：

讲讲 main之前的 加载流程 你就知道为啥有机会改他们代码了

1.配置相关环境的操作

2.设置上下文信息

3.配置进程是否受限

4.检测环境变量

5.直到getHostInfo

第二步 加载共享缓存

第三步：实例化主程序

第四步：load any inserted libraries 加载插入动态库

第五步：链接主程序(就是在做符号绑定)

比如将UIKit、UIFoundation里面的方法的实际地址告诉主程序在哪个位置，会把所有的依赖库加载到内存、包括自己的framework

weakBind()弱绑定

项目中load方法的先后顺序跟Compile Sources中文件顺序有关

framework的执行顺序和link Binary With Libraries 顺序有关

简单理解：

比如这个sdk是framework嘛 无外乎 动态库、静态库，

也就是说只要我们的 写一个framework 在link Binary With Libraries 里面排在SDK的framework之前，或者 我们的framework属于插入动态库

那么我们的代码就比SDK的代码先执行，所以就可以在我们的framework里面 修改SDK里面方法的IMP，这样 等到程序运行的时候 调用SDK的方法就会走到我们修改的IMP上来 就可以做些修改

OC是运行时语言，方法的实现 也就是IMP实在运行时去找的，如果我在运行时 重新指定了一个方法的实现(IMP) 那么调用的时候 就会走到我们指定的位置来，刚刚说的main之前的加载流程 主要想说 framework的加载 也是有顺序的 既然有顺序 就有机会修改

实践：

hook这个方法

这个的时候 就走到我的方法里 打印了我的代码，我已经都修改了SDK的方法调用了 然后我想修改他哪个方法就修改哪个方法调用了

void new_registerMirrorView(id self,SEL _cmd,id view) {

    NSLog(@"set注入成功 🍺🍺🍺🍺");

    old_registerMirrorView(self, _cmd, view);

}

old_registerMirrorView 这个就是原来方法的IMP

oc分类实现