鸿蒙操作系统应用开发（购买纸质书预售赠e读版电子书）

版权信息

书名：鸿蒙操作系统应用开发

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版  权

著    李 毅 任革林 李世军 薛涛风

责任编辑 邓昱洲

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

抢读版免责声明

尊敬的读者：

  感谢您选择本电子书抢读版。当前版本为作品正式出版前的抢先阅读版本，旨在让您尽早体验内容，但稿件尚未经过完整的编辑、校对及审核流程，本抢读版仅供预览与交流，不代表最终出版质量。我们将根据读者反馈持续优化，并在正式出版后第一时间替换为完整版文件。届时，您将自动获取或可手动更新至正式版本。

  对于因抢读版内容疏漏可能带来的阅读困扰或理解偏差，我们深表歉意，但不承担由此产生的任何直接或间接责任。如您发现明显错误，欢迎通过官方渠道反馈，您的意见将帮助我们提升最终版本质量。

  购买或下载抢读版即视为知悉并同意本声明全部内容。

  感谢您的理解与支持！

内容提要

本书主要介绍华为鸿蒙操作系统的应用开发技术与原理。从鸿蒙系统的开发环境准备工作入手，分别介绍了DevEco Studio使用详解，应用开发调试、应用开发实例、应用框架解析、ACE框架使用指南、一次开发多端部署使用指南等基于鸿蒙操作系统的开发技术，详细阐述了利用华为鸿蒙系统开发应用的先进性和便利性，为构建良好的鸿蒙开发者生态，提供最权威的指南。

本书以案例为主，结合实际操作环境，介绍华为鸿蒙操作系统的最新创新，面向行业工程师、开发者、学生，以及对应用开发感兴趣的读者。

丛书编委会

主  编：李 毅

编  委：龚 体 高 泉 李世军 史海谋

     朱 爽 黄 瑾 柳晓见 梁 峰

     杨开封 陈晓晨 龚继华 王长亮

     倪元强 章晓峰 马汉卿 尤 劲

     魏洪康 刘道勇 于小歧 刘长飞

     薛清风 任革林 万承臻 鲜余强

     黄 然 余枝强 任 晗 金 波

     陶 铭 李 锋 陈秋林 李高峰

本书编委会

主  任：任革林

编  者：李世军 李 毅 薛清风 万承臻

     余枝强 任 晗 刘成华 杨 彰

     杨之言 郭玉华 SONGJUN 牛 辉

     鲜余强 黄 然 顾 兵 张小田

     易 见 张志军 马耀辉 柳 正

     唐 春 严 勇 火清羿 李勇彪

     赵小虎 薛竹飚 胡 越 王 雷

     吕 聪 冒晶晶 刘凯鑫 周耀颖

     袁 静 高红彦 蔡 波 孙贤达

     邱功凯 闫永杰 方习文 李昌婷

     平 江 柳 正 吕桂磊 李 杰

     朱 伟 陈 明 陈应华 吕胜军

     赵凡凡 郑凯杰 赵 虹 

前  言

万物互联的智能时代浪潮奔涌，操作系统作为智能终端的核心基座，已然成为全球数字科技竞争与产业创新的核心赛道。伴随物联网、全场景智能技术的飞速迭代，传统终端操作系统的架构局限、设备壁垒与适配短板日益凸显，难以适配多设备融合、跨终端协同的全新产业生态。在此时代背景下，鸿蒙操作系统应运而生、迭代成长，以颠覆性的全场景分布式理念，打破设备边界、重构开发范式，为亿万用户带来沉浸式智慧体验，也为广大开发者开辟了全新的技术创新赛道与产业发展机遇。

鸿蒙操作系统的核心优势，源于其独创的分布式技术架构。系统突破传统单设备运行模式，实现多终端设备无感互联、资源共享、协同交互，构建起全域一体化的智慧终端生态。同时，鸿蒙秉持“一次开发，多端部署” 的轻量化开发理念，大幅精简开发流程、降低适配成本、压缩技术门槛，彻底革新了传统碎片化的终端开发模式。这一变革，为开发者带来了机遇与挑战并存的全新发展格局。一方面，极致的跨设备协同能力、丰富的系统开放能力与灵活的分布式架构，赋予开发者广阔的创新空间，助力开发者突破传统应用的功能边界，打造更贴合全场景智慧需求、更具差异化体验的优质应用与元服务。另一方面，伴随鸿蒙生态的高速扩容、技术持续迭代与体系不断完善，全新的开发框架、工具链与技术体系对开发者提出了更高要求，亟需系统化、体系化的专业指引，帮助开发者快速迭代技术能力、适配生态发展节奏。基于广大中高级开发者的核心诉求，一本权威、系统、全面、贴合实战的鸿蒙应用开发专业指南，成为鸿蒙生态深耕发展的迫切所需。

2024年华为开发者大会（HDC）上，我们推出 “新一代智能终端操作系统丛书” 首部著作《鸿蒙操作系统设计原理与架构》。该书立足底层架构、深耕设计原理，凭借专业的内容体系、权威的技术解读、扎实的内容质量，获得了广大鸿蒙开发者与行业从业者的高度认可与广泛好评。本书作为该系列丛书的第二部力作，聚焦具备一定鸿蒙开发基础的中高级开发者群体，以实战落地为核心、技术进阶为导向，打造全方位、体系化的鸿蒙应用开发权威指南。

全书兼顾基础性与进阶性、理论性与实战性，既系统梳理鸿蒙应用开发核心体系，涵盖开发环境、开发模型、编程语言、系统开放能力等核心基础知识，搭建完整的鸿蒙开发知识框架；又立足HarmonyOS 6.1版本实际开发场景，依托海量一线实战案例与落地经验，聚焦应用、元服务的全流程开发与运行逻辑，精准拆解开发难点、性能优化要点与场景适配关键。旨在帮助开发者掌握鸿蒙开发核心技术与方法论，规避开发误区、优化开发逻辑，高效开发出贴合鸿蒙技术特质、性能优异、功耗可控、稳定流畅的高品质鸿蒙应用与元服务。开发者可在华为应用市场搜索并下载「HMOS 代码工坊」，获取持续更新的海量代码样例，拓展实战思路。

立足全场景智慧产业发展大势，鸿蒙操作系统仍在持续迭代、不断完善，生态规模持续扩大、技术体系日趋成熟，鸿蒙全场景应用开发已然成为智能终端领域极具潜力的核心发展方向。本书的出版，既是对鸿蒙应用开发实战体系的系统梳理，也为广大开发者搭建了专业的学习进阶、技术交流与能力提升平台，助力开发者深耕鸿蒙生态、释放创新价值，与行业同仁携手共建、共荣鸿蒙全域智慧生态，推动国产智能操作系统生态持续蓬勃发展。本书以HarmonyOS 6.1版本API/SDK为基础，

本书由鸿蒙操作系统核心设计团队专家倾力编撰，凝聚了团队多年底层研发、技术迭代与生态建设的一线实战经验与技术沉淀。本书主要贡献者如下：李毅，任革林，李世军，薛清风，余枝强、任晗、刘成华、杨彰、杨之言，郭玉华、SONGJUN，牛辉，鲜余强，黄然，顾兵、张小田、易见、张志军、马耀辉、柳正、唐春、严勇、火清羿，李勇彪、赵小虎、薛竹飚、胡越，王雷、吕聪、冒晶晶、刘凯鑫，周耀颖、袁静、高红彦、蔡波、孙贤达、邱功凯、闫永杰、方习文、李昌婷、平江、柳正、吕桂磊、李杰、朱伟、陈明、陈应华、吕胜军、赵凡凡、郑凯杰、赵虹等。衷心感谢各位作者与技术专家的潜心深耕、伏案耕耘与辛苦付出。

