ARM64 性能实测：一颗移动处理器，能否胜任日常 Linux 开发？

过去几年，ARM 处理器在移动端的性能提升已经相当明显。

如今的手机 SoC 不仅拥有多个高性能核心，也具备相当可观的内存带宽和整数计算能力。但对开发者而言，跑分始终不是最重要的指标。

一个更实际的问题是：如果把完整的 Linux 开发工具链放进 ARM64 环境，它究竟能完成多少真正的开发工作？

例如，GCC 编译一个真实项目需要多长时间？八个核心能否有效缩短构建时间？移动处理器在 CPU 基准测试中的高分，是否意味着实际开发体验也足够好？

为了回答这些问题，我用自己旧手机一加Ace5安装NimoteCode的local linux环境做了了几组测试，包括 CoreMark、SQLite 源码编译，以及多文件并行构建。

目的是我想验证下，再不考虑手机部署的linux环境的兼容性问题方面，安卓手机如果安装linux实际到底能不能用来搞开发？性能到底达标不达标？

实际测试结果比我预想中更有意思。

一、测试环境：NimoteCode部署的Local linux，使用内置Ubuntu

本次测试使用 Ubuntu 24.04.4 LTS，运行于 ARM64 容器环境。

硬件配置如下：

这是一套典型的 ARM 异构多核配置：高性能核心负责计算密集型工作，能效核心主要面向低功耗任务。

测试环境存在一些限制。容器屏蔽了部分 CPU 频率和系统硬件信息，无法通过常规 sysfs 接口准确获取运行频率。

曾利用依赖加法链得到约 2.34 GHz 的间接估计，但由于指令延迟和实际调度行为无法完全确认，这个数值不作为正式性能分析依据。

需要说明的是：本次数据来自 NimoteCode 在 Android 真机上的 PRoot 环境。 因此，它反映的是当前 ARM64 测试环境的计算与编译能力，不能直接视为 Android Local Linux 的实测成绩。

因此，它反映的是当前 ARM64 测试环境的计算与编译能力，不能直接视为 Android Local Linux 的实测成绩。

具体NimoteCode安装部署Local linux参考教程：https://nimotecode.com/zh/docs/local-linux

实际测试直接让deepseek-flash进行环境部署和实际测试

二、CoreMark：单核约 23,400，多核超过 144,000

首先测试 CPU 的基础计算能力。

CoreMark 是 EEMBC 提供的处理器基准测试，涉及整数运算、链表操作、矩阵计算和状态机等工作负载。

与一些侧重图形性能的跑分工具不同，CoreMark 更关注处理器执行通用计算任务时的表现。

本次测试得到：

单核成绩约为 23,400，8 线程总成绩约为 144,200。

<指标：单核约 23,400 / 多核约 144,200 / 扩展比约 6.15×>

这里值得注意的是多线程扩展能力。

8 个 CPU 核心并没有带来理想情况下的 8 倍提升，而是获得了大约 6.15 倍的吞吐增长。

这并不意外。

一方面，这颗处理器采用异构架构，Cortex-A520 与大核心的性能存在差异；另一方面，多线程任务还可能受到频率分配、内存访问、调度和功耗限制影响。

不过，对于只有 8 个物理核心的移动处理器而言，6 倍以上的扩展比至少说明：在当前测试负载下，并行计算确实能够有效利用多个核心。

当然，CoreMark 主要代表特定计算负载的吞吐能力。它无法直接回答 GCC、Git 或 Python 项目的实际运行效率。

所以，接下来的测试更有意义。

三、SQLite 编译：真实项目比跑分更值得关注

为了避免只测试合成负载，这次选择了 SQLite 3.54.1 的 amalgamation 源码进行编译。

SQLite 是非常成熟的嵌入式数据库项目，其 amalgamation 版本将大量实现代码整合到单个 C 源文件中。

本次使用的源码约 271,131 行，能够给编译器带来具有实际意义的词法分析、语法分析、优化和代码生成工作。

分别测试 GCC 的 -O0 和 -O2 优化等级。

最有意思的是 -O0 与 -O2 的差距。

不开启优化时，编译仅需要约 7.6 秒；开启 -O2 后，耗时增加至约 34–35 秒。

优化编译所需时间约为非优化编译的 4.5 倍。

这背后并不只是 CPU 快慢的问题。

GCC 在 -O2 下会执行更复杂的优化流程，需要额外分析代码结构、控制流和数据依赖，并生成更高效的机器码。

大型单文件编译还会对缓存、内存访问和编译器内部数据结构产生明显压力。

这也解释了为什么处理器在基础 CPU 基准测试中表现良好，但面对较重的优化编译任务时，耗时仍然可观。

对日常开发而言，这个结果很有参考价值。

假设开发者正在维护一个小型 C 工具、修复某段业务逻辑，或者修改编译配置，非优化构建通常能提供更短的反馈周期。

而当任务变成大型代码库的完整优化构建时，等待时间就可能明显增加。

这也是移动端开发环境需要考虑的现实问题：不是所有代码任务都需要桌面级算力，但不同任务对本地计算资源的要求差别很大。

四、并行编译：8 核到底能带来多大收益？

单文件 SQLite 编译主要考验单个编译进程，无法充分体现多核心优势。

因此，还进行了另一组测试。

构造一个约 75,001 行的 C 代码测试负载，再将其拆分为多个独立编译单元，通过 GNU Make 测量串行与并行构建时间。

结果如下：

从将近 10 秒缩短至 1.6 秒，差异非常明显。

这个结果与前面的 CoreMark 多核扩展比也比较接近。

不过，这并不意味着所有项目使用 make -j8 都能获得 6 倍以上的提速。

真实项目还包含头文件依赖、链接、生成代码、文件系统操作和无法并行的构建步骤。

