HarmonyOS NEXT：一次开发，多端部署

寄语

这几年特别火的uni-app实现了“一次开发，多端使用”，它这个端指的是ios、安卓、各种小程序这些，而HarmonyOS NEXT也提出了“一次开发，多端部署”，而它这个端指的是终端设备，也就是我们的手机、平板、电脑、智能手表这些。是不是很惊奇那，这也是HarmonyOS NEXT的强大之处，它在创立之初就以打造一个完整生态为目的，相信在不久的未来，一多能结合元服务或者更加强大的体系能实现真正的“万物互联”，不单单是网络的互联，而是像科幻电影中那种。同时，这也是最近鸿蒙被各位大佬比较看好的原因之一。

概述

简介

HarmonyOS系统面向多终端提供了“一次开发，多端部署”（简称为一多）的能力，让开发者可以基于一种设计，高效构建多端可运行的应用。

目标：

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

方舟开发框架

简介

方舟开发框架（简称：ArkUI）提供开发者进行应用UI开发时所必须的能力，方舟开发框架提供了两种开发范式，分别是基于JS扩展的类Web开发范式和基于ArkTS的声明式开发范式。

1.声明式开发范式

简介

采用TS语言并进行声明式UI语法扩展，从组件、动效和状态管理三个维度提供了UI绘制能力。

特点

适用于移动系统应用开发人员，占用内存更少，更适用大型的应用开发。

2.类Web开发范式

简介

采用经典的HML、CSS、JavaScript三段式开发方式，使用HML标签文件进行布局搭建，使用CSS文件进行样式描述，使用JavaScript文件进行逻辑处理。

存在原因

更接近Web前端开发者的使用习惯，快速将已有的Web应用改造成方舟开发框架应用。

特点

适用于Web前端开发人员，主要适用于界面较为简单的中小型应用开发。

应用程序包结构

简介

在进行应用开发时，一个应用通常包含一个或多个Module。

Module

Module是应用/服务的基本功能单元，包含了源代码、资源文件、第三方库及应用/服务配置文件，每一个Module都可以独立进行编译和运行，Module分为Ability和Library两种类型。

Module的类型

1.Ability类型的Module编译后生成HAP包。

2.Library类型的Module编译后生成HAR包或HSP包。

HAP

应用以APP Pack形式发布，其包含一个或多个HAP包，HAP是应用安装的基本单位，Ability类型Module编译后会生成HAP包，HAP可以分为Entry和Feature两种类型。

HAP的类型

1.Entry类型的HAP：应用的主模块。在同一个应用中，同一设备类型只支持一个Entry类型的HAP，通常用于实现应用的入口界面、入口图标、主特性功能等。

2.Feature类型的HAP：应用的动态特性模块。Feature类型的HAP通常用于实现应用的特性功能，一个应用程序包可以包含一个或多个Feature类型的HAP，也可以不包含。

部署模型

简介

一多有两种部署模型：

部署模型A：不同类型的设备上按照一定的工程结构组织方式，通过一次编译生成相同的HAP或HAP组合

部署模型B：不同类型的设备上按照一定的工程结构组织方式，通过一次编译生成不同的HAP或HAP组合

泛类是什么？

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

如何选择部署模型？

1.应用在不同泛类设备上的UX设计或功能相似时，可以使用部署模型A。

2.应用在同一泛类不同类型设备上UX设计或功能差异非常大时，可以使用部署模型B，但同时也应审视应用的UX设计及功能规划是否合理。

3.如果目标设备类型较多，往往是部署模型A和部署模型B混合使用。

4.不管采用哪种部署模型，都应该采用一次编译。

代码工程结构

简介

一多推荐了一种三层工程结构

代码工程结构和部署模型的关系

部署模型不同，相应的代码工程结构也有差异。部署模型A和部署模型B的主要差异点集中在products层：部署模型A在products目录下同一子目录中做功能和特性集成；部署模型B在products目录下不同子目录中对不同的产品做差异化的功能和特性集成。

三层工程结构 

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包

开发说明

1.整个代码工程最终构建出一个APP包，应用以APP包的形式发布到应用市场中

2.开发阶段应考虑不同类型设备间最大程度的复用代码，以减少开发及后续维护的工作量。

开发实例

概述

通过一个天气应用，介绍一多应用的整体开发过程，包括UX设计、工程管理及调试、页面开发等

UX设计

简介

一多建议从设备屏幕宽度的维度将设备划分为四大类，设计师只需要针对这四大类设备做设计。

开发思路

1.在不同的屏幕宽度下，应用的整体风格基本保持一致

2.在相近的屏幕宽度范围内，应用的布局基本不变；在不同的屏幕宽度范围内，应用的布局有较大差异。

3.应用在小屏幕下显示的元素，是大屏幕中显示元素的子集

四大类

不同设备的效果

 

工程管理及调试

创建项目

注意Device Type选项要勾选所有该应用期望运行的目标设备类型

预览调试

开启预览器并打开Multi-profile preview开关，还可以点击+ New Profile按钮，新增自定义预览器

预览器Multi-profile preview开关

页面开发

开发思路

1.划分9个基础区域

2.基础区域9仅在大设备上显示，基础区域1-8虽然在各设备上始终展示但其尺寸及区域内的布局基本保持不变，可以结合自适应布局能力以自定义组件的形式分别实现这9个基础区域。

3.基础区域1-8之间的布局在不同设备上有较大差异，可以使用响应式布局中的栅格布局能力实现组件间的布局效果

4.展开和隐藏侧边栏的功能可以通过侧边栏组件来实现。侧边栏是大设备上独有的，借助响应式布局中的媒体查询能力，控制仅在大设备上展示侧边栏即可

划分区域演示

功能开发

在超小设备上，考虑CPU、内存、硬盘等硬件限制，往往会对系统进行裁剪。