极客观点
项目管理
HarmonyOS
最新文章
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，聊聊为什么我觉得「看得见的反馈」比记账更能让人坚持存钱
后来我琢磨了一下原因：存钱这个动作太「无感」了。钱从余额里少了一个数字，目标账户多了一个数字，没有任何正反馈。跟打游戏比起来，这体验差太远了。
独立开发了一个 iOS 呼吸训练 App，聊聊状态机驱动动画的实现思路
去年焦虑比较严重，试了几个呼吸/冥想 App，要么太重要么上来就要年费。呼吸训练核心逻辑不复杂，就自己做了一个——「呼吸视界」，目前 App Store 上线，12 个评分全 5 星，规模很小但方向没偏。
做了个iOS App，把你走过的城市面积算出来
问题在北京住了六年，突然想知道：我到底走过了这座城市多大的面积？翻了一圈市面上的运动记录App——Keep、悦跑圈、两步路——要么关注公里数，要么关注打卡点。没有一个能回答「覆盖面积」这个问题。方案自己做了一个，叫「雁过留痕」，iOS端，核心逻辑：把地图切成25米精度的网格，人经过一个格子就点亮，累计面积单位是 ...
告别深拷贝的痛：在鸿蒙PC与ArkTS中玩转 `@ObservedV2` 装饰器
做前端或ArkUI开发的兄弟们，大概率都曾被深层级数据更新折磨过。你改了数组里某个对象的属性，UI却稳如泰山地不作任何反应。无奈之下，只能祭出 JSON.parse(JSON.stringify(obj)) 这种极客看了会沉默的深拷贝大法，或者用 @State 包一层又一层臃肿的父组件。
做了个把专注计时包装成「飞行护照」的 iOS App，聊聊几个实现细节
所以我做了「声境护照」——本质是番茄钟，但套了一层旅行叙事：每次专注是一段「飞行」，时长换算里程，连续打卡天数决定旅行者等级，结束后生成一张像登机牌的战报卡片。
做了个存钱罐App，因为记账根本拦不住我花钱
最花时间的部分其实是个"看起来很傻"的动画：每次点存入，硬币从屏幕上方落下来，带物理碰撞——弹跳、叮当响、慢慢堆满罐子。用 SpriteKit 的物理引擎做的，光调参数就折腾了好几天：
做了一个 iOS App，把你走过的路换算成「探索面积」
问题用跑步/运动 App 记轨迹，记了几年，回头一看——全是线。沿同一条路跑一百遍，轨迹叠得再密，你真正「探索」过的地方其实没增加。我想要的不是「我走过哪条路」，而是「我到底覆盖了多少土地」。这两个问题看着像，本质完全不同。方案做了「雁过留痕」，核心就一件事：把轨迹转换成探索面积（km²）。25m 网格方案最早...
HarmonyOS APP开发玩透 ArkTS 并发编程
在鸿蒙的声明式 UI 体系里，主线程的唯一使命就是“伺候好用户的交互和界面的丝滑刷新”。凡是涉及 CPU 密集型（大数据排序、图像处理）或 IO 密集型（网络请求、大文件读写）的操作，都必须毫不留情地扔给并发线程。今天，咱们不扯那些干巴巴的官方文档，直接掀开 ArkTS 引擎的盖子。我会带你从早期的“刀耕火种”一路看到 ...
HarmonyOS APP开发玩透鸿蒙代码混淆的防逆向心法
咱们做鸿蒙应用开发的兄弟，只要发过正式包，多半都经历过这样一种“血压飙升”的时刻：好不容易熬了几个通宵把业务代码写完，打个 release 包传上架，结果没过两天，核心算法或者 API 接口逻辑就被人扒得干干净净。
用 struct 替掉所有 ObservableObject：一个 SwiftUI 专注 App 的实践记录
我在做一个 iOS 专注计时工具（声境护照，白噪音 + 番茄钟 + 游戏化成长），过程中把所有 ViewModel 从 class 换成了 struct，干掉了全部 @Published 和 Combine pipeline。代码量少了近三分之一，但中间有个坑差点让我全部回滚。
HarmonyOS 6.0升级至6.1改动点
2026年4月20日，HarmonyOS 6.1.0 Release正式发布，同时，DevEco Studio 6.1.0 Release版本也同步发布，标志着以API 23为核心的HarmonyOS全套开发套件（含SDK及开发工具DevEco Studio）均达到Release状态并正式发布。开发者可基于Release状态的开发套件进行HarmonyOS 6应用开发。HarmonyOS 6.1.0 Release版本操作系统也...
分论坛
友情链接
