摘要

随着鸿蒙应用逐步走向国际化，应用不再只面对中文和英文用户。
在 中东、北非 等地区，阿拉伯语、希伯来语 这类 从右到左（RTL）语言 是主流，如果应用在这些语言环境下：

• 布局顺序是反的
• 返回按钮方向不对
• 文字对齐看着很别扭

那基本可以直接劝退用户。

好消息是：
鸿蒙系统对 RTL 是原生支持的，而且大部分情况下是“自动完成”的。
坏消息是：
一旦你写了不该写的代码，系统也救不了你。

这篇文章就从真实开发角度，聊清楚鸿蒙里 RTL 适配到底该怎么做、哪些地方最容易踩坑，以及在真实页面里该怎么写。

引言

在早期做 Android / Web 国际化时，RTL 基本属于“高级需求”，很多项目甚至直接忽略。
但在鸿蒙生态里，国际化是默认要考虑的事情，尤其是：

• 智能设备出海
• 海外 ROM
• 多语言系统级应用

在这些场景下，RTL 不再是“锦上添花”，而是基础能力。

鸿蒙的设计理念其实很明确：

系统帮你做方向适配，你只要别把方向写死。

问题就在于：
很多开发者在不知不觉中，把方向写死了。

鸿蒙对 RTL 的整体支持机制

系统层是自动感知的

当系统语言切换为 RTL 语言时，鸿蒙会自动做这些事情：

• 整体布局方向切换为 RTL
• 文本阅读方向切换
• Row / Flex 子组件顺序镜像
• 列表、导航组件交互方向变化

前提只有一个：
你的代码要写得“语义化”。

布局方向适配的核心原则

永远不要写死 left / right

这是 RTL 适配里最常见、也是最致命的问题。

错误示例（真实项目里经常看到）

Text('返回')
  .margin({ left: 16 })

这段代码在中文、英文环境下完全正常，
但在 RTL 环境下：

• 系统已经整体翻转
• 你又强行加了 left
• 结果就是布局看起来“很怪”

正确示例（推荐写法）

Text('返回')
  .margin({ start: 16 })

这里的 start 是一个语义方向：

• LTR 语言下等价于 left
• RTL 语言下等价于 right

你不用管语言，系统会帮你算。

Demo：基础 RTL 自适应 Row

下面是一个可以直接运行的 Demo，你只需要切换系统语言就能看到效果。

@Entry
@Component
struct RtlBaseDemo {
  build() {
    Row() {
      Image($r('app.media.arrow'))
        .width(24)
        .height(24)

      Text('返回')
        .margin({ start: 8 })
    }
    .padding({ start: 16, end: 16 })
  }
}

这个 Demo 的特点：

• 没有写 left / right
• 没有强制方向
• 图标和文字顺序会自动镜像

在阿拉伯语系统下，你会发现：

• 箭头跑到了右侧
• 文本在左
• 间距依然正确

文本方向与对齐的正确方式

文本不要写 Left / Right 对齐

很多人习惯性这样写：

Text('مرحبا')
  .textAlign(TextAlign.Left)

问题是：
Left 在 RTL 里并不是“阅读起点”。

正确的写法是：

Text('مرحبا')
  .textAlign(TextAlign.Start)

系统会自动判断：

• 英文 → 左对齐
• 阿拉伯语 → 右对齐

Demo：多语言文本展示

@Entry
@Component
struct TextAlignDemo {
  build() {
    Column() {
      Text('Hello HarmonyOS')
        .textAlign(TextAlign.Start)
        .fontSize(18)

      Text('مرحبا هارموني')
        .textAlign(TextAlign.Start)
        .fontSize(18)
    }
    .padding(16)
  }
}

这个 Demo 非常适合用来自测：
切换系统语言，你能直观看到对齐方向变化。

结合真实业务场景的 RTL 适配实践

场景一：应用顶部导航栏

这是 RTL 最容易翻车的地方。

典型需求

• 返回按钮
• 页面标题

正确实现方式

@Component
struct TitleBar {
  build() {
    Row() {
      Image($r('app.media.back'))
        .width(24)
        .height(24)

      Text('设置')
        .margin({ start: 12 })
        .fontSize(20)
    }
    .padding(16)
  }
}

这里的关键点：

• 不指定 FlexDirection
• 使用 start 间距
• 图标自动镜像

系统语言一换，整个标题栏方向自然就对了。

场景二：设置页列表项

设置页通常是左右结构，比如：

• 左边是标题
• 右边是开关或箭头

