如何理解鸿蒙应用开发的三层架构与“一多”

441 阅读8分钟

背景

随着终端设备形态日益多样化,分布式技术逐渐打破单一硬件边界,一个应用或服务,可以在不同的硬件设备之间随意调用、互助共享,让用户享受无缝的全场景体验。而作为应用开发者,广泛的设备类型也能为应用带来广大的潜在用户群体。但是如果一个应用需要在多个设备上提供同样的内容,则需要适配不同的屏幕尺寸和硬件,开发成本较高。HarmonyOS系统面向多终端提供了“一次开发,多端部署”(后文中简称为“一多”)的能力,让开发者可以基于一种设计,高效构建多端可运行的应用。

定义及目标

定义:一套代码工程,一次开发上架,多端按需部署。

目标:支撑开发者快速高效的开发支持多种终端设备形态的应用,实现对不同设备兼容的同时,提供跨设备的流转、迁移和协同的分布式体验。

为了实现“一多”的目标,需要解决两个基础问题:

  • 不同设备间的屏幕尺寸、色彩风格等存在差异,页面如何适配。
  • 不同设备的系统能力有差异,如智能穿戴设备是否具备定位能力、智慧屏是否具备摄像头等,功能如何兼容。

应用程序包结构

在进行应用开发时,一个应用通常包含一个或多个Module。Module是应用/服务的基本功能单元,包含了源代码、资源文件、第三方库及应用/服务配置文件,每一个Module都可以独立进行编译和运行。

Module分为“Ability”和“Library”两种类型:

  • “Ability”类型的Module编译后生成HAP包。
  • “Library”类型的Module编译后生成HAR包HSP包

应用以APP Pack形式发布,其包含一个或多个HAP包。HAP是应用安装的基本单位,HAP可以分为Entry和Feature两种类型:

  • Entry类型的HAP:应用的主模块。在同一个应用中,同一设备类型只支持一个Entry类型的HAP,通常用于实现应用的入口界面、入口图标、主特性功能等。
  • Feature类型的HAP:应用的动态特性模块。Feature类型的HAP通常用于实现应用的特性功能,一个应用程序包可以包含一个或多个Feature类型的HAP,也可以不包含。

部署模型

“一多”有两种部署模型:

  • 部署模型A:不同类型的设备上按照一定的工程结构组织方式,通过一次编译生成相同的HAP(或HAP组合)。
  • 部署模型B:不同类型的设备上按照一定的工程结构组织方式,通过一次编译生成不同的HAP(或HAP组合)。

开发者可以从应用UX设计及应用功能两个维度,结合具体的业务场景,考虑选择哪种部署模型。当然,也可以借助设备类型分类,快速做出判断。

从屏幕尺寸、输入方式及交互距离三个维度考虑,可以将常用类型的设备分为不同泛类:

  • 默认设备、平板
  • 车机、智慧屏
  • 智能穿戴
  • ……

对于相同泛类的设备,优先选择部署模型A,对于不同泛类设备,优先选择部署模型B。

三层工程结构

“一多”推荐在应用开发过程中使用如下的“三层工程结构”。

  • common(公共能力层):用于存放公共基础能力集合(如工具库、公共配置等)。

    common层可编译成一个或多个HAR包或HSP包(HAR中的代码和资源跟随使用方编译,如果有多个使用方,它们的编译产物中会存在多份相同拷贝;而HSP中的代码和资源可以独立编译,运行时在一个进程中代码也只会存在一份),其只可以被products和features依赖,不可以反向依赖。

  • features(基础特性层):用于存放基础特性集合(如应用中相对独立的各个功能的UI及业务逻辑实现等)。

    各个feature高内聚、低耦合、可定制,供产品灵活部署。不需要单独部署的feature通常编译为HAR包或HSP包,供products或其它feature使用,但是不能反向依赖products层。需要单独部署的feature通常编译为Feature类型的HAP包,和products下Entry类型的HAP包进行组合部署。features层可以横向调用及依赖common层。

  • products(产品定制层):用于针对不同设备形态进行功能和特性集成。

    products层各个子目录各自编译为一个Entry类型的HAP包,作为应用主入口。products层不可以横向调用。

代码工程结构抽象后一般如下所示:

/application
├── common                  # 可选。公共能力层, 编译为HAR包或HSP包
├── features                # 可选。基础特性层
│   ├── feature1            # 子功能1, 编译为HAR包或HSP包或Feature类型的HAP包
│   ├── feature2            # 子功能2, 编译为HAR包或HSP包或Feature类型的HAP包
│   └── ...
└── products                # 必选。产品定制层
    ├── wearable            # 智能穿戴泛类目录, 编译为Entry类型的HAP包
    ├── default             # 默认设备泛类目录, 编译为Entry类型的HAP包
    └── ...