诚挚感谢以下行业专家为本书提供专业严谨的评审指导与宝贵修改建议：龚体、陈海波、高泉、史海谋、于小歧、刘长飞、周未来、王帅、张殿芳、张立哲、王经、崔坤、陈健、王长亮、戴志成、鲜余强、高涵一、张明修、张栋、夏峰、武斌、陈晓闯、张义军、刘东旭、许斯豪、李钱钱、吕竟雷、郑智超、杜卿、季昀、邱榆、翁长成、陈牡丹、黄慧进、戴慧娜、陈远方、郑家欢、强波、兰守忍、黄施煜、孙斐、严水峰、张海波、晏国淇、陈本智、贾德祥、蒋大圆、路石、汪坷、张凯祥、姜俊超、吴江铮、徐堡垒、刘明祥、杨靖骁、张颖峰、粆倩文、任亚飞、叶飞、张居杰、吴宁宁、朱欢欢、牛国亮、李义兵、傅志诚、蔡波、单以文、李兵、刘耀明、周葛、汪洋、刘德钱、韩记晓、张创、刘洪杰、董慧滨、尹友展、李建钊、郭金卫、刘超、王春风、王张军、龚阿世、谢刚、林大伟、赵文华、张斌、代育红、陶铭、沈芬、吴昊、周英玉、谭景盟、廖智琪等。

同时，由衷感谢人民邮电出版社科技出版中心总经理王威、学术分社副社长韦毅对本书出版工作的鼎力支持，感谢出版社全体编辑团队的专业打磨、精心编审与辛勤付出。对于所有为本书编撰、评审、出版提供帮助与贡献的各界同仁，凡未及逐一署名者，在此一并致以诚挚谢意！

由于作者学识与认知有限，书中疏漏与不妥之处在所难免，恳请广大开发者、行业专家批评指正。

第1章 应用开发基础

1.1 整体介绍

1.1.1　集成开发环境

1. DevEco Studio

DevEco Studio是面向鸿蒙操作系统应用/元服务开发场景的集成开发环境（Integrated Developmant Environment，IDE）。该工具提供AI辅助编程、实时预览、编译构建、跨语言调试、应用性能调优、应用/元服务体检、本地模拟器和依赖管理等功能，帮助开发者高效开发鸿蒙操作系统应用/元服务。

• AI辅助编程：结合CodeGenie工具，提供鸿蒙操作系统应用开发知识智能问答、代码生成、万能卡片生成、用户界面（User Interface，UI）生成等能力，并为ArkTS、JS和C/C++编程语言提供代码智能补全、代码重构等能力。

• 实时预览：在UI编码时快速预览界面在多种设备上的显示效果，查看组件布局，提升UI开发效率。

• 编译构建：结合Hvigor工具，支持自定义源码、资源、构建流程，可以灵活构建差异化的多目标产物，并通过Build Analyzer帮助分析构建性能，提升构建效率。

• 跨语言调试：提供ArkTS和C++语言调试、汇编调试、LLDB命令调试、反向调试、智能跳转和数据断点等调试能力。

• 应用性能调优：结合Profiler工具，支持分析多种场景的应用性能问题，包括内存泄漏、组件耗时、网络请求、应用启动、界面卡顿等，并通过可视化泳道图工具帮助优化鸿蒙操作系统应用性能。

• 应用/元服务体检：结合AppAnalyzer。在开发阶段发现可能影响应用/元服务上架的兼容性、性能、功耗、稳定性等问题，并支持场景化检测，提升应用/元服务的基础体验及上架成功率。

• 本地模拟器：提供手机（包括折叠屏手机）、平板计算机、PC/2in1等类型的模拟器，在鸿蒙操作系统各种设备上调测应用，以更好地适配不同的机型和鸿蒙操作系统版本。

• 依赖管理：结合ohpm包管理工具，支持对鸿蒙静态共享包（Harmony Archive，HAR）和鸿蒙动态共享包（Harmony Shared Package，HSP）的安装、更新、删除操作，统一管理各类模块之间的依赖关系。同时，结合ohpm-repo工具帮助开发者搭建轻量级的私仓服务。

2. 鸿蒙应用开发流程

应用/元服务的开发流程如图1-1所示。

图1-1　应用/元服务的开发流程

（1）开发准备

从华为开发者联盟官网下载DevEco Studio，并完成DevEco Studio的安装。

DevEco Studio的运行依赖网络环境，需要连接网络才能正常使用。在企业网络受限的情况下，需要配置代理信息。

（2）开发应用/元服务

DevEco Studio集成了手机、平板计算机、PC/2in1、车机等典型场景模板，可以通过工程向导轻松地创建新的工程。

接着需要定义应用/元服务的UI、开发业务功能等编码工作，可以通过查看应用程序接口（Application Program Interface，API）文档查阅需要调用的API。

在开发代码的过程中，可以使用预览器查看应用/元服务的效果，支持实时预览、动态预览、双向预览等操作。

（3）运行、调试和测试应用/元服务

应用/元服务开发完成后，可以使用真机进行调试（需要申请调测证书并进行签名），提供单步调试、跨语言调试等调试手段。

接下来需要对应用/元服务进行测试，主要包含设备端测试、本地测试，确保应用/元服务纯净、安全，以便给用户带来更好的使用体验。

（4）发布应用/元服务

应用/元服务测试完成后，需要将应用/元服务发布到华为应用市场，以便应用市场对应用/元服务进行分发，让普通消费者可以通过应用市场获对应的鸿蒙操作系统应用/元服务。需要注意的是，发布到华为应用市场的鸿蒙操作系统应用/元服务，必须使用华为应用市场颁发的发布证书进行签名。

1.1.2　应用结构

1. 开发态包结构

典型的开发态包结构（以实际为准）如图1-2所示：

图1-2　开发态包结构

开发态包结构包含的主要文件类型及其说明如表1-1所示。

表1-1　开发态包结构中主要的文件类型及其说明

2. 编译态包结构

不同类型的模块编译后会生成对应的HAP、HAR、HSP等文件，将这些文件编译后可通过DevEco Studio或打包工具打包成APP包，用于上架应用市场。编译HAP和HSP时，会把所依赖的HAR直接编译到HAP和HSP中，因此将这些文件打包成APP包后，编译态工程结构视图中没有.har文件。开发态与编译态的工程结构视图如图1-3所示。

图1-3　开发态与编译态的工程结构视图

从开发态到编译态，Module文件的变更如下。

• ets目录：ArkTS源码编译生成.abc文件。

• resources目录：AppScope目录下的资源文件会合并入Module下面的资源目录。如果两个目录下存在重名文件，编译打包后只保留AppScope目录下的资源文件。

• module配置文件：AppScope目录下的app.json5文件字段会合并入Module下面的module.json5文件，编译后生成HAP或HSP最终的module.json文件。

HAR与HSP的主要区别如表1-2所示。

表1-2　HAR与HSP的主要区别

HAP、HSP、HAR支持的规格如表1-3所示，其中“√”表示支持，“×”表示不支持。开发者可以根据具体的应用需求，选择相应类型的包进行开发。

表1-3 HAP、HSP、HAR支持的规格

3. 发布态包结构

每个应用中至少包含一个.hap文件、零至多个.hsp文件，一个应用中的所有.hap与.hsp文件合并在一起称为Bundle，其对应的bundleName是应用的唯一标识。

当应用发布上架应用市场时，需要将Bundle打包为一个.app后缀的文件，这个.app文件称为App Pack（Application Package）。与此同时，DevEco Studio工具会自动生成一个pack.info文件。pack.info文件描述了App Pack中每个HAP和HSP的属性，包含APP中的bundleName和versionCode信息以及模块的name、type和abilities等信息。

图1-4　应用编译发布与上架部署的流程

1.2 应用架构设计

随着应用规模不断扩大、业务需求日趋复杂，代码的复杂度也随之持续提升。优秀的架构设计是保障应用可维护、可扩展、可测试的关键。在实际的应用开发中，通常会面临以下典型问题。

• 代码组织混乱，模块间耦合度高，改动一处易引发连锁反应，显著提升维护成本与风险。

• 应用扩展性不足，新增功能往往需要对现有代码进行大量修改，难以快速适配业务变化。

