极客观点
项目管理
HarmonyOS
最新文章
鸿蒙跨平台开发全景：从 ArkUI-X 到 RN/Flutter，一次搞懂怎么选怎么写
做移动端久了你会发现，跨平台从来不是一个"能不能做"的问题，而是"哪种代价你能承受"。HarmonyOS NEXT 全面到来之后，不少团队开始焦虑——已有的 RN/Flutter 资产能不能搬过来？原生 ArkTS 写的界面能不能反向跑到 iOS 和 Android 上？
跨项目设计模式（六）：Builder 模式——链式 API 的设计与实现
Builder 模式在 GoF 分类里属于创建型模式，核心思路是把一个复杂对象的构造过程拆成若干步骤，允许调用方按需选择和组合。在 HarmonyOS 三方库生态中，这个模式常见两种变体：一种是以 HMRouter 为代表的链式 API，方法逐个追加配置并返回 this，最后以一个终结方法触发动作；另一种是以 ImageKnife 为代表的配置对象模...
跨项目设计模式（五）：工厂模式——加载策略工厂与服务工厂
工厂模式在 GoF 分类中属于创建型模式，核心目标是将对象的创建逻辑从使用方剥离。在 HarmonyOS 开源项目中，ImageKnife、HMRouter、ImageKnifePro 三个仓库分别采用了不同变体的工厂模式来解决各自的创建问题。这篇文章以这三个仓库的实际源码为素材，逐一拆解四种工厂实现，并在最后讨论工厂模式的适用边界。
跨项目设计模式（四）：观察者模式——EventBus / Emitter / @Watch
观察者模式的核心思路是"发布-订阅"：一方发出事件，若干订阅者响应。在 HarmonyOS 生态的三方库中，这一模式的落地方式差异明显。HMRouter 自己实现了一个轻量 EventBus，ImageKnife 选择了系统提供的 @ohos.events.emitter，而 ArkTS 框架层面则给出了 @Watch 装饰器，直接在属性变更时触发回调。
深潜 HarmonyOS APP开发中AVSession 音视频会话管理
做过音视频类应用（比如音乐播放器、播客 App 或者带背景音的游戏）的朋友，大概率都遇到过这种让人抓狂的场景：用户退到后台，音乐还在响，但通知栏的播控按钮却失灵了；或者按了暂停，声音停了，但系统控制中心的进度条还在走。
HarmonyOS APP开发中userAuthIcon 统一认证控件的原理与实战破局
做过移动端开发的朋友都有体会，应用里的登录和敏感操作验证，向来是个让人头疼的平衡术。一方面，你得设下重重关卡，防止恶意攻击和数据泄露；另一方面，繁杂的密码输入和验证流程，又在无声地劝退用户。难道就没有一种两全其美的办法吗？
跨项目设计模式（一）：单例模式在鸿蒙框架中的 6 种实现
阅读 HMRouter、ImageKnife、ImageKnifePro 三个鸿蒙开源库的源码时，我发现单例模式出现的频率远超预期。粗略统计，三个仓库中至少有 6 处显著不同的单例实现，从最基本的懒汉式，到 C++ 静态局部变量，再到构建工具生命周期驱动的自毁式单例，覆盖了 ArkTS、C++、hvigor 三个技术层。
跨项目设计模式（三）：责任链 / 拦截器——OkHttp → HMRouter → ImageKnifePro
责任链模式在客户端框架中出镜率很高，但不同框架的实现差异远比"链表依次调用"这个概括要大。OkHttp 用递归 + 索引推进来实现同步洋葱模型，HMRouter 在同步三值返回之上叠加了异步洋葱接口，ImageKnifePro 则用 C++ 虚函数 + 链表指针做了一套 bool 短路链。三者分别面对 HTTP 管线、路由导航、图片加载这三种场景，在...
跨项目设计模式（二）：策略模式——从 ImageKnife 的加载器到 HMRouter 的生命周期
这是跨项目设计模式系列的第二篇，聚焦策略模式（Strategy Pattern）。策略模式的核心思路是把一组可互换的算法封装在独立的类里，让调用方通过统一接口选择具体实现，而不必在业务代码中写大量 if-else 或 switch-case。
跨越山河的握手：揭秘 HarmonyOS 分布式跨设备启动 UIAbility 的底层校验机制
做鸿蒙原生开发的朋友，一定对“万物互联”这四个字不陌生。想象一个典型的场景：你正在手机上填一张复杂的表单，突然旁边一台超大屏幕的折叠屏设备亮起，你轻轻一划，表单连同输入焦点无缝“飞”到了大屏上——这就是分布式跨设备启动 UIAbility 的魅力。
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 下的不同配置变体（比如免费版和付费版）。这套机制配合条件编译和资源分离，能在一个工程里管理多个产品形态。
分论坛
友情链接
