Pycopy：极简Python方言，如何在STM32上省下每一KB内存

简介：这是Pycopy极简高效Python方言的项目资源包，面向希望在云、台式机、受限系统和微控制器上使用可扩展Python运行时的开发者与嵌入式工程师。Pycopy由MicroPython项目演进而来，在保留完整Python 3.4语法的基础上引入Python 3.5的异步特性，支持包含基本Unicode的字符串核心类型，整体设计强调轻量、可裁剪和跨平台。压缩包采用zip格式，体积约7.77MB，文件总数和类型明细暂时未列出，不过从体积看更便于在小型设备上部署和移植。当前已有两百多人学习/下载，适合用来评估极简Python解释器的实现方案，或作为研究MicroPython衍生分支、理解CPython与精简运行时差异的参考。通过阅读源码与项目文档，可以梳理嵌入式环境下的内存与性能取舍，掌握面向微控制器移植Python的轻量化思路。项目目前处于测试阶段，后续代码可能与当前版本不一致，使用时应留意版本变化。 如果你玩过嵌入式Python，大概率绕不开MicroPython。但比起它的名气，我更关注它背后那支更偏执的队伍——Pycopy，一门把自己定位成"极简且高效存储的Python方言"的实现。这句宣传语后面还跟了一句野心更大的话：适用于台式机、云、受约束的系统、微控制器，以及所有内容。我第一次看到这句话时觉得是吹牛，一门语言实现怎么可能通吃这么多场景。后来断断续续在桌面端、树莓派和STM32上折腾过几轮，我承认它有资格这么说，但前提是你得接受它跟CPython不是一回事，也得接受它的生态明显比正经Python小一圈。

1. 先搞清楚：Pycopy和Python、MicroPython到底是什么关系

1.1 从MicroPython里分出来的"偏执分支"

Pycopy起源于MicroPython的一个分支，作者Paul Sokolovsky是MicroPython早期的核心贡献者之一，后来因为发展方向上的理念分歧选择了另起炉灶。简单理解就是：MicroPython想把Python送进单片机，追求稳定、易用、生态做大；而Pycopy这边更极端，把"极简"和"高效存储"当成第一优先级，宁可让一些API跟主流不同，也要在每个字节、每KB内存上抠成本。

这套思路带来的结果是：Pycopy保留了Python 3的核心语法体验，但内核实现几乎是自己另搞一套。你在里面可以写for循环、定义类、用列表推导式、跑生成器，体验和CPython非常接近，不过底层解释器、对象模型、内存管理都是重新设计的。所以标题里用"方言"这个词很准确——它还是Python，但口音和别人不一样。

从源码层面看，Pycopy的仓库结构也很有个人色彩。不像MicroPython那样维护一大套面向教程和社区的规范，Pycopy的设计决策更多围绕"跑得动、放得下"来展开，甚至一些在CPython里想都不敢想的激进优化，在这里只是日常操作。

1.2 和CPython、MicroPython的定位差异

做选型之前，我建议你先弄清楚三者的边界，不然很容易用错场景。我给它们画一个大致的对照：

CPython是官方标准实现，适合跑在PC、服务器上，生态最全，但体积和启动时间注定它与小型MCU无缘。MicroPython是嵌入式领域的事实标准，资料多、教程多、板卡厂商也愿意适配，适合大多数人入门嵌入式Python。Pycopy则像是"硬核玩家专用赛道"，它不满足于只在单片机上苟活，而是想用同一套精简内核覆盖从MCU到云端的全部场景。

这里有个容易被忽略的点：Pycopy并不是单纯替代MicroPython的固件，它自己维护着多个平台的后端。除了裸机上的STM32、nRF系列，还有类Unix系统、Windows上的移植版。你在PC上编译出一个精简的Pycopy解释器，代码只要注意平台差异，就能几乎原样挪到开发板上跑，这种"一套运行时到处用"的感觉，确实对得上标题里那句"所有内容"。

1.3 为什么需要这样一门"方言"

很多人会问：直接用MicroPython不好吗？为什么要自找麻烦用一个生态更小、资料更少的变体？我的答案很直接：因为有一批设备真的被卡在"用CPython太大、用MicroPython又嫌浪费"的尴尬间隙里。

比如老一代的STM32F103系列，Flash只有64KB到512KB，RAM只有20KB到64KB。MicroPython能在上面跑，但能留给用户脚本和应用逻辑的空间已经不多。如果你还想塞一套简单文件系统、几个业务模块、一点协议栈，容量马上捉襟见肘。Pycopy的做法是从运行时层面往下削，把解释器、对象表示、字节码都压得更紧，让用户那部分代码有更多呼吸空间。反过来，在桌面端和云端，Pycopy追求的是"轻装上阵"：小体积可执行文件、毫秒级启动、尽量少吃内存，这些特点在容器和Serverless场景里都有实际价值。

