今天我们来聊聊如何跟Unity学代码优化，准确地说，是通过学习Unity的IL2CPP技术的优化策略，应用到我们的日常逻辑开发中。
做过Unity开发的同学想必对IL2CPP都很清楚，简单地说，IL2CPP就是Unity用来替代mono的一种script backend。至于说Unity为什么用IL2CPP替代mono，就是另外的话题了，本文就不细港了。
IL2CPP由两部分组成：
一个AOT（ahead of time）compiler。完全用C#写的。
一个VM runtime library。主体C++，外加部分平台特定的汇编代码。
IL2CPP AOT compiler的工作原理就如字面意思，读取并Parse （虽然并不知道用Mono.Cecil算不算Parse）IL Assembly ，分析并优化，然后生成cpp代码。IL2CPP的实现也很简单，生成的C++代码基本跟IL一一对应，有兴趣的同学可以自己试一下写点C#，然后看看生成的C++代码。
IL2CPP正式release已经有一年多了，一开始人人质疑，现在大家已经基本接受。这种转变肯定不是一日促成的，主要还是靠Unity对IL2CPP的重视和持续跟进的优化。
这两个月，Unity官博发了一个IL2CPP优化三部曲，接下来我们就看看如何从其中学习代码优化思路。
首先是第一个优化例子：
public abstract class Animal {
public abstract string Speak();
}
public class Cow : Animal {
public override string Speak() {
return "Moo";
}
}
public class Pig : Animal {
public override string Speak() {
return "Oink";
}
}
public class Farm: MonoBehaviour {
void Start () {
Animal[] animals = new Animal[] {new Cow(), new Pig()};
foreach (var animal in animals)
Debug.LogFormat("Some animal says '{0}'", animal.Speak());
var cow = new Cow();
Debug.LogFormat("The cow says '{0}'", cow.Speak());
}
}
这个是最教条主义的面向对象编程入门示例，很显然，从常识来思考的话，示例中的animal.Speak()是多态的，而cow.Speak()不是，前者会做一次virtual function call，而后者会做一次direct function call，两者的性能差距是一次虚函数表查询。
但是，IL2CPP实际上并不会这么做。IL2CPP的优化策略非常保守，而且为了实现简单，IL2CPP并不会在读IL指令的时候维护上下文状态。因此IL2CPP看到cow.Speak()没有办法判断cow的具体类型，保险起见，只能做一次虚函数表查询，也就是表现为virtual function call。
当然优化起来也很简单，程序员人肉加hint即可。而且这种hint方式我们在各种语言里都能见到，那就是给Cow的类型定义加一个sealed修饰符，问题终结。
优化一方面要跳过不需要的逻辑，另一方面还要简化无法跳过的逻辑。毕竟对于大多数情况，virtual function call的开销是逃不掉的。接下来，IL2CPP开发组又介绍了他们优化virtual function call的思路。
先看示例代码：
class BaseClass {
public virtual string SayHello() {
return "Hello from base!";
}
}
class GenericDerivedClass<T> : BaseClass {
public override string SayHello() {
return "Hello from derived!";
}
}
public class VirtualInvokeExample : MonoBehaviour {
void Start () {
Debug.Log(MakeRuntimeBaseClass().SayHello());
}
private BaseClass MakeRuntimeBaseClass() {
var derivedType = typeof(GenericDerivedClass<>).MakeGenericType(typeof(int));
return (BaseClass)FormatterServices.GetUninitializedObject(derivedType);
}
}
MakeRuntimeBaseClass().SayHello()这个坑相信大家刚接触Unity的时候都踩过，由于iOS平台不支持JIT compile method，这里如果不做hint，就会导致真机运行时crash。
IL2CPP的runtime library实现也类似，会在SayHello这个virtual function call的过程中查一次虚表，如果找不到调用方法，就会抛出一个托管的异常。
代码在这里：
static inline void GetVirtualInvokeData(Il2CppMethodSlot slot, void* obj, VirtualInvokeData* invokeData) {
*invokeData = ((Il2CppObject*)obj)->klass->vtable[slot];
if (!invokeData->methodPtr)
RaiseExecutionEngineException(invokeData->method);
}
这里对于我们写逻辑的来说，其实真没什么可优化了。而且对于有指令级优化经验的程序员，会把这个机会交给CPU的branch prediction。
但是IL2CPP团队还是选择把这个if优化掉了。简单地说就是自己写了个stub method，然后vtable[slot]本来应该为null的情况都给指到stub method。
这样，虽然在极少数需要抛出异常的情况下，多了一次函数调用的开销，但是对于绝大多数情况，都省了一次if检查开销。
按IL2CPP官博的说法是，这个优化提高了3%到4%的表现，我们就姑且信之，淆习一个。
接下来是原博的第三个示例：
interface HasSize {
int CalculateSize();
}
struct Tree : HasSize {
private int years;
public Tree(int age) {
years = age;
}
public int CalculateSize() {
return years*;
}
}
public static int TotalSize<T>(params T[] things) where T : HasSize
{
var total = ;
for (var i = ; i < things.Length; ++i)
if (things[i] != null)
total += things[i].CalculateSize();
return total;
}
注意第21行中的things[i] != null，这里如果T具现为Tree类型，就会做一次装箱操作。
如果对代码生成有了解的同学，可能还会联想到generic sharing，也就是泛型函数具现为不同的引用类型时可以共享同一个方法实例，而具现为值类型时就会决议到不同的方法实例。
同时由于IL2CPP的AOT性质，编译期就已经知道了这些事情，所以IL2CPP完全可以把具现的每个值类型泛型函数实例特殊处理，去掉里面的装箱操作。
事实上，IL2CPP就是这么干的，也确实让程序员少操了不少心。
小结一下，以上优化技巧，我们应该如何在写逻辑的时候应用上？下面就逐条淆习一下：
第一个例子中，IL2CPP借助编译期hint获得了额外的优化元信息。
针对这一点不太好列举写逻辑时候的应用情景，如果经常用可以给类型加注记或Attribute的语言（比如C#）可能会有类似的优化经验。
假设我们要开发一个非侵入式的序列化库，核心需求是把传进来的object序列化成字节流。
对于库来说，传进来的是一个未知的object，需要借助反射拿到类型元信息，然后动态生成序列化代码，以供之后的该类型object序列化使用。
这就跟JIT一样，相当于在每种类型的object第一次序列化的时候，库需要动态生成方法，这个成本相当高，不过好在可以之后摊还。但是对于有些服务端来说，这种随机的性能压力是不可忍受的。
因此我们可以hint住可能会序列化的类型定义，形成一种约束，规定程序员在运行时只能给库这些hint过的类型的object。
这样，序列化库初始化的时候一次性生成好这些类型的序列化函数，就能把不确定的消耗转化为确定的消耗，把运行时的消耗提前，提高整体的性能表现。
第二个例子中，IL2CPP把nullcheck的极少数分支转为stub method，消除了nullcheck。
其实我们在写逻辑的时候，也不知不觉就会写出各种带if-elseif的恶心逻辑，这时候我们也可以用类似于stub method/stub class的方法，既能让代码变优雅，又能提高效率。
举个例子，我们有一个IServiceProvider，它会根据配置的不同实例化为不同的ServiceProvider。那么，一种设计是每个用到ServiceProvider的地方都checknull，另一种设计是让ServiceProvider一开始初始化为一个TrivialServiceProvider，后面该怎么用就怎么用。
其实两种设计并没有绝对的好坏之分，完全看IServiceProvider在逻辑中扮演什么角色。
如果IServiceProvider的接口并不具有默认值语义，那有可能第一种设计更适合你。但是相反的话，第二种比第一种更优雅，而且对于trivial占极少数情况的逻辑，还能获得额外的性能表现。
第三个例子中，IL2CPP对可以优化的情况做了特殊处理。
这类例子就比较多了，比如redis的zset在元素少的时候会用ziplist，元素多的时候才改为skiplist等等。
最近开始在订阅号写文章了，觉得合适的会转过来博客。但是几番对比，发现订阅号的写文章体验完爆各种博客。
有兴趣的同学可以关注下订阅号「说给开发游戏的你」，下面是二维码。