鸿蒙化架构，开发规范

确认适合自己的架构

官方方案

架构官方可参考内容：https://bbs.huaweicloud.com/blogs/416914

读了官方内容之后，其中有一些组件化规范不太适合所有人，并非通用架构，下面我将详细说明。

官方推荐的架构图如下：

官方给的架构图

从图中可以看出，中间层和业务模块都是shared动态包，这里我认为在但应用情况下是没必要的（如果您是要将iOS或安卓做鸿蒙化），鸿蒙组件包分为hsp和har，简单说就是hsp就是动态包，特点就是按需引用，多应用复用。首先鸿蒙化往往是单应用，实际hsp无任何优势；其次构建内测包的时候，如果有hsp需要先安装hsp，造成内测发布麻烦；最后和har相比没有任何优势。再来说说har包，首先官方认为har包最大特点是会把依赖包打进har包，造成包体变大，经验证并不会有这个问题，只有本地引用方式会有这种问题；其次har包会被打到app包内，内测发布没那么多弯弯绕。综上所述，中间层和业务模块层，99%的工程选hsp是没必要的。

我给的推荐是，整个工程组件全是har包，但是前提是需要创建自己的ohpm私有仓库，原因后面会讲。

依赖规则

上层可以依赖下层（可以跨层依赖），下层不可以依赖上层。模块有路由的情况下，路由优先于依赖。平级之间不允许相互依赖。

应用层

应用层也就是壳工程，壳工程里只能配置工程特有的配置项，不允许写业务代码（可以依赖功能模块）应用层包含打包构建相关配置（例如网络环境配置、各种三方密钥配置、授权文件等）

业务层

这里的模块都是应用中和业务逻辑相关的组件，业务层组件之间不可以相互依赖，只能通过路由来进行通信，包括数据路由和跳转路由

中间层

中间层有两种形式

1，对三方库的二次封装，对外提供统一出口。比如高德地图二次封装，就成了可以路由调用的地图组件。 2，对相同功能的三方库进行功能聚合。比如支付中心就是对微信支付、京东支付等支付方式的聚合。

为什么需要中间层（中间层的意义）

三方库的管理规则是不允许源码修改，因此为了方便使用或者替换三方库，大部分情况下需要自定义中间层，比如存储，七牛存储经过中间层封装后，如果突然要替换为其他存储（比如百度存储），只需要修改实现，对外接口定义不需要调整（特殊情况下可能有入参的微调），从上面官方架构图中可以看出，他们称为聚合层。

是否需要中间层判断规则

工具类不需要中间层，比如（数据模型Model的序列化、zip压缩工具），这些工具都是粒度极小，中间层意义不大。非工具类的功能型三方库需要中间层，比如各种支付，各种分享等，中间层既能统一管理又方便共享其他工程使用。

三方库

三方库的引入需要经过先经过功能调研（至少两种相同功能的三方库对比，满足需求所需），然后需要经过组内至少两人评估，确认这个三方库是必须要用的。

路由

我推荐的路由是HMRouter，重度使用路由就需要对路由有一个全面的认识，所以后面我有对路由的全面介绍

ohpm私仓

ohpm私仓搭建并不复杂，后面我也会单独介绍，使用ohpm私仓的好处是，组件har包上传上去之后，其他组件要用就可以直接install进来，而且虽然相互依赖，但是打出来的har包并不会包含依赖项的har包，因此上面说har包大多数情况下是不会导致包体增大的，只有把har包直接放到当前组件的libs下进行引用才会打入har包，如果多个组件这么干，会造成被依赖的har包重复，也就是包体会变大

开发规范&代码规范

上面介绍的架构模式是完全组件化的，每个组件的创建和协作开发都会额外花费时间，虽然这种模式利于维护，但是前期的开发效率并不高，因此最初快速鸿蒙化不应该是组件化形式，而是模块化

模块化介绍

所谓模块化就是一个工程下面，每个独立功能都是一个独立模块，也就是组件化中的har包在这里都是独立模块，他们不能独立运行也没有自己独立的git地址，这种方式对于前期快速鸿蒙化比较友好，小型工程也推荐这种方式

推荐结构如下：

XXXProj
 |-AppScope
 |-commons
   |-entity(主要负责管理应用的数据实体类)
      |-XxxEntity.ets(存放数据实体类)
      |-.....
   |-components(主要负责应用的公共组件)
      |-XxxComponent.ets
      |-.....
   |-constants(主要负责管理应用的公共常量)
      |-XxxConstant.ets
   |-dialog(主要负责管理应用的公共弹窗)
      |-XxxDialog.ets
   |-viewmodel(主要负责管理应用的逻辑处理)
      |-XxxModel.ets
   |-utils(主要负责管理应用的工具)
      |-XxxModel.ets
 |-entry
 |-features(存放所有业务模块)
   |-home
      |-entity（存放当前home模块的数据实体类）
      |-page （存放home模块下的主页面，一般支持其他模块路由跳转）
      |-model （负责管理应用的公共数据及业务逻辑，通常与后端服务交互）
      |-dialog （home模块下的弹窗）
      |-component （home模块下的组件）
   |-find
		|-结构和features/home下面一样）
   |-.....

组件命名规范

组件命名一定要全小写，涉及到多单词时使用下划线

鸿蒙官方三方库组件命名往外是这样的：rapid_kit_foundation、middy-http、@pura/harmony-utils 对于我们自定义的组件，推荐全小写+多单词下划线分割，拒绝名字中带@和/以及中划线

其他命名规范

变量、函数、类方法、自定义组件中的方法、接口、类属性、对象属性----->小驼峰
类名、.ets文件名----->大驼峰
如果是代码中的不建议写死,定义成常量
文件名和类名保持一致,文件命名要做到见名知意
魔鬼数字建议抽成常量,最低限度要有注释
定义工具类,根据功能能力命名,以Utils结尾,抽离的方法,需要有注释,功能干啥的?参数说明等
如果是common中的弹窗/组件,根据弹窗的能力命名,以XxxxDialog/XxxxCompent命名,写好注释(字段啥意思?弹窗的作用/组件的作用)
如果是模块的弹窗/组件,根据业务能力命名,以XxxxDialog/XxxxCompent命名,写好注释(字段啥意思?弹窗的作用/组件的作用)

确认适合自己的架构​

官方方案​

推荐方案​

依赖规则​

应用层​

业务层​

中间层​

中间层有两种形式​

为什么需要中间层（中间层的意义）​

是否需要中间层判断规则​

三方库​

路由​

ohpm私仓​

开发规范&代码规范​

模块化介绍​

组件命名规范​