极客观点
项目管理
HarmonyOS
最新文章
一文读懂 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 处...
ImageKnifePro 源码解读（六）：图片解码——从格式识别到 AVIF 动态导入
图片加载的后半段是把字节流变成可渲染的 PixelMap。ImageKnifePro 用 C++ 拦截器链驱动解码分发，并通过 dlopen 在运行时动态加载 AVIF 解码器。编译期通过 #ifdef 控制头文件引入，运行时通过 dlopen 检测设备能力，两层防线保证在不支持 AVIF 的环境下安全降级。
ImageKnifePro 源码解读（四）：拦截器链——四层责任链的设计与扩展
ImageKnifePro 的加载引擎围绕拦截器-责任链模式构建。缓存、加载、解码各自独立成链，每一层拦截器只做一件事，做不到就传给链上的下一个。运行时随时可以插入、替换、重排。这篇从源码看四层拦截器的内部结构，它们怎么串联、怎么短路、怎么处理异步下载的线程分离，以及自定义拦截器怎么塞进去。
ImageKnifePro 源码解读（三）：双层 LRU 缓存的设计
图片加载库的缓存直接决定用户感知：命中就瞬间上屏，没命中就闪一下占位图再切换。ImageKnifePro 的缓存要同时处理多线程并发读写、内存字节级上限管理、磁盘文件的并发保护三件事，整套实现在 C++ 层用 lru11 加 std::mutex 完成。
ImageKnifePro 源码解读（二）：请求调度与并发控制
ImageKnifePro 把线程调度交给了 HarmonyOS 的 FFRT（Function Flow Runtime），一个内核级的协程式任务框架。相比 ArkTS taskpool 的"每个 task 独占线程直到返回"，FFRT 的并发队列允许更灵活的线程复用，配合 Detach 异步分离机制，网络 I/O 阶段不再占用并发位。
ImageKnifePro 源码解读（一）：鸿蒙图片加载框架全貌
鸿蒙系统的 Image 组件支持加载网络和本地图片，但四个短板在业务复杂度上升后依次暴露：没有二级缓存控制，冷启动重复拉取网络图片；没有占位图和错误图的切换机制，列表滑动时白屏闪烁；图片变换（模糊、裁剪等）需要手动操作 PixelMap；组件销毁后请求仍在飞，复用场景旧图残留。ImageKnifePro 针对这些问题，把整个...
做了个毒舌版 MBTI App，聊聊 ImageRenderer 的坑和零后端互测方案
核心想法很简单：结果海报要天然适合截图转发。四个自定义维度（C/S/E/A），16 种人格，每种配一个毒舌称号（「六边形悍匪」「优雅吸血鬼」「赛博隐形人」），文案走冒犯但又觉得准的路线。
做了个 iOS App：把每天走路变成像素格子占领游戏，聊聊核心规则设计
运动 App 太多了，但全在卷步数和卡路里。我对这些数字没感觉，所以做了「像素征途」——你走过的街道会在地图上被点亮成像素格子，走得越多领地越大。把现实世界当棋盘来征服。
做了一个 iOS 专注计时器，把每次专注包装成飞行旅程
去年给自己定了每天专注写稿 25 分钟的规矩，试了一圈番茄钟，发现都是同一个模式：倒计时→叮→结束。用两周就不想打开了，没有留存感，就是个闹钟。
用 SpriteKit 物理引擎做了个存钱罐 App，聊聊为什么我觉得「看得见的反馈」比记账更能让人坚持存钱
后来我琢磨了一下原因：存钱这个动作太「无感」了。钱从余额里少了一个数字，目标账户多了一个数字，没有任何正反馈。跟打游戏比起来，这体验差太远了。
分论坛
友情链接
