游戏开发者永远在压榨平台性能这件事上赛跑。每削掉一个CPU周期，你的游戏就有可能从掉帧和差评迈入A级游戏和百万销量的天堂。
最快编写的代码实现却是很少运行最快的。相反，优化需要消耗工程时间。高度优化过的代码缺乏灵活性，很难改变。
一、命令模式：对象化的方法调用，封装在一个对象中的一个方法的调用。
A---->command---->method
二、享元模式
数据: 内部状态（可共享） + 外部状态（唯一）
三、观测者模式
在对象间定义一种一对多的依赖关系，以便当某个对象的状态改变时，与它存在依赖关系的所有对象都能收到通知并自动进行更新。
四、原型模式
使用特定原型实例来创建特定种类的对象，并且通过拷贝原型来创建新的对象。核心思想就是一个对象可以生成与自身相似的其他对象。
五、单例模式
确保一个类只有一个实例，并为其提供一个全局访问入口。
全局变量是有害的：a、令代码晦涩难懂。b、促进了耦合。c、对并发不友好。
不合时机的延迟初始化很致命，会导致明显的掉帧和卡顿。
考虑用静态类来替代单例：Foo：：bar（） 替代 Foo：：instance（）.bar（）
六、状态模式
1、有限状态机： 走、跑、跳
2、并发状态机：走开火、跑开火、跳开火
3、层次状态机：站立--->（按下B键）--->跳 站立--->（按下B 两次）--->闪避
4、下推自动机：跑-->跑+开火--->能够回到跑，而不是站立
七、序列型模式
1、双缓冲
2、游戏循环：实现用户输入和处理器速度在游戏行进时间上的解耦。
3、更新方法：通过对所有对象实例同时进行帧更新来模拟一系列相互独立的游戏对象。
八、行为型模式
1、字节码：通过将行为编码成虚拟机指令，而使其具备数据的灵活性。（xml到界面）
2、子类沙盒：使用基类提供的操作集合来定义子类中的行为。
3、类型对象：通过创建一个类来支持新类型的灵活创建，其每个实例都代表一个不同的对象类型。（npc表到npc）
九、解耦型模式
1、组件模式：允许一个单一的实体跨越多个不同域而不会导致耦合。
2、事件队列：对消息或事件的发送与受理进行时间上的解耦。
3、服务定位器：为某个服务提供一个全局访问入口来避免使用者与该服务具体实体类之间产生耦合。
十、优化型模式
1、数据局部性：通过合理组织数据利用CPU的缓存机制来加快内存访问速度。
当代CPU带有多级缓存以提高内存访问速度。这一机制加快了对最近访问过的数据的邻近内存的访问速度。通过增加数据局部性并利用这一点可以提高性能——保持数据位于连续的内存中以供程序进行处理。
a、包装数据。
为实现流水线模式，CPU必须猜测哪些指令是接下来将会执行。在顺序结构的代码中这很简单，但在控制流结果中就麻烦了。当预测失败时，CPU要对先前投机执行的指令进行撤销（流水线清理）并重新执行正确的指令，这样的性能损耗在计算机运转过程中是很常见的，而这也是为什么你有时会看到开发者们会在关键代码中避开 控制流语句的原因。
b、热/冷分解。
将数据结构分成两部分。第一部分为“热数据”，也就是我们每帧都需要用到的数据，另一个部分是“冷数据”，也就是那些不会被每帧频繁用到的剩余数据。
2、脏标记模式：将工作推迟到必要时进行以避免不必要的工作。
3、对象池：使用固定的对象池重用对象，取代单独地分配和释放对象，以此来达到提升性能和优化内存使用的目的。
4、空间分区：将对象存储在根据位置组织的数据结构中来高效定位它们。
空间分区会使用额外的内存来保存数据结构。像许多优化一样，它是以空间换速度。如果内存比时钟周期更吃紧的话，这可能是亏本生意。