说组件化的结构，是指整个项目工程使用组件化模式开发时，整个项目中包含的所有组件结构。而不是指某一个组件工程的结构。某一个组件工程的结构，理论上我们是不用关心的，但是为了代码风格统一，我们可以做一些要求。

组件颗粒度

那么，问题来了，一个项目应该怎么拆分组件呢？拆分多少个组件合适呢？按照什么标准进行组件的拆分呢？

这个问题只是抛出来，我不作回答。因为这个涉及到组件划分颗粒度的问题。这个颗粒度的把握，是需要沉淀的。对组件划分的太细会导致项目过于分散，划分粒度太大会引起项目组件臃肿。项目都是有一个发展过程的，组件也一样。所以，不断进行重构是掌握这个组件细化程度的最好方式。

但是，工作还是要进行，那么项目开始时，必须要定一个颗粒度！我的原则是：

• 抽出业务之外，即：不依赖业务的UI或方法函数，规划出不同的组件；

• 按需求业务，完成一个业务流程的，当成一个组件开发。若业务流程冗长且有分支的，可从分支处拆分成多个组件开发；

这只是雏形，还是需要组件重构沉淀出更好的颗粒度划分。

不管组件的颗粒度是大还是小，项目中组件必须是有层级结构的。有层级就表示了会有依赖，所以说项目组件化也是无法避免依赖关系的。准确来说是，项目组件化避免的是业务之间依赖，因为不同业务属于同一层级。我们定义同一层级的组件之间是不可以存在依赖关系的。

那么，该如何定义组件的层级结构呢？

我们是这样定义的：

首先，组件库分为五大部分：业务模块层、中间件层、部件层、定制层、基础层。

依赖关系是这样的：

• 业务模块层 → 中间件层

• 业务模块层 → 部件层→ 定制层→ 基础层

这样的依赖关系呈现，大家应该明白越向下底层的组件应该尽量少量的更改，因为你的任何一次更改都将会影响到很多业务组件或很多部件。

我从由低至高的层级关系进行解释：

基础层

可以这样定义基础层，这一层的组件拥有以下特点：

• 可以用于其他项目工程；

• 组件里的方法必须考虑周全；

• 不应该任何的业务逻辑；

在我的架构中，基础层现在包括了 网络库、工具库、语言国际化。关于网络库，采用的是离散式网络请求，接口对象化之后给业务调用提供灵活性，工具库包括对系统工具库的浅层封装、第三方平台SDK、第三方工具库；语言国际化库，放在最底层，是因为任何UI相关的都会涉及到语言国际化的问题。语言国际化库中，对外提供的方法是稳定，但是其中的国际化字符的key value是一直在增加的，因为外部调用是没发生变化的，所以这里的内部变化对上层的组件不会有大的影响。当然需要对语言国际化有很好很严谨的管理机制，不然会内部紊乱的。

定制层

顾名思义，定制层就是针对项目定制的组件层。准确地说是，项目基础定制层。

在我的架构中，定制层目前包括 项目环境配置库、****App****风格****UI****库。

项目环境配置库，主要用于：1、配置项目不同开发环境的请求地址；2、配置第三方平台AppKey；

App风格UI库，我认为一般稍成熟的App，UI那边都会有一套自己的UI风格。比如说：几种字体、几种颜色、几种按钮、几种标签、几种cell。是的，App风格UI库就可以封装这些东西，这个库的使用率越高，你的App风格就会越统一。

部件层

多业务会使用+ 相对固定的UI + 需要接口请求+ 不掺杂业务逻辑。是的，我们可以从这几个维度去定义一个部件组件。比如：上传图片组件、选择地域地址组件、支付组件、分享组件。

中间件

它的存在就是为了业务组件，它的作用：

1、解除所有业务组件之间可能存在的耦合；

2、将App生命周期事件分散到所有业务组件中处理；

业务层

这一层其实没什么好说的。在组件化思维中，这一层主要要考虑的是如何使用中间件，需要中间件做什么。在做一个业务组件初期一般需要考虑四个问题：

1、这个组件是否需要传参才能被创建；

2、这个组件是否需要告诉调用方某个值(比如说状态)；

3、这个组件是否需要在发生什么事件或变化时，需要其他业务知晓的；

4、这个组件有几个入口；

这四个问题的解决都是要通过中间件来解决的。是的，中间件可以解决掉！

总结：开发者铭记三点

1 不可出现反向依赖，只能上层依赖下层，不可反之

2 所有上层组件都能对下层组件充分利用使用，达到最大化的代码复用！

3 脑中始终需要有组件分层架构图，明确自己所做组件属于哪一层