为有效解决上述问题，开发者应重点关注以下架构设计思路。

• 分层架构设计：将应用划分为产品定制层、基础特性层与公共能力层，明确各层职责与交互规范，降低层间依赖，为代码开发提供清晰、稳定的结构化框架，从而提升整体代码的可维护性。

• 模块化设计：将应用按功能拆分为多个独立模块，每个模块专注实现单一任务。模块化设计可有效提升代码的可读性与复用性，降低系统耦合度，便于应用的灵活扩展与高效维护。

1.2.1　分层架构设计

鸿蒙操作系统中应用的分层架构设计依托单一代码工程，支持手机、平板计算机、PC/2in 1、车载设备等设备，真正实现“一次开发，多端部署”的开发理念。本节将从逻辑模型、开发模型、部署模型3个维度，详细阐述应用的分层架构设计规则。

1. 逻辑模型

应用的分层架构逻辑模型如图1-5所示，应用分层架构由产品定制层、基础特性层、公共能力层构成，具备清晰、高效、可扩展的架构特性。

（1）产品定制层

专注于满足不同设备与使用场景的个性化需求，主要包含 UI 设计、资源与配置文件，以及面向特定场景的交互逻辑和功能特性。

功能模块相对独立，具体业务功能依赖基础特性层与公共能力层实现。

作为应用的入口层和用户直接交互的界面，可根据实际需求灵活调整与扩展，以适配多样化的使用场景。

图1-5　应用的分层架构逻辑模型

（2）基础特性层

该层位于公共能力层之上，用于承载相对独立的功能UI与业务逻辑实现。各功能模块遵循高内聚、低耦合、可定制的设计原则，支持产品的灵活部署。

该层为产品定制层提供稳定、丰富的基础功能支撑，包括通用UI组件与基础业务服务；同时，该层的通用能力与底层服务依赖公共能力层提供。

为提升系统的可扩展性与可维护性，该层多采用模块化设计与管理。例如，应用底部导航栏中的每个选项，均可作为独立的业务模块进行实现与维护。

（3）公共能力层

该层承载应用的公共基础能力，包含公共UI组件、数据管理、外部交互、工具库等共享功能，供上层模块统一调用。

该层提供稳定、可靠的底层支撑，是保障应用整体稳定性与可维护性的关键。

公共能力层主要包含以下部分。

• 公共UI组件：采用通用化、高复用设计方式，确保在不同应用模块中保持一致的用户体验。组件提供标准化、易用的界面功能，可快速实现提示、警告、加载状态等常见交互需求，有效提升开发效率与用户体验。

• 数据管理：负责应用内数据的统一存储与访问，包括应用数据、系统数据等类型，对外提供统一的数据管理接口，简化数据读写操作。集中式数据管理既可降低数据的维护成本，又能保障数据的一致性与安全性。

• 外部交互：负责应用与外部系统的对接，包括网络请求、文件输入/输出（Input/Output，I/O）、设备I/O等，提供统一的外部交互接口，简化应用与外部环境的通信流程。开发者可便捷实现网络通信、数据存储与硬件接入，在提升开发效率的同时，保证程序的稳定性与性能。

• 工具库：提供一系列通用工具函数与工具类，包括字符串处理、日期时间处理、加解密、数据压缩解压等常用功能，帮助开发者提升开发效率与代码质量。

2. 开发模型

应用的分层架构开发模型如图1-6所示。

图1-6　应用的分层架构开发模型

架构分层的开发态代码，按照不同的架构层次（产品定制层基础特性层、公共能力层），编译为不同模块（HAP、HAR或HSR）。

（1）产品定制层

产品定制层中的各子目录会编译为Entry类型的HAP，作为应用的主入口。该层面向多设备场景，集成对应设备所需的功能与特性。产品定制层可划分为多个功能模块，各模块针对特定设备或使用场景进行设计，并可根据产品需求灵活开展功能与交互的定制化开发。

（2）基础特性层

在基础特性层中，功能模块根据部署需求被分为两类。对于需要通过Ability承载的功能，可以设计为Feature类型的HAP；而对于不需要通过Ability承载的功能，根据是否需要实现按需加载，可以设计为HAR模块或者HSP模块，编译后对应HAR或者HSP。

（3）公共能力层

公共能力层的各子目录将编译成HAR，仅产品定制层和基础特性层可依赖，不允许反向依赖。该层提取模块化公共基础能力，为上层提供标准接口和协议，提高复用率和开发效率。

3. 部署模型

应用的分层架构部署模型如图1-7所示。

图1-7　应用的分层架构部署模型（可针对不同设备定制）

应用程序（.app文件）在流水线或应用市场上被解包为N个Entry类型的HAP和N个Feature类型的HAP，并根据设备类型和使用场景部署到不同设备，实现多端统一用户体验。

在部署模型中，每个Entry类型的HAP代表应用的入口点，而Feature类型的HAP则包含应用的特定功能模块。应用能够以模块化的方式适配和部署，从而满足不同设备和场景的需求。

部署模型优化了应用的组织结构，确保应用在各种设备和场景下的一致性。通过根据设备类型和使用场景区分和部署不同的HAP，用户在任何设备或场景下都能获得统一且高质量的体验。

1.2.2　模块化设计

1. 模块化设计理念

大型软件工程一般需要多团队参与开发。各团队之间以弱耦合方式交互，通过契约化接口定义业务之间的交互，确保各团队业务独立发展、互不影响，实现快速迭代演进。业务模块化是现代软件工程的核心原则之一，通过将大型复杂系统拆解为更小、更易管理和理解的功能模块，提高系统的可维护性和可扩展性。每个功能模块都是独立单元，具有清晰定义的接口和职责，能够与其他模块交互以完成复杂任务。

在鸿蒙应用开发中，模块化既是设计原则，也是开发实践。该原则要求将应用程序拆分为多个功能模块，每个功能模块负责特定功能或特性。这些功能模块可以独立开发、编译和部署，也可以在不同设备上灵活组合和调用。在进行模块化设计时，需要考虑鸿蒙操作系统的应用结构，因为应用结构（定义）应用的组织方式。通过开发态、编译态、发布态阶段的包结构，可以了解不同模块的具体使用场景及规则。

2. UIAbility组件的设计

鸿蒙应用的业务逻辑通常由UIAbility组件承载。根据业务场景、目标设备与实际诉求的差异，需要合理进行UIAbility组件的选型与设计。在多设备环境下，应用形态不再局限于传统移动设备的单任务、单窗口模式。在诸多场景下，采用多任务、多窗口形态，能够为用户带来更流畅的使用体验，显著提升操作效率。

每个任务通常对应一个UIAbility组件实例，且可单独展示为一个窗口。用户可在同一应用的不同任务间自由切换，使用体验与独立应用一致。在功能设计阶段，需明确应用是否支持多任务、多窗口模式，这将直接影响整体工程的模块化结构。

在单Ability场景（只包含一个UIAbility组件）下，可对应单窗口类应用、基于多实例实现的多任务应用，或通过指定实例运行的多任务应用。例如，常规游戏应用建议采用单HAP承载对应的UIAbility。

多Ability场景（包含多个UIAbility组件）主要分为两类。

• 对于多窗口类应用，不同窗口对应不同功能，可通过不同的UIAbility组件分别承载。例如导航应用中，导航界面与主页面分属不同功能，并以两个独立任务呈现给用户，该类模块可采用Feature类型的HAP承载对应的UIAbility组件。

• 对于卡片、分享等应用扩展功能，通常不会以独立任务或窗口形式运行。由于这类功能业务相对独立，且由系统提供的独立ExtensionAbility承载，从业务解耦与模块化拆分的角度出发，建议使用Feature类型的HAP单独承载对应的ExtensionAbility组件。

3. 应用模块化选型

应用的架构旨在实现业务服务功能，从技术角度规划业务实现的方式；工程模块化模型则基于技术架构，完成代码工程层面的模块化选型，重点考虑技术如何在代码工程中落地。只有代码工程的技术与模型选型合理，才能在包体积、运行性能、产品部署等维度实现最优的综合效果。

