再也忍受不了缓慢的 MicroPython 了？最高 3.5 倍性能！PikaPython v2 开始预览！

说在前面的话

MicroPython 是嵌入式 Python 里绕不开的名字。它能跑、资料多，很多开发板也有现成支持。

但项目一旦从点灯、打印和简单控制，走到真实应用，问题就会慢慢冒出来：模块调用够不够快？Flash 够不够？

RAM 会不会先被解释器吃掉？代码再多一点，是不是最后还得回到 C 语言？

为了解决真实项目绕不开的性能和资源限制，我们完全重写了 Python 解释器内核，推出了 PikaPython V2！

先把 PikaPython v2 和 MicroPython 的实测结果摆出来。

先看结果：性能最高达到 3.54 倍

在相同 workload、匹配 CPU 的 Linux 环境中，PikaPython v2 与 MicroPython v1.28.0 Unix minimal 进行了对比测试：

换成增幅来表达，相当于最高提升约 254%。

速度是一方面。对 MCU 来说，Flash 和 RAM 同样是稀缺资源：

上面的性能数字来自 Linux benchmark ，并用 QEMU 测量 Flash、RAM的资源指标。

PikaPython v2，为什么要重新做？

如果只是继续给旧版本加几条语法、移植几个模块，版本号没有必要升到 v2。

PikaPython v2 重新梳理了运行时执行路径、程序交付方式、Python 与 C 的模块边界，以及从项目创建到目标构建的工程流程。

它要解决的不是“Python 能不能勉强跑在 MCU 上”，而是“Python 能不能在 MCU 项目里真正承担一部分工作”。

第一件事：让高频执行路径少绕路

PikaPython v2 使用面向寄存器的运行时快速路径。

大家不需要先记住这个名词，只要理解一件事：Python 代码执行时，每多一层临时对象、栈操作和动态查找，就会多付出时间和内存成本。

v2 针对模块调用、控制流、容器操作和对象访问等高频路径，尽量减少这些额外开销。

这不是在某个函数上打补丁，而是运行时执行方式的变化。性能对比中，控制流达到 3.53x、模块调用最高达到 3.54x，与这条执行路径直接相关。

第二件事：把 Python 程序提前做成 Program Image

PikaPython v2 引入了 Program Image，也就是程序镜像。

Python 程序、纯 Python 模块和对应的 binding 可以在主机侧完成预编译，再作为明确的程序镜像交付给目标设备。

import 和 from ... import ... 等模块关系也可以进入 Program Image。

这意味着：

• 目标设备不必承担全部源码分析和模块装配工作；
• 哪些脚本和模块进入固件，在构建阶段就能确定；
• 没有被选中且不可达的脚本，不需要跟着固件一起占空间；
• Python 模块与原生 C 模块可以进入同一套构建和交付流程。

对资源紧张的 MCU 来说，把复杂工作放到主机侧完成，比让目标板什么都自己处理更实际。

第三件事：写 Python，也不必把 C 丢掉

嵌入式项目离不开 C。驱动、寄存器、中断和现有 SDK，大多还是 C 接口。

PikaPython v2 继续使用 .pyi 描述 Python 可见 API，再通过 CLI 生成 C binding。

一个模块可以使用纯 Python 实现，也可以调用原生 C 实现，还可以把已有 binding 重新导出给上层模块。

这样，Python 和 C 的分工比较清楚：性能和硬件控制敏感的部分继续使用 C，业务逻辑和流程控制可以使用 Python。

中间由可生成、可检查的 binding 连接起来。

第四件事：别让工具链把人劝退

一个 Python 内核跑分再高，如果创建项目、安装模块、生成 binding 和编译固件全靠手工拼命令，实际开发仍然会很累。

PikaPython v2 同时提供统一 CLI、模块包、项目模板和构建流程。CLI 可以用于：

• 创建和配置项目；
• 安装模块依赖；
• 选择语法和功能 capability；
• 生成 C binding；
• 预编译 Program Image；
• 构建 Linux 或 MCU 目标；
• 检查配置和构建问题。

仓库还提供面向 Code Agent 的 PikaPython CLI Skill。使用 Codex、Claude Code 等工具时，可以让 Code Agent 按照这套流程创建、构建和诊断项目。

目前的验证结果

PikaPython v2 当前已经完成：

• 506 项语法兼容检查；
• 99.31% 的测试覆盖率；
• Linux runtime suite 611/611 测试通过；
• 6 个 Valgrind runner 通过，没有发现内存错误和报告泄漏。

CPython 是当前模块行为的主要兼容目标，但这里说的是面向嵌入式场景的文档化语法子集和模块接口，不是把完整 CPython 标准库原样搬进 MCU。

现在可以用了吗？

可以开始试用，但请注意：这仍然是预览版。

当前公开版本号为 v2.0.0-rc3。正式版 2.0.0 发布前，部分 API、项目配置和模块行为仍可能调整。

当前版本也暂不包含基于线程的并发和锁 API；eventloop 提供的是协作式调度能力。

如果准备把它放进量产项目，建议先针对自己的芯片、编译器、模块组合和内存预算完成验证。

如果想了解 v2 的运行方式、评估移植成本，或者参与完善模块和平台支持，现在可以先从预览版开始。

怎么开始

从 PikaPython 仓库的 v2 分支获取源码：

bash
git clone --branch v2 --single-branch https://github.com/pikasTech/PikaPython.gitcd PikaPythonpython3 skills/pikapython-cli/scripts/pikapython-cli.py --help

基础环境包括：

• Python 3.9 或更高版本；
• PyYAML>=6.0,<7；
• Git；
• CMake；
• 可用的 C 编译器。

相关入口：

• PikaPython v2 分支
• PikaPython v2 README
• v2.0.0-rc3 预览版说明
• 性能与资源测试资料
• GitHub Issues
• PikaPython 论坛

说在后面的话

做嵌入式 Python，最容易走向两个极端：一边只谈 Python 好不好用，回避 MCU 的 Flash、RAM 和实时约束。

另一边只谈资源有多紧张，认为除了 C 以外什么都不该出现。

PikaPython v2 想做的事情很具体：在 MCU 的限制下，把运行时做得更快、更小；在工程开发上，让 Python、C、模块和构建工具能够配合起来。

这次发布的是 PikaPython v2 的第一次公共预览，还不是最终答案。

欢迎大家拿自己的代码、模块和开发板来试。跑得快不快、占得省不省、接口顺不顺手，最后都应该由真实项目说话。

欢迎加作者好友，加入交流群一起和行业大佬交流~