先说好的吧。可能目前最令我满意的就是IMGUI这部分API的定义，写Editor Plugin和In-game Debug Menu爽到飞起，很快就能出效果。

UI一向是很麻烦的东西，要保存状态，还要异步，还要同步View和Model的数据。很多框架动不动就是MVC，各种模式，用起来都痛苦的一比。这个IMGUI非常简单粗暴，反正也不能用来开发更复杂的玩意儿，设计和使用契合度非常高。

目前用到的其他特色的设计，比如Component Based，和别的商业引擎比起来大同小异。当然从价格和可用性的角度，Unity更胜一筹，以后有机会再多扯点。

主要还是吐槽，就说点看似美好其实比较坑的东西吧。

官方文档

全还是比较全的，这个我主要吐槽两点。

第一是组织方式，有些很重要的东西（比如对象的生命周期），或者说Unity和其他引擎比很不一样的东西（例如特殊目录，Editor/Resources/），隐藏在犄角旮旯等着你来发现。基本上都是在别处找到更直接的教程，然后拿到关键字，再到官方来看细节。

第二是官方真喜欢视频教程啊，不能搜还看得慢，动不动20分钟说点屁事。不能写点图文教程吗？比如IMGUI的各种用法，第三方写的比官方好用多了。

资源加载

三种方式，内在逻辑截然不同。

以Editor内操作为主，基于Reference的这套可能比较适合小游戏，或者非程序员开发的游戏。只要一切资源都是经过Editor操作和绑定的，那么后续过程也都是自动的。官方强力推荐这种，美术和策划友好的东西。

所有不能在Editor上绑定的数据，都需要Load-on-demand。一但牵扯到Load-on-demand，需要动态加载数据，事情就来了。

其实加载资源（Loading）是非常简单粗暴的操作。储存方面就是打个包，把数据和标识存起来。读取方面，只要给定一个标识（比如路径或者id），然后决定是同步加载还是异步即可。同步立刻返回结果，异步就给个handle或者允许callback。这样的底层设计几乎可以满足所有基本需求，其他花哨的玩意儿再上面继续包装即可。

但Unity的坑无处不在。首先是打包，Unity有两套截然不同的资源管理方式，分别对应Resources目录下的文件和Asset Bundle，姑且称为R和A。

R的打包是自动的，所有此目录下的文件都会在运行时打包，方便的很。这么好的东西，官方给出的Best Practice居然是“别用”。写文档的朋友，你以为自己很幽默吗？不能用的东西做出来吃屎呢……

A的打包是手动的，只不过没有现成UI可用，需要在Editor里调用API。但官方文档写的稀烂，打包和加载的过程同DLC的资料搅合在一起，还要牵扯到Cache和Server。乍一看仿佛要启动什么web service做host才能使用，打开还得从WWW下载。其实只要StreamingAssets目录一放，自己写脚本打包就好。

别忙，坑还没完。

R打包出来的资源是不带扩展名的，因为自动打包的时候就是根据扩展名来的，打好就全给删了。加载的时候遇到重名，请提供type。再出现重复我就不知道要怎么玩了……R的路径是相对于Resources的，这个倒还能理解。

A打包出来的资源，标识是写入的时候给定的数据，如果写的时候带了扩展，那就是有扩展名，目测不能重复。

所有“测试的时候想用R，发布的时候想用A”的同学，请自己写wrapper吧……真的好痛苦好痛苦。实际上更好的做法是，测试的时候直接读取Editor里面的AssetDatabase，并不需要使用Resources。官方说的“别用”就是字面意思，但您能提示下还有别的选择吗？直接介绍大家用AssetsBundle真的很不友好啊。

序列化和热更新 Hot-swapping

Unity一大特色就是各种自动，写个public直接就能在Editor上改了。而且改改c#，一回头自动把新的dll热更新上去，数据都还在。

听着很美好，实际情况是，改完代码出现大量Null Reference的异常……

https://gist.github.com/cobbpg/a74c8a5359554eb3daa5

这个小哥大概记录了一下，我踩了半天坑再补充一点：

1、首先是ISerializationCallbackReceiver，调用时机很诡异，Editor下如果你选中了带有这个接口的对象，Inspector会疯狂触发OnBeforeSerialize()。存起来很慢的东西就悲剧了。而OnAfterDeserialize()在Swap的时候会触发多次，目测Editor有创建多个实例，有些数据是没准备好的，还得自助检查。

2、在Editor里创建的各种引用，例如Component都会存下来。但如果动态AddComponent出来的玩意儿就悲剧了，在OnBeforeSerialize()之前就会被干掉，请自己重新动态创建。后来证明只要是Unity的Component，引用都会正确的保存下来，核心的混乱点还是Editor里有多个实例，初始化状态各不相同。

3、虽说需要动态创建，但特么的所有AddComponent这类方法，甚至GetTime都不允许在callback种调用。大概恢复数据的时候是多线程环境？所以只能自己搞个boolean做dirty check，然后在Update()里面实际恢复数据。实际上参考官方的例子，可以在OnEnable里面做恢复处理，比Update要省。

4、虽然官方号称大部分数据类型都可以自动保存，但“大部分”这种说法就意味着你需要被干很多次才能修复“少部分”的问题。比如标记为Serializable的数据，运行时可以为null，但Swap的时候会变成non-null状态。例如字符串变成了””，结构体变成了初始状态，最坑的是Array，里面的null元素会被填充。如果有逻辑依赖于null-check就悲剧了。

以后遇到新的再补充。

补充个新坑：打包的时候如果用BuildAssetBundleOptions.None这个option，看似人畜无害的默认选项居然是用LZMA压缩整个包，第一次开启会做解压缩操作，慢的一笔。最好的方式是使用ChunkBasedCompression，这个选项开包很快。港真我不知道None这个选项除了给网络下载几件衣服的DLC用以外还有什么应用场景，官方文档用这个名字（None是压缩的，咱还提供UncompressedAssetBundle选项哦～），并且用在代码范例真的好么？