应用通常分为多个模块，例如某购物软件，包含主页导航、商品详情、购物车、支付、订单、个人信息等模块。技术架构上，这些业务模块属于高内聚、低耦合的模块。在代码工程的模块选型中，由于Entry类型的HAP是工程默认存在的，且不能存在多个，所以主要考虑的模块类型有Feature类型的HAP、HAR和HSP。

在模块选型时，需要根据业务特性和模块功能等多方面因素进行综合评估。基于常见的应用模块类型，以下是几种实际业务中可能遇到的情况。

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

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

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

4. 多HAP工程

对于同一种设备类型，如果需要不同的独立功能模块，并且具有单独入口的功能特性，建议选择独立特性的HAP，按需下载并安装。此时一个APP包中就会有多个HAP，其中有且仅有一个Entry类型的HAP，其他均是Feature类型的HAP。多HAP之间业务独立，可能会有业务能力共享，所以在进行模块型时，需要考虑模块是否具有公共能力。

对于具备公共能力的模块，和上述HAP+HSP组合类似，需要在App Size与性能之间进行平衡。

HAP应用架构一般采用以下模型，除了产品组件中存在HAP，其余的均是HAR，如图1-8所示。

图1-8　多HAP工程模块示意（性能优先）

从图中可以看出，编译产物中多个HAP之间存在相同的HAR（如har_2、har_3、har_C、har_D、har_E）。这种情况下，App Size可能会增大。如果App Size不是应用的瓶颈，或者HAR较小，对App Size的影响可控，那么可以采用这种性能优先的模型，从而减少动态加载的性能损耗。

App Size和性能的平衡问题的本质在于如何在HAP和HSP之间分布HAR包，以最小化App Size并减少HAR的重复编译和打包。最小化App Size的主要方式是将公共能力模块封装为公共HSP，如图1-9所示。

图1-9　多HAP工程模块示意（App Size优先）

从图中可以看出，有3个HAP（1个Entry类型和2个Feature类型）将公共的HAR封装到HSP工程中，例如common_wrap_hsp和feature_wrap_hsp这两个HSP从严格意义上不能称为模块，仅称为模块壳，用于合理放置模块在编译产物中的位置，不具备模块功能，也不能共享，仅能在APP内使用，依赖这些模块壳的模块无法在应用间实现共享。

图1-9所示的模块通过HSP将HAR合理分配到编译产物中，确保每个HAR在APP编译产物中仅出现一次，从而减小App Size。模块壳的数量不宜过多，否则可能影响安装速度和启动性能。

上述这两种模块都是理想模块，真实的业务模块通常是两者的平衡态或组合。例如，打印日志模块的代码和资源较少，占用空间较小，将该模块编译进所有编译产物中，App Size较少，同时性能较好。

1.3 多设备开发

鸿蒙操作系统系统面向多终端设备提供“一次开发，多端部署”（以下简称一多）能力，支持开发者基于一套工程与设计，高效构建可在多端运行的应用，如图1-10所示。本节从体验设计、页面开发、功能开发等维度，介绍端到端的设计与开发，助力开发者快速构建适配多类设备的应用。在应用开发前期，建议开发者充分评估多设备适配场景，提前规划应用架构，避免后期新增设备类型时再对应用整体架构进行大幅调整。

1. 解决方案

为实现一多的开发目标，需解决以下3个核心问题。

• 页面如何适配不同的屏幕尺寸与视觉风格。

• 功能如何兼容不同设备的系统能力差异，如是否支持NFC、SIM 卡等。

• 如何设计代码工程，真正实现一多。

图1-10　一次开发、多端部署的应用示意

针对以上问题，鸿蒙操作系统分别从界面适配、功能兼容、代码工程设计3个维度提供了完整的解决方案，如图1-11所示。

图1-11　一多解决方案

• 工程级一多：应用采用三层架构设计，结合工程管理与包管理功能，实现工程代码的统一管理与多设备按需部署。

• 功能级一多：在工程级一多的基础上，通过API能力绑定机制，提升功能模块的灵活性与代码复用率。

• 界面级一多：在功能级一多的支撑下，依托UI一多设计规范，包括响应式与自适应布局，以及统一的视觉与交互归一设计，实现界面在多设备上的自适应展示与一致体验。

开发流程通常包含体验设计（包含UX设计、业务功能设计等）、架构设计、界面开发、功能开发等步骤。实现一多应用同样遵循这一流程。

2. 体验设计

要实现一多的应用开发，在产品设计的早期阶段就需要考虑多设备适配的问题，通过统一规划实现跨终端的功能布局与用户体验一致性。UX设计原则应该遵循多设备的“差异性”“一致性”“灵活性”和“兼容性”。

3. 架构设计

• 产品定制层：面向不同设备和场景的个性化需求，涵盖UI设计、资源配置及交互逻辑。该层作为用户直接交互的界面，具备灵活调整与扩展能力，适配多种应用场景。

• 基础特性层：位于公共能力层之上，封装独立功能模块与业务逻辑，具有高内聚、低耦合、可定制等特点，为产品定制层提供基础功能支撑，并支持灵活部署。

• 公共能力层：提供通用能力支撑，包括公共UI组件、数据管理、工具库等共享资源，保障系统的稳定性与可维护性，为基础特性层与产品定制层提供统一服务支持。

4. 界面开发

（1）窗口适配

在一多开发过程中，开发者需要考虑如何适配多种不同窗口类型，并关注同一窗口类型在不同设备上的差异化属性，如尺寸规格、系统区域限制、是否支持沉浸式显示、自由窗口是否包含标题栏等。为确保应用在多设备上的良好兼容性，开发者需重点关注以下几个方面。

• 横竖屏切换策略与实现方案：根据不同设备的使用场景和用户习惯，制定合理的屏幕旋转控制逻辑，并实现适配。

• 窗口沉浸式页面的适配方式：针对沉浸式体验需求，合理配置状态栏、导航栏的隐藏与交互逻辑，确保视觉完整性。

• PC/2in1设备中窗口的自由适配：包括窗口化布局、标题栏显示控制、全屏沉浸式体验的实现，以保障桌面级交互的流畅性和一致性。

（2）响应式布局

响应式布局是指页面内的元素能够根据窗口尺寸自动调整。响应式布局中最常用的媒体特征是窗口宽度，因此系统侧将窗口宽度划分为不同的范围（称为断点）。当窗口宽度从一个断点变化到另一个断点时，需要改变页面布局（如将页面内容从单列排布调整为双列排布甚至三列排布等）以获得更好的显示效果。

（3）交互归一

在多设备应用开发中，交互体验是关键指标。面对触控屏、鼠标、键盘、遥控器等多种输入方式，需考虑不同设备的交互适配。

交互归一是一种适配多设备输入的交互响应框架，可以将各类输入行为统一为标准化事件，确保界面在不同设备上保持一致的交互体验。开发者只需调用统一接口，无须为每种设备单独进行适配，从而简化开发流程。

5. 功能开发

系统能力（System Capability，SysCap）指操作系统中每一个相对独立的特性，如蓝牙、Wi-Fi、NFC、摄像头等。每个系统能力均对应多个API，随着目标设备是否支持该系统能力共同存在或消失。因此，开发一多应用时，需要借助SysCap机制，在各个环节中对系统能力进行拦截或管控，保证应用可以在设备上正常安装和使用。

1.3.1　多设备体验设计

鸿蒙操作系统为设计师提供了面向多设备的统一设计指南，可最大限度降低多端设计成本，保障多设备体验在一定程度上的一致性。同时，鸿蒙操作系统也提供了配套的技术支撑能力，帮助开发者高效实现多端应用的开发与适配。多设备体验设计如图1-12所示。

图1-12　多设备体验设计示意图

结合用户在多端设备上的历史交互习惯、各场景下的核心诉求等因素，适用于多设备体验设计的方法主要包含以下几个部分。

