unity架构方面的思想：搜集整理+项目实践感受

在实际项目中，个人感觉，整个架构的核心（对我来说也是难点）就是数据的传递问题，尤其在unity中，跨脚本间的数据传递，首先要拿到脚本吧。有的架构思路呢，是建议少用或不用MonoBehaviour，就像非unity项目中的那样，有个主控逻辑驱动的类，里面进行update，这样抛弃了unity的组件优势，主要是因为不同脚本的初始化顺序、显隐控制是由MonoBehaviour自己控制的，不方便架构的驱动；另有思路是采用事件进行管理，通用的功能组件通过事件传递响应。实际应用很火的FSM有限状态机，我个人没有实际使用，但是我自己写的UIManager很像FSM，只不过我还是使用挂接脚本的方式，即UI呢是继承MonoBehavior的，具体优劣呢还是要分项目来说。unity架构中一些思想，我觉得有一些不错的，搜集整理一下。

• 设计的prefab，要考虑一下他人拿到后，拖入一个空场景里是否直接能够使用，顶多再简单设置几下。独立性。
• 代码结构要好好规划一下，包括文件夹组织、文件或组件命名规范等。
• 数据的抽离：静态的、动态的、全局的、本地配置文件的。
• 美术和策划的修改，提交后，其他人更新运行，能通过比较简单的方式或者说直接就能够看到效果。
• 状态这种思想有必要好好体会理解，在很多架构中应用，若设计得好，既方便修改扩展，也方便调试。
• 解耦，组件的独立性，说容易也容易，说不容易也不容易，不好细说，看具体情况。（可能我还没深入理解,因为我设计的不够好）
• 改动所牵连的修改尽可能的减少，牵一发而动全身的话，到了后期就完蛋了。如果过于复杂，还可以分层，分层的好处是专注，不同模块的开发干扰较少。

以上呢基本上包括通用的架构思路，但还是需要实际的项目磨炼，有时间，我自己打算尝试几套不同思路的框架，以项目的形式展现。