所以这门方言不是技术炫技，它是在回答一个很实际的问题：当设备资源有限到边缘，还想要Python级别的开发效率，到底能做到多极致。

2. 极简高效存储的底层逻辑：代码体积和内存是怎么省下来的

2.1 源码和二进制体积的双重瘦身

Pycopy第一个让人印象深刻的地方是固件体积。我最初以为这只是把源码里多余的模块删掉，实际看下来远没那么简单。

首先是模块的"可裁剪性"。Pycopy把大量功能做成可选编译单元，编译固件时按需打开。你不需要蓝牙、不需要文件系统、不需要某些网络协议栈，直接在配置阶段关掉，现代编译器的链接优化会自动把没引用的代码剔除掉。这样一来，最终固件里只留下真正要用的部分。

其次是源码本身也在为体积服务。Pycopy在实现标准库功能时反复压缩代码量，能共用底层函数的绝不重复造轮子。这种方式带来的收益是双份的：Flash空间省了，RAM占用也省了，因为运行时要加载到内存里的模块代码更少。

我实测时最直观的感受是，同样一块板子、同一套工具链，Pycopy编译出来的固件比MicroPython要小一截。具体小多少跟板型和开关的模块有关，不同版本差异也大，但按我手头的STM32F103VET6来说，剩下的Flash空间够我多存好几个业务脚本和静态资源。

2.2 对象模型与内存管理：省堆就是省命

在小内存设备上，"省堆"比"省Flash"更关键，因为Flash只能决定你的程序装不装得下，RAM才决定程序跑不跑得动。

Pycopy在对象模型上做了很多面向空间的设计。举个例子，小整数这种高频对象会被直接内联表示，尽量压在寄存器或栈上，而不是每次创建都去堆里申请一块内存。字符串、bytes这类不变对象也有专门的紧凑表示，减少元数据开销。对比CPython里每个对象动辄带一堆字段的设计，Pycopy的对象头明显更轻薄。

垃圾回收也不是简单的标记-清除。Pycopy针对受限设备做过堆策略调整，允许你精确控制堆的位置和大小，必要时可以只给GC一个很小的堆，剩下的RAM完全留给用户对象和原生缓冲。这对那些需要处理网络帧缓冲、音频采样数据的场景非常关键。我自己的体会是，在64KB RAM的板子上，GC参数调对了，系统稳定性和响应延迟完全是两种表现。

2.3 字节码与存储布局：让每个字节都有存在意义

Python源码在执行前会被编译成字节码。CPython的字节码指令平均长度较长，Pycopy在重新设计字节码时，明显对"热门指令"做了压缩优化——使用频率高的指令用更短的编码，低频指令可以走扩展序列。整体下来，一套业务逻辑编译出的字节码体积会小于传统实现。

存储布局方面，Pycopy对文件系统也有一套自己的取舍。对于必须长期保存的配置、脚本数据，你可以选择是否启用日志型文件系统、是否需要掉电保护。很多资源极其有限的板子上，省掉复杂文件系统的元数据开销，能把更多Flash让给用户数据。

这里想强调一点：这些优化不是"免费午餐"。字节码越紧凑，解释器加载和执行时的解包逻辑就越复杂；GC可配置的代价是你必须理解它。所以用Pycopy，你得有那么一点"啃源码"的觉悟，和直接用MicroPython写业务代码的心态完全不一样。

2.4 省出来的空间到底有多大价值

空间这种东西，平时不觉得，等你真正被工程约束卡住时就懂了。

我手头有个小项目，要在STM32F103VET6上加一块TFT屏幕、一个无线模块，还要留出OTA升级的备份区。整个Flash 512KB，看起来不少，但把引导区、备分区、固件区、脚本区一划，留给应用逻辑的空间立刻紧张。用MicroPython可以跑通，但每加一个功能都要精打细算。换到Pycopy之后，固件本体和运行时开销往下压了一截，至少省出一个放日志、放字库、放配图文件的空间。这次体验之后我明白了，它说的"高效存储"不是一个抽象形容词，而是实打实能让你多存点东西、多干点事。

3. 在STM32微控制器上跑Pycopy的完整实操

3.1 硬件准备和开发板选择