• 基础要求：指多设备体验设计中必须遵守的核心准则，若未满足这些基础要求，将极大降低用户使用体验，影响应用的可用性。

• 响应式布局：针对常见界面元素，提出适配宽屏设备的响应式布局设计范式，有效规避因简单拉伸、放大界面而导致的体验瑕疵，保障不同屏幕尺寸下的界面合理性。

• 增值体验：在多设备体验设计中，需结合不同设备的场景差异，灵活适配用户体验，在满足基础要求的前提下，提供更具场景价值的体验升级，提升用户使用好感度。

• 场景化设计参考：针对垂直领域的典型应用，提供场景下代表性页面的具体设计建议，为设计师提供针对性的参考依据，便于快速落地多设备适配设计。

1.3.2　多设备界面开发

1.3.3.1 窗口形态

1. 应用窗口模式

鸿蒙操作系统目前支持全屏、分屏、自由悬浮多窗3种应用窗口模式。它们的窗口效果如下图1-13所示：

• 全屏：应用主窗口启动时铺满整个屏幕。

• 分屏：应用主窗口启动时占据屏幕的某个部分，当前支持二分屏。两个分屏窗口之间具有分界线，可通过拖拽分界线调整两个分屏窗口的尺寸。

• 自由悬浮多窗：分为自由多窗和悬浮窗。自由多窗的大小和位置可自由调整。同一个屏幕上可同时显示多个自由窗口，这些自由窗口按照打开或者获取焦点的顺序在Z轴排布。当自由窗口被点击或触摸时，其Z轴高度提升，并获取焦点。悬浮窗是一种在设备屏幕上悬浮的非全屏应用窗口。一般在已有全屏任务运行的基础上，临时处理另一个任务，或短时间多任务并行时使用，如浏览网页的同时回复消息。

图1-13　3种应用窗口模式的窗口示意

窗口模式是由系统提供的功能，不需要开发者单独开发功能，所以开发者只需要考虑悬浮或者分屏之后应用界面的适配问题。不同产品支持的窗口模式不同，如表1-4所示。

鸿蒙设备涉及屏幕、窗口、rotation、orientation等多个显示方向相关术概念。窗口的orientation和屏幕的rotation并没有直接关系，在使用上也不能相互替代。图1-14描述了折叠屏手机在不同形态下orientation与rotation的映射关系。在rotation为0°的情况下，窗口的orientation可能是竖屏，也可能是横屏。

表1-4 设备支持的窗口模式表

图1-14　折叠屏手机orientation与rotation的映射关系

2. 应用窗口的设计

鸿蒙应用的窗口一般采用沉浸式模式进行设计。沉浸式模式是指通过减少无关元素的干扰，使应用界面更加专注于内容呈现，以提升用户体验的设计模式。典型应用的全屏窗口，其UI元素包括状态栏、应用界面和底部导航条。在沉浸式模式下，状态栏和导航条称为避让区，避让区之外的区域称为安全区。沉浸式模式设计时通常通过布局与颜色调整，将应用界面延伸至状态栏和导航条，降低系统界面突兀感，实现统一沉浸的 UI 体验。沉浸式模式设计时主要考虑如下两个因素。

• 实现沉浸式效果：通过特定方法、属性或接口，使界面突破安全区或标题栏限制，延伸至目标区域。界面沉浸式效果分为窗口级、组件级两个层级。窗口级作用于所有页面；组件级作用于当前组件，可针对单个页面内的多个组件分别配置。

• 避让处理：避免界面内容与避让区的系统信息（如电量、时间）、交互功能（如导航条手势）或窗口控制键（如关闭、最小化）发生遮挡和冲突。

沉浸式模式的核心设计要求有以下两个。

• UI 避让：仅导航条底部可响应点击，核心可交互元素、关键信息不放入导航条；状态栏与界面冲突时必须进行避让。

• 颜色匹配：状态栏、导航条颜色与应用界面统一，无视觉断层。

为实现沉浸式效果，鸿蒙操作系统提供表1-5所示的4种沉浸式模式设计方案。窗口沉浸式效果由不同页面的沉浸实现，页面沉浸式效果由不同组件的沉浸策略组合而成。建议通过组件沉浸方案为每个页面配置不同的沉浸策略，以实现应用的沉浸式效果。

在实现页面沉浸式效果后，往往会和避让区产生UI元素的遮挡、视觉上的违和或交互上的冲突等问题，开发者可以针对不同场景选择合适的避让方式。

在PC/2in 1和折叠手机设备的自由多窗模式下，开发者可以设置应用窗口的标题栏不可见，将应用页面扩展至原标题栏区域，实现窗口的沉浸式效果。组件沉浸式策略不适用于自由窗口标题栏的沉浸，需要开发者单独适配。

1.3.3.2 界面布局

界面布局分为自适应布局和响应式布局。

自适应布局是指当外部容器的大小发生变化时，元素可以根据相对关系自动变化，以适应外部容器变化。相对关系包括占比、固定宽高比、显示优先级等。当前，自适应布局功能有7种：拉伸能力、均分能力、占比能力、缩放能力、延伸能力、隐藏能力和折行能力。自适应布局可以实现界面显示随外部容器大小连续变化，多用于解决界面各区域内的布局差异。

响应式布局是指当外部容器的大小发生变化时，元素可以根据断点、栅格或特定的特征（如屏幕方向、窗口宽高等）自动变化，以适应外部容器变化。当前，响应式布局功能有3种：断点、媒体查询、栅格。响应式布局可实现界面随外部容器大小的不连续变化，通常在不同特征下，界面显示会有较大差异，多用于解决页面各区域间的布局差异。

1. 自适应布局

针对常见的开发场景，鸿蒙操作系统提供了7种自适应布局功能，这些功能可以独立使用，也可叠加使用，如表1-6所示。

表1-5 沉浸式模式设计方案对比表

表1-6 自适应布局的7种功能

2. 响应式布局

响应式布局是指基于响应式设计方法论进行布局，核心思想是页面根据不同的屏幕尺寸自动调整布局，提供更舒适的界面和更好的用户体验。响应式布局页面的效果如图1-15所示。

鸿蒙操作系统提供了4种响应式布局功能，如表1.7所示。

下面介绍断点和栅格这两种响应式布局功能。

（1）断点

应用响应式布局中的断点功能进行设计时，应遵循以下原则。

• 两个宽度相近的窗口，如果页面布局相同，则断点归一。

• 高度相对宽度较小的窗口，如果呈现横向窗口或类方形窗口，则页面布局进行差异化设计，增加断点。

图1-15　响应式布局效果示意

表1-7　响应式布局的4种功能

鸿蒙操作系统设计了横向断点和纵向断点，分别代表窗口的不同特征，作为判断页面布局和交互体验的条件。横向断点以窗口宽度值区分，代表窗口宽度。纵向断点以窗口高宽比区分，代表窗口相对高度，表示横向、方形或纵向窗口。

鸿蒙操作系统常用设备的断点区间表如图1-16所示。

（2）栅格

栅格是应用于页面布局的二维网格结构体系，可作为多设备场景下通用的辅助定位与排版工具。它将页面水平方向划分为等宽的列，通过设置内容占据的列数来实现灵活的布局。

栅格可以显著降低适配不同屏幕尺寸的设计及开发成本，使得整体设计和开发流程更有秩序和节奏感，同时也保证多设备上应用界面显示的协调性和一致性，提升用户体验。

图1-16　鸿蒙操作系统常用设备的断点区间表

鸿蒙操作系统的栅格功能采用了12列设计，因为12可以被2、3、4、6整除，提供了更灵活的布局可能性。

栅格的样式由Margin、Gutter、Column 3个属性决定，如图1-17所示。

图1-17　栅格功能示意

• Margin是相对应用窗口、容器的左右边缘的距离，决定了内容可展示的整体宽度。

• Gutter是相邻的两个Column之间的距离，决定内容间的紧密程度。

• Column是栅格中的列数，其数值决定了内容的布局复杂度。

