游戏框架的搭建涉及游戏的分工，游戏的设计，游戏的实现，但是这是所有游戏开发前必须要明确的事。

由此才可以进行相应的分工，讨论暴露接口，构思实现。

首先明确一款游戏所必须要有的部分：底层逻辑，画面显示。

而很多著名游戏，并不是从这两个方面长驱直入的，而是先编写许多好用的小工具，使得游戏开发事半功倍。

所以我采用的包类架构是三个主要的包：

util，gameview，gamemodle，分别代表了游戏的工具，画面的实现，底层模型的构建。

其中首先应该搭建的是应用层的util包，其中可以有丰富系统自带工具的自定义工具类，如画笔Painter，资源加载Assets，一些独立的线程，数据库操作封装，随机数生成等。

然后是底层的实现与GameView的显示两个方面同时进行，二者相互联系比较密切，GameView通过底层逻辑返回的数据进行绘画。

其中GameView中最主要的就是游戏的主循环，这是一个游戏的基础，如果将一个游戏看做一个抽象世界的话，游戏的主循环就是时间在流逝，任何时间的变化，帧数的运转都是通过主循环的，主循环要进行的操作就是，将当前时刻的底层逻辑，用绘图的方式展现在当前的屏幕上，可以理解为一个视角的展现。

时间的操作一定要准确，并且尽量要通过手段使游戏更新中，帧数的变化相仿，这样才能达到游戏的最佳效果。

GameModle中的底层逻辑不仅仅包括每个游戏对象的逻辑，还应该体现整个物理世界的构建，如果主循环是时间在流逝，那么底层逻辑就是各种物理定律和物理量的构建。

GameModle是最能体现框架构架的地方，我的GameModel设置了三个小包，分别是Modle，World，State分别代表了游戏的对象模型，世界物理量管理，游戏状态的抽象（游戏界面）。

Modle的建立最能体现抽象性，也是非常多的逻辑需要在其中进行编写，碰撞检测，速度计算，位置运转等都要在其中有逻辑体现，一个优秀的框架，在模型的编写上要体现良好的可扩展性（如继承的体现），封装性——各个物理模型可以通过时间的流逝，或者事件的发生自动根据物理规则进行运转（进行自更新），安全性——每个物理类暴露足够并且不多不少的属性，让外部调用，并且各个对象的关系逻辑，在最底层逻辑中不体现，而是在更高层逻辑中处理，简单的来说就是处理刚刚好的逻辑量。

World的建立也是吧十分必要的，这里要尽量的抽象所需要的物理量，物理定律，如速度，初速度，加速度，人物的长宽，屏幕的大小（世界的长宽）等，将这些量置入World可以很好的实现各种手机的适配，并且将各种物理量在这里设置为final的也体现了了安全性，同时也方便了后期的调整，速度等量的微调，可以只需调整一个类。

State是一种抽象的游戏模型，他的逻辑在各种Modle之上，可以理解为整合最底层逻辑，并且处理上层指令到底层逻辑的地方，这里应该处理底层模型的关系处理，并且可以有一定的绘画功能辅助上层绘画。状态某种程度就是一个个的界面的抽象逻辑，如死亡界面，游戏界面，分数界面，加载界面。

并且一个良好的架构会给用户输入以明确的分类，并进行相应的处理，架构的层与层之间的联系要有足够，且不缀余的处理层进行转化指令，或者解释逻辑。

资源的加载需要有条理，并且相应的有一定的智能，提前加载到内存，不要让用户在游戏中等待，这样会降低用户体验。

并且资源回收问题也是一个非常值得关注的话题，良好的资源回收机制是游戏开发中的重要组成部分。