蚁人论坛 (iYenn.com)

安卓和iOS已有项目要做鸿蒙版，最快的方式就是模块化开发。我这里整理了一份开发方案原文地址

鸿蒙开发架构图

整体架构设计如下图，所有功能都是模块，上层可以依赖下层，下层不可以依赖上层，同级之间不可以相互依赖。业务层之间可以通过路由通讯。

单体式分层架构

所有鸿蒙化app开发时，为了开发效率，工程架构采用模块化开发。所有独立的功能都会以模块形式存在，模块代码管理跟随主工程管理。

为什么选择HAP+HAR模式，简单来说就是这种模式最适合我们鸿蒙化场景。为什么这种模式最适合，需要大家对HAP、HSP和HAR有一定了解，相关文档：blog.csdn.net/chuyouyingh…

依赖规则

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

应用层

应用层也就是壳工程，壳工程里只能配置工程特有的配置项，不允许写业务代码（可以依赖功能模块）

应用层包含打包构建相关配置（例如网络环境配置、各种三方密钥配置、授权文件等）

业务层

这里的模块都是应用中和业务逻辑相关的组件，

业务层组件之间不可以相互依赖，只能通过路由来进行通信，包括数据路由和跳转路由

中间层

中间层有两种形式

1，对三方库的二次封装，对外提供统一出口。比如三方库秒验进行二次封装，就成了可以路由调用的一键登录组件。

2，对相同功能的三方库进行功能聚合。比如支付中心就是对微信支付、京东支付等支付方式的聚合。

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

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

是否需要中间层判断规则

工具类不需要中间层，比如（数据模型Model的序列化、zip压缩工具），这些工具都是粒度极小，中间层是没有任何意义的。

非工具类的功能型三方库需要中间层，比如各种支付，各种分享等，中间层既能统一管理又方便共享其他工程使用。

三方库

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

开发规范&代码规范

全局工具类方法

1，全局工具类方法（对标iOS|安卓宏定义的方法与c方法）

全局工具类方法是通用的方法，比如获取屏幕宽高、获取系统版本号等，在开发过程中如果业务组件需要用到公共方法，请先全局搜索的方式确认通用工具方法的基础组件里是否已经定义，如果没定义再确认这个方法是否通用，如果通用则放基础工具组件中。

如图：这个是组件特有的工具类方法，这种工具类放到特有的组件内

2，全局通用变量，主要针对魔法文字

比如'100%'这类，应该定义为通用的静态只读变量，例：


js
 代码解读
复制代码
export default class CommonConstants {
  static readonly FULL_LENGTH: string = '100%';
  satic readonly TITLE_WIDTH: string = '80%';
}

不通用的示例如下：（通用的定义方式一样，只是放的位置不同）

命名规则：全局通用的我们会统一命名，为了保证类名不重复，每个组件都要有自己的特定前缀，比如上图，KCSoftSDK组件下的类名都可以KC为前缀

3，组件编码规范

3.1 组件模块（静态共享包）详细步骤：developer.huawei.com/consumer/cn…

在第一步创建的组件工程上右键->New→Module...新建模块→ Static Library(har)

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

以上结论是参考官方三方库及实践得出。官方三方库：ohpm.openharmony.cn/#/cn/home

3.2 代码结构

代码规范

通用原则

1，避免魔鬼数字，如if(res.result == 99)，99应该用变量赋值代码，如if(res.result == MAX_COUNT)；

2，代码逻辑如果复制三次以上，需要提取共有函数，进行复用

编码规范

1.命名
1.1 命名需要富有含义，尽量能达到见名知义的程度，避免无意义的命名。禁止使用系统关键字

1.2 变量名详细程度，根据变量作用范围而定，成员变量 > 函数的局部变量，作用域越大，变量名则应更详细。
例如对于一个类型的变量，成员变量命名越详细越好，如命名为localUserInfo ，函数的局部变量可以简单命名为info或userinfo。

1.3 类名
采用大驼峰命名法，尽量避免缩写。Manager、Module、Page等常见类型应添加对应的前缀标识。

1.4 方法名采用小驼峰命名法，方法名通常是动词或动词短语。布尔类型函数使用谓语动词为前缀。如：isXX()。
回调类方法，添加on前缀，如onRequestFaild(MobileErrorCode，mobileErrorCode)

1.5 枚举变量常量变量命名，枚举变量名模式为大写。

1.6 命名注意事项命名应该使用正确的英文拼写，除常用习惯缩写外应该尽量少用缩写避免混淆，避免使用拼音命名比如：bg表示背景为常用习惯缩写，可以使用

避免使用否定的布尔类型变量名，布尔类型变量名应该加上表达含义的前缀（has、is等）比如：isNotLogin 属于否定类型，应该避免使用

2.注释

2.1 不言自明的方法、变量不需要添加注释。例如：

2.2 注释主要是为了说明变量名、方法名无法阐述的含义，不要直接翻译。

比如下图，需要解释说明的阐述一下，而不是直接翻译

3.代码数量限制

3.1 一个函数体不要超过80行

3.2 函数中大括号不要超过4层

3.3 三行以上重复三次以上，或五行及以上重复两次及以上，代码必须另写出一个函数；

如果有一两个地方不同，要考虑使用参数进行概括，而使之成为共用的一段代码

应用权限使用原则

(1) 应用申请的权限，都必须有明确、合理的使用场景和功能说明（遵循最小化原则，只申请业务功能所必要的权限）。
(2) 应用在首次启动时，避免频繁弹窗申请多个敏感权限；敏感权限须在用户使用对应业务功能时动态申请。
(3) 非系统应用自定义权限名，禁止使用系统权限名前缀（如:以ohos开头为系统权限），建议以应用包名或公司反域名为前缀，防止与系统或其他应用定义的权限重名。

版本管理

由于模块的代码都在壳工程中管理，所以版本管理跟随主工程代码一起管理

开发阶段分支命名

命名规则：f_日期_需求简短描述
例如：f_20241016_update_pay

更新阶段

特性分支合并到develop使用git打tag，tag和版本号保持一致，版本号保持四位数字形式
tag命名规则：不允许包含任何字母，仅数字形式
例如：四位版本号：1.0.1.2
满十进一，例如：1.0.1.9 版本号加一之后：1.0.2.0

发布阶段

develop分支合并到master使用git打tag，tag和版本号保持一致，版本号升级到三位版本号形式

问题定位

最后，如果有问题实在找不到答案，不妨试下这个： developer.huawei.com/consumer/cn…