极客观点
项目管理
HarmonyOS
最新文章
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 抽象类开放了自定义扩展点。
ImageKnifePro 源码解读：性能监控与错误分阶段追踪
图片加载慢，慢在哪一步？请求失败，失败在哪个环节？一张图片从 URL 到屏幕要经过内存缓存查询、磁盘缓存查询、网络下载、解码多个阶段，任意一步都可能成为瓶颈或故障点。ImageKnifePro 在内部埋了分阶段打点机制，每个阶段的起止时间都记录在 TimeInfo 结构体里。配合 LoadFailedCode 枚举和 onLoadListener 回调，开...
一文读懂 HarmonyOS 6.1 带来的十大重要升级
HarmonyOS 6.1 已于 2026 年 4 月 20 日正式发布，该版本在 HarmonyOS 6.0 基础上增强了若干特性，让鸿蒙系统变得更智能更好用，下面结合《鸿蒙HarmonyOS 6应用开发:从零基础到App上线》一书对 HarmonyOS 6.1 新特性中的常用部分逐一讲解。
ImageKnifePro 源码解读（十五）：预创建组件与长列表优化
长列表的图片加载有两个经典症状：首屏刷出来的那一刻所有图片位置都是白块，要等一段时间才逐个填上内容；快速滚动时新进入可视区的 item 也是先白再亮。这两个问题的根源相同——图片从"组件创建"到"画面上屏"之间存在一条完整的延迟链路，而组件创建本身就是这条链路的第一环。
ImageKnifePro 源码解读（十四）：EXIF 方向处理、HDR 显示与内存分配模式
图片从文件字节流变成屏幕上的像素，中间有几个容易被忽略的环节：手机拍的照片可能带有 EXIF 方向标记，不处理的话图片会显示成横的或倒的；HDR 图片需要在支持的设备上以高动态范围模式渲染；解码后的 PixelMap 内存从哪里分配，DMA 还是共享内存，直接影响送显效率和内存占用。ImageKnifePro 在解码拦截器里统一处理...
ImageKnifePro 源码解读（十三）：NAPI 桥接——ArkTS 和 C++ 之间的三层绑定
ImageKnifePro 的 Native 侧代码按职责分成三层：最底层的模块注册（napi_init.cpp），中间的 ArkTS 接口绑定（imageknife_napi.cpp），以及独立于 NAPI 之外的纯 C API 封装（imageknifec.cpp）。三层各自解决一个问题——怎么让系统发现模块、怎么把 JS 调用翻译成 C++ 调用、怎么让其他 Native 模块不依赖 NAPI 就能使...
ImageKnifePro 源码解读（十）：网络可靠性——CRC32 校验、备用 URL 与动态 DNS
网络图片加载有三个常见的失败场景：CDN 返回了损坏的图片数据、主域名不可达需要切换备用域名、DNS 解析被劫持或延迟过高。ImageKnifePro 在 C++ 层针对这三个场景分别实现了 CRC32 数据校验、fallbackUrls 多域名自动重试、以及静态/动态两种自定义 DNS 机制。三者的触发点都在 LoadInterceptor 的加载链路上，与 Deta...
ImageKnifePro 源码解读（十二）：从 ImageKnife 迁移到 ImageKnifePro
ImageKnife（@ohos/imageknife）是纯 ArkTS 实现的图片加载库，图形变换依赖独立的 @ohos/gpu_transform 包在 ArkTS 层完成。ImageKnifePro（@ohos/imageknifepro）把核心逻辑下沉到了 C/C++ Native 层，通过 libimageknifepro.so 做网络下载、解码、缓存和变换，ArkTS 侧只保留声明式接口。两个包的 API 表面高度相似，...
ImageKnifePro 源码解读（十一）：缩略图三阶段加载与动图逐帧解码
一张网络大图从发起请求到最终显示，用户看到的可能是三张不同的图：先是一个极小的占位图，接着是中等分辨率的缩略图，最后才是完整的主图。ImageKnifePro 把这三个阶段拆成了三条独立的加载管线，每条管线各自走拦截器链、各自查缓存，互不阻塞。动图场景下还有另一个维度的复杂度——GIF/WebP 的帧数乘以分辨率可以轻松...
ImageKnifePro 源码解读（八）：GPU 滤镜与 CPU 变换
ImageKnifePro 把所有图形变换收归到 C++ Native 层，分出 GPU 和 CPU 两条管线。GPU 管线通过 OpenGL ES 离屏渲染执行片段着色器，CPU 管线在像素缓冲区上直接操作或调用系统 API。两条管线统一挂在 TransformationBase 下面，由 MultiTransformation 做链式编排，对上层完全透明。
ImageKnifePro 源码解读（七）：降采样——大图解码时省内存的关键一步
一张 4000x3000 的照片，RGBA 四通道，每像素 4 字节，解码后占 4000 3000 4 = 48 MB。列表里塞 20 张这样的图片，光 PixelMap 就接近 1 GB，在大部分鸿蒙设备上会直接触发 OOM。但实际显示区域可能只有 360x270，真正需要的内存不到 400 KB。降采样的作用就是在解码阶段把图片缩小到接近显示尺寸，让系统分配的内存和实...
ImageKnifePro 源码解读（九）：组件设计——ContentSlot 包裹 Native 节点
ImageKnifePro 的组件层面临一个核心问题：ArkTS 的 Image 组件接收 PixelMap 后需要经过框架层的序列化和渲染调度，这个过程在列表滚动场景下开销明显。ImageKnifePro 的解法是绕过 ArkTS Image，在 C++ 层直接创建和操作 ArkUI 原生节点，再通过 ContentSlot 把原生节点挂载到 ArkTS 组件树上。
ImageKnifePro 源码解读（五）：五种图片来源的加载策略
ImageKnifePro 的图片来源不止 HTTP 一种。datashare:// 开头的图库图片、打包进 HAP 的 Resource 资源、应用沙箱里的本地文件、base64 字符串，以及业务方自己注册的 loader，都需要统一接入同一条加载管线。加载拦截器链上默认挂了两个实现——DownloadInterceptorDefault 处理网络下载，ResourceInterceptorDefault 处...
分论坛
友情链接
