HarmonyOS 6.1+ 新特性实战（13）：TaskPool并发取消与结果归并方案

cslgtdz

194人浏览 · 2026-08-31 00:56:12

cslgtdz · 2026-08-31 00:56:12 发布

把十个耗时函数全部丢进TaskPool不一定更快。任务粒度过小会放大调度成本，并发度过高会争抢CPU，返回宿主线程后的大批量数据加工仍可能造成掉帧。需要用同一组输入比较串行、受控并发和取消三种路径。

方案面向HarmonyOS 6.1.1 Release SDK（API 24），系统Kit调用进入适配层，命令约束、状态归并和恢复策略进入可测试的业务层。范围包含状态与资源生命周期设计、失败恢复和验收合同，不包含业务内容生产、服务端协议改造以及特定厂商网页或媒体源的兼容承诺。

TaskPool并发取消与结果归并方案架构方案图

先定义串行基线和任务粒度

方案准备多组像素直方图数据，每组任务只接收ArrayBuffer和taskId，子线程返回统计结果，不引用UI组件、Context或页面单例。调度器限制同时执行的任务数，并为每批次分配batchId；用户重新开始时，旧批次结果可以返回，但不会进入当前列表。

状态数量不是越多越好。每个状态必须回答三个问题：当前允许哪些命令、收到迟到事件怎样处理、页面退出后是否还可以更新UI。下面的状态对象携带operationId，新的操作开始后，旧操作回调会被拒绝。

export enum BatchState {
  QUEUED = 'queued',
  RUNNING = 'running',
  CANCELLING = 'cancelling',
  CANCELLED = 'cancelled',
  MERGING = 'merging',
  DONE = 'done'
}

export interface BatchSnapshot {
  state: BatchState;
  progress: number;
  message: string;
  operationId: number;
  updatedAt: number;
}

export type BatchEvent =
  | { type: 'START'; operationId: number }
  | { type: 'PROGRESS'; operationId: number; progress: number }
  | { type: 'SUCCESS'; operationId: number }
  | { type: 'FAIL'; operationId: number; message: string };

export function acceptEvent(
  snapshot: BatchSnapshot,
  event: BatchEvent
): boolean {
  return event.type === 'START' || event.operationId === snapshot.operationId;
}

设计对象	保存内容	不应该保存的内容
页面状态	可展示阶段、进度、错误摘要	系统对象和页面Context
适配器	Kit实例、监听注册、资源句柄	ArkUI组件引用
业务记录	operationId、版本、恢复点	未脱敏的敏感原始数据
诊断信息	阶段耗时、错误码、能力检测	Token、图片原始内容

跨线程参数如何限制

任务取消采用“双层判断”：能取消的Task调用cancel，已经运行的任务在返回后比较batchId。归并阶段每帧最多消费固定数量的结果，避免Promise同时完成时在宿主线程执行长循环。并发度展示为可调参数，文章记录不同规模下的耗时中位数。

这套分层把系统事实和产品行为分开：Kit适配器负责获得事实，领域对象决定是否接受事件，页面只渲染快照。更换API版本或加入真机能力时，只需要替换适配器；状态归并和异常策略仍可在模拟器中重复验证。

并发度由数据规模决定

下面是主题专属的接入或核心算法代码。示例刻意保留资源创建、前置条件和清理逻辑，因为高频故障往往出现在成功调用之外。

import { taskpool } from '@kit.ArkTS';

@Concurrent
function histogram(buffer: ArrayBuffer, taskId: number): number[] {
  const source = new Uint8Array(buffer);
  const bins: number[] = new Array(16).fill(0);
  for (let i = 0; i < source.length; i++) {
    bins[Math.floor(source[i] / 16)]++;
  }
  bins.push(taskId);
  return bins;
}

export class BatchRunner {
  private batchId: number = 0;
  private tasks: taskpool.Task[] = [];