推荐写法

@Component
struct SettingItem {
  build() {
    Row() {
      Text('通知')
        .layoutWeight(1)

      Image($r('app.media.arrow'))
        .width(16)
    }
    .padding({ start: 16, end: 16, top: 12, bottom: 12 })
  }
}

在 RTL 下：

• 文本会靠右
• 箭头会跑到左侧
• 整体阅读顺序符合习惯

你不需要为 RTL 单独写一套 UI。

场景三：列表页面与滑动方向

鸿蒙的 List 在 RTL 下：

• 排列顺序自动调整
• 滑动方向符合阅读习惯

示例代码

@Entry
@Component
struct ListDemo {
  build() {
    List() {
      ForEach(['Item A', 'Item B', 'Item C'], (item: string) => {
        ListItem() {
          Text(item)
            .padding(16)
            .textAlign(TextAlign.Start)
        }
      })
    }
  }
}

只要你不去强制对齐方向，列表在 RTL 下基本是“零成本适配”。

QA：开发中常见问题

Q1：需要手动判断当前是不是 RTL 吗？

一般不需要。
90% 的页面交给系统就够了。

只有在：

• 自定义绘制
• 特殊动画
• 非标准交互

这些场景下，才需要手动处理。

Q2：图片什么时候需要手动镜像？

• 返回箭头
• 方向性极强的图标

可以使用：

Image($r('app.media.arrow'))
  .mirror(true)

普通装饰性图片不建议镜像。

Q3：为什么我写了 start / end 还是不生效？

通常是因为：

• 强制写了 FlexDirection.Row
• 写死了 Alignment.Left
• 在父容器里破坏了方向规则

RTL 出问题，优先回头检查是不是哪一层写死了方向。

总结

鸿蒙里的 RTL 适配，其实不是“多写代码”，而是“少犯错误”。

一句话经验总结：

• 用 start / end
• 用 TextAlign.Start
• 不强制方向
• 相信系统

只要遵守这几条规则，
绝大多数 RTL 问题都会在你“什么都没做”的情况下自动解决。

摘要

随着智能终端越来越多，应用早就不再只运行在一台设备上。手机、平板、智慧屏、手表之间的协作，已经成了很常见的需求。在这种背景下，多设备任务该怎么分、分到哪台设备执行，就成了开发中绕不开的问题。

在鸿蒙系统中，这个问题并不是靠开发者“手动指定设备”来解决的，而是通过 设备能力感知 + 分布式调度机制 来完成。开发者更多关心的是：
这个任务适合干什么，而不是非要在哪台设备干。

本文会结合鸿蒙系统的分布式能力，介绍多设备任务分配的整体思路，并通过可运行的 Demo 代码，把这个过程完整跑一遍，最后再结合几个真实场景，聊聊它在实际项目中该怎么用。

引言

如果放在以前，一个应用基本只跑在一台手机上，最多考虑前后台切换。但现在不一样了：

• 手机在你手里
• 平板在桌子上
• 智慧屏在客厅
• 手表戴在手上

用户希望的是：
设备不同，但体验是连着的。

鸿蒙系统的分布式能力，正是为这种场景设计的。它不是简单的“跨设备通信”，而是把 任务、数据、能力 都变成可以在多设备之间流动的资源。

而多设备任务分配，本质上就是一句话：

把合适的任务，交给合适的设备去做。

鸿蒙多设备任务分配的整体思路

先发现设备，再谈分配

在鸿蒙系统中，只要设备在同一个分布式网络里，系统就能自动发现它们。
开发者不需要自己维护“设备表”，也不用关心设备什么时候上线、下线。

系统会帮你感知这些信息：

• 设备类型（手机、平板、智慧屏）
• 基本性能情况
• 是否可信
• 当前是否可用

你只需要在合适的时机拿到设备列表即可。

任务一定要能拆

多设备任务分配的前提是：
你的业务本身是能拆开的。

比如：

• 页面展示是一块
• 数据采集是一块
• 计算处理是一块

如果一个任务从头到尾全写死在一个 Ability 里，那基本就没法分配了。

系统负责“怎么选设备”

在鸿蒙里，真正“选哪台设备执行”的逻辑，大部分是系统完成的：

• 当前设备忙不忙
• 网络情况好不好
• 设备能力是否匹配
• 是否更适合本地执行

开发者更多是通过 Ability 启动方式、Service 类型、数据同步方式 来间接影响分配结果。

核心实现方式一：跨设备启动 Ability

适合什么场景

这种方式最常见，适合：

