鸿蒙应用开发到底选哪门语言？这个问题在白皮书里其实有明确答案——不是"选哪一门"，而是"怎么组合"。ArkTS主攻UI和快速迭代，仓颉扛起高性能和并发计算，C/C++守住底层和硬件加速。三套工具各有定位，选型的关键不是语言本身，而是你的业务场景落在哪个性能象限里。

ArkTS基于TypeScript，保留了TS的基本语法风格，鸿蒙开发者可以通过极简语法快速上手。白皮书将其核心价值概括为"易学易用、生态丰富、极简开发、持续创新"。适用场景明确：动态更新业务场景、与TS/JS高效互通场景、快速构建等场景建议优先选择ArkTS。

ArkTS的类型系统在TS的基础上做了收敛：不支持结构化类型、不支持更改对象布局、强制编译时空安全检查。这三条规则在保持语法亲和力的同时，提升了大型应用的长期可维护性和运行时可靠性。对于大多数应用开发者来说，ArkTS是进入鸿蒙生态的首选路径——它有最丰富的UI组件库、最完整的开发工具链、最成熟的社区生态。

仓颉走的是完全不同的技术路线。静态类型、静态编译、全栈垂直优化——这三个关键词定义了仓颉的本质。它的适用场景包括高吞吐量/高频读写的数据处理、高频交互高负载场景、启动时延敏感场景。在这些场景中，仓颉的静态编译执行能力、轻量用户态线程和低时延GC能够提供接近C/C++级别的性能表现。

仓颉的差异化竞争力来自四个维度的叠加：高性能（M:N线程模型、亚毫秒GC、静态编译优化）、强安全（静态类型、自动内存管理、多重运行时检查）、跨平台（一码编译到六大主流OS平台）、智能化（Agent DSL）。它不是ArkTS的替代品，而是ArkTS在性能敏感场景的搭档。

C/C++在鸿蒙中的定位是最底层的支撑层。白皮书的表述很谨慎："当前鸿蒙的开放策略明确以ArkTS优先，CAPI则遵循谨慎提供原则"。开放CAPI的场景有严格的边界：极致性能与硬件加速（高性能IO、CPU密集计算、音视频编解码、图形计算、硬件指令集优化）、生态框架兼容（Unity、Electron、CEF等）、行业标准与约定场景。

C/C++通过NDK提供完整的编译工具链、系统CAPI接口和C++运行时环境。基于开源的MUSL库优化libc，采用LLVM15版本的libc++提供标准C++支持，毕昇编译器作为官方C/C++编译器。C/C++的优势在于没有运行时开销、完全可控的内存管理、可以直接操作硬件指令集——但这同时也意味着更高的开发门槛和更长的调试周期。

Node-API是ArkTS与C/C++交互的官方通道。ArkTS侧通过import加载Native模块，引擎加载so文件并注册导出方法；调用时引擎找到对应的C/C++方法执行。这套机制基于Node.js 18.x LTS的N-API规范扩展开发，提供稳定的跨平台API。

混合开发的价值在于：UI层用ArkTS快速迭代，性能敏感的核心模块用C/C++实现。游戏引擎、物理仿真、音视频编解码等场景都可以通过Node-API封装为ArkTS可调用的模块，开发者无需在效率和性能之间做非此即彼的选择。

仓颉与C的互操作在设计上追求极致效率。白皮书用完整的代码案例展示了"零拷贝"的实现：C侧产生大段文本，仓颉侧先获取字节长度，创建精确大小的Array，获取数组原始指针传给C侧直接写入UTF-8数据，最后零拷贝构造String。整个过程没有一次内存拷贝。关键机制包括：inout关键字将仓颉栈上变量引用传递到C侧避免拷贝；@FastNative注解减少跨语言调用运行时开销；Array原始指针传递避免大块内存拷贝。对于C++代码，需要先封装为C接口再由仓颉调用。这一套互操作机制使仓颉在需要频繁与底层交互的场景中保持极低的开销。