我用来做测试的是STM32F103VET6，Cortex-M3核心，512KB Flash、64KB RAM。这块板子属于"比上不足、比下有余"的典型：比F103C8T6的64KB Flash宽裕很多，价格又比F407便宜，用于折腾Pycopy非常合适。如果你手头是其他型号，只要Flash在128KB以上，基本都值得一试。

除了板子本身，还需要一个ST-Link V2调试下载器，再加一根USB转串口线或者带串口功能的调试板。Pycopy的固件本身就是裸机程序，不依赖操作系统，烧录和调试流程跟传统STM32开发一致。连线方面，SWD接口接ST-Link，串口则接芯片的USART1，我用默认的PA9和PA10。

3.2 获取源码和准备工具链

Pycopy源码可以直接从GitHub仓库拉取：

git clone https://github.com/pfalcon/pycopy.git cd pycopy

编译需要arm-none-eabi-gcc工具链。在Ubuntu等Linux发行版上直接用包管理器安装即可：

sudo apt install gcc-arm-none-eabi make

这里有一个容易忽略的细节：Pycopy的源码目录结构在不同版本里有过调整，我当时差点找不到STM32的移植代码。实际上入口一般就在ports目录下，stm32相关的代码会在stm32或stm32f之类子目录里。如果你拉到的版本目录变了，别慌，先在仓库里搜索stm32关键词，很快就能定位。

3.3 编译固件与烧录

进入对应端口目录后，先查看支持的开发板配置：

ls boards

如果没有你手中型号的现成配置，就选一个Flash、RAM规格最接近的board作为模板，改一下链接脚本。我当时的做法是参考STM32F103VE系列已有的board配置，检查stm32f103xe.ld里的Flash大小声明是512KB、RAM大小是64KB，确认无误就直接用。

编译命令很简单：

make BOARD=你的板型名称

第一次编译会比较久，主要是在编译C标准库和运行时核心。编译完成后，目录下会生成一个hex或bin固件文件。烧录可以选择：

make BOARD=你的板型名称 deploy

这个命令依赖ST-Link，如果你已经装了openocd或stlink-tools就能直接跑通。没有的话，手动用ST-Link Utility或stm32flash工具烧录bin文件也一样。烧录完成后，用串口连接需求串口参数，我用的是115200波特率、8N1。

screen /dev/ttyUSB0 115200

如果一切顺利，你会看到Pycopy的交互式REPL提示符>>>。

3.4 第一次控制外设：点灯和按键

进到REPL之后，先感受一下环境：

import sys print(sys.implementation)

它会打印出Pycopy的版本信息，看到这行输出就说明解释器已经活了。接下来做经典的点灯实验：

import machine import time pin = machine.Pin('PB0', machine.Pin.OUT) while True: pin.toggle() time.sleep_ms(500)

有一点需要提醒：Pycopy不同板型对引脚命名的方式不完全统一，有的版本继续沿用pyb风格，有的更推荐使用machine库。你拿到板子后最好先用help(machine.Pin)看一眼支持的引脚名，再决定用哪个编号。我第一次就在命名上卡了一下，翻源码才确认正确写法。

按键读取的思路也类似，把引脚配置成输入模式，再循环读取value值。和MicroPython的体验几乎一致。这套REPL联调方式比传统的"改代码-编译-烧录"循环快太多，改Python脚本根本不用重新烧固件，把文件放到文件系统里或者直接在REPL里敲代码就行。

4. 受限环境下的一线优化手法：内存和存储还能再省一点

4.1 先学会观察，而不是凭感觉优化

很多人在小内存设备上写Python，上来就各种"省内存技巧"乱试。我的经验是先量化问题，再动手。在Pycopy的REPL里，直接可以用gc模块查看堆状态：

import gc print(gc.mem_free()) print(gc.mem_alloc())

如果固件支持更细的统计，也可以用gc.get_stats()拿到分配次数、回收次数等更详细的数据。观察几次之后，你对项目的内存画像会非常清楚：哪段代码突然吃掉大量内存、哪些对象一直没被释放、GC频繁触发的时间点在哪里，全都有数。

不要一上来就怀疑"是不是语言不够高效"。很多时候，问题出在业务代码里的临时对象太多。

4.2 写代码时的省内存习惯

在Pycopy上写应用，我慢慢养成了一套自己的代码风格，核心原则是"能不生成对象，就不生成对象"。

