HarmonyOS 鸿蒙Next APP快速架构

HarmonyOS 鸿蒙Next APP快速架构

背景介绍

基于目前完成,包含行业金融,物联网,电商,展业工具等类型APP总结;

适用于APP功能相对单一,开发对于业务比较了解,鸿蒙开发初级者,能够快速构建应用,以及一些开发经验

实际业务中不需要考虑以下几种情况

1.按需加载模块：某个功能模块，使用时由用户决定安装时机，动态从应用市场下载安装使用

2.多HAP/HSP引用相同HAR包的影响：从性能角度出发，需要减少多HAP/HSP对相同HAR包的引用。

实际业务考虑

共享模块：某个功能模块（业务模块或者能力模块）需要在多个应用之间共享其代码逻辑和资源。

分层架构

应用程序包结构

Entry类型的HAP:APP主入口,建议一个,其他页面用Component

HAR静态模块:拆分

官方推荐的三层架构模型

common

1.工具类：日志、时间、设备信息等等

2.全局常量：比如:全局开关,KEY,

export class GlobalTogger{
  //全局开关,true 打开  false  关闭
  static readonly  LOG_TOGGLE:boolean=false
}

3.全局资源：颜色、尺寸、文字大小、全局图片、实体类

static readonly  C000000:string='#000000'
 static  readonly sp12:string='12sp'
static readonly vp10:number=10
static readonly PX2VP100=px2vp(100)
static readonly  my_btn_select_type:ResourceStr=$r('app.media.my_btn_select_type')
export class GlobalParams{  firstParam:string=''}

全局的可以用Class也可以用enmu
class GlobalClasee{  static  readonly  VP10=10}
enum GlobalEnum{  VP10=10,  VP11=11,  VP12=12}

网络请求

API、网络工具、统一返回实体等

const baseUrl:string=GlobalTogger.TOGGLE?'releaseBaseUrl':'debugBaseUrl'
export enum ApiEnum {    RegisterByTourist =baseUrl+ "SFitWeb/sfit/registerByTourist",}

数据管理

首选项 KV DB 懒加载基础类

参考官方文档

• [@ohos.data.distributedKVStore (分布式键值数据库)](https://developer.huawei.com/consumer/cn/doc/harmonyos-references-V13/js-apis-distributedkvstore-V13)
• [@ohos.data.preferences (用户首选项)](https://developer.huawei.com/consumer/cn/doc/harmonyos-references-V13/js-apis-data-preferences-V13)
• [@ohos.data.relationalStore (关系型数据库)](https://developer.huawei.com/consumer/cn/doc/harmonyos-references-V13/js-apis-data-relationalstore-V13)

如实际业务需求中非常规类的数据管理需求可以参考如下

• 方舟数据管理

feature

创建规则

1.根据业务实际情况,一个模块中业务逻辑只在自己模块内部完成,对外暴露的接口越少越好

2.使用静态har包

按照业务划分

1.用户类：用户登录注册、用户信息展示等

2.公共类：hybird、webview、支付、认证等独立业务场景，只需要暴露接口给实际业务调用

3.业务类：

1- .公共业务：业务1 、业务2、…

2- .独特业务：业务3、业务4、…

product

此模块作为APP入口，

可以根据实际业务创建多个入口，例如根据feature创建多个模块，这里根据实际情况引用，创建公司多个功能不同的APP，也可以根据手机 平板设备类型进行分类

技术选择

路由选择

Navgation 官方方案

• HMRouter，官方针对Navgation进行封装
• 直接使用Navgation，虽然麻烦但是后续可替代性很强，例子

/**
 * 公共资源
 */
export namespace GlobalCommon {
  export const pageInfos = new NavPathStack()
  }
  static toWebPage(url: string) {
    GlobalCommon.pageInfos.pushDestination({
      name: "WebPage", param: url
    })
  }
  /**
   * 全局Navgation跳转封装  要在IndexPage完成渲染之后使用
   * @param pageInfos
   * @param name
   * @param parms
   */
  static pushDestination(name: string, parms?: object | string | number | boolean, parms1?: object | string | number,) {
    GlobalCommon.pageInfos.pushDestination({ name: name, param: Global.setPushDestinationParam(parms) })
      .catch((err: BusinessError) => {
        LoggerUtil.error(err, 'pushDestination')
      })
  }
  /**
 * 根据跳转页面名称获取参数
 * @param name 页面名
 * @returns 
 */
  static getNavgationRouterParams<T>(name: string): Array<T> | undefined {
    let result: Array<T> | undefined = []
    let params = GlobalCommon.pageInfos.getParamByName(name) as Array<T>
    LoggerUtil.error(params, `getNavgationRouterParams  ${name}  onReady`)
    if (params.length > 0) {
      result?.push(params[0])
    }
    return result
  }

跨平台

ArkUI-X 官方推荐,目前支持打包Android,IOS

网络请求

官方 需要自己手撸工具类

• axios 很强大也需要手撸工具

• eftool

  • 封装Axios
  • 封装官方的rcp

数据持久化

根据实际业务选择首选项  KV  数据库,一般项目中都是混合使用
数据量非常小：首选项
数据量键值对存在：KV
数据量大,并且字段多,更新查询比较频繁：数据库DB

开发模式MVVM

目前成熟API12 分为两个版本

• 状态管理（V1）-MVVM
• 状态管理（V2）-MVVM

经验总结

性能优化,四板斧

官网上和论坛有写的非常好的，下面做一些推荐

• 第一板斧：合理使用并行化、预加载和缓存 需要合理地使用并行化、预加载和缓存等方法，例如使用多线程并发、异步并发、Web预加载等能力，提升系统资源利用率，减少主线程负载，加快应用的启动速度和响应速度。
• 第二板斧：尽量减少布局的嵌套层数 在进行页面布局开发时，应该去除冗余的布局嵌套，使用相对布局、绝对定位、自定义布局、Grid、GridRow等扁平化布局，减少布局的嵌套层数，避免系统绘制更多的布局组件，达到优化性能、减少内存占用的目的。
• 第三板斧：合理管理状态变量 应该合理地使用状态变量，精准控制组件的更新范围，控制状态变量关联组件数量上限，控制对象级状态变量的成员变量关联组件数，减少系统的组件渲染负载，提升应用流畅度。
• 第四板斧：合理使用系统接口，避免冗余操作 应该合理使用系统的高频回调接口，删除不必要的Trace和日志打印，避免注册系统冗余回调，减少系统开销

实际开发业务中总结

1.模块划分不清楚：比如在common层出现逻辑业务–这里需要优化拆分业务代码到feature层

2.未使用MVVM开发模式，在@Component中存在大量不合理代码，比如：实体类，在build(){}中组件中使用网络价值，计算逻辑等

3.团队协作时各自开发，对于基础层引用计数方案混乱，比如：比如:网络请求框架中有Axios 官方 还有其他三方 ，一些三方库已经停止更新或者未适配最新API

4.编译器和API选择问题：编辑器版本很老的工程,IDEA中出现很多问题，旧版支持的ArkTS语法,新版本会报错