• 页面展示
• 功能模块整体迁移
• 用户可感知的交互任务

比如：
手机负责控制，平板负责显示大屏内容。

Demo：在平板上启动远程 Ability

import distributedDeviceManager from '@ohos.distributedDeviceManager';
import featureAbility from '@ohos.ability.featureAbility';

const BUNDLE_NAME = 'com.example.distributeddemo';

let deviceManager = distributedDeviceManager.createDeviceManager(BUNDLE_NAME);

function startRemotePage() {
  let devices = deviceManager.getTrustedDeviceListSync();

  devices.forEach(device => {
    if (device.deviceType === 2) { // 假设 2 表示平板
      let want = {
        bundleName: BUNDLE_NAME,
        abilityName: 'RemotePageAbility',
        deviceId: device.deviceId
      };
      featureAbility.startAbility(want);
    }
  });
}

代码说明

• createDeviceManager：创建设备管理器
• getTrustedDeviceListSync：获取可信设备列表
• deviceType：用于简单区分设备类型
• startAbility：指定 deviceId 后，Ability 会在远端设备启动

整个过程不需要你关心远端设备的进程、生命周期，系统会处理。

核心实现方式二：分布式 Service 执行任务

适合什么场景

这种方式更适合：

• 计算密集型任务
• 后台处理
• 不需要 UI 的逻辑

比如：
手机采集数据，交给性能更强的设备做分析。

Demo：连接远端计算 Service

import featureAbility from '@ohos.ability.featureAbility';

function connectRemoteService(remoteDeviceId: string) {
  let want = {
    bundleName: 'com.example.distributeddemo',
    abilityName: 'ComputeServiceAbility',
    deviceId: remoteDeviceId
  };

  featureAbility.connectAbility(want, {
    onConnect(elementName, remote) {
      console.log('远程 Service 已连接');
      remote.sendMessage({
        command: 'startCompute',
        data: [1, 2, 3, 4]
      });
    },
    onDisconnect() {
      console.log('远程 Service 已断开');
    }
  });
}

代码说明

• Service 在远端设备运行
• 本地通过 IPC 的方式和远端通信
• 计算逻辑完全在远端执行
• 本地只负责发请求、收结果

这种方式非常适合“重计算、轻交互”的任务。

典型应用场景分析与示例

场景一：手机 + 平板的学习展示系统

场景说明

• 手机负责控制、翻页
• 平板负责展示课件内容

实现思路

• 手机发现平板
• 在平板启动展示 Ability
• 通过分布式数据同步当前页码

import distributedData from '@ohos.data.distributedData';

async function syncPage(page: number) {
  let kvManager = distributedData.createKVManager();
  let store = await kvManager.getKVStore('pageStore');
  await store.put('current_page', page);
}

平板端监听数据变化，自动刷新页面。

场景二：多设备健康数据分析

场景说明

• 手表采集心率
• 手机做基础处理
• 平板做数据可视化

实现思路

• 手表同步原始数据
• 手机过滤、预处理
• 平板负责展示图表

核心在于：
任务不是“复制”，而是“分工”。

场景三：家庭智慧屏协同控制

场景说明

• 手机是遥控器
• 智慧屏负责 UI 展示
• 计算逻辑放在智慧屏

实现思路

• 手机只负责发指令
• 智慧屏 Service 处理业务逻辑
• 结果同步回手机

这种模式下，手机压力很小，体验反而更流畅。

常见问题 QA

Q1：我能不能指定“一定要某台设备执行”？

不推荐。
鸿蒙的设计思想是 声明需求，而不是指定设备。
你可以通过能力需求去“引导”，但不建议写死。

Q2：设备突然下线怎么办？

系统会通知连接断开，
你需要做的只有一件事：
支持本地降级执行或重试。

Q3：分布式任务一定比本地慢吗？

不一定。
当任务本身就不适合本地执行时，
分布式反而更快、更省电。

总结

在鸿蒙系统中，多设备任务分配并不是一套复杂、难以理解的机制，它的核心思想其实很简单：

• 把任务拆清楚
• 描述好任务需求
• 把调度交给系统

只要你在设计阶段考虑好“哪些任务适合分出去”，鸿蒙的分布式能力就能自然地帮你把事情做好。

一句话总结就是：

多设备任务分配，不是设备协作有多复杂，而是你有没有把任务设计清楚。

摘要

随着智能终端越来越多，应用早就不再只运行在一台设备上。手机、平板、智慧屏、手表之间的协作，已经成了很常见的需求。在这种背景下，多设备任务该怎么分、分到哪台设备执行，就成了开发中绕不开的问题。