具体实例参考

gitee.com/harmonyos_s…

如何创建 Module

  1. 通过如下三种方法,在工程中添加新的Module。

    • 方法1:鼠标移到工程目录顶部,单击鼠标右键,选择New > Module...,开始创建新的Module,此时该module将创建在工程根目录下。

    • 方法2:选中工程目录中任意文件,然后在菜单栏选择File > New > Module...,开始创建新的Module,此时该module将创建在工程根目录下。

    • 方法3:在工程根目录下创建一个新的Directory,可在该目录下单击鼠标右键,选择New > Module...,创建新的Module,此时module将创建在该文件目录下,方便开发者对模块进行分类管理。

      说明

      当前暂不支持在AppScope、hvigor、oh_modules、build、点开头的目录(如:.hvigor、.idea)下通过单击鼠标右键创建module。

  2. New Project Module界面中,选择需要创建的模板,单击Next

  3. 在Module配置页面,设置新增Module的基本信息,然后单击Next

    • Module name:新增模块的名称,Module name不可与工程名称相同。

    • Module type:仅在Ability模板存在该字段,可以选择Feature和Entry类型。

      说明

      • 同一工程通过新增Module仅支持创建一个Entry模块。如需构建Entry类型模块,可在module.json5文件中修改相应module下的type字段。
      • 如果同一类型的设备已经存在Entry模块,出现新的Entry模块后,还需要配置distroFilter分发规则
    • Device type:选择模块的设备类型,如果新建模块的Module type为feature,则只能选择该工程原有的设备类型;如果Module type为entry,可以选择该Module支持的其他设备类型。

    • Enable native:仅Library模板存在,将创建一个可以调用C/C++的共享包。

  4. 若该Module的模板类型为Ability,还需要设置新增Ability的Ability nameExported参数,Exported参数表示该Ability是否可以被其它应用/服务所调用

    • 勾选(true):可以被其它应用/服务调用。
    • 不勾选(false):不能被其它应用/服务调用。
  5. 单击Finish,等待创建完成后,可以在工程目录中查看和编辑新增的Module。

配置distroFilter/distributionFilter分发规则

同一类型的设备(Phone、Wearable、Lite Wearable等)可能在系统API版本(apiVersion)、屏幕形状(screenShape)、窗口分辨率(screenWindow)上存在差异。针对这些差异,开发者需要针对同一类型设备的不同型号进行适配开发,然后在应用市场实现精准的分发,以便不同设备的用户能获得更好的使用体验。为了实现应用市场的精准分发,需要在一个工程中,针对同一类型设备添加多个Entry模块来适配不同型号的设备,然后再配置不同的分发规则。具体规则如下:

  • 通过DeviceType与screenShape等属性的组合唯一确定一个Entry。
  • distroFilter/distributionFilter中至少包含属性中的一个标签。
  • 如果一个Entry模块中配置了screenShape等任意一个或多个标签,则其他的Entry模块也必须包含相同的标签。
  • 一般情况下,screenShape和screenWindow标签用于Lite Wearable设备中。
  • 不同属性标签的配置格式如下。其中,policy取值为include时,表示设备满足value取值时,应用市场向该设备进行分发;policy取值为exclude时,表示除了value的取值外,其它合法的取值,应用市场都会向设备进行分发。

说明 screenWindow标签的policy取值只能为include。

Stage模型配置分发规则

  1. 在entry > src > main > resources > profile文件夹中新建一个.json文件,并根据开发实际需要,配置如下代码信息。Stage模型下分发规则请参见distributionFilter标签
{
   "distributionFilter": {
      "screenShape": {    //屏幕形状枚举
         "policy": "include",
         "value": ["circle", "rect"]
      },
      "screenWindow": {   //窗口分辨率
         "policy": "include",
         "value": ["454*454", "466*466"]
      },
      "screenDensity": {  //屏幕的像素密度
         "policy": "exclude",
         "value": ["ldpi", "xldpi"]
      },
      "countryCode": {   //国家地区
         "policy": "include",
         "value": ["CN", "HK"] 
      }
   }
}

2. 在module.json文件中指定分发文件。

{
  "module": {
    "name": "MyAbilityStage",
    "metadata": [
      {
        "name": "ohos.module.distro",
        "resource": "$profile:distro_filter_config"    //distro_filter_config为被指定的分发文件
      }
    ]
  }
}