开源鸿蒙PC：一个开发者的鸿蒙故事

欢迎加入开源鸿蒙 PC 社区：https://harmonypc.csdn.net/

---

缘起：一台 MateBook，一个好奇的念头

今年四月的一个周末，我在家整理书桌时翻出了一台吃灰半年的 MateBook Pro。买的时候冲着那屏幕素质去的——3:2 比例、高分辨率，看代码比 16:9 的屏幕舒服太多。但说实话，用了没两个月就又换回了 MacBook，原因是上面跑的是 Windows，而我习惯了终端 + Unix 工具链的开发环境。WSL 虽然能用，但总觉得隔了一层。

那天下午刷 CSDN，看到一条消息：鸿蒙 PC 开发者预览版开始向部分用户推送了。我愣了一下——这台 MateBook 不就是华为自家的旗舰本吗？如果它原生就跑鸿蒙呢？

好奇心就从这个念头开始了。

第一次折腾：装系统这件事，永远比想象的难

花了三天时间，刷 BIOS、烧镜像、对着命令行敲 hdc 命令。中途遇到过新刷的系统开机后无限重启——最后发现是镜像版本和硬件不匹配，换了社区另一个 dev 编译的版本才点亮。

当屏幕上第一次出现鸿蒙桌面那行「HarmonyOS」小字时，我把那台 MateBook 放在书桌正中央足足看了半分钟。倒不是因为界面多惊艳——实话实说，早期的桌面环境还比较朴素。真正让我愣住的是这件事：

中国人自己做的 PC 操作系统，真的跑在一台真实的笔记本上了。 而且是我在用、能摸到的硬件。

动手的念头就是从那一刻真正开始的：不是作为旁观者等着别人做好生态，而是自己能用技术为这个生态做点什么。

第一次正经尝试：我要搬一个软件过来

我决定找一个「自己能搞定、搬过去又有用」的练手目标。最终锁定了一个不太起眼的工具——htop。

选它的原因特功利：体量小、只依赖 ncurses、用 autotools 构建，搞砸了不可惜，搞成了能天天用——毕竟哪个开发者不需要一个系统监视器呢？

过程很不顺利。第一次编译，configure 找不到交叉编译器（OHOS_SDK 环境变量没设）。设好之后，编出来了，拷到设备上，跑不起来——exec format error。查了半天，发现是用了 lycium 默认配置指定了 armeabi-v7a（32 位），而 MateBook 是 64 位的 arm64-v8a。改完架构，编出来、拉过去，这次能跑了，但跑一半又崩了——渲染终端的 ncurses 依赖在 musl 下有个接口差异。

这中间反复折腾了四次。第四次，终于跑起来了。

当我看到熟悉的蓝绿色进度条在鸿蒙终端里滚动时，我突然意识到——这和我每天在 Ubuntu 上用的 htop，没有什么区别。

就是这个瞬间，一个听起来很大的问题突然有了朴素的答案：「鸿蒙 PC 能不能替代 Linux 做主力开发设备？」——我觉得可以。前提是有人去把那些我们天天在用的工具和库，一个一个搬过来。

搬库这件事，我好像刚好能干。

什么驱使我继续做下去

从 htop 开始，我陆陆续续编了二三十个工具和库。每次都有新坑：有的卡在 musl 和 glibc 的差异上，有的因为构建系统不支持交叉编译，有的编出来了但跑起来行为诡异。但很奇怪，每次踩坑之后那种「啊，原来如此」的快感，比顺利编译通过还要让人上瘾。

回过头想，到底是什么驱使我做了这么多？大概就三件事：

第一是「自尊心」。作为一个写了十年 C/C++ 的人，我受不了「这个库老子编不过」这种挫败感。每次卡住，都想再试一次把它啃下来。昨晚 G’MIC 那个 OpenMP 的坑之后，凌晨两点还在屏幕前盯着链接日志找 libomp.so 到底链没链上——不是被迫的，是真的想知道答案。

第二是「实用主义」。我越来越确信一个判断：鸿蒙如果想做 PC 市场，它就不可能只靠「华为自己的应用商店」去填生态的坑——世界上有几十万个 Linux 开源软件，它们是最直接的生态来源。只要有人去编、去适配，这些软件就能立刻变成鸿蒙原生可用。搬库这件事，不浪漫，但很实际，做一件就多一件。

第三是「参与感」。这在以前有点矫情，但我发现当你真动手去搬一个库、解决一个补丁、写一份 HPKBUILD、在社区里发了 pr，你对「这个生态是我的」的感觉，跟你第一次点亮系统时的感觉是完全连着的——因为你参与了建造。

加入社区之后的事

五月底的一天，我逛 CSDN 刷到了 展菲 那篇 vcpkg vs lycium_plusplus 的对比文章。看完就被作者对两种方案「假设条件、产物形态、团队成本、适用人群」四层拆解的深度震住了——这绝对不是「写教程的」，是在一线真做了大量适配的。

