鸿蒙原生APP开发之应用架构设计(应用并发设计)

往期推文全新看点

• 鸿蒙（HarmonyOS）北向开发知识点记录~
• 鸿蒙（OpenHarmony）南向开发保姆级知识点汇总~
• 鸿蒙应用开发与鸿蒙系统开发哪个更有前景？
• 嵌入式开发适不适合做鸿蒙南向开发？看完这篇你就了解了~
• 对于大前端开发来说，转鸿蒙开发究竟是福还是祸？
• 鸿蒙岗位需求突增！移动端、PC端、IoT到底该怎么选？
• 记录一场鸿蒙开发岗位面试经历~
• 持续更新中……

简介

ArkTS是HarmonyOS APP的开发语言，它在保持TypeScript（简称TS）基本语法风格的基础上，一方面规范强化静态检查提升开发者代码的规范性；另一方面基于TypeScript增强了一些特性提升开发体验和执行效率，尤其是在并发能力上的提升。

本文档主要面向HarmonyOS APP的设计人员或开发人员，介绍应用在并行任务方案设计过程中，可能会遇到的典型场景以及对应的推荐设计方案，同时给出了方案的关键点及参考案例。

典型业务场景

根据当前HarmonyOS APP开发过程中遇到的实际并发业务场景，总结提炼出如下典型场景，可供更多APP参考，设计其并发业务方案。

并发能力整体架构

并发能力概述

并发能力框架如下：

• 主线程： 执行UI业务、不耗时操作、单次I/O任务，与其他ArkTS线程共享系统I/O线程池，不阻塞当前ArkTS线程。
• TaskPool 高并发任务池： 执行耗时任务，基于TaskPool封装任务执行的入口，可统计模块负载，开发者无需管理线程实例的生命周期。
• Worker 线程： 执行常驻任务，CPU密集型、耗时任务，当前限制线程个数为64。
• FFRT 任务池：
  1. 系统任务：系统分发到FFRT线程的业务，例如异步I/O任务等，开发者无需关注；
  2. 用户任务：开发者创建的C/C++耗时任务，支持负载均衡及线程生命周期管理等能力。
• Pthread 线程： 采用C/C++开发的模块，需要后台运行或者耗时的ArkTS无关业务，不限制线程个数。

并发模型与业界模型的差异

共享内存并发模型

共享内存模型指的是采用线程和锁的并发模型，不同线程之间共享内存，通过锁来进行临界区保护。对于不同业务，如果包含I/O操作或者锁，为了业务不被阻塞，需要开启多个线程来执行不同的业务，线程情况如下图所示：

因此，应用上经常存在几百个线程，增加了调度开销和内存占用。

ArkTS并发模型

ArkTS采用了内存隔离的线程模型，不同线程之间通过消息通信，线程内无锁化运行。对于不同业务，其内部的I/O操作会由系统分发到后台的I/O任务池，不阻塞ArkTS上层逻辑，线程情况如下图所示：

异步I/O不阻塞ArkTS线程，同时TaskPool及I/O线程池由系统管理，提升能效。

ArkTS语言支持了TaskPool和Worker的并发能力，接下来简单介绍TaskPool和Worker的功能。

TaskPool的运作机制可参考 TaskPool简介 ，TaskPool提供了任务分发的入口，支持将任务分发到不同优先级的队列，TaskPool底层自动管理了一定数量的工作线程，会从队列获取任务执行。同时，工作线程会根据任务数量进行自动扩缩容，保证任务执行效率。TaskPool内部会根据任务量及当前线程数量，决定是否扩容或缩容，当任务较多时会扩容。线程的上限跟硬件核数相关，例如8核设备，线程数上限大概为7-15左右。

Worker的运作机制可参考 Worker简介 ，空任务的Worker线程的内存占用大约2MB左右，因此需要控制线程的数量，避免内存过大。

ArkTS与传统共享内存并行化的差异

通过上述并发模型的对比，可以看出在ArkTS中的异步I/O操作，会分发到I/O任务池中，不阻塞ArkTS语言的执行。而Java需要大量线程进行阻塞I/O操作，导致线程数较多。

其次，ArkTS采用内存隔离的并发模型，不能跨线程共享对象，需要进行线程间数据通信。而Java可以直接访问不同线程的对象，但是需要使用锁进行数据的线程安全保护。

并发能力选择

概述