  async execute(buffers: ArrayBuffer[]): Promise<number[][]> {
    const current = ++this.batchId;
    this.tasks = buffers.map((value, index) =>
      new taskpool.Task(histogram, value, index));
    const values = await taskpool.execute(this.tasks);
    if (current !== this.batchId) return [];
    return values as number[][];
  }

  cancel(): void {
    this.batchId++;
    this.tasks.forEach(item => taskpool.cancel(item));
    this.tasks = [];
  }
}

代码迁入业务工程时，应把错误码转换为稳定的领域错误，不让页面直接判断系统错误字符串。对于异步回调，还要在写入状态前比较operationId或资源版本；仅检查组件是否存在，无法阻止旧任务污染新页面。

取消为什么需要双层判断

故障输入	状态变化	恢复动作
传入UI对象	序列化失败	只传值对象或ArrayBuffer
并发度过高	CPU争用	按核心数和任务规模限流
取消后结果返回	batchId不一致	结果丢弃
归并耗时过长	分帧消费	保持页面响应

异常注入按钮用于稳定复现应用侧恢复路径。真实错误发生时，诊断记录同时保存错误码、权限结果、设备能力和用户可见状态；敏感原始数据不进入日志，截图只呈现与问题直接相关的结果。

结果归并留在宿主线程

页面层不直接调用Kit，而是通过动作按钮驱动同一份状态模型。这样既能在系统能力可用时接真实适配器，也能在模拟器缺少硬件时验证错误页面、幂等逻辑和资源清理。

@Component
struct BatchPanel {
  @State stateText: string = 'QUEUED';
  @State progress: number = 0;
  @State logs: string[] = [];

  private append(message: string): void {
    const time = new Date().toLocaleTimeString();
    this.logs = [`${time}  ${message}`, ...this.logs].slice(0, 8);
  }

  private startDemo(): void {
    this.stateText = 'RUNNING';
    this.progress = 20;
    this.append('开始：TaskPool并发取消与结果归并');
  }

  private injectFailure(): void {
    this.stateText = 'DONE';
    this.append('已注入可恢复故障');
  }

  build() {
    Column({ space: 12 }) {
      Text('TaskPool并发取消与结果归并').fontSize(24).fontWeight(FontWeight.Bold)
      Text(this.stateText).fontSize(18).fontColor('#2563EB')
      Progress({ value: this.progress, total: 100 }).width('100%')
      Row({ space: 12 }) {
        Button('开始实验').onClick(() => this.startDemo())
        Button('注入故障').onClick(() => this.injectFailure())
      }
      ForEach(this.logs, (item: string) => Text(item).fontSize(13))
    }.padding(20).width('100%')
  }
}

实施顺序先完成可序列化的数据合同和纯函数测试，再加入受控并发调度、batchId隔离、任务取消和分帧归并。验收准备1、4、16、64组输入，分别记录串行和TaskPool耗时；执行中触发取消后检查完成数停止增长；连续启动两批任务时，列表只能展示后一批。验收材料包含并发度、队列长度、取消次数和耗时分位数。

并发实验不能只记录总耗时。调度等待、子线程计算、序列化传输和宿主线程归并应分别计时，否则很容易把数据拷贝成本误认为算法变慢。ArrayBuffer用于一次性转移时要明确所有权，仍需在主线程读取的数据不能提前转移。任务异常也不能让Promise.all直接抹掉其他成功结果，批处理返回值应同时包含taskId、状态和耗时。只有输入规模、并发度与失败比例固定，优化前后的结果才具备可比性。页面刷新频率限制在固定节奏，任务完成不等于立即触发一次完整列表重建。

验收记录至少包括SDK版本、模拟器系统版本、操作顺序、预期状态、实际状态和截图编号。快速点击、返回再进入、故障后重试和页面销毁是必测项；涉及资源的主题还要显示活动对象计数，涉及异步任务的主题要验证迟到结果不会改变当前页面。