寄语
这几年特别火的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包。
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、内存、硬盘等硬件限制，往往会对系统进行裁剪。