单个Column的宽度是系统结合Margin、Gutter和Columns自动计算的，不需要也不允许开发者手动配置。

栅格宽度的计算公式如下。

1个栅格的宽度=（屏幕宽度-Margin×2-Gutter×3)/4=(360-24×2-24×3)/4=60（vp）。

2个栅格的宽度=1个栅格的宽度+Gutter+1个栅格的宽度=60+24+60=144（vp）。

3个栅格的宽度=2个栅格的宽度+Gutter+1个栅格的宽度=144+24+60=228（vp）。

4个栅格的宽度=3个栅格的宽度+Gutter+1个栅格的宽度=228+24+60=312（vp）。

综合权衡各类设备的屏幕特征，基于8vp为网格的基本单位可以对界面中元素的大小、位置、对齐方式进行更好的规划，构建更有层次感、秩序感以及多设备一致的布局效果。一些更小的控件（例如图标）大小可以对齐4vp的网格大小。栅格的Margin和Gutter的值参考8vp/4vp网格系统设置。例如，手机设备上的栅格化设计，基础栅格的Margin为24vp，等于3个8vp的宽度；卡片栅格的Margin为12vp，等于一个8vp加上一个4vp的宽度。

各类设备的栅格参数如表1-8所示。

表1-8 各类设备的栅格参数表

实现栅格功能的组件名为栅格组件。在实际使用场景下，可以根据需要配置不同断点下栅格组件中元素占据的列数，也可以调整Margin、Gutter、Column的取值，从而实现不同的布局效果。

1.3.3.3 用户交互

多设备交互开发需针对触屏、鼠标、键盘、遥控器等不同输入设备进行交互适配，在保证功能一致性的基础上，遵循各设备的交互规范，实现自然、流畅的应用体验，如图1-18所示。交互归一是一种面向多设备输入的响应框架，通过将不同输入设备的交互行为抽象为同一事件，来简化开发逻辑，例如触屏点击、触控板点击、鼠标左键单击、遥控器OK键确认等统一抽象为点击事件；遥控器功能键、键盘快捷键抽象为按键事件。交互归一可以实现对多样化输入源的统一处理，确保组件在不同交互场景下具备一致的行为逻辑与用户体验。

图1-18　针对不同输入设备进行交互适配

交互归一并非将所有输入方式简单合并为单一事件或通过一个API处理，而是通过对不同设备的几十种底层交互事件进行语义抽象与归类，在保证交互差异可控的前提下，大幅减少事件类型的数量，最终形成一组标准化的交互API集合。开发者仍需根据具体场景选择并适配相应的抽象事件，以实现跨设备的一致性与灵活性兼顾的交互体验。

1. 基础输入事件

当用户使用输入设备（如触摸屏、键盘、鼠标或触控板）进行交互时，设备驱动层会检测并生成相应的原始信号。鸿蒙操作系统捕获这些底层信号，并将其封装为标准化的“基础事件”，随后传递给上层应用程序进行处理。

基础事件根据特点总体上分为两类，即指向性基础事件与非指向性基础事件。我们可以从“事件的目标如何确定”来理解指向性事件和非指向性事件。

• 指向性基础事件：交互动作第一次开始时（比如手指按下、鼠标点击），用户的手指或鼠标指针碰到了屏幕上的哪个组件，这个被“命中”的组件就是整个交互过程（包括后续的移动、抬起）的接收目标。这类事件包括触摸事件、鼠标事件、轴事件、手写笔事件。典型场景如使用手写笔在屏幕上书写，当手写笔首次点击屏幕的某个位置（例如画板），时当前画板组件就是交互的目标。

• 非指向性基础事件：事件的接收者由当前焦点所在的组件决定。这类事件包括按键事件、表冠事件、焦点轴事件。典型场景如在使用键盘填写表单时，多个输入框之间可通过Tab键进行切换，当前获得焦点的输入框通常会被高亮显示。用户输入的字符内容会被系统视为针对该焦点输入框的交互，直接发送至该组件进行处理。

图1-19所示为常见的基础输入事件在不同输入设备上的触发方式。

图1-19　常见的基础输入事件在不同输入设备的触发方式

2. 手势事件

手势事件是由一系列基础事件累积并满足特定条件后被识别出来的交互行为，例如“点击”即快速按下并抬起。系统组件默认支持常见的手势事件（如按钮支持点击事件），也可在组件上绑定一个或多个手势。默认情况下，多手势事件的识别会按照手势注册的顺序依次进行匹配和处理。

• 在希望多个手势互斥执行（仅一个生效）的情况下，可使用互斥识别机制，避免冲突响应。

• 在希望多个手势同时响应的情况下，可使用并行识别机制，允许多个手势并发处理，提升交互灵活性。

• 在需要精细控制哪些手势可参与识别与竞争的情况下，可以使用手势冲突处理机制。

图1-20所示为常见的手势事件在不同输入设备上的触发方式。

图1-20　常见的手势事件在输入设备上的触发方式

3. 焦点事件

使用键盘、电视遥控器、车机摇杆或旋钮等非指向性输入设备与应用程序进行间接交互时，建议将界面中可操作元素设置为可获焦状态，并配置获焦视觉效果，以保证交互体验。

• 获焦/失焦：通过onFocus和onBlur事件来监听组件的焦点变化。当组件获焦时，遵循子组件优先原则。若子组件需获焦，其所有祖先组件均需可获焦。当容器组件需获焦时，其子组件应不可获焦，并配置点击事件。

部分组件默认可获焦，如Button、TextInput等基础组件和Column、Row等容器组件。若组件（如Text、Image等）有获焦能力但默认不可获焦可设置通用属性focusable（true）使其可获焦。部分组件为无交互行为的组件，通常不可获焦，例如Blank、Circle组件。

• 走焦：触发走焦时，系统会遍历组件树中可走焦的组件。当前焦点事件支持3种走焦算法：第一种是线性走焦，按照子节点在节点树中的挂载顺序进行焦点导航；第二种是投影走焦，适用于容器内子组件尺寸不一的场景，通过空间位置关系计算最佳焦点目标；第三种是开发者通过tabIndex和nextFocus灵活自定义走焦逻辑，满足复杂交互需求。

图1-21所示为不同输入设备上支持焦点事件的触发方式。

图1-21　不同输入设备上焦点事件的触发方式

4. 拖拽事件

拖拽事件发生在两个组件之间，它不是简单的单次输入，而是一个”过程”，通常包含以下步骤（以将组件A拖拽到组件B中为例）。

• 长按或点击组件A，触发拖拽。

• 保持按压或点击，持续将组件A向组件B拖拽。

• 抵达组件B中，释放按压点击，完成拖拽。

• 也可以在未抵达组件B时，释放按压点击，取消拖拽。

图1-22所示为不同输入设备上拖拽事件的触发方式。

图1-22　不同输入设备上拖拽事件的触发方式

1.3.3.4 资源文件

在界面开发过程中，经常需要用到颜色、字体、间距、图片等资源，这些资源的值在不同的设备或配置中可能不同。资源文件有两种应用方式。

• 自定义资源：借助资源文件能力，开发者可以在应用中自定义资源，自行管理这些资源在不同的设备或配置中的表现。

• 直接使用系统资源：开发者直接使用系统预置的资源。

图1-23所示为开发者分别在默认设备和平板计算机（平板计算机的限定词子目录）上创建相应的应用资源及其运行效果，可以发现，同一资源在不同设备上的取值不同。

图1-23　多设备资源访问效果示意

除了自定义资源，开发者也可以直接使用系统中预定义的资源（即分层参数，同一资源ID在设备类型、深浅色等不同配置下有不同的取值）。

在开发过程中，分层参数的用法与资源限定词基本一致。开发者可以通过"$r('sys.type.resource_id')"的形式引用系统资源。sys代表系统资源；type代表资源类型，值可以为color、float、string和media；resource_id代表资源id。

1.3.3　多设备功能开发