在鸿蒙系统中，这个问题并不是靠开发者“手动指定设备”来解决的，而是通过 设备能力感知 + 分布式调度机制 来完成。开发者更多关心的是：
这个任务适合干什么，而不是非要在哪台设备干。

本文会结合鸿蒙系统的分布式能力，介绍多设备任务分配的整体思路，并通过可运行的 Demo 代码，把这个过程完整跑一遍，最后再结合几个真实场景，聊聊它在实际项目中该怎么用。

引言

如果放在以前，一个应用基本只跑在一台手机上，最多考虑前后台切换。但现在不一样了：

• 手机在你手里
• 平板在桌子上
• 智慧屏在客厅
• 手表戴在手上

用户希望的是：
设备不同，但体验是连着的。

鸿蒙系统的分布式能力，正是为这种场景设计的。它不是简单的“跨设备通信”，而是把 任务、数据、能力 都变成可以在多设备之间流动的资源。

而多设备任务分配，本质上就是一句话：

把合适的任务，交给合适的设备去做。

鸿蒙多设备任务分配的整体思路

先发现设备，再谈分配

在鸿蒙系统中，只要设备在同一个分布式网络里，系统就能自动发现它们。
开发者不需要自己维护“设备表”，也不用关心设备什么时候上线、下线。

系统会帮你感知这些信息：

• 设备类型（手机、平板、智慧屏）
• 基本性能情况
• 是否可信
• 当前是否可用

你只需要在合适的时机拿到设备列表即可。

任务一定要能拆

多设备任务分配的前提是：
你的业务本身是能拆开的。

比如：

• 页面展示是一块
• 数据采集是一块
• 计算处理是一块

如果一个任务从头到尾全写死在一个 Ability 里，那基本就没法分配了。

系统负责“怎么选设备”

在鸿蒙里，真正“选哪台设备执行”的逻辑，大部分是系统完成的：

• 当前设备忙不忙
• 网络情况好不好
• 设备能力是否匹配
• 是否更适合本地执行

开发者更多是通过 Ability 启动方式、Service 类型、数据同步方式 来间接影响分配结果。

核心实现方式一：跨设备启动 Ability

适合什么场景

这种方式最常见，适合：

• 页面展示
• 功能模块整体迁移
• 用户可感知的交互任务

比如：
手机负责控制，平板负责显示大屏内容。

Demo：在平板上启动远程 Ability

import distributedDeviceManager from '@ohos.distributedDeviceManager';
import featureAbility from '@ohos.ability.featureAbility';

const BUNDLE_NAME = 'com.example.distributeddemo';

let deviceManager = distributedDeviceManager.createDeviceManager(BUNDLE_NAME);

function startRemotePage() {
  let devices = deviceManager.getTrustedDeviceListSync();

  devices.forEach(device => {
    if (device.deviceType === 2) { // 假设 2 表示平板
      let want = {
        bundleName: BUNDLE_NAME,
        abilityName: 'RemotePageAbility',
        deviceId: device.deviceId
      };
      featureAbility.startAbility(want);
    }
  });
}

代码说明

• createDeviceManager：创建设备管理器
• getTrustedDeviceListSync：获取可信设备列表
• deviceType：用于简单区分设备类型
• startAbility：指定 deviceId 后，Ability 会在远端设备启动

整个过程不需要你关心远端设备的进程、生命周期，系统会处理。

核心实现方式二：分布式 Service 执行任务

适合什么场景

这种方式更适合：

• 计算密集型任务
• 后台处理
• 不需要 UI 的逻辑

比如：
手机采集数据，交给性能更强的设备做分析。

Demo：连接远端计算 Service

import featureAbility from '@ohos.ability.featureAbility';

function connectRemoteService(remoteDeviceId: string) {
  let want = {
    bundleName: 'com.example.distributeddemo',
    abilityName: 'ComputeServiceAbility',
    deviceId: remoteDeviceId
  };

  featureAbility.connectAbility(want, {
    onConnect(elementName, remote) {
      console.log('远程 Service 已连接');
      remote.sendMessage({
        command: 'startCompute',
        data: [1, 2, 3, 4]
      });
    },
    onDisconnect() {
      console.log('远程 Service 已断开');
    }
  });
}

代码说明

• Service 在远端设备运行
• 本地通过 IPC 的方式和远端通信
• 计算逻辑完全在远端执行
• 本地只负责发请求、收结果

