InjectionIII项目中动态方法注入的注意事项

动态方法注入的基本原理

InjectionIII是一个iOS/macOS开发中的热重载工具，它允许开发者在运行时动态注入代码变更，而无需重新编译整个应用。这种技术极大地提升了开发效率，特别是在UI调试和快速迭代阶段。

非final类方法注入的风险

在InjectionIII的使用过程中，当尝试向非final类(如示例中的TOPMonmentDraftTools)动态添加或移除方法时，系统会发出警告。这是因为Objective-C运行时对非final类的方法表处理存在固有风险。

运行时系统维护着一个方法列表，当类不是final时，其方法表可能在运行时被修改。动态注入新方法会导致方法表重建，这可能破坏现有的方法调用关系，特别是当其他代码已经缓存了该类的原始方法实现时。

崩溃的根本原因

动态方法注入导致崩溃的核心机制在于：

1. 方法调用缓存失效：Objective-C运行时为了提高性能会缓存方法实现，动态修改方法表会使这些缓存失效
2. 子类继承关系混乱：非final类可能被继承，方法表的修改会影响所有子类的行为
3. 并发访问问题：方法表修改过程中如果有其他线程正在访问，会导致内存访问异常

解决方案与最佳实践

针对这个警告，InjectionIII给出了一个看似矛盾的解决方案：将被注入的类声明为final。这实际上是通过以下机制解决问题：

1. final类禁止继承，消除了子类继承关系带来的复杂性
2. 编译器可以对final类进行更多优化，包括方法调用的静态分派
3. 方法表的稳定性更高，减少了运行时修改带来的风险

在实际开发中，建议：

1. 对于需要频繁注入的类，考虑声明为final
2. 如果类必须保持可继承性，考虑使用其他热重载策略
3. 在开发阶段使用final修饰，发布时再移除（如果需要）
4. 对于核心业务类，避免过度依赖运行时方法注入

深入理解技术细节

Objective-C的消息发送机制基于objc_msgSend函数，它会在类的方法列表中查找方法实现。当类不是final时：

• 运行时需要处理方法重写和类别添加的情况
• 每次方法注入都可能导致方法列表重建
• 已有objc_msgSend调用缓存可能指向错误地址

而final类由于继承链固定，方法查找可以更高效，也更容易安全地修改。

实际开发中的权衡

虽然将类声明为final可以解决注入警告，但开发者需要权衡：

1. 设计灵活性：final类无法被继承，可能影响某些设计模式
2. 测试便利性：无法创建子类来模拟测试
3. 框架扩展性：第三方无法通过继承来扩展功能

在快速迭代的开发阶段，临时使用final修饰是合理的折中方案。