cocos2d_工程结构

cocos2d项目的结构。新建的cocos2d项目最外层有3个目录，分别存放代码、类库和app包。

代码目录的结构如下图所示：

最上面的几个是开发者自己编写的类，当然图中是一个新建的项目，所有类都是引擎自动写好的。Resources目录用来存放资源，libs中是cocos2d的源代码，Supporting Files中是入口函数（main）。

Libs路径结构，其中cocos2d的逻辑代码都存放在cocos2d路径中（已用红框标记）。

Supporting Files路径，入口类就放在这里（实际开发中基本不需要过问）。

Frameworks路径，其中最常用的就是Foundation.framework了。

 

读者们可能已经发现，cocos2d的源码是开放的，这有利于我们研究它的内部结构，从而加深理解，但作者建议不要去修改源代码，因为cocos2d是一个标准，是完全公开的，就是说所有cocos2d项目中的libs应该是完全一致的，如果修改了，引擎就会失去兼容性，在这个项目能够正常运行的代码到了另一个项目就会报错，如果API是这种效果的话，我想任何一个开发者都会抓狂吧（J2ME就是一个很好的例子，由于硬件和API实现方法的差异，导致相同的代码在不同的手机上差异性很大），所以我们在开发时最好把它看成一个SDK，只要使用它的API就好。

好吧，貌似又说了一堆和引擎的研究无关的东西，接下来我真的要将引擎的实际应用了= =（其实作者之所以在一开始说这么多，并不是想凑字数，而是因为这些才是对开发者来说最重要的，如果一个程序员连基本的开发规范都不知道，那他即使有再好的引擎，甚至精通各种语言，也绝不可能写出高质量的代码，理由很简单，南辕北辙只会使你离目的地越来越远，但如果方向正确，即使是乌龟也有超过兔子的可能）

在作者看来，cocos2d中最常用的类可以大致分为两部分——实体类和行为类，所谓实体类就是非常容易具体化，我们能够直观的感受到的东西，比如桌子、图片、人，这些是现实中实际存在的，实体类可以说就是对这些东西的模拟，当然也有稍微抽象一些的，比如菜单、按钮，但不管怎么说我们都很好理解它们的存在；行为类相比之下就显得很抽象了，它们封装的主体并不是某一事物（或者说是属性），而是方法，就是该类的实例表示的是实体类的一种行为模式，不同的行为模式需要不同的类来封装。从语文的角度讲，实体类就是主语（谁），行为类就是谓语（做什么），根据作者的开发经验，cocos2d大部分时间都是在围绕这两者工作。

cocos2d中的类采用的是树状继承的方式，即最上层的基类只有几个，拓展功能都是通过一层层的继承父类来实现的，这样做便于类于类之间的协作，因为很多接口都是共通的（都来自于基类）。实体类的基类是CCNode（cocos2d的所有类都以CC开头，这就表示你完全可以54它的存在= =b），它是所有实体类的父类，它内部封装的参数与方法是整个引擎中出镜率最高的，可以说是cocos2d的核心（菜单、精灵都是继承自它），下一章节会对它进行详细介绍。

行为类则大部分继承自CCAtion，它的子类实例可以让一个CCNode对象执行一个行为，比如旋转、移动，甚至是自定义的行为，一个CCNode可以同时执行多个行为或是按顺序执行一个行为序列，有了这些类，开发者就可以在游戏中轻松加入各种华丽的效果了。

有了CCNode和CCAction，我们是不是就可以开发游戏了呢？还不行，我们还需要一个乘纳它们的舞台。比如我们创建一张图片，并赋予它一个移动的行为，但是我们无法看见它，因为我们并没有把它显示到屏幕上，而舞台的作用就是把它上面的演员显示到屏幕上，呈现给观众。cocos2d实现舞台的方式是这样的：

舞台分为三部分：导演–场景–层。首先，屏幕的显示是以场景为单位的，我们通过显示器看到的所有内容都在一个场景中，而层是构成场景的元素，就好比场景是一个舞台，我们通过它观看游戏中的世界，而层就是组成舞台的各种背景，比如远近、近景、字幕。当一段故事讲完后，我们可能需要切换到另一个舞台来讲述下一段故事，在戏剧中通常是拉上大幕，在幕后切换背景，然后再拉开大幕，在cocos2d中也是这个步骤，而完成这一工作的就是导演。导演类负责场景间的切换，场景负责将游戏中的元素呈现给玩家，而层负责容纳元素以及接收玩家的输入信息。

通过这些类的合作，我们就可以进入自己创造的游戏世界了～