• 尽量用array.array代替list存数值序列，尤其是传感器采集、波形数据这种批量数值，省下的内存非常可观。
• 循环里避免用字符串拼接，尽量用bytearray一次性构造；大量字符串格式化在资源紧张时非常容易撑爆堆。
• 自定义类加上__slots__，禁掉默认的__dict__，每个实例能省下几十甚至上百字节。
• 能全局复用的对象不要放在函数里反复创建，尤其是大缓冲区，比如网络接收缓存，定义成模块级变量一次性分配。
• 用完的大对象，比如临时列表、帧缓冲，马上del，配合gc.collect()手动触发一次回收。

这些习惯在CPython里只是"性能优化"，在Pycopy的严苛环境下经常是"能不能跑"的区别。

4.3 关于文件系统存储的几个提醒

存储空间也要精打细算。Pycopy支持把Python脚本以冻结字节码（frozen bytecode）的形式编进固件，这样做的好处是启动快、不占RAM、也不需要额外文件系统。对于那些长期不变的核心驱动和基础工具，我建议走冻结模块的方式；只有需要频繁更新的业务逻辑和配置数据，才放到可写文件系统里。

文件系统的选择也要谨慎。功能强的文件系统有日志、掉电保护、坏块管理，但也要付出额外的Flash和RAM代价。如果设备只是存一些配置项，用最简单的块设备文件系统就好；如果你要频繁写入传感器数据，就考虑带磨损均衡的日志型方案。另一个坑是频繁擦写Flash：没有磨损均衡的文件系统，反复写一个日志文件可能几个月就磨坏Flash区块。给日志最好也做一下简单的分文件轮换，或者用RAM缓存批量写入。

4.4 我踩过的几个具体坑

一个印象深刻的问题是深度递归导致栈溢出。PC上Python递归深度到几百上千都没感觉，但在Cortex-M3这种板子上，每次递归调用占用的栈空间是实打实的硬件栈。我用递归做目录遍历时，实现了树上还正常，换成又深又宽的真实目录结构，直接死机。后来改成显式栈+迭代写法，问题消失，内存占用也更稳。

另一个坑是浮点数。Pycopy在部分板型上默认不开启浮点支持，即使开了，软件浮点的计算代价也很高，内存占用比整数运算大得多。我在做UI动画时用了大量浮点计算，结果掉帧加内存飙升。把所有浮点改成定点数之后再跑，流畅度和内存表现同时改善。

5. 把Pycopy搬上桌子和云端：它并不只是嵌入式专用

5.1 桌面端体验：轻量到可以随手启动

Pycopy在类Unix系统上有独立移植。编译出来后，你会得到一个几MB甚至更小的可执行文件，启动速度非常快，和CPython那种"先加载一大堆模块再说"的体验完全是两回事。

我试过在树莓派上用Pycopy跑一些轻量网络脚本。同样一段实现HTTP请求的小服务，CPython启动需要几百毫秒，Pycopy这边几乎是秒开。对于本地开发时想快速验证一个小想法，这种即时反馈很舒服。更不用说把Pycopy解释器打包成一个极小的二进制放进容器镜像里，镜像体积降下来，冷启动时间也跟着降，这让它天然适合一些Serverless和边缘计算场景。

5.2 云端的定位：做"小而快"的节点

云端不一定都是几GB内存的大型服务，很多微服务其实只是转发、校验、做一点轻逻辑。用CPython可以，但容器镜像几百MB、冷启动几百毫秒，有时候并不划算。Pycopy在这些场景里可以当一把"小刀"用：一个小体积、低内存、毫秒级启动的脚本运行时。

当然，它的生态短板很明显。CPython的pip仓库有几十万个包，Pycopy只能提供其中一小部分标准库和少量自研模块。所以我的建议是：核心业务如果依赖大量第三方库，老老实实用CPython；如果只是一些边角服务、独立小工具、协议转换器，Pycopy值得尝试。

5.3 什么时候别用Pycopy

说了这么多优点，也得说清边界。如果应对的场景是"团队协作开发、代码要长期维护、有大量现成依赖可用"，Pycopy不适合，生态差距会拖累效率。另一个极端是，如果你刚从Arduino转到Python，直接上MicroPython更稳妥，因为教程和社区资料多，遇到问题容易查到答案。Pycopy更适合那些明确知道自己在干什么、愿意为资源极限去阅读源码和调整运行时的开发者。

从我个人的角度，Pycopy给我最大的收获不是"多了一种固件选择"，而是改变了我对Python运行时的认知：原来一门高级语言可以在那么少的资源里活得这么自在。它逼着你去理解内存、理解编译、理解解释器，这些收获是单纯用MicroPython写应用的人很难体会到的。如果你也有资源吃紧的项目，不妨给它一次机会，带着"可能要啃几小时源码"的心理预期去折腾，大概率会物超所值。

本文还有配套的精品资源，点击获取