上次吐槽鸿蒙还是一月份，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 的话，个人觉得是没有太大问题的，可以冲。
一季度最后一个月了，希望华为官方也可以提一提进度，保障一下广大程序员的开发者体验。