极客观点
项目管理
HarmonyOS
最新文章
HarmonyOS APP开发玩转鸿蒙 HSP：打造高复用“乐高模块”的底层逻辑
当你的项目里充斥着三个以上的业务模块，或者你同时在维护两个极其相似的 APP 时，你会发现，把通用的工具类、精美的 UI 组件甚至高性能的 C++ 算法隔离开来，变成一个个独立的标准件，是多么的重要。
HarmonyOS APP开发拒绝代码“坏味道”：DevEco Studio 重构实战
做鸿蒙开发的朋友，大概率都经历过这样的至暗时刻：接手一个祖传页面，里面几百行 UI 代码揉成一团，魔法数字（Magic Numbers）满天飞，同一个网络请求逻辑在三个地方复制粘贴……改一个样式，生怕牵一发而动全身引发雪崩。
一文速览 HarmonyOS 6.0.1 引入的十个新特性
HarmonyOS 6.1 已于 2026 年 4 月 20 日正式发布，但在 HarmonyOS 6.0 和 HarmonyOS 6.1 两个版本之间，还有 HarmonyOS 6.0.1 和 HarmonyOS 6.0.2 两个小版本。下面结合《鸿蒙HarmonyOS 6应用开发:从零基础到App上线》一书对 HarmonyOS 6.0.1 新特性中的常用部分逐一讲解。
鸿蒙工程化：hvigorw 命令行构建与 CI/CD 流水线
DevEco Studio 里点 Run 就能构建安装，但 CI 服务器没有 GUI——构建、测试、打包、签名全靠命令行。hvigorw 是 Hvigor 构建系统的命令行入口，所有在 IDE 里能做的构建操作都有对应的命令行参数。
鸿蒙工程化：第三方 C++ 库预编译与集成
鸿蒙 Native 开发中，引入第三方 C++ 库不像 ArkTS 层那样 ohpm install 一下就完事。libyuv、libavif、libaom 这些图像编解码库都是用 C/C++ 写的，源码量大、编译耗时长，不可能每次构建应用都从源码重新编译。常见做法是预先把它们交叉编译成鸿蒙平台的 .so 文件，存放在项目仓库里，CMake 直接链接预构建产物。
鸿蒙工程化：code-linter 代码规范与自定义规则
Code Linter 是 DevEco Studio 内置的代码检查工具，对标前端生态的 ESLint。它能在编码阶段检查 ArkTS/ETS 代码的规范性问题，涵盖通用编程规范、性能优化、安全风险和预览器兼容性等维度。和手动 code review 不同，Code Linter 是自动化的、可配置的、能集成到 CI 流水线的——这让它成为团队代码规范落地的关键工具。
鸿蒙工程化：Native C++ 编译配置——CMakeLists.txt 完全指南
鸿蒙的 Native C++ 开发和 Android NDK 的思路很像：ArkTS/ETS 层通过 NAPI 调用 C++ 编写的 .so 动态库，C++ 代码由 CMake 管理编译。但鸿蒙有自己的一套 SDK 目录结构、系统库命名规范和交叉编译工具链，CMakeLists.txt 的写法有不少鸿蒙特有的细节。
鸿蒙工程化：依赖冲突解决与版本锁定
一个鸿蒙工程往往不止一个模块，entry、feature、library 各自声明各自的依赖，同一个三方 HAR 很可能被多个模块同时引用。当它们要求的版本区间不一致时，ohpm 就需要做版本仲裁——这个过程在小项目里几乎无感，但随着模块数量增加和依赖树变深，冲突会变得越来越难以控制。
鸿蒙工程化：ohpm 包从开发到发布的全流程
ohpm 是鸿蒙三方库的包管理工具，类似 npm 在前端生态中的角色。这篇文章基于 ImageKnife、ohrouter、PullToRefresh 三个实际发布到 ohpm 中心仓的开源库，讲从开发到发布过程中的配置细节和注意事项。
鸿蒙工程化：多 target 与多 product 构建
鸿蒙工程支持通过 product 和 target 机制实现多变体构建。product 面向不同的设备或市场（比如 HarmonyOS 和 OpenHarmony），target 面向同一个 product 下的不同配置变体（比如免费版和付费版）。这套机制配合条件编译和资源分离，能在一个工程里管理多个产品形态。
鸿蒙工程化：hvigorfile.ts 编译配置与自定义脚本
hvigorfile.ts 是鸿蒙构建系统 Hvigor 的核心脚本文件。每个模块和工程根目录都有一份，决定了构建时使用哪些内置任务、加载哪些自定义插件。配合 hvigor-config.json5 的依赖声明，构成了完整的构建流程配置。
鸿蒙工程化：module.json5 与多设备适配
module.json5 是 Stage 模型下每个模块的应用配置文件，决定了模块的类型、支持的设备、权限声明、页面路由等运行时行为。和 build-profile.json5 管的编译时配置不同，module.json5 管的是应用安装后"长什么样、能做什么"。
HarmonyOS APP开发告别盲盒式优化：吃透 DevEco Profiler
你吭哧吭哧写完一个鸿蒙页面，点了几下按钮，滑了滑列表，感觉隐隐有些卡顿。但你盯着那几百行 ArkTS 代码，却像在看天书——到底哪里的逻辑拖慢了主线程？是哪个没用的对象把内存吃光了？
HarmonyOS APP开发之解密 ArkTS 状态管理：@State, @Observed, @ObjectLink 三角阵
爱的是，一旦摸清了它的脾气，UI 就能跟着数据乖乖跑，彻底告别命令式操作 DOM 的痛苦；恨的是，面对多层嵌套对象和数组时，如果不小心踩了坑，改了数据 UI 却不刷新，真的能让人对着屏幕怀疑人生。
HarmonyOS 6APP开发之摸透ArkUI FrameNode
做鸿蒙原生开发的朋友多少都遇见过这种场景：要搞个高度自定义的仪表盘、动态表单生成器，或者把第三方DSL（比如JSON配置的页面）转成鸿蒙UI，用纯声明式@Component写，要么嵌套深到怀疑人生，要么动态增删节点时diff计算卡得人牙痒痒。这时候就该把FrameNode掏出来了——它是ArkUI框架给开发者的“后门”，让你能直接捏组件...
鸿蒙6 PC开发摸透ArkTS按键事件：从“按了没反应”到“指哪打哪”，连鸿蒙6 PC适配也给你盘明白
做鸿蒙开发的朋友多少都踩过按键事件（Key Event）的坑：明明挂了onKeyEvent回调，按键盘半天体感跟没按一样；做PC端适配时想搞个Ctrl+S保存，要么触发两次要么压根拦不住输入法吞字符；甚至方向键导航按着按着焦点就飞出去了——别骂自己菜，大概率是没摸透这套事件流的脾气。
鸿蒙工程化：build-profile.json5 逐字段解析
build-profile.json5 是鸿蒙工程里控制编译行为的核心配置文件。它和 oh-package.json5 一样分成工程级和模块级两份，但职责完全不同：oh-package.json5 管依赖，build-profile.json5 管构建。
鸿蒙工程化：oh-package.json5 完整字段与依赖管理
鸿蒙项目里 oh-package.json5 的角色类似于前端的 package.json，但它分成了工程级和模块级两份文件，各自承担不同的职责。这篇文章基于 OHPM 5.0+ 的实际项目配置，把每个字段的设计意图和使用场景讲清楚。
ImageKnifePro 源码解读：ImageKnifeView 自渲染与内容过渡
ImageKnifePro 提供了两个上层组件：ImageKnifeComponent 和 ImageKnifeView。前者在 C++ 层创建系统 ARKUI_NODE_IMAGE 节点，把 PixelMap 包装成 DrawableDescriptor 送给 Image 组件渲染。后者走了一条不同的路——创建 ARKUI_NODE_CUSTOM 节点，注册 ON_DRAW 回调，在每帧回调中拿到 Canvas 句柄，用 Drawing API 手动...
ImageKnifePro 源码解读：缓存键生成、混淆兼容与工程化
图片缓存的核心问题之一是"怎么定位一张图"。URL 相同但裁剪参数不同，同一张原图在内存中可能有多份变体。URL 过长又不能直接做文件名，需要哈希压缩。ImageKnifePro 把缓存键生成逻辑下沉到 C++ 层，用 SHA256 做文件键的哈希，用结构化字符串拼接做内存键的标识。同时通过 CacheKeyGenerator 抽象类开放了自定义扩展点。
分论坛
友情链接
