1. 原子化服务开发的核心思路与价值

如果你已经跟着上篇教程完成了第一个原子化服务卡片的创建和基础配置，那么恭喜你，你已经跨过了从0到1的门槛。但上篇更多是“照猫画虎”，让你跑通流程。这篇下集，我们要深入腹地，聊聊那些真正决定你开发效率和卡片质量的“硬核”细节。原子化服务的魅力，绝不仅仅是把一个应用功能做成卡片那么简单。它的核心价值在于“服务随人”，即用户无需安装完整应用，就能在合适的设备、合适的场景下，获取精准的服务。比如，早上在手表上瞥一眼通勤卡片，上车后车机自动续播导航，到公司后手机弹出会议提醒卡片——这一套无缝流转的体验，才是HarmonyOS分布式能力的精髓。

因此，开发原子化服务，尤其是涉及多设备适配的卡片，思维必须转变。你不能只想着“我这个页面在手机上长什么样”，而要考虑“这个服务信息，在手表、平板、智慧屏上，分别应该以何种最自然、最高效的方式呈现给用户”。这背后涉及到布局的弹性设计、资源的多态适配以及逻辑的动态响应。本教程的下半部分，就将围绕这些实战要点展开，我会结合官方示例项目，拆解多设备适配的代码逻辑，并分享我在实际开发中总结的配置技巧和避坑指南。无论你是想开发一个简单的信息展示卡片，还是构思一个跨设备联动的复杂服务，这些内容都能帮你打下坚实的基础。

2. 深入项目结构：理解配置与模板

拿到示例项目代码后，别急着运行。花十分钟理清它的目录结构，比你盲目调试一小时都管用。一个标准的HarmonyOS原子化服务工程，其核心在于 entry 模块下的几个关键目录和文件。

2.1 src/main/resources 资源目录解析

这个目录是卡片视觉呈现的“弹药库”，也是多设备适配的第一战场。

  • base/profile/ ：这里存放着核心配置文件 form_config.json 。这个文件定义了卡片的“元信息”，是卡片能够被系统识别和管理的根本。你需要重点关注 updateDuration 字段，它决定了卡片定时更新的频率。 注意 ：出于功耗和系统资源考虑，这个值不能无限小，对于需要实时更新的卡片（如股票、秒级倒计时），你需要使用“定点更新”或“主动更新”API，后续会详细说明。
  • base/media/ ：放置所有的图片资源。 这里有一个关键实践 ：对于图标类资源，务必提供不同像素密度的版本（如 ic_launcher.png 对应 ic_launcher.9.png 用于自适应拉伸）。虽然系统会自动缩放，但提供适配资源能避免在高分辨率设备上模糊。
  • zh_CN/element/ ：存放字符串资源文件 string.json 。将UI上所有可见文字都定义在这里，是支持国际化的第一步，也让后续修改文本内容变得异常轻松。

2.2 src/main/ets 逻辑代码目录剖析

这里是卡片“大脑”所在，主要包含两个部分：

  • widget/ ：卡片专属包。 FormAbility.ts 是卡片生命周期的主要承载者，负责处理卡片的创建、销毁、更新等事件。 pages/ 目录下则是卡片实际的UI页面，示例中是一个简单的 Index.ets 。
  • entryability/ ：应用主入口能力，对应的是整个原子化服务应用（虽然可能只有一个卡片）。 EntryAbility.ts 负责应用级别的生命周期管理。 一个重要但容易被忽略的点是 ：卡片和其所属的原子化服务应用是松耦合的。即使用户没有打开过主应用，卡片也可以独立运行和更新。因此，在 FormAbility 中实现的业务逻辑应尽可能自包含。

2.3 module.json5 模块配置文件详解

这是HarmonyOS应用的“总纲”，地位堪比Android的 AndroidManifest.xml 。对于原子化服务开发，你需要额外关注 abilities 和 extensionAbilities 这两个节点。

在 extensionAbilities 中，你会找到类型为 form 的扩展能力声明。这里定义了卡片的名称、描述、支持的窗口尺寸等。 一个实用的技巧 ：在开发初期，你可以在这里为同一个UI组件声明多个不同尺寸的卡片配置，方便在模拟器上快速测试不同规格卡片的显示效果，而无需反复修改代码。

{
  “extensionAbilities”: [{
    “name”: “Widget”,
    “srcEntry”: “./ets/widget/FormAbility.ts”,
    “type”: “form”,
    “metadata”: [{
      “name”: “ohos.extension.form”,
      “resource”: “$profile:form_config”
    }]
  }]
}

