HarmonyOS鸿蒙Next中preview是我用过最费力的预览插件

HarmonyOS鸿蒙Next中preview是我用过最费力的预览插件

1、多模块、引用了其他子模块资源…

2、引用了其他模块的工具类、直接不能预览（tell me why？tell me？ tell me？）、最终还要去写mock文件才行…强制开发者写单元测试？

总结：代码灵活性就是一坨、真不好意思 我不知道设计者是站在哪种角度去思考的问题？

扩展：还有就是全球主流开发无非 android/IOS 你要让其他开发者过渡到鸿蒙、起码开发语言至少让OC/Swift ，Kotlin/java 开发者能适应、或者研发一个折中的语音都可以、

ArkTs（Ts） 你是想告诉Kotlin、Swift 我比你俩语言优秀、更好用？ 最终你选择了站到这两种语言上、拉坨大的… 还要告诉各位、快趁热… 人人有份！ 让人不禁猜疑arkTs的设计者是面向Web、面向魔都的宛平南路600号…


更多关于HarmonyOS鸿蒙Next中preview是我用过最费力的预览插件的实战教程也可以访问 https://www.itying.com/category-93-b0.html

6 回复

应该就是面向h5开发人员设计的

更多关于HarmonyOS鸿蒙Next中preview是我用过最费力的预览插件的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


希望仓颉能做的好一点，

  • 姓名：张三
  • 年龄：28
  • 职业：软件工程师
  • 所在地：北京
  • 技能
    • 熟练掌握Java
    • 熟悉Python
    • 了解C++

习惯就好。

这个 ArkTS 和 ArkUI 一看就是外包风格的，非常随意，而且很不负责。

搞不懂为什么这么重要的核心功能要外包。

抑或，华为本身就这……

华为的很多部门招了很多外包… 我自己亲历都去过（搞车载）、一言难尽…，

在HarmonyOS NEXT中，preview插件目前存在性能优化不足的问题，导致预览响应延迟和卡顿。这主要由于实时渲染机制未针对复杂UI做深度适配，且与DevEco Studio的协同效率较低。

开发者需注意：

  1. 减少单次预览的组件数量；
  2. 关闭非必要的实时刷新选项；
  3. 确认SDK版本与工具链匹配。

华为已知晓该问题并在后续版本规划优化。

关于HarmonyOS Next预览功能的问题，确实存在一些需要改进的地方：

  1. 多模块资源引用问题： 当前预览功能对跨模块资源引用的支持确实不够完善，这主要是由于预览环境与实际运行环境的差异导致的。建议在开发时：
  • 优先使用相对路径引用资源
  • 对于必须的跨模块引用，可以暂时使用条件编译或模拟数据
  1. 工具类引用限制： 这是出于性能和安全考虑的设计选择，预览环境需要保持轻量级。建议：
  • 将核心工具方法提取到独立模块
  • 使用接口隔离依赖

关于ArkTS语言的几点说明：

  1. 选择TypeScript作为基础是为了降低Web开发者迁移成本
  2. 类型系统设计确实参考了现代语言特性
  3. 与Kotlin/Swift的互操作方案正在完善中

当前版本确实存在改进空间，建议关注后续版本更新说明。

回到顶部