年后新项目就要转UE4了，本文主要是启发式的总结一下这2年多使用Unity做手游的经验和遇到的坑。以下讨论的Unity版本为5.6，本文仅代表个人的一些拙见哈哈。
打包构建
为什么是先说打包？因为我觉得出包的时间是影响团队工作效率最重要的因素。尤其是大项目，如果打包时间在一个小时以上，一般这个团队都避免不了996。再加上如果测试出现了一些卡流程的bug，再重出包的效率真的低的可怕。下面简单的说下我们项目是怎么做到打包时间控制在半小时内的：
- AssetBundle与il2cpp代码并行打包
不得不说，Unity在多核PC上的打包优化做的真的烂，完全不能充分利用多核机器的并行性能优势。所以我们的做法很简单粗暴：就是弄2个工程，1个负责打ab包，另1个工程打il2cpp包，这2者并行，且ab包和il2cpp.so都备份，供下次打包有需要时使用。 - 项目尽可能的早投入使用Lua类语言进行开发
项目的il2cpp.so达到90M，C#代码实在太多，每次转il2cpp几乎都要占用20-30分钟，转il2cpp都是全量转（听说新版Unity做了增量编译），特别蛋疼。后面接入了xLua后，对C#代码做了些裁剪，尽量让framework层都用C#，业务层都改用lua，使得转il2cpp时间大概控制在5-15mins。 - 记录每次打的ab包的md5，只在md5发生变更时才打包
这个应该很多项目都会做，理由也很简单，就是一些美术资源没变更，就不用浪费时间再打一次包了，直接复用上次打好的ab包就好。我们的实现方式是将ab包的bytes和路径转成一串md5，然后把所有ab包的md5都记在一个xml里，通过这个xml文件，每次打包就可以与之前的md5做一下diff，没变更就直接跳过打ab包的流程。
同时，这个在做资源更新的时候，如果发现更新包体过大，也方便查找问题源头。 - ab打包粒度控制
这个问题因项目而异，因为unity的ab包怎么打，在很多层面上，其实是个取舍问题。
至于我们项目是：- icon资源，可配置打图集或者各打在同一bundle
- 对于每一个ui界面，它的prefab各自单独打bundle，并记录每一个界面依赖的资源bundle（如icon资源、动画、特效的bundle），在加载ui的prefab前，先加载这个prefab依赖的bundle。
- 对于每一个npc模型，它的prefab、mesh、动画、材质、特效打在同一bundle
- 对于场景的资源，其所有依赖的资源跟场景打在同一bundle
- 如果同一个资源被2个或以上的ab包引用，则把它打在common的bundle包里
- 配置表打在同一个bundle
- Lua按协议、配置、GamePlay这3部分分开打bundle
- Shader按模块（如ui、character、effect等）分开打bundle
这里不讨论为啥这么设计了，因为其实这里也有很多问题，比如场景引用了一个npc，使得场景的ab包和npc的ab包都引用了npc资源，导致打在common包里了，我们的解决办法是把npc在场景里的显示人肉改成代码动态加载；还有万一shader在线上有bug，整个shader和依赖这个shader的材质要重新发一个完整的资源包。
- 构建时打的log不要太多
半年前的版本发现打包时打了15w行的log，单是这个打log的操作就占了15分钟。所以除非要定位打包问题，建议在平时的日构建尽可能的少打日志。当然，有些log是引擎里的，有源码的话直接注释就好了。
性能
这个话题太广，不同类型的游戏都有各种特定的优化，这里只是简单提一些我觉得比较冷门的（需要引擎源码）。
- 引擎Background线程数量改成2，Unity默认是16，引擎启动的时候这些线程就会创建，相信大部分做手游都用不上这么多线程。
- 引擎启动的时候会创建Enlighten和Substance线程，如果不用的话，可以把引擎编译宏ENABLE_SUBSTANCE和ENABLE_RUNTIME_GI去掉。
- 在做一些类似皮肤换装的需求时，尽量把蒙皮和贴图合并的逻辑做在引擎的C++层，可以避免顶点和贴图拷贝操作。
- il2cpp的反射信息是存储在dense_hash_map上的，这个dense_hash_map在我们项目运行时会占用30M左右的内存，这个大小与项目运行时加载的C#代码量（反射信息的读取是lazy load）成正比，所以在低端机上，我们把这个存储方式改成更省内存的sparse_hash_map，但其实cpu会更耗一点，最终大概省到10M左右，本质是时间换空间的方案。
- 引擎资源的Remapper也是用dense_hash_map的，内存很吃紧的情况下，也是可以改成sparse_hash_map的形式。
- Strip Engine Code可以尝试开下，能省一些编译的引擎包量。但是会有很多坑，官方的解释是如果开了会有问题，就关掉，哈哈，服不服。
- 引擎里返回给C#层的数组类接口，如GetVertices(),GetMaterials()等，都是有gc风险的，因为它会重新alloc一个C#的数组，然后把C++对象再一个个塞到这个数组里。例子如下：
void Update()
{
var mats = renderer.GetMaterials(); // gc
for(int i = 0; i < mats.Length;++i)
{
var mat = mats[i];
// mat.SetXXX()
}
}
简单的解决办法当然是缓存，不用每次都调。其实也可以在引擎层加类似GetXXX(int index)和GetXXXCount()的接口，避免遍历数组时造成的gc。所以上面的例子可以改写成下面的形式。
void Update()
{
var matCount = renderer.GetMaterialCount();
for(int i = 0; i < matCount;++i)
{
var mat = renderer.GetMaterial(i);
// mat.SetXXX()
}
}
-
Time.realtimeSinceStartup在iOS上会走系统调用，非常耗，尽可能的少调用，如下图是引擎的Lod系统时每个几帧会调用这个接口，导致了一些无用的开销。改法是把他改成用Time.frameCount，不必用启动时间来做diff。
Time.realtimeSinceStartup的系统调用 - 在大多数的简单渲染场景下，如ui，Camera的多线程culling在反而比同步culling要耗。引擎内部默认是用JobSystem来实现多线程culling的，建议加个Camera的属性，让这个culling可以动态改成同步执行。
- il2cpp的内存alloc是通过内存池（也可以说分块申请）的形式分配的，用instrument是截取不了准确内存申请的堆栈，所以如果某个时刻分配了很多内存，这个时候想找到代码源头就比较蛋疼了。一个粗暴的解决办法是，在il2cpp向内存池申请内存时，再alloc一个相同大小的内存，这个时候instrument就能截到堆栈了。当然这个方法只在dev包的时候才可以做，否则代码内存会翻一翻。
坑
- 打外网包时要备份library，否则在打资源更新包时，如果library没有备份，而是重新import生成的，其中很多序列化id都是随机生成的，会跟之前的不一致，而结果就是在打资源更新包的时候会发现有一堆变更。
- 资源更新和一些cache不要存在Application.temporaryCachePath，在手机上有可能会被系统删掉。简单的改法是用Application.persistentDataPath，但对于iOS，这个目录文件过大的话，可能会不过审，最好的做法是放在Library/Application Support/{packageName}里，具体见苹果的文档File System Basics
-
尽量少直接引用fbx里的子asset。举个例子：如果一个prefab里引用了如下fbx的_cao这个mesh，那在打包的时候调用就会把fbx的_cao2、_shui2、_shan这些mesh也打在包里，因为这个prefab你调用GetDepdency的时候会发现，这个prefab依赖的是_shui.fbx这个整体，所以打包的时候会把整个整体都打进去。解决办法是把fbx里的子asset单独拆出来，并制作规范禁止直接引用fbx里的资源。
多asset的fbx在被引用时要留意打包问题 - ip5和ip5c不能开启Metal和OpenGL ES3，所以是不支持Half float；而Android则没有这个问题。
所以在处理mesh顶点格式时要注意，否则ip5和ip5c会崩溃。具体原因可参考引擎PrepareMeshDataForBuildTarget::VertexCompression PrepareMeshDataForBuildTarget::GetMaxVertexCompressionForPlatform(BuildTargetSelection targetPlatform)的实现。 - ab包的加载，在引擎里的实现会有各种lock/unlock，这也是为啥unity加载资源卡顿的问题不好解决的原因。我们后面把ab包做了多线程的异步加载（非协程的异步加载），途中改造了不少引擎代码，到最后帧率才逐渐稳定。不过现在看来其实治标不治本，因为锁的消耗还是很高，Unity的官方驻场表示也没法解决，毕竟AssetBundle这个系统设计的太臃肿。。
