1、SendMessage会在同一帧调用，当调用参数为null的时候，会匹配无参数的函数签名，所以非常恶心，也就是当你传某个可能会变成null 的参数的时候，将无法完成调用
2、Instantiate实例化的对象在同一帧实例化，但是碰撞却是在下一帧或几帧生效，这个比较恶心，会导致许多问题
后来查了一下，这个是碰撞检测的bug，碰撞是在另一条线程做的，但检测到碰撞再通过消息发送回来调用脚本的回调，所以会有一帧的延迟，但是有时候会到两帧后才调用这个就有点说不通了，因为按照文档的说明，物理引擎线程总是比主线程快的。这个问题直到现在4.3似乎也没解决
3、iTween性能非常糟糕，刚开始看到很多人推荐，以为基本上没什么问题 了，后来发现整个工程的性能不怎么行，还以为是2dtoolkit性能不行，后来看到HOTween和iTween的对比才知道。打开Profiler看看性能就知道其实占用了很多。其实自己读读那个代码就知道完全是为了使用方便设计而不是性能设计，用在小游戏没问题，但是大量单位都使用，性能堪忧，特别是手机应用。iTween性能最大瓶颈应该是每次的组件创建和释放，行动时添加，结束后释放。在测试中发现，如果循环使用，iTween就不至于这么糟糕，说明在释放和GC的时候消耗很大，我最初就对这种做法表示怀疑，果然是没想错的。补充：iTween有许多地方可以优化的，比如每帧都去CleanArgs，我实在想不出这个东西有多少用处，即使注掉了也不会对结果有任何影响，还能提高不少效率。另外在LookUpdate，里面对于转向的平滑消耗很大却效果不明显，可以省略掉。还有很大地方的实现，完全不考虑效率，很多地方使用transform的参数作为临时变量使用，非常影响效率，详见第9条。
4、对象池的必要性？经过使用对象池测试每帧同时生产大概60个Cube，产生6000个后释放，观察发现最高帧数上面对象池只高出了1-5帧，也许更极端的情况下会优势高一些，不过大部分时候Unity的回收机制已经相当不错。不过这样的测试没有配合脚本组件，不能说明多少问题，有些组件的创建释放会消耗较大，比如iTween，但是我还是比较相信Unity的回收机制。
对象池会占用大量的内存，因为每个不同的对象都需要一个池，如果对池进行内存优化释放，应该可以减少内存占用，于是事情又变得复杂起来。我觉得大部分时候应该都不需要，除非像发射子弹这类需要快速又频繁创建销毁的东西。
补充：对于PC对象池是看不出多少区别的，但是对于安卓端，对象池是相当必要的，手机性能实在太弱了。其他平台估计也差不多。
5、鼠标事件延迟。如果自己设置鼠标Cursor，调用Input.mousePosition会发现，存在明显的延迟，搜了一下，解决办法是关闭垂直同步。于是同时发现，关闭垂直同步后，帧数大幅度提升！不过即使关闭了垂直同步，还是有一点点的的延迟，这样做FPS真的没问题么，当然我没做过
6、LoadFromCacheOrDownload 的version参数。Google一下就会找到解释，并不是给资源包什么版本号，这个参数只是表明了缓存的版本号，也就是你不想用这个缓存的时候就改变版本号，那么就会重新下载，所以这个版本号通常应该是从服务器传过来的。
7、关于TextAsset，搞得差点吐血。原因在于虽然都叫TextAsset但是实际上会根据你导入的后缀名判断是二进制还是文本，也就是txt是文本，这时候你用.bytes取到的就是错误的二进制流数据，要取到二进制数据必须把资源命名为.bytes后缀名。
8、WWW加载不支持中文路径！简直要吐血！
9、Transform.postion/Transform.rotation一类函数，包括欧拉角转换，开销都很大，旋转物体，开销很大，比移动大得多，具体为什么不知道
10、对于安卓端，粒子性能实在不堪入目，比我想象中的糟糕太多了。尽管已经努力的降低了纹理和数量，依然可以把帧数降低一半。而一些高级着色器就更不用想了，比如火焰的扰动效果。甚至RenderLine都会消耗较大资源。说到底，就是draw call不能太高。总感觉是引擎的优化问题。
11、4.3引入的2D引擎，效率很差，我最不理解的是，为什么移动物体，会去更新包围盒的信息，每次看profiler，都会看到2d物理消耗很大，开始以为是矩形会这样，于是把大部分换成了圆形包围盒，卧槽，还是一样，圆形包围盒就算是更新也就是一个圆心的更新，怎么可能会消耗这么大？我想了想，可能是因为基于四叉树所以每次都要更新节点信息？需要说的是我把物理引擎由3d换成2d后，效率并没有明显提升，似乎3d的物理引擎会单独开线程进行计算，而2d的直接就在主线程进行了，大概除了能提供轻松的碰撞检测，让你不需要移动考虑z轴以外，没其他好处了
待续。。。