十年 Androider 写了两个月 uni-app x

时光荏苒，岁月如梭。

自 2014 年开始接触 Android 至今已有十年之久，自己也没有想到会在这一行业 “耕耘” 这么长时间。

随着各种跨平台技术的涌现，目前的 Android 原生开发就如 2017 年的 iOS 开发，已是明日黄花。

跨平台技术最大的优势就是一套代码适配多个平台，亦如当年的 Java 一次编译到处运行。

跨平台技术凭借着这个优势迅速崛起，其中不乏一些优秀的框架，例如：flutter，compose，uni-app x等。

笔者把玩过一段时间的 compose，对于 flutter 的了解还是在它发布的时候。

flutter 首先需要学习 Dart 语言，对于大部分程序员学习另外一门语言的成本不是很高。Dart 语言笔者不做过多评价，参考网上的评价：“flutter 苦 Dart 久已”。鉴于笔者对 flutter 了解的不多，对 flutter 就不过多展开了。

compose 基于 Kotlin 语言，大部分 Android 开发者对 Kotlin 还是比较熟悉的，毕竟目前是 Android 开发的首选语言。compose 可以说将 Kotlin 语言特性发挥的淋漓尽致，什么高阶函数，委托属性，DSL，协程，KCP 等，只能说玩的太6了。

总得来说，这两个框架都很优秀，但其中的学习成本和心智负担还是比较高的。

uni-app x 基于 Vue3 框架，使用 UTS 语言(即 TypeScript 语言的变种，是一种强类型语言)，对于有 Java 或 Kotlin 语言经验的程序员来说，学习 UTS 语言基本没有成本。

笔者之前也没有了解过 Vue，花费了一周左右的时间过了一遍 Vue 的官方文档和官方示例，对 Vue 就有了一个基本的了解，总结起来无非是响应式编程，数据驱动视图，与 flutter 和 compose 类似，理解了其中一个，再理解其他的响应式框架就容易多了。

由于笔者之前把玩过一段时间的 OpenHarmony，OpenHarmony 使用 ArkTS 语言，ArkTS 语言也是基于 TS 语言的变种，所以对 TS 语言有一定的了解，那么对于学习 UTS 语言也有一定的帮助。笔者花费了一上午的时间了解了 UTS 语言的数据类型、函数、类、接口等基本语法。

开发 uni-app x 目前只能使用 HBuilder X 这款 IDE，为统一话术，以下简称HBX，以下是笔者在这两个月里使用 HBX 的一些感受。

最直观的感受就是 HBX 启动很快，打开文件也很快，这与其官网介绍的第一个特性「轻巧、快速」比较相符，不像现在的 AS 启动半天，打开项目后再 Gradle Sync 半天，最后再告诉你 Sync 失败 😂，而且 AS 打开一个项目占用的内存不是一般的多，在笔者 16G 内存的台式机上 AS 最多打开两个项目，并且还不是很大的项目，相比之下 HBX 的内存占用就小了太多，而且还可以管理多个项目，这点与 Eclipse 类似，相信还有不少 Java 程序员还在使用 Eclipse。Jetbrains 公司的全家桶 IDE 是很强大也很好用，但是内存占用大是它们的一个“硬伤”。

对于官方提到的 「强大的语法提示」这一特性，笔者在使用过程中感受不深，因为经常不提示代码或者代码提示的比较慢，代码补全也有一点不太智能，例如补全类名的时候会把后面的函数名删除掉，替换方法名时还会补全双括号。在写 style 样式输入数字时总会因为代码提示而选择了提示的代码，我明明以设置了 Alt + 数字才会选择提示的代码。在写 UTS 代码时，莫名其妙的没有了代码提示，也不能转到定义，要不就是 Ctrl + 左键识别了一个不是单词的代码变量。总得来说，词法和语法的分析能力并没有官方描述的那么强大。

在使用 HBX 的过程中最不能忍受的是不能类似 AS 那样快速重命名变量(可能是笔者没有发现)，HBX 的「选择相同语法词或配对符号」功能在笔者这里没有效果，而「选择所有相同词」功能会把不是变量的单词选中。目前笔者只能通过 Alt + J 快捷键选择相同的词后再进行多光标编辑，搞到最后笔者只能尽量起一个符合业务逻辑的变量名，尽量减少变量重命名。

HBX 竟然支持条件编译，这就有点 C、C++ 的影子，看来 HBX 也是吸收了前人的经验。

HBX 的控制台竟然不支持搜索和过滤，对于输出的日志信息也是比较杂乱的，这一点还能忍受。

总得来说，HBX 还是需要优化，特别是词语与语法分析这块。编译器也需要优化，笔者在代码中写的变量明明是一个对象类型，编译的时候非得说是一个数组，试了重启 HBX 和清空缓存重新编译也不行，没办法，最后只能把变量改成数组类型。