仓颉与ArkTS的互操作通过ohos.ark_interop库实现。ArkTS调用仓颉时，开发者需要在仓颉侧实现接口并注册导出；仓颉调用ArkTS时，通过requireArkModule加载NAPI模块或ABC模块并调用导出函数。

为了降低手写互操作代码的复杂度，仓颉提供声明式互操作宏@Interop[ArkTS]，编译阶段自动生成胶水层代码和ArkTS接口声明。DevEco Studio也提供工具对ArkTS库进行互操作自动封装。未来演进方向包括双向互操作的声明宏、跨语言混合栈调试、Extern类型作为中立数据载体实现非侵入式动态类型传播。

垃圾回收暂停时间是衡量语言运行时性能的关键指标。白皮书披露了仓颉并发GC的具体数据：应用线程完成GC同步的平均耗时小于2毫秒，典型情况下在百微秒量级。这一数据比传统的STW GC或近似并发GC有数量级的提升。

ArkTS的GC机制同样针对鸿蒙应用场景做了精细优化。敏感场景中将GC触发水线临时调高避免卡顿；后台场景中利用闲时GC触发压缩GC回收内存。ArkTS支持强引用和弱引用两种引用类型，开发者可以通过WeakMap/WeakSet/WeakRef在缓存、元数据等场景中防止内存泄漏。

仓颉采用数据共享的多线程模型，提供轻量用户态线程和M:N线程调度。开发者通过spawn语法即可创建仓颉线程，无需手动标记async/await，没有"函数染色"问题。调度支持抢占，阻塞时native线程会挂起当前仓颉线程并调度下一个就绪线程。

ArkTS的并发模型基于TaskPool和Worker。TaskPool支持开发者提交任务到队列，系统自动调度到工作线程执行，支持负载均衡和弹性扩缩容。Worker需要开发者自行创建和管理。Sendable类型支持线程间引用传递对象无需拷贝，配合异步锁机制和对象冻结接口避免数据竞争。TaskPool适用于大多数并发场景，Worker适用于需要精细控制的后台服务场景。

仓颉的静态编译特性使应用在启动时直接执行优化后的机器指令，无需解释器预热或JIT编译，冷启动时间有天然优势。编译器通过函数内联、冗余代码消除和LTO能力最大程度降低代码产物大小。

ArkTS通过动态加载（异步函数动态导入）和延迟加载（import lazy关键字）优化启动性能。两者的对比数据：动态加载控制粒度精细适合功能独立模块，延迟加载自动触发适合快速实现懒加载的模块。

动态更新业务场景、与TS/JS高效互通场景、快速构建场景优先选择ArkTS。UI开发是ArkTS的绝对主场，声明式UI语法和丰富的组件库使界面开发效率远高于CAPI。对于大多数应用开发者，ArkTS是进入鸿蒙生态的最佳入口。

高吞吐量/高频读写的数据处理场景、高频交互高负载场景、启动时延敏感场景优先选择仓颉。涉及金融交易等安全敏感场景中，仓颉的静态类型系统和自动内存管理能有效消除整型溢出和内存类安全漏洞。需要跨平台一码三端（鸿蒙、Android、iOS）的场景中，仓颉的跨平台编译能力可以大幅降低维护成本。

游戏引擎、物理仿真等计算密集型任务场景、需要深度优化CPU指令集的专用算法库硬件加速场景优先选择C/C++。生态框架兼容场景（Unity、Electron、CEF）中，C/C++是必要的底层支撑。行业标准与约定场景中，需要满足合规或互操作性要求时开放相应的CAPI。

三种语言不是互斥关系，而是协作关系。UI层用ArkTS快速迭代，高性能计算模块用仓颉或C/C++实现，通过互操作机制打通。白皮书的核心建议是：根据业务场景需要，选择使用ArkTS、仓颉和C/C++进行特性开发，三种语言相互配合、互不替代、长期演进。