runtime性能优化

先区分“运行时机制”与“性能瓶颈”

很多性能问题并不是 runtime 本身慢，而是业务层做了高频反射、频繁对象创建、主线程重逻辑。优化应先定位热点，再决定是否调整 runtime 用法。

高频场景优化点

1. 减少重复反射

class_copyPropertyList、method_get... 等反射操作放在初始化阶段缓存结果，不要每次请求都重新解析。

2. 控制 swizzling 范围

不要在大量类上全局交换。只对必要类和必要方法注入，避免全链路副作用。

3. 避免主线程做动态组装

模型映射、selector 组装等可在后台线程预处理，然后主线程只做轻量 UI 绑定。

监控与验证

• Time Profiler 看热点函数占比
• Main Thread Checker 看主线程违规
• 对比优化前后关键页面首屏时间和卡顿率

常见误区

• 为“追求优雅”过度依赖动态分发
• 没有基准数据就盲目重构
• 把可读性换成微小性能收益

总结

runtime 优化的核心是“减少不必要的动态行为”。先做缓存、限范围、避主线程，再考虑更激进的架构调整。