之前游戏为了解决在ios自动更新的问题，想到使用了将游戏代码打包成dll，使用反射加载执行的办法。办法想好了以后，一直没有做测试。上周不知道什么原因，终于有人去测试了，结果发现报错了。我当时觉得有点意外。虽说网上有人说ios上不能使用.net的反射模块，但是后来我仔细研究过这个问题，发现技术上应该是可行的。因为unity在使用C#作为脚本时，底层是使用的是mono。而使用mono的话，在ios平台上面，底层就应该是使用的Xamarin.iOS。它对于ios的限制主要在于它使用了AOT编译，而不是传统的JIT，也就是说IL代码在编译时，就被翻译成对应平台的机器码，而不是如JIT一样，在运行时动态翻译。其实大部分嵌入式平台都不会对JIT进行支持，主要是几个方面原因的考虑，（1）加快启动程序时间；（2）执行效率；（3）节约内存。既然是使用AOT编译，那么它对反射的限制应该主要是限制部分依赖JIT的功能，因此这个问题得核心不是反射的问题，而是JIT与AOT区别的问题。而我们使用反射只是在dll中查找一个已知类，这个应该是可以静态编译的，对JIT没有要求。
带着疑问，我帮忙查看了下报错的日志。结果才发现不是加载dll的地方报错了，而是在之后的代码里，protobuf-net的代码。这个发现说明了两个问题：（1）第一是dll里的入口函数已经进入了，因为报错的位置在这个之后很远的地方。这说明了之前的思路是没有问题。（2）第二protobuf-net在ios上面报错的原因还是和前面说的AOT编译限制有关。因为它使用了反射中对JIT有依赖的功能。
接下来就是解决protobuf-net的问题。其实之前早有人遇到了这个问题，protobuf-net作者因此提供了一个procompile的模块来解决它。大概的思路是（1）将proto文件解析出来的cs文件编译到一个独立的dll中；（2）使用precompile模块对这个新的dll进行处理，生成一个新的序列化dll，我个人觉得这个步骤主要是在这个序列化dll中记录消息类的描述信息，以便后面序列化，反序列化时不需要对JIT依赖。（3）将生成的两个dll，加上本身protobuf-net的dll一起加入到游戏工程，通过序列化dll里的序列化方法对消息进行处理。
到这里，这个问题应该就算解决了。不过感觉步骤还是有点繁琐，这种机械化的工作就应该让机器做，所以接下来就是将上面的几个步骤，做成自动化批处理，每次编译工程时，自动执行。这样一来，也算完美解决了。