这种方式非常适合“重计算、轻交互”的任务。

典型应用场景分析与示例

场景一：手机 + 平板的学习展示系统

场景说明

• 手机负责控制、翻页
• 平板负责展示课件内容

实现思路

• 手机发现平板
• 在平板启动展示 Ability
• 通过分布式数据同步当前页码

import distributedData from '@ohos.data.distributedData';

async function syncPage(page: number) {
  let kvManager = distributedData.createKVManager();
  let store = await kvManager.getKVStore('pageStore');
  await store.put('current_page', page);
}

平板端监听数据变化，自动刷新页面。

场景二：多设备健康数据分析

场景说明

• 手表采集心率
• 手机做基础处理
• 平板做数据可视化

实现思路

• 手表同步原始数据
• 手机过滤、预处理
• 平板负责展示图表

核心在于：
任务不是“复制”，而是“分工”。

场景三：家庭智慧屏协同控制

场景说明

• 手机是遥控器
• 智慧屏负责 UI 展示
• 计算逻辑放在智慧屏

实现思路

• 手机只负责发指令
• 智慧屏 Service 处理业务逻辑
• 结果同步回手机

这种模式下，手机压力很小，体验反而更流畅。

常见问题 QA

Q1：我能不能指定“一定要某台设备执行”？

不推荐。
鸿蒙的设计思想是 声明需求，而不是指定设备。
你可以通过能力需求去“引导”，但不建议写死。

Q2：设备突然下线怎么办？

系统会通知连接断开，
你需要做的只有一件事：
支持本地降级执行或重试。

Q3：分布式任务一定比本地慢吗？

不一定。
当任务本身就不适合本地执行时，
分布式反而更快、更省电。

总结

在鸿蒙系统中，多设备任务分配并不是一套复杂、难以理解的机制，它的核心思想其实很简单：

• 把任务拆清楚
• 描述好任务需求
• 把调度交给系统

只要你在设计阶段考虑好“哪些任务适合分出去”，鸿蒙的分布式能力就能自然地帮你把事情做好。

一句话总结就是：

多设备任务分配，不是设备协作有多复杂，而是你有没有把任务设计清楚。

摘要

随着 HarmonyOS / OpenHarmony 在手机、平板、智慧屏、车机等多设备上的落地，应用的复杂度正在明显提升。页面不再只是简单展示，而是伴随着网络请求、数据计算、设备协同等大量逻辑。如果这些逻辑处理不当，很容易出现页面卡顿、点击无响应，甚至 Ability 被系统回收的问题。

线程阻塞，已经成为鸿蒙应用开发中最容易踩坑、也最影响体验的问题之一。本文将结合实际开发场景，用尽量口语化的方式，聊一聊在鸿蒙系统中如何系统性地避免线程阻塞，并给出可以直接运行的 Demo 代码。

引言

在早期的应用开发中，很多开发者习惯把逻辑直接写在点击事件里，或者在页面加载时同步读取数据。这种写法在简单页面中问题不大，但在 HarmonyOS 这种强调流畅体验和多设备协同的系统中，很容易暴露问题。

鸿蒙的 UI 是声明式的，系统对主线程（UI 线程）非常敏感。一旦主线程被占用，页面掉帧、动画卡住、操作延迟都会立刻出现。因此，理解哪些操作会阻塞线程，以及如何把这些操作合理地“挪走”，是每个鸿蒙开发者绕不开的一课。

下面我们从原理、工具、代码和真实场景几个角度，完整地拆解这个问题。

为什么线程阻塞在鸿蒙中这么致命

UI 线程到底在忙什么

在 HarmonyOS 中，UI 线程主要负责三件事：

• ArkUI 页面渲染
• 用户事件分发（点击、滑动等）
• Ability 生命周期回调

简单理解就是：只要和“看得见、点得动”有关的事情，几乎都在 UI 线程上完成。

一旦你在这里做了耗时操作，比如计算、IO、网络等待，页面就会立刻表现出“卡”的感觉。

常见的阻塞来源

在实际项目中，最容易导致阻塞的操作通常包括：

• 同步网络请求
• 文件读写
• 数据库查询
• 大量 for 循环计算
• 人为 sleep 或死循环

这些操作本身不一定是错的，问题在于它们被放在了不该放的线程上。

鸿蒙中避免线程阻塞的核心思路

一个总原则

可以把鸿蒙里的线程使用总结成一句话：

UI 线程只处理 UI，其他事情交给异步、线程池或 Worker。