3. 实战：多设备卡片UI适配策略

示例项目展示了Phone、Tablet、Wearable三种设备的卡片效果。实现这种适配，主要依靠HarmonyOS的“响应式布局”和“资源限定词”两套机制。

3.1 使用响应式布局构建弹性UI

在 Index.ets 页面中，我们不再使用固定的像素值（px），而是采用弹性单位（vp）和比例布局。更重要的是使用 @ohos.arkui.advanced 提供的API，如 @State , @Prop , 以及布局容器如 Flex , Stack , Grid 等，它们能根据容器尺寸自动调整子组件的位置和大小。

例如，一个简单的信息卡片，在手机上可能是上下堆叠布局，在平板上则可以借助 Flex 的 wrap 属性或 Grid 容器，实现左右分栏甚至更复杂的网格布局。关键在于：你的UI组件树应该描述的是“组件间的相对关系”，而非“绝对位置”。

// 一个简单的响应式布局思想示例
@Entry
@Component
struct AdaptiveCard {
  // 通过媒体查询或设备信息获取当前设备类型或屏幕宽度
  // 此处为简化示例，实际应从AppStorage或设备能力接口获取
  @State deviceType: string = ‘phone’;

  build() {
    Column() {
      if (this.deviceType === ‘phone’) {
        // 手机竖屏布局：大图在上，文字在下
        this.BuildPhoneLayout()
      } else if (this.deviceType === ‘tablet’) {
        // 平板布局：图文左右排列
        this.BuildTabletLayout()
      } else if (this.deviceType === ‘wearable’) {
        // 手表布局：极简，只显示核心信息和图标
        this.BuildWearableLayout()
      }
    }
  }
}

注意 ：在实际项目中，更推荐使用 栅格系统 或 断点 进行响应式设计。你可以定义一个屏幕宽度断点（如600vp），小于它为手机布局，大于它为平板布局。这样代码更清晰，也更符合前端响应式开发习惯。

3.2 利用资源限定词进行精细化资源管理

响应式布局解决了结构问题，但不同设备上可能还需要不同的图片、字号甚至颜色值。这就是 resources/ 目录下子文件夹的用武之地。

HarmonyOS允许你使用限定词来创建资源目录，系统会根据当前设备的特性自动匹配最合适的资源。例如：

  • resources/base/media/ ：默认图标。
  • resources/tablet/media/ ：平板专用的、尺寸更大的图标。
  • resources/zh_CN/base/element/ ：中文默认字符串。
  • resources/en_US/base/element/ ：英文字符串。

对于字体大小，你可以在 float.json 中定义一套基准值，然后在不同设备规格的目录下覆写这些值。比如，在 resources/tablet/ 下，你可以将标题字号从默认的 18fp 改为 22fp ，以获得更好的平板阅读体验。

实操心得 ：不要过度设计资源限定。初期可以只为手机和平板提供两套主要的尺寸资源，手表因其屏幕极小，往往需要完全重绘的图标，可以单独处理。通用的颜色和字符串定义放在 base 里即可。

4. 卡片动态更新与数据交互实战

静态卡片价值有限。真正的原子化服务需要动态展示信息，比如天气、待办事项、快递状态。这涉及到卡片如何获取数据并更新UI。

4.1 卡片更新机制剖析

卡片更新主要有三种模式：

  1. 定时更新 ：在 form_config.json 中配置 updateDuration 。这是最简单的“轮询”方式，适用于更新频率要求不高的场景，如每日新闻、天气预报。
  2. 定点更新 ：通过 setFormNextRefreshTime API，在卡片生命周期回调中设置下一次刷新的具体时间。适用于在特定时刻更新的场景，如整点报时、会议开始前提醒。
  3. 主动更新 ：通过 updateForm API，由应用主动触发卡片更新。这是最灵活的方式，当应用后台数据发生变化时（如收到新消息、任务完成），可以立即通知卡片刷新。

4.2 实现一个简单的网络数据获取卡片

让我们以“每日一句”卡片为例，演示如何从网络API获取数据并更新卡片。

首先，在 FormAbility.ts 中，我们需要处理卡片的 onCreate 和 onUpdate 生命周期，并在其中发起网络请求。

// FormAbility.ts 部分代码
import formBindingData from ‘@ohos.app.form.formBindingData’;
import formInfo from ‘@ohos.app.form.formInfo’;
import http from ‘@ohos.net.http’;

