1. 从“工具孤岛”到“能力网络”为什么我们需要动态能力注册表在鸿蒙生态里搞开发不知道你有没有遇到过这种场景你精心封装了一个特别好用的工具库比如一个能智能压缩图片的组件或者一个能解析复杂JSON的轻量级工具。你把它打包成HARHarmonyOS Ability Resources或者HSPHarmonyOS Shared Package然后告诉团队“兄弟们好东西在这儿拿去用”结果呢要么是大家不知道有这玩意儿要么是版本满天飞A项目用了v1.2B项目还在用v0.9出了问题排查起来像在考古。这其实就是典型的“工具孤岛”现象。工具本身是好的但它没有被有效地“发现”和“管理”。在大型应用或者跨团队协作中这个问题会被无限放大。想象一下一个电商App商品详情页需要一个“智能推荐”能力购物车需要一个“优惠券计算”能力支付模块需要一个“风控校验”能力。如果这些能力都以静态库的形式硬编码在各个模块里那么当“智能推荐”算法升级或者“风控校验”规则变更时你就需要去修改所有引用了这些能力的地方然后重新编译、测试、发布。这不仅是效率问题更是稳定性的噩梦。所以我们需要的不是一个个散落的工具而是一个能让工具“活”起来的机制。这就是“动态能力注册表”要解决的核心问题。它的目标是把静态的、编译时绑定的工具变成动态的、运行时可被发现和调用的“能力”。你可以把它理解为一个微型的、应用内的“服务注册与发现中心”只不过它管理的不是远程的微服务而是你应用内部一个个封装好的功能单元Ability。这个想法其实并不新鲜在服务端开发中Eureka、Nacos这样的组件早已是微服务架构的基石。但在客户端尤其是在鸿蒙这样的跨端操作系统上实现一个轻量、高效、符合鸿蒙设计哲学的动态能力管理机制就非常有挑战性也极具价值。它能让你的应用架构从“巨石应用”向“模块化”、“服务化”平滑演进为后续实现热更新、动态加载、甚至端侧AI Agent的灵活调度都打下了坚实的基础。接下来我们就深入鸿蒙的底层看看如何亲手搭建这样一个“能力网络”。2. 鸿蒙动态能力注册表的核心设计蓝图要构建一个可用的动态能力注册表我们不能只停留在概念上必须拿出一套具体、可落地的设计方案。这套方案需要紧密贴合鸿蒙系统的特性同时解决前面提到的发现、管理、调用问题。我设计了一个三层架构它包含了注册中心、能力网关和客户端SDK下面我们来逐一拆解。2.1 核心组件注册中心Registry Center注册中心是整个系统的大脑负责能力的“户口管理”。它必须是一个单例在应用生命周期内全局唯一。我选择使用鸿蒙的Preferences持久化能力来实现因为它轻量、异步、且支持跨进程访问需配置非常适合存储这些元数据。一个能力在注册时需要提供哪些信息呢这决定了注册表的“智商”。我定义了以下几个核心字段能力唯一标识AbilityId 类似com.example.image.compressor这样的反向域名格式确保全局唯一。版本号Version 遵循语义化版本规范如1.2.0这是实现多版本共存和灰度升级的关键。提供方信息Provider 指明这个能力来自哪个HAR/HSP包甚至是远程地址为未来扩展预留。能力描述与元数据Metadata 这是一个JSON对象用于描述能力的用途、输入输出参数格式、性能指标、依赖关系等。例如一个图片压缩能力其元数据可能包含{“inputTypes”: [“image/jpeg”, “image/png”], “outputQuality”: [0.1, 1.0], “maxSize”: “10MB”}。这部分信息是动态发现和智能匹配的基础。状态StatusENABLED可用、DISABLED禁用、DEPRECATED已弃用。用于能力的生命周期管理。在内存中我会用一个Mapstring, AbilityDescriptor来维护所有已注册能力的描述符对象以保证查询效率。同时所有变更都会持久化到Preferences中。这里有一个关键设计注册操作应该是幂等的。即多次注册同一个AbilityId和Version的能力结果应该和注册一次相同。这保证了在应用启动或模块加载时可以安全地重复调用注册逻辑。2.2 通信桥梁能力网关Ability Gateway有了注册中心客户端如何调用这些能力呢直接让调用方去注册中心查然后硬编码调用这又回到了老路。我们需要一个抽象的中间层——能力网关。网关的核心职责是路由与协议转换。调用方不需要知道能力具体在哪里、如何实现它只需要向网关发起一个标准的请求。我设计了一个通用的请求体{ “abilityId”: “com.example.image.compressor”, “version”: “^1.0.0”, // 支持语义化版本范围 “action”: “compress”, “params”: { “imageData”: “base64String...”, “quality”: 0.8 }, “callbackId”: “uuid-for-async-response” // 用于异步回调 }网关接收到请求后会执行以下流程路由解析 根据abilityId和version去注册中心查找匹配的能力描述符。这里版本匹配是个学问^1.0.0表示匹配1.x.x(x0) 的最新版本这允许我们在不修改调用方代码的情况下升级能力的小版本。负载均衡与熔断进阶 如果同一个能力有多个实例比如来自不同包网关可以实现简单的负载均衡策略。同时可以集成基础的熔断器当某个能力连续调用失败时暂时将其标记为不可用避免雪崩。协议调用 这是最核心的一步。鸿蒙中Ability之间主要通过FeatureAbility或ParticleAbility进行调用。对于同进程内的能力我们可以直接通过反射或接口调用性能最高。对于跨进程能力则必须封装成Intent通过startAbility或callAbility来通信。网关需要根据能力描述符中的Provider信息决定采用哪种调用方式并对调用方透明。结果返回 将能力执行的结果或错误信息封装成标准响应体返回给调用方。注意 网关的设计要力求“薄”它不应该包含业务逻辑。它的复杂度应该集中在路由、协议适配和容错上。业务逻辑应该完全由后端的能力提供者负责。2.3 开发体验客户端SDKClient SDK为了降低使用门槛我们必须提供一个友好的客户端SDK。这个SDK的目标是让开发者以最自然的方式使用动态能力就像调用本地函数一样。1. 能力使用方SDK对于调用方我们可以利用TypeScript/ArkTS的装饰器或代码生成技术提供类型安全的调用体验。理想的使用方式是这样的// 开发者声明要使用的能力 AbilityConsumer({ abilityId: “com.example.image.compressor”, version: “^1.0.0” }) class MyImageService { // SDK在背后生成代理代码将此方法调用路由到网关 async compressImage(base64Data: string, quality: number): PromiseArrayBuffer { // 实际调用由SDK注入的代码完成 } } // 使用时 const imageService new MyImageService(); const compressedData await imageService.compressImage(originalData, 0.7);SDK在编译时或运行时会根据装饰器信息生成与网关通信的实际代码并处理序列化、反序列化、异步回调等脏活累活。2. 能力提供方SDK对于能力提供者SDK需要简化注册和暴露接口的过程。// 实现一个能力 AbilityProvider({ abilityId: “com.example.image.compressor”, version: “1.0.0” }) class ImageCompressorAbility implements IAbility { async onCall(action: string, params: any): Promiseany { if (action ‘compress’) { return await this.doCompress(params.imageData, params.quality); } throw new Error(Unsupported action: ${action}); } private doCompress(...){ /* 实际压缩逻辑 */ } } // 在模块入口处一行代码注册所有被AbilityProvider装饰的能力 AbilityRegistry.autoRegisterAll();提供方SDK会自动收集所有装饰的类在合适的时机如模块加载时向注册中心完成注册。2.4 数据流转与持久化设计动态能力的信息不能只存在于内存中否则应用重启就全丢了。我们需要一个可靠的持久化方案。如前所述Preferences是首选但它存储的是键值对我们需要存储结构化的能力描述符列表。我的做法是将整个能力描述符列表序列化为一个JSON数组以单个键值对的形式存入Preferences。虽然每次更新都需要读写整个列表但在能力数量不多几十到几百个的情况下性能是可以接受的。为了优化可以引入一个简单的内存缓存并只在列表发生变化时才执行持久化操作。数据的流转路径如下注册 能力提供方调用SDK - SDK将描述符提交给注册中心 - 注册中心更新内存Map - 异步将整个Map序列化后写入Preferences。发现 调用方通过网关查询 - 网关向注册中心请求 - 注册中心直接从内存Map中返回结果极速响应。注销/更新 类似注册流程更新内存状态后触发持久化。这个设计保证了核心操作查询的高性能同时通过异步持久化平衡了数据可靠性和写入性能。3. 在鸿蒙应用中的具体实现与集成步骤设计图有了接下来我们就要动手把它变成跑在鸿蒙设备上的真实代码。这一部分我会带你一步步搭建这个动态能力注册表并把它集成到一个示例应用中。我们假设要为一个“智能相册”应用添加动态能力支持该应用包含一个主App和多个功能HAR包。3.1 第一步搭建基础框架模块Core Registry Module首先我们创建一个独立的HAR模块比如叫dynamic-ability-registry它将包含注册中心、网关的核心逻辑以及公共的数据模型。1. 定义数据模型AbilityDescriptor在ets/common/目录下创建AbilityDescriptor.ets。// AbilityDescriptor.ets export interface AbilityDescriptor { abilityId: string; // 唯一标识如 “com.xxx.image.compress” version: string; // 语义化版本如 “1.0.0” provider: ProviderInfo; // 提供者信息 metadata: Recordstring, any; // 能力元数据 status: AbilityStatus; // 状态 registerTime: number; // 注册时间戳 } export interface ProviderInfo { packageName: string; // HAR包名 moduleName?: string; // 模块名 location: ‘local’ | ‘remote’; // 位置先实现local uri?: string; // 如果是remote提供地址 } export enum AbilityStatus { ENABLED ‘enabled’, DISABLED ‘disabled’, DEPRECATED ‘deprecated’ }2. 实现注册中心AbilityRegistryImpl在ets/core/目录下创建AbilityRegistryImpl.ets。这里使用鸿蒙的Preferences和util中的LRUCache或自己实现一个简单的Map缓存。// AbilityRegistryImpl.ets import preferences from ‘ohos.data.preferences’; import util from ‘ohos.util’; const PREF_KEY ‘dynamic_abilities’; const PREF_NAME ‘dynamic_ability_registry’; export class AbilityRegistryImpl { private abilityMap: Mapstring, AbilityDescriptor new Map(); // 内存缓存 private preferences: preferences.Preferences | null null; // 单例模式 private static instance: AbilityRegistryImpl; static getInstance(): AbilityRegistryImpl { if (!this.instance) { this.instance new AbilityRegistryImpl(); } return this.instance; } private constructor() { this.initPreferences(); } private async initPreferences() { try { // 获取Preferences实例context需要从使用方传递或通过globalThis获取需谨慎 let context ...; // 如何获取全局Context是一个关键点下文会讲 this.preferences await preferences.getPreferences(context, PREF_NAME); await this.loadFromPreferences(); } catch (err) { console.error(‘[AbilityRegistry] Failed to init preferences:’, err); } } private async loadFromPreferences() { if (!this.preferences) return; const abilitiesJson await this.preferences.get(PREF_KEY, ‘[]’); try { const list: AbilityDescriptor[] JSON.parse(abilitiesJson); list.forEach(desc { const key ${desc.abilityId}${desc.version}; this.abilityMap.set(key, desc); }); console.log([AbilityRegistry] Loaded ${this.abilityMap.size} abilities from disk.); } catch (e) { console.error(‘[AbilityRegistry] Failed to parse abilities JSON:’, e); } } private async persistToPreferences() { if (!this.preferences) return; const list Array.from(this.abilityMap.values()); const abilitiesJson JSON.stringify(list); await this.preferences.put(PREF_KEY, abilitiesJson); await this.preferences.flush(); // 提交更改 } // 核心注册方法 async registerAbility(descriptor: AbilityDescriptor): Promiseboolean { const key ${descriptor.abilityId}${descriptor.version}; if (this.abilityMap.has(key)) { console.log([AbilityRegistry] Ability ${key} already registered.); return true; // 幂等性处理 } descriptor.registerTime Date.now(); this.abilityMap.set(key, descriptor); await this.persistToPreferences(); console.log([AbilityRegistry] Registered ability: ${key}); return true; } // 查询方法 async findAbility(abilityId: string, versionRange?: string): PromiseAbilityDescriptor | null { // 这里简化处理实际需要实现语义化版本匹配 // 例如查找 abilityId 匹配且版本符合 versionRange 的最新版本 const matched Array.from(this.abilityMap.values()) .filter(d d.abilityId abilityId d.status AbilityStatus.ENABLED) .sort((a, b) this.compareVersion(b.version, a.version)); // 降序取最新 if (matched.length 0) { // 如果提供了versionRange需要进一步过滤 return matched[0]; } return null; } private compareVersion(v1: string, v2: string): number { // 简单的版本号比较实现实际应用需更严谨 const parts1 v1.split(‘.’).map(Number); const parts2 v2.split(‘.’).map(Number); for (let i 0; i 3; i) { if (parts1[i] ! parts2[i]) { return parts1[i] - parts2[i]; } } return 0; } }关键踩坑点全局Context获取。在HAR模块中你无法直接使用getContext()。一个常见的做法是在应用主入口EntryAbility初始化时将context通过一个全局管理器如globalThis或一个单例设置进去然后注册中心模块从这个管理器获取。但这需要主应用和HAR模块约定好。更优雅的方式是注册中心的初始化方法init(context: Context)需要由主应用显式调用。3.2 第二步实现轻量级能力网关AbilityGateway网关相对独立我们把它放在同一个HAR模块的ets/gateway/目录下。// AbilityGateway.ets import { AbilityRegistryImpl } from ‘../core/AbilityRegistryImpl’; import { AbilityDescriptor } from ‘../common/AbilityDescriptor’; export interface AbilityRequest { abilityId: string; version?: string; // 可选不指定则用最新 action: string; params: Recordstring, any; timeout?: number; // 超时时间 } export interface AbilityResponse { success: boolean; data?: any; error?: { code: string; message: string; }; } export class AbilityGateway { private registry AbilityRegistryImpl.getInstance(); async callAbility(request: AbilityRequest): PromiseAbilityResponse { // 1. 查找能力 const descriptor await this.registry.findAbility(request.abilityId, request.version); if (!descriptor) { return { success: false, error: { code: ‘ABILITY_NOT_FOUND’, message: Ability ${request.abilityId} not found. } }; } // 2. 根据Provider类型决定调用方式 if (descriptor.provider.location ‘local’) { // 本地调用同进程或同包 return await this.callLocalAbility(descriptor, request); } else { // 远程调用未来扩展 return await this.callRemoteAbility(descriptor, request); } } private async callLocalAbility(descriptor: AbilityDescriptor, request: AbilityRequest): PromiseAbilityResponse { // 这是最复杂的部分需要根据元数据信息动态调用本地代码。 // 方案A约定能力提供者实现一个标准接口并通过某种工厂或DI容器获取实例。 // 方案B使用鸿蒙的“动态导入”dynamic import或“本地共享包”HSP的机制来加载模块。 // 这里以方案A为例假设我们有一个全局的“本地能力工厂”。 try { const abilityInstance LocalAbilityFactory.getInstance().create(descriptor.abilityId); if (!abilityInstance || typeof abilityInstance.onCall ! ‘function’) { throw new Error(‘Invalid ability implementation.’); } const result await abilityInstance.onCall(request.action, request.params); return { success: true, data: result }; } catch (err) { console.error([Gateway] Failed to call local ability ${descriptor.abilityId}:, err); return { success: false, error: { code: ‘EXECUTION_FAILED’, message: err.message } }; } } // LocalAbilityFactory 需要能力提供方SDK来配合注册实现类 }本地调用的具体实现是网关的难点。LocalAbilityFactory可以是一个简单的Map存储abilityId到构造函数的映射。能力提供方在初始化时需要向这个工厂注册自己。3.3 第三步开发供能力提供方使用的SDKProvider SDK为了让能力提供方方便地暴露能力我们创建一个provider-sdkHAR模块或作为上述核心模块的一部分。// decorators.ets // 提供方装饰器 export function AbilityProvider(options: { abilityId: string; version: string; metadata?: Recordstring, any }) { return function (constructor: new () any) { // 将装饰的类信息暂存起来等待注册 AbilityProviderManager.register(constructor, options); }; } // AbilityProviderManager.ets export class AbilityProviderManager { private static classMap: Mapnew () any, any new Map(); static register(clazz: new () any, options: any) { this.classMap.set(clazz, options); } static async registerAll(context: common.Context) { const registry AbilityRegistryImpl.getInstance(); for (const [Clazz, options] of this.classMap.entries()) { const descriptor: AbilityDescriptor { abilityId: options.abilityId, version: options.version, provider: { packageName: context.applicationInfo.name, // 从context获取包名 moduleName: ‘*’, // 需要更精确的模块名 location: ‘local’, }, metadata: options.metadata || {}, status: AbilityStatus.ENABLED, registerTime: 0, }; await registry.registerAbility(descriptor); // 同时向 LocalAbilityFactory 注册 LocalAbilityFactory.getInstance().register(options.abilityId, Clazz); } } }能力提供方在自己的HAR入口文件如index.ets中只需要调用一行代码// 在提供方HAR的初始化方法中 import { AbilityProviderManager } from ‘dynamic-ability-registry’; export function initProvider(context: common.Context) { AbilityProviderManager.registerAll(context); }3.4 第四步在主应用中集成与初始化最后我们需要在主应用的EntryAbility的onCreate阶段完成整个动态能力注册表系统的初始化。// EntryAbility.ets import { AbilityRegistryImpl } from ‘ohos/dynamic-ability-registry’; import { AbilityGateway } from ‘ohos/dynamic-ability-registry’; import { initProvider as initImageTools } from ‘ohos/image-tools-har’; // 假设的图片工具HAR export default class EntryAbility extends Ability { onCreate(want: Want, launchParam: AbilityConstant.LaunchParam) { // 1. 初始化注册中心传入全局Context AbilityRegistryImpl.getInstance().init(this.context); // 2. 初始化各个能力提供方HAR initImageTools(this.context); // 3. 将网关实例挂载到全局方便各模块使用 globalThis.abilityGateway new AbilityGateway(); console.log(‘[EntryAbility] Dynamic Ability Registry initialized.’); } }至此一个基础的、可在鸿蒙应用内运行的动态能力注册表就搭建完成了。它包含了核心的注册、发现和调用链路。当然这只是一个起点一个可用的原型。在实际生产环境中我们还需要考虑更多。4. 生产环境进阶性能、安全与运维考量一个玩具级的注册表和能扛住生产环境流量的系统之间隔着无数个“坑”。当我们把动态能力注册表部署到用户量庞大的鸿蒙应用时以下几个方面的考量就变得至关重要。4.1 性能优化让动态发现快如静态绑定动态调用的开销主要来自两部分查找路由和协议转换/反射调用。我们的目标是让这个开销尽可能小小到与直接函数调用在一个数量级。1. 注册表查询优化内存中的Map查询已经是O(1)但版本匹配逻辑可能成为瓶颈。当同一个abilityId有数十个历史版本时遍历过滤排序的代价就大了。我的优化策略是引入二级索引。第一级索引MapabilityId, SortedSetDescriptor。以abilityId为键值是一个按版本号降序排列的Descriptor集合可以使用数组二分查找维护。查询时先通过abilityIdO(1) 找到集合再在有序集合中快速匹配出版本范围要求的最新版本。这比遍历所有能力描述符高效得多。2. 本地调用性能压榨反射调用Reflect或动态构造实例的性能远低于直接调用。为此我引入了“能力代理缓存”。在网关的LocalAbilityFactory中不仅存储构造函数还为每个abilityIdversion缓存一个单例的能力实例如果该能力是无状态的。更进一步可以使用代码生成技术如编译时注解处理在编译期为每个被AbilityProvider装饰的类生成一个静态的调用桩Stub。网关不再需要通过字符串查找和反射而是直接调用生成的桩代码性能几乎与静态绑定无异。这是从“动态”向“静态”的一种妥协但带来了巨大的性能提升。3. 异步操作的并发控制能力调用可能是耗时的I/O操作如图片处理、网络请求。网关需要管理一个线程池或任务队列避免阻塞主线程或UI线程。鸿蒙提供了TaskPool或Worker进行后台任务处理。网关可以将耗时能力调用封装成任务提交到TaskPool中执行并通过Promise或回调通知调用方结果。4.2 安全与权限守住能力的边界动态加载和执行代码是强大的也是危险的。我们必须建立严格的安全沙箱。1. 能力签名与验签每个能力提供方HAR在打包时必须使用开发者的私钥对其代码和元数据进行签名。注册中心在注册能力时需要验证签名的有效性确保能力来自可信的提供方且在传输过程中未被篡改。鸿蒙应用本身就有签名机制我们可以复用这套体系要求能力HAR的签名必须与主应用签名一致或者来自一个预置的白名单。2. 权限声明与校验能力可能涉及敏感操作如访问相册、读取地理位置、使用网络等。在能力的元数据metadata中必须显式声明其所需的权限列表如[“ohos.permission.INTERNET”, “ohos.permission.LOCATION”]。静态校验在注册阶段注册中心可以检查声明的权限是否被主应用在config.json中声明。如果能力申请了主应用未声明的权限则注册失败。动态校验在网关调用能力前根据能力声明的权限动态调用鸿蒙的abilityAccessCtrl接口检查当前上下文是否已授予这些权限。如果权限不足则直接拒绝调用返回错误。3. 输入验证与沙箱隔离网关作为统一的入口必须对所有输入参数进行严格的验证防止注入攻击。可以根据元数据中定义的参数模式Schema进行校验。对于执行不可信第三方能力的场景理论上应避免可以考虑使用更严格的隔离机制例如将能力运行在独立的Worker线程中限制其内存和CPU使用并拦截其所有的系统API调用。4.3 可观测性与运维让系统透明可控系统上线后我们绝不能是“瞎子”。必须有一套完善的监控和运维手段。1. 全面的日志与指标收集在注册中心、网关的关键路径上打点日志记录能力注册、发现、调用的成功与失败。更重要的是收集运行时指标调用量每个能力的QPS。耗时P50、P90、P99的调用延迟。错误率调用失败的比例。资源使用能力执行时的内存、CPU占用如果可能。 这些指标可以通过鸿蒙的HiTrace链路上报或者集成轻量级的Metrics库定期输出到日志文件或上报到服务端。2. 动态配置与热管理注册表不应该只是一个静态数据库。它应该支持动态配置。我们可以设计一个简单的管理接口通过Settings或一个内部管理页面允许运维人员在不重启应用的情况下禁用/启用某个能力快速下线有问题的能力。调整负载均衡策略如果某个能力有多个实例。修改熔断器参数如失败阈值、恢复时间。查看能力健康状态基于最近一段时间的调用成功率和延迟。3. 版本灰度与回滚这是动态能力最大的优势之一。当能力提供方发布新版本如image.compressor:v1.1.0时我们可以通过配置让10%的流量调用新版本90%的流量仍调用旧版本。观察新版本的错误率和性能指标如果一切正常逐步将流量比例调整到100%。如果发现问题可以瞬间将流量全部切回旧版本实现秒级回滚。这一切都无需更新主应用或重启设备。4.4 与鸿蒙原生机制的深度结合我们的动态能力注册表不应是鸿蒙系统的一个“外来户”而应尽可能利用鸿蒙的原生能力实现“112”的效果。1. 利用HSPHarmonyOS Shared Package实现真动态我们之前的设计主要基于HAR静态共享包能力在编译时已确定。而HSP支持在运行时动态加载和更新。我们可以将能力实现封装成独立的HSP。注册中心不仅可以注册本地代码能力还可以注册一个指向HSP包路径的“动态能力”。网关在调用时如果发现能力是HSP类型则先通过import()动态加载该HSP模块然后实例化并调用其中的能力类。这为实现真正的热修复和功能动态下发提供了可能。2. 与元服务Meta Ability和卡片Form联动鸿蒙的元服务是轻量级的服务入口。我们可以将一些轻量级、独立的功能如计算器、翻译封装成动态能力并为其生成对应的元服务图标。当用户点击图标时实际上启动了一个极轻的壳Ability这个壳Ability的唯一作用就是去动态能力注册表中查找并调用对应的能力。这极大地丰富了元服务生态的构建方式。3. 为端侧AI Agent提供调度底座AI Agent是当前的热点。一个复杂的AI任务如“帮我写周报”可能由规划、搜索、写作、润色等多个子能力协作完成。我们的动态能力注册表可以完美扮演“能力调度中心”的角色。AI Agent的“大脑”规划器根据任务需求实时从注册表中发现和组合所需的能力“搜索最新项目进展”、“调用文本生成模型”、“调用语法检查工具”形成一个动态的工作流。这比硬编码的AI流水线灵活和强大得多。走到这一步动态能力注册表已经从一个解决内部工具共享的技术方案演变为一个支撑应用现代化架构、赋能生态扩展的核心基础设施。它让鸿蒙应用具备了类似云原生应用的“弹性”、“可观测性”和“敏捷性”为应对未来复杂多变的业务需求打下了坚实而灵活的基础。