一、项目结构
如图1所示：
图1
从项目结构来看，这个应用的内部包含了一个子模块叫 entry，模块是应用的基本功能单元，它里面包含源代码、资源、配置文件等。
像这样的模块在应用内部可以创建很多。但模块整体来讲就分成两大类：
-
第一类就像 entry 这样，它的内部其实是开发这个应用内的一些特殊能力的，像这样的模块，我们称之为
Ability Module，顾名思义就是能力模块。一个应用的内部它的能力有很多，我们就可以把不同的能力放到不同的模块里去开发。举个例子，支付宝，它的核心功能是支付，像我们熟悉的付款、转账等都属于是支付类的，这部分能力我们就可以把它们放到一个模块里。后来随着支付宝的发展，又增加了其他的能力，比如小程序、视频、看书等，这些能力相互之间都是独立的，所以它们也都可以放到独立的 Ability Module 里去开发。这样一来整个应用的能力就被清晰的划分出来，管理起来也非常的方便。 -
第二类是在开发的过程肯定有一些通用的工具、资源、配置或者组件等，这些如果每一个模块都各自去开发显然是一种重复和浪费，所以我们就可以把这些通用的东西抽取起来，放到一个单独的模块里去，这样的模块我们称之为
Library Module，顾名思义就是一种共享依赖类型的模块。Ability 类型的 Module 就可以去引用 Library 类型的 Module。
如图2所示：
图2
二、项目编译、打包
源码将来肯定要去编译、打包，最终整个项目会被编译成一个 APP，也就是我们熟悉的那个安装包。只不过，在 Stage 模型里面，为了降低不同功能模块之间的耦合，事实上每一个模块都是可以去独立编译和运行的。所有的 Ability 类型的模块，将来就会被编译成 HAP 文件，而所有的 Library 类型的模块，则会被编译成 HSP 文件。所谓的 HAP 是 Harmony Ability Package，也就是鸿蒙能力类型的包。而 HSP 则是 Harmony Shared Package，也就是鸿蒙共享类型的包。HAP 的包在运行的过程中就可以去引用和依赖 HSP 的包。
一个应用内部可能会包含多个不同的能力，就会分成很多的 Ability Module，因此往往就会有多个 HAP 的文件。但是，尽管都是 HAP 类型的文件，但是它们是有差异的，比如 entry 模块，entry 是项目的入口，在这个能力模块里面，主要开发的是项目入口界面等信息，还有就是整个项目或应用的主能力模块，也就是最核心的部分。剩下的一些特殊的能力模块，比如小程序、视频、看书等，这些能力模块，都是拓展功能。一个应用它的入口只能有一个，所以说如果我们的应用内部有很多的 HAP 文件，但是作为入口的 HAP 文件只有一个，那么这个 HAP 文件就叫 Entry 类型的 HAP，剩下的拓展功能就叫 Feature 类型的 HAP。所以，一个应用内部有且只有一个 Entry 类型的 HAP，但是 Feature 类型的 HAP 可以有多个。
HAP 有很多很多文件，将来最终要合并在一起。合并在一起之后称之为 Bundle。这个 Bundle 有一个自己的名字也就是 Bundle Name，这个 Name 可以理解成整个应用的唯一标识，将来整个 Bundle 最后合并打包会变成一个 APP。
如图3所示：
图3
之所以要采用这种多 HAP 文件打包模式，是因为：
- 降低不同模块之间的耦合，每个 HAP 都可以去独立编译和运行。
- 我们的应用在去下载安装时，可以选择性的安装，不是说一上来就把全部都安装好了，比如我们可以先安装它的核心模块 Entry，其它的 Feature 可以选择性安装。这样就可以降低应用安装时所占用的体积。
三、项目运行
每一个 HAP 都是可以独立运行的，而 HAP 在运行的时候，为了展示我们看到的界面和它的能力，都会创建一个名为 AbilityStage 的实例，我们称它为应用组件的"舞台"。为啥叫舞台呢？舞台肯定是在上面展示东西的，顾名思义展示的就是应用组件。
应用能力组件又有很多类型：
UIAbility：包含UI界面的应用组件，是系统调度的基本单元。ExtensionAbility：拓展能力组件，例如在桌面展示的应用卡片等。- ...
UIAbility 作为UI界面的组件，将来要展示UI界面，需要注意，它不是直接展示，首先会持有一个 WindowStage 的实例对象，WindowStage 跟 AbilityStage 类似，都是一个舞台，但是 WindowStage 是组件内窗口的舞台，也就是说UI组件内部先要有一个窗口（这个窗口是要展示在舞台上），所以 WindowStage 它的上面就会持有 Window 对象，也就是窗口，窗口里面展示我们的UI界面。因此这个 Window 就是用来绘制UI页面的窗口。
如图4所示：
图4
综上所述，Stage 模型采用的是舞台的机制，先来一个 AbilityStage（用来展示这些组件的舞台），然后在舞台上创建 Ability，这个组件将来要去渲染UI，它要持有一个窗口的舞台（WindowStage），在窗口的舞台上有一个窗口（Window），接着呢就可以在窗口里绘制页面。所以正是因为有很多很多的舞台，在舞台上展示东西，这种模型就被称之为 Stage 模型。
为什么 Stage 模型要用这种舞台机制呢？正是由于存在这种舞台机制，Ability 和 Window 就分隔开，它们之间就解耦了，将来在开发跨设备的应用时，就可以针对不同的设备对于窗口进行单独的裁剪，去适应不同的设备。