聊完 HBX，再聊一聊 uni-app x 的内置组件。如果你不是开发特别复杂的 UI 效果，内置组件基本能满足你的需求，一旦你有复杂的效果就得自己写组件，或者在插件市场寻找 UI 组件。好用的 UI 组件需要付费，免费的组件不好用😄。反正笔者在这两个月里写了近 30 个组件。

uni-app x 的内置组件也有不少 Bug。这些 Bug 可能会导致你实现不了一些 UI 效果，严重的会拖慢你的项目进度。例如，以下是笔者或群友遇到的 Bug:

• @transitionend 事件某些情况下不回调，导致笔者的动画效果无法实现，
• uni.createSelectorQuery 在 template 有多个根节点时无效，这个 Bug 还好，只有一个根节点即可避免，
• scroll-view 里 position: absolute 的子组件处于 overflow: visible 子组件范围内时无法获取 touch、 click、 tap 事件，导致 UI 效果无法实现，UI 看上去比较丑，
• scroll-view 加载较多数据时 UI 显示错位，
• list-view 中 list-item 在某些情况下点击事件获取到的 index 不正确，导致你的项目延期。
• 等等。

总得来说，uni-app x 的内置组件能用，并且组件生态目前较为匮乏，官方也没有积极的完善组件生态，推出几个插件大赛，获奖的插件基本都收费，这种情况可能劝退了一批开发者，毕竟不像 uni-app 的生态比较完善，而且 uni-app 大多数都是前端开发者，不行就自己手撸一个插件，但是对于 uni-app x 一定程度上需要开发者了解 Android 或者 iOS 的 API，这对于本身是 Android 或 iOS 的开发者来说不是什么难事，然而让前端开发者去开发原生插件就比较困难了，一定程序是阻碍了 uni-app x 的发展，所以需要官方尽快推进生态的完善。

接下来聊一聊 uni-app x 的文档。整体上文档还是说得过去的，模块的划分，章节的分隔等比较合理，看得出来是经过精心思考设计的，但是在文档细节方面还需要打磨，一些细节描述的不明不白。

下面列举一些笔者认为有问题的地方：

• 修改AndroidManifest.xml：此处应该描述下修改的是哪个模块的 AndroidManifest.xml 文件，
• Kotlin 专有数字类型：此处在描述 number 数字类型，突然提到 ByteArray 类型，而在描述 Array 数组类型时却对 ByteArray 类型一笔带过。此处描述的 ByteArray 与 string 类型的转换笔者认为应该出现在 string 类型或者 Array 类型的描述中，毕竟谁会去 number 类型里找它俩的转换方法呢？
• 拦截器：此处文档没有描述 Interceptor 类型的详细信息，只能参考官方示例，
• 获取窗口信息：此处文档没有描述什么是安全区域？笔者认为应该描述一下，最好带有图示，
• DOMRect：此处文档没有描述 DOMRect 的参考系，是以屏幕为参考还是以 Window 为参考？
• UniTouchEvent：此处文档对 pageX 和 pageY 属性的描述是 “相对于文档左边或顶部的距离”，文档并没有描述 **「文档」**是什么？也没有描述其与 DOMRect 的关系，它俩如何对应，如何协同？
• 等等。

以上问题都很让人摸不着头脑，开发者只能慢慢摸索，徒增开发时间。

最后，笔者再说下这两个月开发过程中与官方交流的感受。

首先官方给人的感觉是有点力不从心，或者说人手有限，不足以支撑 uni-app x 的迭代，导致目前 uni-app x 的迭代周期很长，由于 uni-app x 强依赖 HBuilderX 这款 IDE，而 HBuilderX 的更新周期较长，有 Bug 必须等官方修复更新 HBuilderX，这将导致项目无法推进而延期，对小公司想快速迭代功能抢占市场来说这将是致命的，从这一点看，DCloud 对 uni-app x 的支持力度还远远不够，或者说没有看好 uni-app x 的发展前景？

然后官方人员时常不在线，在群里问的问题要等好久可能才会有回复(可能问的问题比较低级 😂)。程序“猿”都是没有耐心的一种”生物”，对于官方的慢回复，可能会导致部分开发者弃坑。

最后对于提交的 issue 官方处理的也很慢。要求提供可复现的工程，这无可厚非，比较排查问题都需要可复现的环境，但是笔者提供了可复现的工程(基于 hellp uni-app x 项目)还嫌弃工程太大，毕竟谁没事闲的天天给你们找 Bug 再搞个可复现的项目？除非给我发工资 😄。

最后的最后对 uni-app x 做下总结，一个字：快。比原生开发快，还有什么快？