export default class FormAbility extends Ability {
  // 卡片创建时触发
  onCreate(want: Want): formBindingData.FormBindingData {
    // 1. 初始化卡片UI，可以是一个默认的占位图
    let formData = {};
    // 2. 立即发起一次数据请求更新卡片
    this.updateCardData(want.parameters[formInfo.FormParam.IDENTITY_KEY] as string);
    // 3. 返回初始数据
    return formBindingData.createFormBindingData(formData);
  }

  // 自定义更新卡片数据的方法
  private async updateCardData(formId: string) {
    let httpRequest = http.createHttp();
    try {
      let response = await httpRequest.request(
        “https://api.example.com/daily-quote”, // 替换为你的API地址
        {
          method: http.RequestMethod.GET,
        }
      );
      let quoteData = JSON.parse(response.result as string);
      // 构造要更新的数据
      let formData = {
        “quote_text”: quoteData.content,
        “quote_author”: quoteData.author
      };
      // 获取formProvider进行更新
      let formProvider = formBindingData.formProvider;
      formProvider.updateForm(formId, formBindingData.createFormBindingData(formData)).then(() => {
        console.info(‘FormAbility updateForm success.’);
      }).catch((err) => {
        console.error(`FormAbility updateForm failed, code: ${err.code}, message: ${err.message}`);
      });
    } catch (err) {
      console.error(`Failed to request quote, code: ${err.code}, message: ${err.message}`);
    } finally {
      httpRequest.destroy();
    }
  }
}

然后，在卡片的UI文件 Index.ets 中，我们需要绑定这些动态数据。

// Index.ets 部分代码
@Entry
@Component
struct WidgetCard {
  // 绑定从FormAbility传递过来的数据
  @LocalStorageProp(‘quote_text’) quoteText: string = ‘加载中...’;
  @LocalStorageProp(‘quote_author’) quoteAuthor: string = ‘’;

