人工智能

华为仓颉 1.2.0 发布：新增 Android aarch64 支持，强化 iOS LTO 与工具链能力

2026年9月23日 · admin

据 IT之家 9 月 23 日消息，华为仓颉编程语言已发布 1.2.0 版本。来源显示，该版本属于 STS 通道，维护周期为 6 个月；同时，STS 1.1.x 版本计划在 2026 年 10 月 30 日停止维护。与 1.1.3 相比，仓颉 1.2.0 的更新重点集中在跨平台能力、编译器稳定性与工具链体验三方面，尤其补强了 Android、iOS 以及 Objective-C / Java 互操作相关能力。

跨平台能力继续补齐：面向鸿蒙生态之外的工程场景

仓颉是华为自研的现代编程语言，官方定位为面向全场景智能应用开发的新一代语言，强调原生智能化、全场景、高性能与强安全等特性。其主要应用方向包括鸿蒙原生应用及服务应用场景，但从此次更新可以看到，仓颉并未只围绕单一系统环境演进，而是在持续强化跨平台开发基础。

本次 1.2.0 新增了 Android 23（API 23）aarch64 支持，并将 LTO 支持扩展到 iOS 平台。LTO 即链接时优化（Link Time Optimization），是一种在链接阶段进行跨模块优化的编译技术。此前 1.1.0 已在交叉编译至 linux-x64-ohos 场景中新增 LTO 支持，此次拓展到 iOS，意味着仓颉在移动端多平台构建与性能优化方面继续推进。

此外，跨语言互操作能力也有增强，涉及 Objective-C 与 Java。对开发者而言，这类能力的意义在于降低与现有生态对接的成本：移动端已有大量系统能力、SDK 与业务模块沉淀在 Java、Objective-C 等语言体系中，仓颉若要进入更多实际工程，就需要更好地复用既有资产，而不是要求团队完全重写。

编译器与语义问题修复：语言成熟度的关键指标

来源摘要显示，仓颉 1.2.0 还优化了编译器稳定性与性能，修复了一批语义 ICE 问题，包括 broken 声明重载排除、const 函数 ICE、字符串插值位置信息、synchronized 块声明拒绝等。ICE 通常指编译器内部错误，这类问题虽然未必直接体现为新功能，但会显著影响开发者对语言可用性和工程可靠性的判断。

对一门仍在快速演进的编程语言来说，版本更新不只是增加语法或平台支持，更重要的是让工具链在复杂项目中保持可预期。尤其仓颉定位“全场景智能化应用开发”，未来如果要承载鸿蒙原生应用、服务应用以及更多跨端业务，编译器稳定性、诊断准确性和构建性能都会成为开发团队评估采用成本的重要维度。

工具链更新：IDE 体验成为生态建设抓手

此次更新还涉及 LSP 与相关工具链能力。LSP 新增跨平台跳转定义、接口提取 / 重命名、数组索引提取等能力，并包含主线程 GetArkAST 移除、cjo 字节 intern 去重等调整。对于开发者来说，语言本身是否现代化固然重要，但日常效率往往由 IDE 提示、重构、跳转、诊断和构建链路共同决定。

版本通道：1.2.0 属于 STS 版本，维护周期 6 个月。
平台支持：新增 Android 23（API 23）aarch64 支持，并扩展 iOS LTO 能力。
互操作：增强 Objective-C / Java 跨语言互操作，利于复用既有生态。
工具链：LSP 补充跳转、重构与提取能力，提升工程开发体验。

影响解读：仓颉正在从“发布语言”走向“可工程化使用”

仓颉项目启动于 2019 年，2024 年 6 月在华为介绍“纯血鸿蒙”时首次发布，2025 年 7 月 30 日正式开源，开源内容包括编译器、运行时和标准库等。鸿蒙生态目前支持 ArkTS、仓颉和 C/C++ 三类语言，它们面向不同开发需求相互补充。

从 1.2.0 的更新方向看，仓颉的演进重点已经不只是语言概念展示，而是转向更实际的工程落地：支持更多平台、减少编译器异常、增强互操作、完善 IDE 工具链。对于中文开发者和企业团队来说，仓颉后续能否形成足够稳定的版本节奏、丰富的库生态和可迁移的工程实践，将决定它在鸿蒙及更广泛智能应用开发中的采用速度。