应用开发一般包含两部分工作：UI页面开发和底层功能开发；部分需要联网的应用还会涉及服务端开发。前文介绍了如何解决界面适配的问题，本小节主要介绍应用开发时如何解决多设备系统能力差异的兼容问题。

1. 系统能力

与系统能力相关的3个核心概念为支持能力集、联想能力集和要求能力集。

• 支持能力集：设备具备的系统能力集合，在设备配置文件中配置。

• 要求能力集：应用需要的系统能力集合，在应用配置文件中配置。

• 联想能力集：开发应用时DevEco Studio可联想的API所在的系统能力集合，在应用配置文件中配置。

2. 多设备应用开发

开发多设备应用时，工程中默认的要求能力集是多个设备支持能力集的交集，默认的联想能力集是多个设备支持能力集的并集。只有当应用要求能力集是设备支持能力集的子集的时候，应用才可以在该设备上分发、安装和运行。

如果某个系统能力没有写入应用的要求能力集，那么开发者在使用前需要通过canIUse()接口判断该设备是否支持某个特定的系统能力。

    if (canIUse('SystemCapability.Communication.NFC.Core')) { 
      hilog.info(0x0000, 'Index', `该设备支持SystemCapability.Communication.
    NFC.Core`); 
    } else { 
      hilog.error(0x0000, 'Index', `该设备不支持SystemCapability.Communication.
    NFC.Core`); 
    }

DevEco Studio会根据创建的工程所支持的设备自动配置联想能力集和要求能力集，同时也支持开发者自行修改联想能力集和要求能力集。

    //syscap.json 
    { 
        "devices":{
            "general":[             
                "default", 
                "tablet" 
            ], 
            "custom":[             
                { 
                    "Custom Device":[ 
                        "SystemCapability.Communication.SoftBus.Core" 
                    ] 
                } 
            ] 
        }, 
        "development":{              
            "addedSysCaps":[
                "SystemCapability.Communication.NFC.Core" 
            ] 
        }, 
        "production":{               
            "addedSysCaps":[],       
            "removedSysCaps":[]      
        } 
    }

鸿蒙操作系统通过SysCap机制，会从应用开发、应用分发、应用下载、应用安装、应用运行等环节对系统能力进行拦截或管控，保证应用在设备上正常安装和使用。

• 应用分发和应用下载：只有当应用的要求能力集是设备支持能力集的子集时（即设备满足应用运行要求），应用才可以分发到该设备。

• 应用安装：只有当应用的要求能力集是设备支持能力集的子集时，应用才可以安装到该设备。

• 应用运行：应用在使用要求能力集之外的能力前，需要动态判断相应系统能力的有效性，防止崩溃或功能异常等问题。

1.4 应用构建

1.4.1　多目标产物构建

多目标产物在鸿蒙操作系统系统中的应用主要体现在应用开发与应用分发环节，特别是针对不同用户群体、不同业务场景的需求进行定制化开发。多目标产物为开发者提供了灵活和高效的开发方式，使得应用能够更好地适应市场的需求和变化。通过定制化开发，还可以更好地满足用户的个性化需求，提升用户体验。

• target：对应HAR、HSP、HAP的多目标产物。工程内的每一个模块均可以定义多个target，每个target对应一个定制的HAP和HAR，通过配置可以实现一个模块构建出不同的HAP、HAR。

• product：对应APP的多目标产物。一个鸿蒙操作系统工程的构建产物为APP包，一个工程可以定义多个product，每个product对应一个定制化APP包，通过配置可以实现一个工程构建出多个不同的APP包。

在多目标产物的构建过程中，鸿蒙构建系统会根据配置文件中定义的product和target信息，生成相应的构建产物。对于每个target，构建系统会生成对应的HAP、HSP、HAR。HAP、HSP、HAR包含了该target所需的所有代码和资源。对于每个product，构建系统会生成一个包含了其所有依赖的target的APP包。这个APP包可以用于发布和上架应用市场。

开发者需要首先通过修改build-profile.json5、module.json5等配置文件，定义出不同的product和target。在这些配置文件中，开发者不仅可以为每个target指定不同的设备类型、源码集、资源等，还可以根据业务需要为不同的product分配不同的target。然后在构建过程中，构建工具会根据这些配置生成不同的target。最后通过不同的target搭配构建出不同的product。

1. 实现原理

鸿蒙操作系统多目标产物支持HAP（应用安装的基本单位，每个HAP都对应一个应用模块）、HAR、HSP以及APP（由多个HAP打包一起上架的完整应用程序）等多种类型的包，以满足不同业务场景下的应用开发和定制需求。目前，多目标产物支持的定制项信息如表1-9所示。

表1-9　多目标产物支持的定制项信息表

综上所述，APP、HAP、HAR、HSP目前并不支持配置所有配置项的差异化定制。开发者在开发过程中需要根据已支持的配置项进行合理的多目标定制。

2. 构建原理图

多目标产物的构建原理如图1-24所示。首先，每个HAR/HAP/HSP模块可以通过配置模块级的build-profile.json文件定义多个target，每个target可以定制不同的资源，从而形成了具有差异性的target。例如Module A通过定制生成了TargetA-1、TargetA-2；Module B通过定制生成了TargetB-1、TargetB-2、TargetB-3；Module C通过定制生成了TargetC-1、TargetC-2。

图1-24　多目标产物的构建原理图

然后，通过配置工程级的build-profile.json定义多个product，每个product可以依赖不同的target并且配置不同的APP产物定制项，从而形成了具有差异的product。例如依赖TargetA-1、TargetB-1、TargetC-1构建出App-product1；依赖TargetB-3、TargetC-2构建出App-product2。

最后，在构建工程时选择相应的product就可以显示出对应的定制效果。

1.4.2　扩展构建能力

在进行编译构建的过程中，开发者可以通过定制hvigor插件，扩展构建逻辑，实现个性化的打包流程。通过定制hvigor插件，可以支持根据不同的构建需求调整编译产物属性，从而实现灵活的构建管理。

定制hvigor插件的原理如图1-25所示。开发者在编译构建的过程中插入自定义任务，并将这些自定义任务抽象后封装成可复用的部分，通过输出plugin插件的目标形式，实现编译构建个性化逻辑的复用和共享分发，具体流程如下。

• 开发者编写自定义插件plugin，在插件中自定义任务Task，在项目构建脚本中应用插件。

• hvigor-ohos-plugin将默认构建任务和自定义插件任务都装进hvigor任务流。

• hvigor任务流按序执行的过程中，hvigor在节点处检查，如果有自定义任务注册，执行相应的自定义任务逻辑。

图1-25　定制hvigor插件的原理

定制hvigor插件主要有两种方式，这两种方式的核心逻辑类似，都采用以TS文件编写Task任务的方法，主要区别体现在共享和应用方式上。二者的对比如表1-10所示：

表1-10 定制hvigor插件的两种方式的对比

1.5 三方库开发

1.5.1　能力概述

鸿蒙三方库（简称三方库）是由OpenHarmony社区或第三方开发者贡献、遵循开源协议、可被鸿蒙应用复用的软件组件集合，助力开发者提升鸿蒙应用的开发效率。

目前，三方库已覆盖UI组件、安全、工具库等多个技术领域，如表1-11所示，并通过三方库中心仓OHPM进行分发和管理。

• 三方库以HAR的形态呈现，HAR产物分为包含源码的HAR、包含js中间码的HAR以及包含字节码的HAR 3种格式，也可以包含资源和配置等文件。

• 通过三方库HAR可以实现多个模块或多个工程共享ArkUI组件、资源等。

表1-11　典型的三方库

1.5.2　开发三方库

1.5.2.1 基于ArkTS语言开发三方库

1. 创建库模块

在工程中添加模块时，需要在Choose Your Ability Template界面中选择Static Library。创建完成后，会在工程目录中生成库模块及相关文件，如图1-26所示。

图1-26　工程目录中的库模块及相关文件

2. 编译库模块

