鸿蒙高性能API设计理念（上）

本次分享主要分为四个部分：首先概述API的基本介绍，这部分内容在开发过程中较为熟悉；其次讲解哪些API提供同步方式，哪些提供异步方式及其设计原因；第三部分介绍开发者在ArkTS中使用并发能力的途径；最后讲解sendable API，即开发者在并发场景下高效使用API的方法。

一、鸿蒙API介绍

本部分将介绍鸿蒙API的分类，这些基础知识后续会频繁提及，因此仅作简要说明。鸿蒙API位于操作系统层之上，应用层之下，其作用是将系统能力全面开放给开发者，使其能够基于这些API开发应用。从使用角度来看，API可分为两类：系统API和公开API。

系统API仅限系统应用使用，如桌面、设置等系统级应用。这类API权限较高、敏感性较强，第三方应用无法使用。但若开发者参与OpenHarmony商业发行版开发（鸿蒙是OpenHarmony商业发行版之一，OpenHarmony本身是开源项目），作为第三方厂商开发自己的商业发行版时，则可以使用这些API。

重点来看第三方应用可使用的API。这里的第三方应用包括微信、支付宝、美团等，开发者开发的应用均属此类。第三方应用可使用ArkTS API和C API进行开发。鸿蒙主推的应用开发语言是ArkTS，目前ArkTS API数量已达4万至5万个，其能力已完全支撑生态发展。在已发布的5.0版本中，其能力可支撑TOP5000应用，后续还将补充新能力，使开发者能够调用鸿蒙的更新功能。C API数量相对较少，在已发布版本中约有4-5千个。这是因为C语言开发灵活性较低、门槛较高，但其性能优势明显。选择ArkTS还是C API主要取决于应用对性能的要求。

头部厂商（如微信、支付宝、美团）由于团队规模较大，通常更关注代码复用以节省开发成本。这些头部厂商大多拥有自己的三方框架或使用业界通用框架（如ReactNative、Flutter）。对于业务庞大的头部应用，为减少跨平台开发人力投入，他们倾向于通过三方框架对接C API，使应用能在不同操作系统上运行。因此，C API主要服务于三方框架。当然，不使用三方框架的开发者也可使用C API，但其使用相对复杂，且功能可能无法满足所有开发场景。

从其他角度对API进行分类：

1. Test API：部分公开API仅限于测试用例中使用，例如获取UI结构、调试节点数量等，还包括测试用例断言相关API。
2. Form API（卡片API）：鸿蒙元服务特有的万能卡片能力，开发的卡片与常规应用不同，功能有限但短小精悍，属于公开API的一部分。
3. Cross Platform API：仅限跨平台项目使用的API。这里的跨平台指操作系统平台，使用这些API开发的应用不仅能在鸿蒙系统运行，还可兼容Android和iOS系统。OpenHarmony作为开源项目支持跨平台使用，感兴趣者可参考ArkUI-X项目了解如何使用OpenHarmony开发跨平台应用。

以上是鸿蒙API分类的介绍。

二、鸿蒙为什么需要异步的API

若开发者有Android或iOS开发经验，可能会认为鸿蒙的异步API较难使用。因为在Android和iOS中，代码按顺序逐行执行，这种同步方式更符合直觉。而异步API不保证代码执行顺序，发起请求后立即执行下一行代码，待结果返回后才处理响应，这与预期顺序不一致，因此可能造成使用困扰。

鸿蒙设计大量异步接口的原因在于：虽然Android和iOS以同步接口为主（这种转变可能带来不适应），但对于前端开发者而言，鸿蒙ArkTS基于TypeScript演进，其异步API的使用体验与JavaScript开发习惯高度契合。同步与异步API并无优劣之分，只是技术栈差异导致的习惯不同，开发者需要适应过程。

对比两种编程方式：

1. JAVA/C的同步方式：处理耗时操作时，为避免影响主线程（如UI动画），会创建子线程执行文件读取、网络下载或密集计算等任务，完成后将结果返回主线程。
2. ArkTS的异步方式：前端开发者更熟悉此模式，开发者无需过多关注执行顺序问题。文件操作和网络请求等均采用异步方式，使开发者能在主线程同时处理动画、文件管理和网络请求，无需考虑线程创建或竞争锁问题。但密集计算仍需创建子线程，实际API实现中后台操作仍在其他线程执行，只是对ArkTS开发者隐藏了线程管理细节。

需要说明的是，这两种并行设计理念各有特点，不存在优劣之分，关键在于开发者适应。

观察业界趋势：虽然Java和Objective-C以同步API为主，但Android应用启动时并行数百上千线程的问题促使异步API的推广。目前Java和Swift都开始提供异步接口，以适应不同开发场景和开发者习惯。

三、鸿蒙同步和异步API设计规范

基于上述分析，下面说明哪些API提供同步方式，哪些提供异步方式，以及同时提供两种方式的情况。

（一）仅提供同步API的情况：

1. 继承自JavaScript/TypeScript的语言内置方法，如setTimeout、事件订阅类on()/off()等，为保持与业界一致性，仅提供同步方式。
2. 实时性要求极高的API，即该API未完成时其他API无法执行。例如栈操作（压栈/弹栈）必须保证顺序执行。
3. 运算简单的API：快速完成且无需异步处理的场景。内部规则定义为：

• • 仅涉及内存数据获取或简单计算
  • 不涉及I/O操作（如硬盘读写、外设访问）
  • 若涉及IPC调用，且远端无耗时操作、单次IPC即可完成
    这类API约占鸿蒙API总量的三分之一。

（二）仅提供异步API的情况：
核心规则：执行时间长且受外界影响导致耗时不确定的API。具体包括：

1. 网络请求：受网络状况影响，响应时间不确定
2. 长时间运行的后台任务：执行进度不可预估
3. 需要用户交互的API：如弹窗等待用户确认操作

（三）同时提供同步/异步API的情况：
除上述两类外，其他API优先提供异步版本，根据开发者需求补充同步版本。适用场景包括：

1. 执行时间长但外界影响小的操作：

• • 文件读写、数据库操作等I/O类任务（耗时与数据量成正比）
  • 开发者可预估操作时长（如读取配置文件适合同步，大文件处理适合异步）

1. 耗时但可预期的操作：图片/音频解码等
2. 涉及IPC通信且执行复杂的API：优先提供异步方式，按需补充同步实现

--未完待续--

鸿蒙高性能API设计理念（下）-CSDN博客

 更多内容请参见视频教程：《HarmonyOS应用开发实战指南》