我已经在Unity上开发手游大约10年了，其中有一些项目，是casual, puzzle, strategy, 棋盘游戏等各种类型。

我不是在表演自己有多多多的知识。但是，我自己犯了每一下这些错误，甚至有些是职业生涯中，非常可耻的晚期。这些都很容易被忽视，因为你在赶时间，而且截止日期就快到了两个星期了。

这是我认为手游编程中有影响的4个架构的改变：

1. Addressables 代替 Resources/

我纠缠了一会，因为它只是正常工作啊。一旦它变得不正常，它就太麻烦了。

问题是，Resources/会将所有东西加载到内存中，是否游戏正在需要它现在，不需要任何问题。手游中内存紧张，这增加了速度。

一位客户寄来一个Unity项目，需要4分钟来打开，通过Addressables，得到了解决，简化成本花费18秒。虽然学习曲线困难一周，但是我已经从未更改了。

**2. Object Pooling 代替 Instantiate/Dstroy **

每个Instantiation/Dstroy调用都会触发gc。低端安卓设备上，你会感觉到这个问题，就在最紧张的时刻，出现掉帧的问题。

一个简单的池管理器并不是难以建立的。预先制作你的弹丸，敌人，粒子在场景时。重新激活和重新定位，而不创建新的对象。虽然不是那么光辉的代码，但是我认为这些是最高的工作效力。

3. Scriptable Objects 来数据

如果你的装备数据，级别配置，经济数字，依附在MonoBehaviours上，还是被放在场景中的目标，则当你试图平衡内容時，就会感到疼痛。

将这些放在抽象数据中。我是，资产，对象是场景中的。您可以轻易地做出调整而不用重新设计。您可以在测试阶段方便地交换配置等。

任何有进度的游戏中，这是我的不再忽略的时候了。

**4. 分组文件 **

上述这项让我困惑最多的。当我真正统计过了之后，

如果不用Assembly Definition的话，Unity会重新编译其中单个的脚本每一次更改。当你的团队正在每天反复改动，这个时间加起来了。

我们的团队将编译时间截短了近60%。这是一个一口价钱，而不是一次性的。而且还会在之后的团队是继续反复改动，取得时间。

任何时候我都会把所有这点在docs中，所有这些都可以在unity文档中的找到。这只是当团队正在快快乐乐地工作的快速的时候，是被忽略了。

早期实施我们这些架构的项目就感觉得到改善了。不需要是最后关头惊呼，每一次团队可以更好地合作，需要更少的工作和更少的性能问题。

我很好奇其他人有着相似体验。特别是低端安卓团队。编程中哪些方法能够改变方向呢