在确定目标，动手实现huatuo前，有一个必须考虑的问题——我们如何确定huatuo的可行性？

il2cpp虽然不是一个极其完整的运行时，但代码仍高达12w行，复杂度相当高，想要短期内深入了解它的实现是非常困难的。而且除了官方几个介绍il2cpp的博客外，几乎找不到其他文档。 Hybrid mode execution 的实现复杂度也很高，如果不能确信能够在il2cpp上实现这套机制，贸然投入开发，万一几个月后发现此路不通，或者说开发完成后，突然发现有一个严重并且无解的系统性的缺陷导致这个方案完全不可用于商业项目，这会带来巨大的资源浪费，以及对开发者产生巨大的信心挫伤。 磨刀不误砍柴工，在动手前从理论上确信这套方案有极高可行性，是完全必要的。

以我们对CLR运行时的认识，要实现 hybrid mode execution 机制，至少要解决以下几个问题：

• 能够动态注册元数据，这些动态注册的元数据必须在运行时中跟AOT元数据完全等价。

• 所有调用动态加载的assembly中函数的路径，都能定向到正确的解释器实现。包括虚函数override、delegate回调、反射调用等等

• 解释器中的gc，必须能够与AOT部分的gc统一处理

• 多线程相关能正常工作。包括且不限于创建Thread、async、volatile、ThreadStatic等等

我们下面一一分析解决这些问题

我们在动手前检查了多个相关函数，基本没有问题。虽然不敢确定这一定是可行的，但元数据加载是huatuo第一阶段的开发任务，万一发现问题，及时中止huatuo开发损失不大。于是我们认为算是解决了第一个问题。

所有调用动态加载的assembly中函数的路径，都能定向到正确的解释器实现

我们分析了il2cpp中关于Method元数据的管理方式，发现MethodInfo结构中保存了运行时实际执行逻辑的函数指针。如果我们简单地设置动态加载的函数元数据的MethodInfo结构的指针为正确的解释器函数，能否保证所有流程对该函数的调用，都能正确定向到解释器函数呢？

严谨思考后的结论是肯定的。首先AOT部分不可能直接调用动态加载的dll中的函数。其次，运行时并没有其他地方保存了函数指针。意味着，如果想调用动态加载的函数，必须获得MethodInfo中的函数指针，才能正确执行到目标函数。意味着我们运行过程中所有对该函数的调用一定会调用到正确的解释器函数。

至于我们解决了第二个问题。

总结

我们通过少量的对实际il2cpp代码的观察，以及对CLR运行时原理的了解，再配合思维实验，可以99.9%以上确定，既然il2cpp生成的代码都能在运行时正确运行，那huatuo解释模式下执行的代码，也能正确运行。

我们在完成思维实验的那一刻，难掩内心激动的心情。作为一名物理专业的IT人，脑海里第一时间浮现出爱因斯坦在思考广义相对论时的，使用电梯思维实验得出引力使时空弯曲这一惊人结论。我们不敢比肩这种伟大的科学家，但我们确实在使用类似的思维技巧。可以说，huatuo不是简单的经验总结，是深刻洞察力与分析能力孕育的结果。