在游戏的开发过程中，前期的规划 往往比 后期的“优化”更为重要！比如多分辨率适配，如果前期没有规划好，可能导致的情况是，画面只在当前测试开发机或者一部分机型正常显示。做了多套资源适配，可以使在合适的机型使用对应的图片资源，避免在高清屏幕使用低质量的图片，在低分辨率屏幕因为图片太大而浪费硬件资源。机制与策略分离，可以让你设计出简单有效的接口。模块化的设计可以让你组织好各种逻辑流程，条理分明 ~ 前期的规划工作可以有很多，一叶也在摸索之中，以使游戏的开发尽量变的简单灵活且可控。最简单的也是最容易忽略的地方，跟我们打交道最多的要数精灵了，从图片创建一个精灵，很简单的开端，将以此展开行动 ~
本文使用 Cocos2d-3.0alpha1 版本，创建了一个 C++ 项目，介绍在 C++ 中，如何处理资源相关的内容，如果读者使用脚本，也可以参考本文中资源管理理念而忽略语言特性，你可以在 Github1 上面看到本文所有源码。
在 Unix 文化中，有这样一种理念，Happy Hacking！使用 Cocos2d-x/C++ 写过一些游戏，其绑定的脚本语言，用的也不少，脚本语言的一个好处就是快速开发，你无需明白它之运行机理，便可容易的完成所想要的效果，三天上手，五天就能写出像样的程序来，C++ 则不然，其各种语言细节特性，各种开发技巧，内存管理等细枝末叶 ~
计算机不会魔法，在一叶看来其内容，只有 “知、或者不知” ，没有 “懂、或者不懂”，“知或者不知”来自于你的学习历程与经验，至于“不懂”么，我还没接触到的领域内容，我都不懂，哈 ~ Cocos2d-x 脚本引擎也用过一段时间了，但其运行机理还不明白，就使用而言也无需明白，不过于在意细节的实现，可能更好的从宏观角度把握整体。过去只是对其“存疑”（对于这里的“不懂”，一叶通常美其名曰：要学会存疑 :p ），而现在想要对其运行机制多了解一些，那就只有一步步去探究喽，要了解到什么程度，那就随意了～
对 Cocos2d-x 的运行机制只是略懂一二，C++ 的场景由 C++ 运行，脚本呢，先开启脚本引擎，让后将控制权交由脚本代码执行，在这过程中发生了什么，由脚本所控制的元素和 C++ 有什么不同，或者说它的本质是什么！这之前一叶一直说的是脚本引擎，而非具体那种脚本引擎，lua 或者 js (jsvascript)的引擎实现！凭着对已有知识的了解和直觉，很多疑问和可能性随之而来，它所支持的脚本语言有两种，此两种的共同之处是什么，其使用了脚本绑定技术，什么是绑定 ？各种对象在内存中如何分布，如何配合在一起工作。
为了增加探究过程的趣味性，所以一叶试想着能不能让 Cocos2d-x 现今所支持的两种脚本引擎同时运行 (lua and js)，然后确定是否能在三者之间（C++, js, lua）访问同一个内存元素，如果行，便弄出来，即便不能做到，那也无所谓，这其中的过程比结果更有意思，不是吗 ~
本文介绍了 CCScrollView 来编写帮助界面和关卡选择界面的方法，在编写这样一个功能之时，大多会遇到一些困难，这里也是同样，最后提供了一个相应且合理的解决方案，并解说了其它实现方案的优缺点，这里的内容，你可以直接拿去用，或者可以作为实现的参考。总能找到你需要的东西，或多～或少～。文章大致内容如下：
本文所使用的 Cocos2d-x 为当前的稳定版本 2.1.4。（如无说明，文章内容总是配合 当前最新 稳定版库） 原来是使用 Cocos2d-x 2.0.4 编写的功能，周末花了点事件进行了整理 和 重构（触摸机制的重构）。
如果 Cocos2d-x 内存管理浅说 做为初步认识，而 Cocos2d-x 内存管理的一种实现做为进阶使用，那么本文将详细的分析一下 Cocos2d-x 的内存管理的设计实现和原理。知其然，知其所以然 ~或者说：嗯，它这么做，一定是有原因的，体会设计者的用意，感同身受，如果是你，将会如何设计！~~
我觉得 最好的学习方式是以自己的语言组织，说与别人听 ～ 这样对自己：更容易发现平时容易忽略的问题，对别人：或多或少也有所助益！以学习为目的，而别人的受益算是附带的效果，这样一个出发点 ~
由浅入深，总览全局（或者由整体到局部）是我喜欢的出发点，或者思考角度，我不喜欢拘泥于细节的实现，因为那会加大考虑问题的复杂度，所以 把复杂的问题简单化，是必然的过程。 那么本文就说说 Cocos2d-x 的架构是如何设计以方便内存管理的。从理论到实践 ~(当然是从我看问题的角度 :P，读者如有异议，欢迎讨论！文本使用 cocos2d-x 2.0.4 解说。)
使用 Cocos2d-x 编写游戏，常被人吐槽，吐槽什么，当然是内存管理，C++ 的使用本以不易，而在 Cocos2d-x 添加了半内存自动管理，在这么一种 复合机制 下，使得出现内存问题的概率直线飙升 ~
而关于这一点，可能在于并没有一个通用的合理的内存管理方式，能够更好的使用 Cocos2d-x ，或者说，缺少那么一种 规范，如果存在了这么一种 规范，而使得 Cocos2d-x 更为简单优雅，那势必是游戏的开发过程，更加从新所欲，把重点放在游戏本身的设计之上。
稍微了解一点就能知道 Cocos2d-x 是基于引用计数来管理内存的，应用计数的加减就是 retain 和 release 方法的实现。在大多数情况下我们不用 显示 的去调用这两种方法，如在 CCNode 的 addChild 和 removeChild 方法，CCArray 的 addObject 和 removeObject 等这样成双成对的方法，对于这些的使用很简单，一叶上篇文章 Cocos2d-x 内存管理浅说 从概念上简单的分析了内部对象的生命周期特点，在此 浅说 之中，我刻意的绕过了它的底层实现，并没有深究其原理，对引用计数等概念也只是几句话一带而过，重点放在使用者该关心什么，该注意什么。因为我觉得 引用计数是个坑，一个很大的坑 ~
轻量级:一叶非常喜欢的名词，在重量级和轻量级之间，如果做选择的话，一定会选择轻量级，它的特点首先是设计简单小巧，使用方便，更具有灵活性，扩展方便。重量级则大而丰富，全面，但略显笨重，在程序设计之初大多需要全盘考虑。而轻重之间的概念是相对而言，并没有严格的界限。
在 cocos2d-x 使用触摸来触发一些操作是很常用的功能，如果界面非常简单，只需要启用相应层的触摸功能，并处理其触摸事件即可，而如果界面的 UI 复杂，多层管理，又有着隐藏控制，灵活多变，比如 MMO 游戏，当然手游不会 那么 复杂，那么现有的机制实现起来就显得捉襟见肘了，即便实现，也很难维护，而一个简单的方式是 只在场景的 基层 接受触摸消息，然后由此基层向上层发送触摸的消息，上层再根据实际情况进行处理，判断可触摸元素优先级，是否隐藏，返回处理结果，再一层层向下传递，保证实际的操作是我们所期望的。
使用过 Cocos2d-x 都知道，其中有一套自己实现的内存管理机制，不同于一般 C++ 的编写常规，而在使用前，了解其原理是有必要的，网上已经有很多对内部实现详细解说的文章。而对于使用者而言，并不需要对其内部有很深的了解，注重其“机制”，而非内部实现，在这里只是简单的聊一聊它的管理方式以及使用，固为浅说。
Cocos2d-x 将会在下一帧自动清理无用的对象，什么是无用的对象，通过 create() 方法创建的就是无用的对象。
为了简要说明，代码的组织设计一切从简，我们创建了两个辅助类和一个容器类 BaseLayer，在 BaseLayer 之上管理内部对象，并观察它是怎么自动管理对象的。实现了其 构造函数 方法和 析构函数，并做些日志打印，以方便我们观察：
在 cocos2d-x 中实现类 Android 多级日志系统！写程序，免不了调试打印 Log ，而一个方便的日志系统，可以提高不少开发的效率，写过 Android 应用的朋友应该了解在 Android 中的日志包含很多等级，查看日志的时候可以指定日志的级别，从而过滤一些无用的信息，能够更为快速的定位问题的所在。而在 cocos2d-x 的开发中，统一使用 CCLog，只能算是最基本的功能，既然有好的思想可以借鉴，何乐而不为呢～
先看看最终实现的效果，我们使用简单封装过的方法调用打印日志系统（Leafsoar Log:LSLog）：
在读这篇文章之前，先读前一篇文章 Cocos2d-x 屏幕适配新解 是必要的。
如果说前一篇文章文章在 LsSize 提出之前的是基础，LsSize 是应用，那么对于这篇文章来说，LsSize 是基础，而这里是其的综合应用，我之初衷是其扩展性和兼容性，激发读者思维。也许你并没有体会出 LsSize 的强大，而实际上，它能做的比你想象的要多的多，这是前话 ~
首先 LsSize 能满足 ShowAll 模式的需要，因为开始就是把 LsSize 当作 ShowAll 中的 WinSize 来设计的。 并且可以为背景做装饰，而在游戏设计之时并没有什么区别，LsSize 可以设定显示区域的大小，使背景层与 LsSize 分离（这一点在上一篇文章最后已经提到），从而保证了游戏的元素不会超出 LsSize 而露出到 VisibleSize 的区域内。
为了适应移动终端的各种分辨率大小，各种屏幕宽高比，在 cocos2d-x（当前稳定版：2.0.4） 中，提供了相应的解决方案，以方便我们在设计游戏时，能够更好的适应不同的环境。
而在设计游戏之初，决定着我们屏幕适配的因素有哪些，简而言之只有两点：屏幕大小 和 宽高比。这两个因素是如何影响游戏的：