再聊聊鸿蒙

上次吐槽鸿蒙还是一月份,api 升了两个版本之后,一些群众呼声很高的点好像还是没有什么变化。

没有那就没有吧,你就说能不能用吧!但肯定还是希望未来的版本可以带来一些更加实用的修改。

年前快速浏览了一遍 《JavaScript 高级程序设计》,年后回来开始对公司项目进行鸿蒙化,又多了一些感悟,记录一下。

语言选择

如果不是因为 Java 版权问题的话,我实在想象不出选择 JavaScript 的理由是什么。

JavaScript 开发生态好?我想 Java/Kotlin 在移动端领域的生态毫无疑问更好。

JavaScript 开发者更多?事实上更多情况是安卓开发来转型鸿蒙。

ArkTs,里子是 JavaScript,然后努力披上 Java 的壳子。给前端开发带上强类型的枷锁,让移动端开发以为是自己以为的强类型,给两边都不同程度的带来了一定的理解障碍。

但既然已经选定了 ArkTs,还是得去适应。

如果你是移动端开发,未曾接触过 JavaScript 的话,还是建议简单浏览《JavaScript 高级程序设计》的第 3 章 语言基础 ,第 8 章 对象、类与面向对象编程 ,第 11 章 期约与异步函数。因为官网的 ArkTs 语法文档过于简陋,没有 JavaScript 语法基础的话,在一些问题上会比较迷茫。

比如,如果你不知道 ES6 中函数的参数列表实际上就是一个 arguments 数组,根本没有函数签名的说法,你就无法理解 ArkTs 为什么没有函数重载。

如果你不知道 ES6 中 object 的含义,面对遇到的 is not callable 异常就束手无策。

对于前端来说,也是需要彻底改变开发思维,放弃动态类型,避免使用 object,而是尽量使用 class,强类型。

尽管看起来没有多大希望了,如果鸿蒙可以支持 Kotlin,该是一件多么美好的事情。

开发效率

毫无疑问,不考虑一些稀奇古怪的问题的话,鸿蒙的 UI 开发效率远高于 Android View 体系的原生开发。

得益于 声明式 UI状态管理,可以实现纯天然的 MVVM。那么,谁不天然呢?你肯定都知道。

看个最简单的登录页面的示例。

View 本身不持有任何状态,仅仅根据 VM 提供的数据进行渲染。

VM 负责处理具体的业务逻辑。

除了最常用的 @State,ArkUI 提供了丰富的状态管理的装饰器,来满足各种需求。

后续再来细盘一下这些装饰器。

API 选择

可能有很多同学在纠结从 API 9 到 API 11 的跨度问题,担心变化太大导致做很多无用功。

变化可以说大,也可以说不大。整体架构,核心思想,包括组件的基本使用,肯定是没有太大区别的。主要的变化在于 ArkTs 语法的编译期检查,大大增强了强类型检查。如果之前写的比较随意,可能得花点精力来修改。

OpenHarmony 的官网很早也就给出了部分适配规则,详见 从TypeScript到ArkTS的适配规则

如果准备上手鸿蒙,又没有最新 API 的话,个人觉得是没有太大问题的,可以冲。

一季度最后一个月了,希望华为官方也可以提一提进度,保障一下广大程序员的开发者体验。

相关推荐
汪汪大队u13 分钟前
为什么 filter-policy 仅对 ASBR 的出方向生效,且即使在该生效场景下,被过滤的路由在协议内部(如协议数据库)依然存在,没有被彻底移除?
服务器·前端·网络
慧一居士19 分钟前
vue.config.js 文件功能介绍,使用说明,对应完整示例演示
前端·vue.js
颜酱22 分钟前
用导游的例子来理解 Visitor 模式,实现AST 转换
前端·javascript·算法
蒙特卡洛的随机游走40 分钟前
Spark的宽依赖与窄依赖
大数据·前端·spark
共享家95271 小时前
QT-常用控件(多元素控件)
开发语言·前端·qt
葱头的故事1 小时前
将传给后端的数据转换为以formData的类型传递
开发语言·前端·javascript
_23331 小时前
vue3二次封装element-plus表格,slot透传,动态slot。
前端·vue.js
jump6801 小时前
js中数组详解
前端·面试
崽崽长肉肉1 小时前
iOS 基于Vision.framework从图片中提取文字
前端
温宇飞1 小时前
Web Abort API - AbortSignal 与 AbortController
前端