某些项目在增加并行任务后，甚至可能因为内存压力、I/O 竞争和热限制而出现收益递减。

另外，这次使用的是合成代码负载，不能完全代替 LLVM、Chromium 等大型真实项目。

但至少可以确认：对于能够拆分成多个独立编译单元的任务，ARM64 多核心具备明显的并行构建收益。

五、为什么 CPU 跑分不能直接代表 Linux 开发体验？

到这里，其实已经能观察到一个很重要的现象。

同一套 ARM64 硬件，在不同测试中的表现差异相当大。

CoreMark 展示了可观的整数计算能力，多线程扩展也比较理想；但 SQLite 的优化编译仍然需要几十秒。

原因并不复杂：开发工作负载远比单一 CPU 基准测试复杂。

例如：

编译 C/C++ 项目，主要涉及编译器计算、内存访问、进程调度和文件读写。

运行 Git，除了计算哈希，还可能大量遍历文件、读取元数据，并频繁访问存储系统。

安装软件依赖，则会混合网络请求、解压缩、校验、脚本执行和小文件操作。

运行 Python 或 Node.js 工具链，又涉及解释器或运行时启动、模块加载、依赖解析和大量文件系统访问。

因此，一个 CPU 的 CoreMark 分数高，并不能证明它的开发体验一定好。

尤其是在 Android 上运行 Linux 用户态环境时，还需要额外考虑运行机制。

例如 PRoot。

PRoot 可以在不获取 Android root 权限的情况下提供 Linux 用户态文件系统环境，但它并不是虚拟机，也不是原生 Linux 内核。

它需要处理进程执行和部分系统调用相关操作。这些额外开销可能对频繁访问文件系统、创建进程的任务产生影响。

这就带来一个值得单独测量的问题：

同样一段 C 代码，在 Android 原生环境与 PRoot Ubuntu 环境中执行，性能究竟会相差多少？

仅凭前面的 CoreMark 和 SQLite 数据，还无法给出答案。

要回答这个问题，需要在同一台 Android 设备上使用可比的编译器配置，分别测量原生与 PRoot 环境的表现。

六、移动设备上的 Linux 开发，真正的价值是什么？

做完这几组测试之后，我反而觉得，比起追求某个 CPU 跑分，移动开发环境更值得关注的是实际工作流。

移动设备并不需要承担所有桌面开发任务。

但如果它已经能够运行完整的编译器、解释器和基础 Linux 工具链，那么很多原本依赖电脑的轻量开发操作，理论上就有机会在本地完成。

例如：

• 临时修改一段代码，编译并验证结果。
• 在本地 Git 仓库中查看和管理变更。
• 运行脚本、处理文本或调试小型工具。
• 在没有远程服务器连接的情况下，完成部分开发工作。

这也是我在开发 NimoteCode 时一直关注的方向。

NimoteCode 是一款面向 Android 和 iOS 的移动 IDE，最初主要围绕 SSH 远程开发展开，后来逐步加入了 Android Local Linux。

它在支持的 Android 设备上，通过 PRoot 提供 Ubuntu 用户态环境，不需要 root 权限，也不需要额外安装独立终端应用。

与单纯提供一个 Linux Shell 不同，NimoteCode 将本地 Linux 工作区接入现有的文件浏览器、编辑器、终端、Git 和 AI 辅助开发流程。工具链仍然需要按项目需要安装，部分调试与系统级功能也存在兼容性限制。

这种设计并不是为了把手机包装成一台高性能工作站，而是让开发者可以在移动设备上完成一些真正有用的工作。

当然，是否好用，还取决于文件操作、编译耗时、键盘交互、进程稳定性和 Android 后台生命周期等因素。

这些都不是一次 CPU 跑分就能证明的。

七、现阶段的结论：ARM64 已经具备实用开发能力，但边界需要实测

回顾本次测试，几个结果值得关注。

这些数据至少说明，在此次 ARM64 Ubuntu 容器环境中，GCC 能够完成具有一定规模的真实 C 项目编译，多核心也能为独立编译任务带来明显的性能收益。

但它们并不能直接证明 Android PRoot 的性能，也不足以判断该处理器等效于哪一代 Intel 或 AMD 桌面 CPU。

测试还有几项局限：CoreMark 需要进一步核验完整运行参数；没有相同条件下的 x86 对照；尚未进行长时间持续负载测试；Git、APT、小文件 I/O 和 Android PRoot 开销也未纳入本次数据。

后续更值得进行的测试，是在同一台 Android 设备上，对比原生运行环境、Termux 和 PRoot Ubuntu 的真实构建时间，并观察持续负载下的性能变化。

从实际开发角度看，我越来越倾向于这样理解移动端 Linux：

它不一定需要替代电脑，但应该让开发者不必为了每一次简单的代码修改、编译验证和 Git 操作都回到电脑前。

对于轻量任务，本地执行可以减少对网络和远程服务器的依赖；对于大型构建，SSH 连接更强的工作站或服务器仍然更合理。

两种工作方式并不冲突。

或许未来移动端 IDE 真正值得探索的方向，也不是简单复刻桌面 IDE，而是让本地 Linux、远程开发和 AI 工具链能够在同一套工作流中自然衔接。

这比单纯讨论手机处理器的跑分，更值得持续验证。

测试与参考资料

• CoreMark： https://www.eembc.org/coremark/
• SQLite 3.54.1 源码： https://www.sqlite.org/download.html
• NimoteCode Android Local Linux 技术说明： https://nimotecode.com/docs/local-linux
• NimoteCode 项目网站： https://nimotecode.com

测试数据基于本文所述的NimoteCode部署的Local Linux:Ubuntu 环境。结果不代表其他设备的性能，也不构成 Android PRoot 环境的性能保证。