  build() {
    Column() {
      Text(this.quoteText)
        .fontSize(‘14fp’)
        .fontColor(‘#333333’)
        .maxLines(3)
        .textOverflow({overflow: TextOverflow.Ellipsis})
      if (this.quoteAuthor) {
        Text(‘—— ’ + this.quoteAuthor)
          .fontSize(‘12fp’)
          .fontColor(‘#666666’)
          .margin({top: ‘8vp’})
          .alignSelf(ItemAlign.End)
      }
    }
    .padding(‘12vp’)
    .width(‘100%’)
    .height(‘100%’)
    .backgroundColor(‘#FFFFFF’)
  }
}

关键点 ： @LocalStorageProp 装饰器用于建立UI组件和卡片绑定数据之间的单向同步。当 FormAbility 调用 updateForm 时， LocalStorage 中的数据更新会自动触发UI重新渲染。

4.3 更新策略的选择与优化

  • 性能与功耗平衡 ：频繁的网络请求会消耗电量并增加服务器压力。对于非实时性数据，应合理设置 updateDuration （例如30分钟），或使用定点更新（如只在早晚高峰更新交通卡片）。
  • 失败处理与降级 ：网络请求可能失败。在 updateCardData 方法中，必须要有 try-catch 块。失败后，可以尝试重试，或更新卡片显示一个友好的错误提示（如“网络不佳，点击重试”），并提供一个 onClick 事件让用户手动刷新。
  • 数据本地缓存 ：为了提高加载速度和离线体验，可以考虑将获取到的数据用 Preferences 缓存在本地。下次卡片创建或定时更新时，先显示缓存数据，再在后台发起网络请求获取最新数据，实现“秒开”体验。

5. 卡片交互与事件处理详解

卡片不仅仅是展示信息的窗口，更应该是服务的快捷入口。用户可以通过点击、长按等操作与卡片交互。

5.1 为卡片添加点击跳转能力

最常见的交互是点击卡片跳转到对应的原子化服务应用详情页或某个功能页。这需要在卡片的UI组件上绑定 onClick 事件，并通过 postCardAction 方法发起跳转。

// 在Index.ets的组件中
Column() {
  // ... 卡片内容
}
.onClick(() => {
  // 触发卡片行为
  postCardAction(this, {
    ‘action’: ‘router’,
    ‘abilityName’: ‘EntryAbility’, // 要跳转的Ability名称
    ‘params’: {
      ‘from’: ‘widget’, // 可以传递参数，告知主应用是从卡片跳转而来
      ‘targetPage’: ‘detail’ // 指定要跳转的页面
    }
  });
})

在对应的 EntryAbility 中，你可以在 onCreate 或 onNewWant 生命周期里接收这些参数，并导航到指定页面。

5.2 实现卡片内部微交互

除了跳转，卡片内部也可以有一些轻量级交互。例如，一个待办事项卡片，可以有一个复选框，点击后直接标记任务完成。

@Entry
@Component
struct TodoCard {
  @LocalStorageProp(‘todos’) todos: Array<{id: number, text: string, done: boolean}> = [];
  @LocalStorageProp(‘formId’) formId: string = ‘’;

  build() {
    List() {
      ForEach(this.todos, (item: {id: number, text: string, done: boolean}) => {
        ListItem() {
          Row() {
            Checkbox({name: ‘’, group: ‘’})
              .select(item.done)
              .onChange((isChecked: boolean) => {
                // 1. 更新本地数据状态
                let updatedTodos = this.todos.map(todo =>
                  todo.id === item.id ? {…todo, done: isChecked} : todo
                );
                // 2. 通过LocalStorage同步到UI（这里需要@LocalStorageLink才能双向同步，示例简化）
                // 3. 调用FormAbility提供的方法，持久化状态或通知后端
                this.updateTodoStatus(item.id, isChecked);
              })
            Text(item.text)
              .fontSize(‘14fp’)
              .decoration({ type: item.done ? TextDecorationType.LineThrough : TextDecorationType.None })
          }
        }
      })
    }
  }

  // 假设通过RPC或调用FormAbility的方法来更新状态
  private updateTodoStatus(id: number, done: boolean) {
    // 这里可以调用postCardAction向FormAbility发送一个自定义事件
    postCardAction(this, {
      ‘action’: ‘message’,
      ‘params’: {
        ‘type’: ‘UPDATE_TODO’,
        ‘id’: id,
        ‘done’: done,
        ‘formId’: this.formId
      }
    });
  }
}

在 FormAbility 中，你需要重写 onEvent 生命周期方法来接收并处理这个自定义事件，执行真正的业务逻辑（如更新数据库、调用后端API）。

注意事项 ：卡片内的交互应保持轻量、快速。复杂的操作（如多步骤表单填写）应引导用户跳转到主应用完成。卡片的主要职责是“预览”和“快捷操作”。

6. 多设备适配的深度考量与测试

回到我们最初的目标：让一个服务在Phone、Tablet、Wearable上都有良好的表现。除了UI布局和资源，还需要考虑更多维度。

6.1 设备能力查询与差异化逻辑

不同的设备拥有不同的硬件能力和传感器。例如，手表可能没有GPS但有心率传感器，智慧屏有摄像头但用户交互距离远。你的卡片逻辑可能需要据此调整。

你可以使用 @ohos.deviceInfo 和 @ohos.systemCapability 等模块来查询设备信息。

import deviceInfo from ‘@ohos.deviceInfo’;
import systemCapability from ‘@ohos.systemCapability’;

// 获取设备类型
let deviceType = deviceInfo.deviceType;
// 判断是否支持某种能力，例如蓝牙
let hasBluetooth = systemCapability.hasSystemCapability(‘SystemCapability.Communication.Bluetooth.Core’);

// 根据设备类型和能力执行不同的逻辑
if (deviceType === ‘wearable’) {
  // 手表端：简化信息，优先使用本地传感器数据
  if (hasBluetooth) {
    // 尝试通过蓝牙连接手机获取更丰富数据
  }
} else if (deviceType === ‘phone’) {
  // 手机端：作为数据和控制中心，可以展示完整信息
}

6.2 跨设备数据同步与流转

原子化服务的更高阶玩法是跨设备协同。例如，在手机上开始一项运动，在手表上实时显示心率配速。这依赖于HarmonyOS的分布式数据管理。

  • 分布式数据对象 ：允许网络内可信设备间同步同一个数据对象。当任一设备上的对象属性发生变化，所有设备上的该对象都会自动更新。
  • 跨设备调用 ：一个设备上的应用可以像调用本地方法一样，调用另一个设备上Ability提供的方法。

在卡片开发中，你可以利用这些能力。比如，一个智能家居控制卡片，在平板上显示所有房间的完整控制面板，在手表上只显示“离家模式”和“回家模式”两个快捷按钮。手表点击“离家模式”时，通过跨设备调用，触发手机上实际执行关闭所有灯光、电器的操作。

6.3 多设备测试策略与工具

测试是保证多设备体验一致性的关键。光靠模拟器是不够的，有条件一定要进行真机测试。

  1. 模拟器测试 ：DevEco Studio提供了多种设备类型的模拟器。利用它们快速验证UI布局在不同屏幕尺寸和分辨率下的表现。重点关注布局错乱、文字截断、图片拉伸等问题。
  2. 真机调试 ：将应用签名后，安装到真实的手机、平板、手表上进行测试。真机能暴露模拟器无法完全模拟的性能问题（如卡片刷新流畅度）、传感器交互以及真实的网络环境问题。
  3. 分布式测试 ：如果你开发了跨设备联动的功能，必须测试设备发现、连接、数据同步、远程调用的全流程。模拟多设备网络环境（如Wi-Fi和蓝牙共存）下的稳定性。

一个实用的测试清单 ：

  • [ ] 卡片在目标设备的所有支持尺寸下是否正常显示？
  • [ ] 图片和文字在不同像素密度的设备上是否清晰？
  • [ ] 点击、长按等交互事件是否响应正确？
  • [ ] 定时更新、主动更新逻辑是否按预期工作？
  • [ ] 网络异常、数据获取失败时，卡片是否有合理的降级UI？
  • [ ] 跨设备功能（如有）的发现、连接、数据传输是否稳定可靠？

7. 发布、上架与运维监控

开发完成并通过测试后，下一步就是让用户能用上你的原子化服务。

7.1 工程构建与签名打包

在DevEco Studio中，选择 Build > Build Hap(s)/App(s) > Build Release Hap 来生成发布版的HAP包。 关键步骤是应用签名 。HarmonyOS要求所有安装包都必须经过签名。你需要提前在AGC（AppGallery Connect）网站创建项目和应用，并申请发布证书和Profile文件，然后在DevEco Studio中配置签名信息。

避坑指南 ：调试证书和发布证书是分开的。真机调试使用调试证书，上架市场必须使用发布证书。切记保管好你的签名密钥库（.p12文件）和密码，丢失将无法更新应用。

7.2 提交AGC审核与上架

将签名的HAP包上传到AGC。你需要填写详细的应用信息，包括服务卡片的预览图、描述、适用设备等。审核团队会测试你的卡片功能、UI规范、隐私合规等。

提高审核通过率的技巧 ：

  • 提供清晰的预览图 ：展示卡片在手机、平板、手表等设备上的实际效果图。
  • 详细描述服务场景 ：说明你的卡片在什么情况下能为用户提供价值。
  • 严格遵循隐私规范 ：如果卡片需要获取网络、位置等权限，必须在应用配置文件中明确定义，并在隐私声明中清晰说明用途。 切忌私自收集用户数据 。

7.3 上线后的监控与迭代

服务上线后，工作并未结束。利用AGC提供的“数据分析”服务，关注卡片的添加量、点击率、用户活跃设备类型等指标。这些数据能帮你判断：

  • 哪种尺寸或样式的卡片更受欢迎？
  • 用户主要在什么设备上使用你的服务？
  • 卡片的更新频率是否合理？有没有因为频繁更新导致用户移除卡片？

根据数据反馈，持续优化卡片的UI、更新策略和功能。原子化服务的特点决定了它可以快速迭代，无需用户手动更新应用，即可通过云端配置或动态更新机制，为所有用户推送新的卡片样式或功能。

8. 常见问题排查与性能优化实录

在实际开发中，你肯定会遇到各种问题。这里记录了一些典型场景和我的解决思路。

8.1 卡片不显示或显示异常

问题现象 可能原因 排查步骤与解决方案
卡片添加到桌面后一片空白 1. UI组件构建失败。
2. 数据绑定异常，初始数据为空。		 1. 检查 Index.ets 的 build() 方法内组件树是否有语法错误。
2. 在 FormAbility 的 onCreate 方法中，确保返回的 formBindingData 包含UI所需的所有字段，且字段名与 @LocalStorageProp 绑定的变量名一致。
3. 查看DevEco Studio的Log窗口，过滤 Form 关键字，寻找错误日志。
卡片布局错乱，元素堆叠或溢出 1. 使用了固定尺寸（px）而非弹性尺寸（vp）。
2. 容器尺寸计算错误，或未设置 width(‘100%’) / height(‘100%’) 。		 1. 将所有尺寸单位改为 vp ，间距用 vp ，字体用 fp 。
2. 确保根容器或主要布局容器设置了与卡片配置相符的尺寸。使用边框背景色临时调试，看清每个容器的实际占位区域。
3. 复杂布局多用 Flex 和 Grid ，少用绝对定位。
图片资源无法加载 1. 图片路径错误或文件名大小写不对。
2. 图片尺寸过大，解码失败。		 1. 使用 $r(‘app.media.ic_launcher’) 方式引用资源，确保 media 目录下存在该文件。
2. 对于大图，先进行压缩和缩放，适配卡片显示的实际尺寸，避免内存浪费。

8.2 卡片无法更新数据

问题现象 可能原因 排查步骤与解决方案
定时更新不生效 1. form_config.json 中 updateDuration 设置错误或未生效。
2. 卡片被系统休眠。		 1. 确认修改了正确的 form_config.json 文件并重新编译安装。
2. updateDuration 单位为分钟，且有一定最小值限制（通常为30分钟），如需更短间隔，需使用定点更新。
3. 在 FormAbility 的 onUpdate 生命周期里加日志，看是否被触发。
调用 updateForm 后UI无变化 1. 更新的数据格式错误，或未通过 formBindingData 包装。
2. UI组件未正确绑定数据。		 1. 确保 updateForm 的第二个参数是 formBindingData.createFormBindingData(formData) 的返回值。
2. 检查 @LocalStorageProp 或 @LocalStorageLink 装饰的变量名是否与 formData 中的键名完全匹配。
3. 在 updateForm 的成功和失败回调中打印日志，确认调用结果。
网络请求失败导致卡片无数据 1. 未申请网络权限。
2. API地址错误或服务器异常。
3. 未处理请求异常。		 1. 在 module.json5 中申请 ohos.permission.INTERNET 权限。
2. 在代码中使用 try-catch 包裹网络请求，并在 catch 中更新卡片显示错误状态或默认数据。
3. 使用Postman等工具先验证API本身是否可用。

8.3 性能优化要点

卡片作为系统桌面的常驻组件，其性能直接影响用户体验和系统流畅度。

  • 减少不必要的刷新 ：评估数据更新的必要性。天气卡片可能每小时更新一次就够了，而不是每分钟。
  • 优化图片资源 ：使用WebP等更高效的图片格式，根据设备屏幕密度提供切合尺寸的图片，避免大图小用。
  • 精简UI组件树 ：避免嵌套过深的布局，减少不必要的组件节点。对于列表数据，使用 LazyForEach 延迟加载。
  • 避免阻塞主线程 ：网络请求、复杂计算等耗时操作，应使用异步任务（Promise, async/await）或Worker线程处理，防止卡片渲染卡顿。
  • 及时释放资源 ：在卡片的 onDestroy 生命周期中，取消未完成的网络请求、关闭定时器、释放不必要的内存引用。

开发原子化服务卡片是一个从“功能实现”到“体验打磨”的过程。初期聚焦于让卡片跑起来、数据动起来；中期深入多设备适配和交互流畅性；后期则要关注性能、功耗和用户真实的使用数据。希望这篇结合了官方教程与实战心得的指南，能帮你更快地跨越入门阶段，开发出真正好用、用户爱用的HarmonyOS原子化服务。

# 原子化服务
Logo
HarmonyOS开发者社区

讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐

鸿蒙开发-想做毛玻璃和发光效果？MaskFilter遮罩滤镜详解

本文介绍了HarmonyOS中MaskFilter的使用方法，这是一种实现图形模糊效果的工具。文章详细说明了MaskFilter的概念、四种模糊类型（NORMAL/OUTER/INNER/SOLID）及其适用场景，并提供了创建模糊滤镜的代码示例。重点讲解了createBlurMaskFilter方法的两个参数（BlurType和sigma）的作用，以及如何将MaskFilter应用到画笔上。此外，

avatar HarmonyOS开发者社区
cover

【HarmonyOS 6.1 全场景实战】《灵犀厨房》实战（二十五）：【深色模式】一键切换暗色主题——让 App 在深夜也温柔

avatar HarmonyOS开发者社区

鸿蒙开发-想做高级文本排版？text文本模块的排版和字体管理

文章摘要： HarmonyOS的text模块提供了强大的文本排版功能，支持自定义字体加载和精细排版控制。核心流程包括：获取字体集（FontCollection）、加载自定义字体、定义文本样式（TextStyle）和段落样式（ParagraphStyle）、通过段落生成器（ParagraphBuilder）构建段落对象，最终执行排版并获取结果。该模块支持同步/异步字体加载、多种排版参数设置，并能查询

avatar HarmonyOS开发者社区