|
| 1 | +--- |
| 2 | +layout: default |
| 3 | +title: AutoDev 1.6.4:HarmonyOS 应用开发体验提升 |
| 4 | +nav_order: 7 |
| 5 | +parent: 更新日志 |
| 6 | +--- |
| 7 | + |
| 8 | +生成式 AI 在软件研发和知识管理上,有着非常大的潜力,也因此这项技术被越来越多的企业所采用。而在一些新兴的技术上,诸如于鸿蒙操作系统,它带来了一些新 |
| 9 | +的理念、开发工具 DevEco Studio、新的语言 ArkTS、新的 UI 框架 ArkUI 等等。从模式上来说,它与生成式 AI 结合企业内部的基础设施过程非常相似。 |
| 10 | + |
| 11 | +因此,我们开始在 AutoDev 中探索如何结合这些新知识的可能性,同时降低开发人员的学习负担。 |
| 12 | + |
| 13 | +源码:https://github.com/unit-mesh/auto-dev |
| 14 | + |
| 15 | +## 鸿蒙操作系统 + 生成式 AI 的三个试验式功能 |
| 16 | + |
| 17 | +在初步听鸿蒙团队介绍完 HarmonyOS 的一些自研工具之后,便有了三个在 AutoDev 试验的思路: |
| 18 | + |
| 19 | +- 添加 ArkTS 支持。ArkTS 是鸿蒙生态中基于 TypeScript 扩展的应用开发语言。 |
| 20 | +- 自动 ArkUI 页面生成。ArkUI 是一套构建分布式应用界面的声明式 UI 开发框架。它与我们先前引入的 AutoPage |
| 21 | + 并没有太多的区别,可以结合思维链进行代码和 UI 生成。 |
| 22 | +- UI 布局迁移。即将其它语言、框架编写的代码,交由生成式 AI 转化成适用于鸿蒙的代码。 |
| 23 | + |
| 24 | +作为阅读过 Gradle、Intellij Community、DevEcoStudio 源码,以及《前端架构:从入门到微前端》作者,我大抵算是对于 TypeScript、 |
| 25 | +ArkUI、 |
| 26 | +声明式 UI 有一定的经验,所以我自信的开始了 AutoDev 的新功能开发 —— 然后就踩了一堆坑。 |
| 27 | + |
| 28 | +## 1. ArkTS 语言的 AI 支持 |
| 29 | + |
| 30 | +在我下载安装完 DevEco Studio 之后,发现 AutoDev 居然不支持 TypeScript???经过我在 WebStorm 反复测试后,发现是 IDE 的关系。结合 |
| 31 | +PSIViewer 插件后, |
| 32 | +才发现差异之后,DevEco Studio 的 JavaScript/TypeScript |
| 33 | +语言是自己实现的,诸如于:`com.huawei.ace.language.psi.impl.JavaScriptIdentifierNameImpl`。 |
| 34 | + |
| 35 | +原因不外乎: |
| 36 | + |
| 37 | +- Intellij 平台中的 JavaScript 插件是收费的,没有开源版本。 |
| 38 | +- 鸿蒙直接针对于 TypeScript 语法进行扩展,会比实现一个新的更简单。 |
| 39 | + |
| 40 | +所以 DevEco Studio 自研了一个 JavaScript/TypeScript 模块,支持 JavaScript 语法高亮、代码提示、代码格式化等功能。与此同时,DevEco |
| 41 | +Studio |
| 42 | +添加了 ArkTS 语言,即 TypeScript 扩展语法。 |
| 43 | + |
| 44 | +这就意味着,使用 DevEco Studio + AutoDev 时,会出现三种新的文件类型: |
| 45 | + |
| 46 | +- Huawei JavaScript |
| 47 | +- Huawei TypeScript |
| 48 | +- Huawei ArkTS |
| 49 | + |
| 50 | +头疼。。 |
| 51 | + |
| 52 | +为此,在 AutoDev 中采取的方法是,其于标准 PSI 做初步的抽象,以实现对于文档生成的支持。而如果要做好则需要: |
| 53 | + |
| 54 | +1. 基于反射来重复利用 JavaScript PSI |
| 55 | +2. 融入 DevEco Studio 的 JavaScript 支持 |
| 56 | + |
| 57 | +当然,考虑到调试上的难度,以前代码中各种现的 xxStudio 字眼(新的自研 IDE 平台??),我暂时放弃了上述的做法:大体上鸿蒙 IDE |
| 58 | +会有自己的 AI 能力。 |
| 59 | + |
| 60 | +## 2. AutoArkUI:RAG 增强的 ArkUI 代码生成 |
| 61 | + |
| 62 | +> ArkUI 是一套构建分布式应用界面的声明式 UI 开发框架。 |
| 63 | +
|
| 64 | +与 ArkTS 相比,要结合 ArkUI 显得稍微复杂一些。 所以,我在当前版本里考虑的是:结合经典 UI 的元素生成页面,即: |
| 65 | + |
| 66 | +- 布局。诸如于:线性布局(Row、Column)、层叠布局(Stack)、弹性布局(Flex)等。 |
| 67 | +- 组件。诸如于:按钮(Button)、单选框(Radio)、切换按钮(Toggle)等。 |
| 68 | + |
| 69 | +而由于 ChatGPT 是不包含 HarmonyOS 的最新知识的,所以需要采用类似于 AutoPage 的两步生成特性。 |
| 70 | + |
| 71 | +1. 分析用户的需求,选择合适的布局与组件。 |
| 72 | +2. 根据用户的需求与详细的布局、组件信息,生成对应的 ArkUI 代码。 |
| 73 | + |
| 74 | +上述的两步便是 AutoDev 中 AutoArkUi 生成 UI 的特性,详细可以参考 AutoDev 的代码,以及对应的 prompt。如下是对应的步骤 1 的 |
| 75 | +prompt: |
| 76 | + |
| 77 | +- User: // maybe send Android Layout code, maybe some requirements |
| 78 | +- Your Answer: [FlexLayout, Button, CheckBox, Checkbox, Button] |
| 79 | + |
| 80 | +考虑到编程语言 DSL(领域特定语言)极易受用户语言的影响,所以采用的是英语的方式,避免无端生成中文 DSL 。 |
| 81 | + |
| 82 | +## 3. 迁移 Android/iOS/小程序 应用 |
| 83 | + |
| 84 | +生成式 AI 具备极好的代码翻译能力。诸如于 IBM 在 Cobol 转化为 Java 上的工程化设计,以及我们在 AutoDev 中设计的遗留系统改造能力,其所针对的 |
| 85 | +都是生成 AI 在这方面的能力。 |
| 86 | + |
| 87 | +所以,我们也在 AutoDev 中内置了这个功能,只是当前支持的只是布局上的迁移。但是,考虑到这种生成方式依旧有一系列的问题,有待我们进一步寻找更好的方式。 |
| 88 | +类似的问题在生成 ArkUI 也是存在的。 |
| 89 | + |
| 90 | +相似的,这个功能目前是与 AutoArkUI 融合在一起的,理论上通过静态代码分析是最简单的,有待未来进一步完善。 |
| 91 | + |
| 92 | +## 4. RAG 增强的聊天上下文:C++ NAPI 等 |
| 93 | + |
| 94 | +在试验了多次之后,会发现对于 HarmonyOS 这种新知识,ChatGPT 是不知道的。所以,需要基于 AutoDev 的上下文接口,创建基于 |
| 95 | +HarmonyOS 的上下文。 |
| 96 | +当然的版本(1.6.4)里, 添加的是:`This project is a HarmonyOS project.` (毫无意义的废话),再结合不同语言来写一些上下文: |
| 97 | + |
| 98 | +- TypeScript/JavaScript/ArkTS. Which use TypeScript (ArkTS) as the main language, and use Flutter like TypeScript UI |
| 99 | + framework. |
| 100 | +- CPP/"C/C++"/CCE. Which use C++ as the main language, and NAPI for building native Addons. |
| 101 | + |
| 102 | +大体来说,就是告诉 AI: |
| 103 | + |
| 104 | +- 编写 ArkUI/前端代码的时候,考虑一下这个项目是类似于 Flutter 的声明式 UI 。 |
| 105 | +- 编写原生代码的时候,考虑一下这个项目是基于 NAPI 来构建插件的。 |
| 106 | + |
| 107 | +当然了,这些是基于我的初步理解所构建的上下文, |
| 108 | + |
| 109 | +## 未来 |
| 110 | + |
| 111 | +考虑到上述的功能,就是几小时内实现的,就不要有太高的期望了。 |
| 112 | + |
| 113 | +当前版本依旧有诸多问题: |
| 114 | + |
| 115 | +- 转换 Android 布局易瞎编。除了需要知道更多的转换规则,还需要知识更多的属性,而这些部分是通过传统的代码分析工具解决的 |
| 116 | +- 组件和布局信息的 hardcode。懂的都懂 |
| 117 | +- 缺少示例代码。没有动态生成的示例代码,使得 RAG 的效果是有限的 |
| 118 | +- 诸如于 C++ 语言的支持 |
| 119 | +- 微信小程序等小程序平台的转换 |
| 120 | + |
| 121 | +然而我并非 Android、小程序应用迁移到鸿蒙应用的专家,所以还是有一系列的挑战。等我心情好的时候,再考虑写一些更好玩的新特性。 |
0 commit comments