开发完库模块后，首先选中模块名，然后通过DevEco Studio菜单栏的Build> Make Module${libraryName}进行编译构建，生成HAR。HAR可用于工程中的其他模块的引用，或将HAR上传至ohpm仓库，供其他开发者下载使用。编译构建的HAR可在模块下的build目录下获取，包格式为*.har。

在编译构建HAR时，需要注意以下事项。

• 编译构建HAR的过程中，不会将模块中的C++代码直接打包进.har文件，而是将C++代码编译成动态依赖库.so文件，并放置在.har文件中的libs目录下。

• 在编译构建HAR的过程中，会生成资源文件ResourceTable.txt，以便编辑器可以对HAR中的资源文件进行联想。因此，如果不使用DevEco Studio对HAR进行构建，则DevEco Studio的编辑器无法联想HAR中的资源。

• 如果使用的Hvigor为2.5.0-s及以上版本，如果在打包后发现缺少部分本地依赖（如cpp/types目录），是因为dependencies内处于本模块路径下的本地依赖未被打包进.har文件中。

1.5.2.2 基于C/C++语言开发三方库

基于C/C++语言开发三方库的流程如图1-27所示。

图1-27　基于C/C++语言开发三方库的流程

1. 三方库依赖分析

通过扫描工具扫描三方库是否有对NDK、OpenGL等鸿蒙不支持接口的依赖。扫描时可以使用OpenHarmony-SIG社区tpc_c_cplusplus仓提供的依赖分析工具。该工具的用法如下。

进入工具的e2e/thirdparty_compare目录，执行以下命令：

    python main.py-f thirdPartLibDir –b blackListDir(optional) –g greyListDir (optional) –d outputPath(optional)

• -f：输入存放三方库文件夹的上层路径。

• -b：可选，输入黑名单excel表格存放路径（默认./back_list）。

• -g：可选，输入灰名单excel表格存放路径（默认./grey_list）。

• -d：可选，文件输出路径（默认./out）。

2. 三方库的移植开发

将开发三方库源码或新开发的C/C++代码放在cpp文件夹下，如图1-28所示。

3. 三方库的编译构建

三方库的编译构建方式主要包括cmake、configure、make和lycium 4种。

图1-28　三方库移植代码文件目录

（1）cmake 构建方式

步骤一：新建编译目录。

为了不污染源码目录文件，我们推荐在三方库源码目录中新建一个编译目录，用于生成需要编译的配置文件。本例中在cJSON目录下新建一个build目录：

    mkdir build && cd build            ## 创建编译目录并进入     编译目录

步骤二：配置交叉编译参数，生成Makefile。

    /home/owner/workspace/ohos-sdk/linux/native/build-tools/cmake/bin/cmake -DCMAKE_TOOLCHAIN_FILE=//home/owner/workspace/ohos-sdk/linux/native/build/cmake/ohos.toolchain.cmake -DCMAKE_INSTALL_PREFIX=/home/owner/workspace/usr/cJSON -DOHOS_ARCH=arm64-v8a .. -L

注意，这里执行的cmake必须是三方库内的cmake，不是系统中原有的cmake，否则无法识别参数OHOS_ARCH。

步骤三：执行编译并安装。

    make && make install              ## 执行make命令进行编译，成功后将编译产物安装到DCMAKE_INSTALL_PREFIX指定的路径

（1）configure构建方式

步骤一：查看configure配置。

进入源码目录，执行以下命令查看原库的一些配置与属性：

    ./configure --help

步骤二：配置交叉编译命令，在命令行输入以下命令，具体的配置需要参照./configure --help给出的信息：

    export OHOS_SDK=XX               ## 配置SDK路径，此处需配置成自己的sdk解压目录 
    export AS=XX 
    export CC="XX"                   ## 32bit的target需要配置成 --target=arm-linux-ohos 
    export CXX="XX"                  ## 32bit的target需要配置成 --target=arm-linux-ohos 
    export LD=XX 
    export STRIP=XX 
    export RANLIB=XX 
    export OBJDUMP=XX 
    export OBJCOPY=XX 
    export NM=XX 
    export AR=XX 
    export CFLAGS="-fPIC-D__MUSL__=1"        ## 32bit需要增加配置 -march=armv7a 
    export CXXFLAGS="-fPIC-D__MUSL__=1"      ## 32bit需要增加配置 -march=armv7a

步骤三：执行configure命令，生成makefile：

    ./configure--prefix=XX/--host=XX       ## 执行configure命令配置交叉编译信息, 具体的参数配置也需要参照./configure--help给出的信息

步骤四：执行编译并安装：

    make && make install                   ## 执行make命令进行编译，成功后将编译产物安装到--prefix指定的路径

（3）make 构建方式

步骤一：分析Makefile文件，确定需要配置的编译命令，一般有以下几个编译命令（每个库可能会有差异）：

    #To assist in cross-compiling 
    CC=gcc 
    AR=ar 
    RANLIB=ranlib 
    LDFLAGS=

步骤二：配置交叉编译命令，执行交叉编译：

    make CC="XX--target=XX" AR=XX

特别说明：CC除了配置交叉编译的clang外，还需要配置target的架构，即配置成aarch64位，按此配置编译出来的文件才能在64位设备上运行。若需要编译32位的文件，则target配置成arm-linux-ohos即可。

步骤三：安装。

    make install --prefix=XX

（4）lycium构建方式

为了帮助开发者快速、便捷地完成C/C++三方库的交叉编译，三方库社区提供了一套交叉编译框架lycium，其涵盖了以上3种构建方式。lycium构建三方库的步骤如图1-29所示。

图1-29　lycium构建三方库的步骤

步骤一：配置OHOS_SDK：

    export OHOS_SDK=XX      ## 此处SDK的路径使用者需配置成自己
的sdk解压目录

步骤二：编写HPKBUILD文件，此文件主要体现每个库的差异性，需放入thirdparty目录，具体配置信息如表1-12所示。

步骤三：编写完HPKBUILD文件并放入指定目录后，可以直接执行build.sh 库名进行自动构建：

    build.sh 库名           # 库名需和HPKBUILD文件中的pkgname
保持一致

表1-12　HPKBUILD文件的配置信息

1.5.3　使用三方库

使用三方库时，包括从仓库进行安装和从本地库模块中进行安装两种方式。

1. 使用仓库安装的HAR

使用ohpm仓库中的HAR时，首先需要设置三方库信息。DevEco Studio默认仓库地址为三方库中心仓。如果想设置自定义仓库，需要在DevEco Studio的Terminal窗口执行如下命令进行设置。执行命令前，确保将DevEco Studio中ohpm仓库的安装地址配置在“环境变量→系统变量→PATH”中（ohpm支持多个仓库地址，采用英文逗号分隔）。

    ohpm config set registry your_registry1,your_registry2

配置三方库依赖信息有以下3种方式。

• 方式一：在菜单栏单击Tools>OHPM Index，进入DevEco Studio内置的三方库中心仓，选择需要的三方库。

• 方式二：在Terminal窗口中，切换到需要引入三方库的模块，如entry模块，执行如下命令安装三方库，DevEco Studio会自动在该模块的oh-package.json5中添加三方库依赖。

    cd path/to/your/project/entry
    ohpm install @ohos/lottie

• 方式三：在需要引入三方库模块的oh-package.json5中设置三方库依赖，配置示例如下：

    "dependencies": {
    "@ohos/lottie":"^2.0.0"
    }

依赖设置完成后，需要执行ohpm install命令安装依赖包。依赖包会存储在工程的oh_modules目录下。

    ohpm install

2. 使用本地库模块的文件和资源

方式一：在Terminal窗口中，执行如下命令进行安装，会在oh-package5.json中自动添加依赖。

    ohpm install ../library

方式二：在工程的oh-package.json5中设置三方库依赖，配置示例如下：

    "dependencies":{
    "@ohos/library":"file:../library"
    }

依赖设置完成后，需要执行ohpm install命令安装依赖包，依赖包会存储在工程的oh_modules目录下。

    ohpm install