围绕这个原则，系统也提供了多种工具，帮助开发者把任务“分流”。

异步编程是第一道防线

使用 async / await 处理耗时逻辑

在 ArkTS 中，官方推荐优先使用 Promise 和 async / await。它的好处是代码结构清晰，而且不会阻塞 UI 线程。

示例：页面加载网络数据

@Entry
@Component
struct AsyncDemo {
  @State message: string = '加载中...'

  build() {
    Column() {
      Text(this.message)
        .fontSize(20)
        .margin(20)

      Button('重新加载')
        .onClick(() => {
          this.loadData()
        })
    }
  }

  async loadData() {
    this.message = '请求中...'
    let response = await fetch('https://example.com/data')
    let result = await response.text()
    this.message = result
  }
}

代码说明

• loadData 使用 async 声明，不会阻塞 UI
• await 只是暂停当前函数执行，不会卡住页面
• UI 更新完全由状态变化驱动

这是最基础、也是最常用的一种防阻塞方式。

TaskPool：处理计算和 IO 的利器

什么时候该用 TaskPool

当你遇到下面这些情况时，TaskPool 几乎是必选项：

• 大量计算
• 批量数据处理
• 文件压缩、解析

可运行 Demo 示例

import taskpool from '@ohos.taskpool'

@Concurrent
function calculateSum(count: number): number {
  let sum = 0
  for (let i = 0; i < count; i++) {
    sum += i
  }
  return sum
}

@Entry
@Component
struct TaskPoolDemo {
  @State result: string = '等待计算'

  build() {
    Column() {
      Text(this.result)
        .fontSize(18)
        .margin(20)

      Button('开始计算')
        .onClick(() => {
          this.startTask()
        })
    }
  }

  startTask() {
    this.result = '计算中...'
    taskpool.execute(calculateSum, 1000000).then(res => {
      this.result = `结果是：${res}`
    })
  }
}

代码说明

• @Concurrent 表示该函数可以并发执行
• TaskPool 自动管理线程，不需要开发者手动创建线程
• UI 线程只负责接收结果和更新状态

在真实项目中，使用 TaskPool 往往能立刻解决页面卡顿问题。

Worker：长期后台任务的选择

Worker 的使用场景

如果任务具有下面这些特点，就更适合使用 Worker：

• 长时间运行
• 需要持续处理数据
• 与 UI 强隔离

比如日志分析、音视频处理、复杂解析等。

示例：使用 Worker 处理数据

主线程代码

let worker = new Worker('workers/data_worker.ts')

worker.postMessage({ action: 'start' })

worker.onmessage = (e) => {
  console.log('收到结果：', e.data)
}

Worker 线程代码

onmessage = function (e) {
  if (e.data.action === 'start') {
    let result = 0
    for (let i = 0; i < 500000; i++) {
      result += i
    }
    postMessage(result)
  }
}

代码说明

• Worker 与 UI 线程完全独立
• 即使计算时间较长，也不会影响页面交互
• 通过消息机制进行通信

结合实际场景的应用示例

场景一：列表页面加载大量数据

问题：

• 首次进入页面时一次性处理全部数据
• 页面明显卡顿

解决思路：

• 网络请求使用 async
• 数据整理放入 TaskPool

async loadList() {
  let data = await fetchData()
  taskpool.execute(processData, data).then(list => {
    this.list = list
  })
}

场景二：文件导入与解析

问题：

• 文件较大
• 解析过程耗时

解决思路：

• Worker 负责解析
• UI 只显示进度

worker.postMessage({ filePath })

场景三：复杂计算驱动 UI 更新

问题：

• 计算逻辑和 UI 耦合

解决思路：

• 计算完全放到 TaskPool
• UI 只订阅结果

QA 环节

Q：async / await 会不会阻塞线程？
A：不会，它只是让出执行权，不会卡住 UI 线程。

Q：TaskPool 和 Worker 怎么选？
A：短期、一次性的任务优先 TaskPool，长期或持续任务用 Worker。

Q：能不能在生命周期里做耗时操作？
A：不建议，生命周期函数应尽量轻量。

总结

线程阻塞并不是某一个 API 的问题，而是设计问题。在 HarmonyOS 中，系统已经为我们准备好了异步模型、TaskPool 和 Worker，只要遵循“UI 线程只做 UI”的原则，大多数卡顿问题都可以提前避免。

在真实项目中，提前做好任务拆分、线程规划，比后期排查卡顿要省心得多。这也是鸿蒙开发从“能跑”到“跑得顺”的一个重要分水岭。