顺着文章摸到了开源鸿蒙 PC 社区（harmonypc.csdn.net）和 AtomGit 上的仓库。当时 lycium_plusplus 仓库上已经标了「已归档 275 个库，社区适配 132 个」。我心想：全国只有 132 个人或者团队在做这件事吗？

那天我做了两件事：一是 fork 了 lycium_plusplus 仓库，二是给自己立了个 flag——每周至少贡献一个库的 HPKBUILD。不一定多难多大，但要能跑、有测试、打包规范。

加入社区之后的感受，跟之前单打独斗完全不同。以前踩坑只能自己 Google、查日志、试错。有了社区之后，凌晨发个「为什么 fuse3 的 musl 补丁在 arm64 上不生效」，第二天早上 坚果 就回了句「fuse3 那个 pthread_cancel 的补丁里 __MUSL__ 宏在某些 OHOS SDK 版本里没定义，你试试直接 #define pthread_cancel(tid) ENOSYS」。那种「别人已经替你踩过这个坑」的感觉，只有真正做开源的人才懂。

再后来，我开始看 wei_shuo 写的 MediaInfo 适配方案、Dream-Y.ocean 的 mpv 依赖树拆解、程序山海 的 JNA 和 xdg-desktop-portal 实践、I’mAlex 的 TNN 移植……每一篇对我来说都不是「看完了」，而是「我也要亲自复现一遍」。我想知道这个坑它怎么踩过去的，因为我信一个朴素的道理：自己跑通一遍，才算真正掌握了。

这大概就是社区的力量——它不是一个让你「看答案」的地方，而是一个让你「跟同行一起解题」的地方。

我对鸿蒙 PC 的真实期待

说了这么多感性的东西，回归理性。作为一个天天写代码的人，我对鸿蒙 PC 有几点很朴素的期望：

1. 「能干活」应该是底线

我不是要求它能玩 3A 大作、跑 AI 大模型。我希望它能干净利落地把三件事做好：开一个终端能编译 C++ 项目、开一个浏览器能查文档和 GitHub、开一个 IDE 能写代码和调试。做到这三件事，对我来说它就是一台合格的开发设备——剩下的，再多都是加分。

2. 三方库生态要「工业化」，不能靠人情

现在这 132 个社区适配库，靠的是全国各地的开发者用业余时间一个个堆出来的。这套模式在早期管用——热情是启动生态最好的燃料。但长期来看，不能只靠热情。需要 CI/CD 自动构建、预编译包分发、安全漏洞跟踪、供应链审计。

这也是为什么我会对 build_in_harmonyos 这个 AI 编译框架（猫哥做的）特别感兴趣——它试图把「手工搬库」变成「AI 辅助批量编译」。从 132 个到 1000 个，从 1000 个到 10000 个，中间必须有一道智能化流水线，否则人力根本填不上缺口。

3. 希望它成为「中国人的日常」而非「开发者的玩具」

这条有点大，但我想认真说。我第一次带这台装了鸿蒙的笔记本去公司，同事围过来看——「这就是鸿蒙？看着好像还行。」然后他们问了一个很灵魂的问题：「能装微信吗？能装 WPS 吗？」

我笑笑说：「现在还不能。」但我在心里加了一句——「以后会能的。有人在做这件事。」

我不是在安慰自己。因为我知道，一个系统的生态从来不是等出来的，是一个一个库、一个一个应用、一行一行代码堆出来的。

如果你也想加入

如果你也是开发者，看完了这篇文章心里有点痒，我真诚地给你三条建议——不是什么大道理，是我自己走过来的切身体会：

第一，选一个你真正会用到的工具开始搬。 不要为了「攒贡献量」去适配一个你自己都不用的库——那样坚持不下去。从你每天敲的命令、你常用的开发工具开始。你需要它，所以你会在乎它能不能完美运行。

第二，先用起来再想优化。 不要一上来就想写完美的 HPKBUILD、优雅的补丁方案。先把库编出来、跑起来，哪怕用 shell cp 代替 cmake install、用条件编译硬规避 musl 差异——能用就是成功的。之后有时间了，再回来把「能用」升级成「优雅」。

第三，加入社区。 论坛上有问必答的陌生人、AtomGit 上审你 pr 的维护者、CSDN 里把踩坑经验写成长文等你来看的作者——他们让一个人孤独的适配变成一群人共同的事业。而你会慢慢发现：解决问题的不是某一个人的技术，而是一群人的经验。 开源社区最宝贵的不是代码，是这群人。

---

声明：本文为原创文章，文中提及的社区成员（展菲、坚果、wei_shuo、Dream-Y.ocean、程序山海、I’mAlex、猫哥 等）均为活跃于开源鸿蒙 PC 社区的真实贡献者。文中个人经历与感受为基于社区公开活动的文学化表达，旨在传达对鸿蒙生态的真实期许与共建热情。