从零开始开发纯血鸿蒙应用之探析仓颉语言与ArkTS的差异

〇、前言

截止到本文发布的日期为止，鸿蒙官方所推荐的开发原生鸿蒙应用的语言，有两种，分别是扩展自 Typescript 的 ArkTS，以及华为公司自主研发的仓颉语言。那么，这两种语言在具体开发中，有什么不一样的地方呢？下面一一介绍。

一、IDE 的支持程度不同

鸿蒙版仓颉语言，目前只有 DevEco Studio 支持，但却并没有像 ArkTS 那样出厂就支持，需要通过加装插件的形式去赋予 IDE 解析仓颉代码的能力：

仓颉插件下载地址

二、内置组件的使用方式不同

使用 ArkTS 开发鸿蒙应用时，如果是使用内置组件，那么是完全不用写导包语句的，直接在 build 函数中使用即可；而到了仓颉语言这边，这些内置组件的使用，也必须通过导包语句引入，否则编译器就会标红报错：

只有显式写上 import ohos.component.Text，IDE 才不会报语法错误：

所以，就只是使用内置组件、而不使用自定义组件的情况而言，ArkTS 脚本会比仓颉脚本的行数少很多，因为 ArkTS 脚本文件头没有大量的导包语句。在这里，有必要提供一个建议：在仓颉脚本用导包语句导入内置组件时，都使用 internal 进行修饰，internal 关键字在仓颉语言中，具有如下作用：

在仓颉编程语言中，internal 是一个访问修饰符，用于控制声明的可见性。具体来说，internal 修饰的声明在其当前包及子包（包括子包的子包）内可见。这意味着，使用 internal 修饰的元素可以在同一包内或该包的任何子包中被访问，但不能跨模块访问。

在如图的两个构建应用UI的仓颉脚本中，共同地使用到了 Column 等内置组件，但是 second_page.cj 文件中，并没有出现 Column 的导包语句，IDE 也没有提示语法错误，这正是因为 index.cj 文件中在导入 Column 组件时，使用 internal 修饰了导包语句，对比之下，因为没有使用 internal 修饰的 Text 组件，就需要在两个文件中都显示写明导包语句。

总结地说，用好 internal 修饰符，可以让仓颉脚本减少重复的导包语句。

其实，就在上面那张图中，如果仔细看文件头，就会发现 package 开头的一行代码，这也是仓颉脚本与 ArkTS 脚本的区别。

使用仓颉脚本去构建鸿蒙UI，类似于 Jetpack Compose 构建安卓 UI，特别时代码脚本的头部：

三、页面路由实现方式的不同

同样适用内置的 router 模块进行页面路由时，ArkTS 构建的页面，必须在 resources 目录下的 main_page.json 文件中，注册对应的页面 url，而用仓颉代码构建的页面，则无需如此操作。我猜测，仓颉脚本中 package 语句，在一定程度上具有页面 url 声明定义的功能。

四、总结

仓颉语言与ArkTS之前，除了上面这些大方面上的差异，还存在很多细节上的差异，有兴趣的，可以自行探索。