Python打包的APK体积过大？优化依赖与精简构建的技巧

沈亦白

发布时间：2026-11-10 | 4人浏览过

原创

针对Python打包Android APK体积动辄几十甚至上百兆的问题，系统讲解多架构动态库过滤、排除无用源码缓存、裁剪标准库与字节码优化、中文字体子集化及APK分析工具的使用技巧。

使用 Buildozer、python-for-android (p4a) 或 BeeWare 将 Python 脚本打包为 Android 安装包时，哪怕只写了几十行代码，生成的 APK 也常常达到 70MB 至 100MB 以上。导致体积失控的核心原因在于全架构二进制库重复打包、全量 Python 标准库和冗余测试文件的无差别打包。通过配置目标 ABI 架构过滤、设置精细化排除规则、裁剪标准库黑名单并剥离动态库调试符号，能够将最终产物缩减 60% 至 75% 以上。本文将系统拆解这些可直接落地的关键配置与工程技巧。

概览：Python 移动端打包体积优化与瘦身路径全景

一、为什么 Python 打包的 APK 体积会失控？

要有效精简安装包，首先需要理解 APK 的内部构成。APK 本质上是一个用 ZIP 格式压缩的文件包。普通原生 Android 应用（Java/Kotlin）编译后主要是 DEX 字节码与少量资源，体积通常只有几兆到十几兆；而 Python 应用能在 Android 上运行，是因为打包工具把一套完整的 Python 运行时、C 解释器动态库以及所有依赖都完整封装进了 APK 中。

解压一个未经优化的 Python APK，其体积通常被以下四个部分所占据：

lib/ 目录（原生动态链接库）：通常占 APK 总大小的 60% 至 75%。默认情况下，构建工具会同时编译 armeabi-v7a、arm64-v8a、x86、x86_64 四个 CPU 指令集的 libpython.so 和 C 扩展依赖（例如 NumPy、Pillow），一套相同的动态库被复制了四份，且这些 .so 文件通常带有大量调试符号。
assets/ 目录（Python 运行时与标准库）：通常占 15% 至 20%。默认包含完整的 Python 标准库。很多专为桌面端设计的模块（如 tkinter、idlelib、turtle）以及庞大的 test、unittest 测试套件都会被完整复制。同时，如果未开启字节码编译优化，还会同时保留未压缩的 .py 源码与 .pyc 文件。
项目源码与构建残留：由于未显式声明排除路径，开发过程中生成的 .git 版本库历史、本地虚拟环境目录（.venv）、单元测试用例及缓存无意间被全部打入应用包。
静态媒体与中文字体：UI 框架若引入了未经子集化的完整中文字体（如思源黑体、苹方），单个 TTF/OTF 文件往往达到 15MB 至 25MB，加上未压缩的高清 PNG 图片，成为额外的体积负担。

图 1：Python 打包 APK 体积构成剖析与典型冗余分布

二、核心技巧一：过滤目标 ABI 架构，消除成倍的动态库冗余

在所有优化手段中，收益最显著、风险最低的操作就是过滤目标 CPU 架构（ABI）。当我们在 Android 手机上安装应用时，系统只会执行与本机 CPU 架构对应的一套 .so 动态库，其余架构的二进制文件完全是静默占位的废弃数据。

目前市面上绝大多数在用的 Android 设备均为 64 位 ARM 架构（arm64-v8a）。在开发测试以及面向主流用户分发时，只需在 buildozer.spec 中明确指定编译架构：

# buildozer.spec 配置示例：仅编译主流 64 位架构
[app]
# 默认可能为 armeabi-v7a, arm64-v8a 多个架构
# 优化为仅编译当前设备所需的架构
android.archs = arm64-v8a

仅凭这一项改动，APK 内部的 lib/ 目录体积就会直接减少 50% 至 70%。例如一个原本 85MB 的包，去除 armeabi-v7a、x86 和 x86_64 后，体积通常会直接降到 30MB 左右。

面向应用商店的分发建议：如果应用需要兼顾少数老旧 32 位设备，不要重新打包为一个全架构的大胖包（Universal APK），而是应通过 buildozer android aab 构建 Android App Bundle（AAB）格式，或者分别构建 arm64-v8a 与 armeabi-v7a 的独立 Split APK，由应用商店根据用户设备类型动态分发。

三、核心技巧二：设置精细化排除规则，剔除源码垃圾与缓存

打包工具默认会扫描项目根目录，并将所有文件视作应用资产复制到 APK 的 assets/app 目录中。很多开发者在项目根目录下维护了开发文档、测试脚本、Git 仓库和本地虚拟环境，导致大量非生产代码被打包进最终文件。

检查你的 buildozer.spec，严格配置 source.exclude_dirs 与 source.exclude_patterns：

# buildozer.spec：配置严格的目录与文件过滤规则
[app]
# 排除版本控制、虚拟环境、测试脚本及构建缓存目录
source.exclude_dirs = tests, test, docs, .git, .github, venv, .venv, env, __pycache__, .pytest_cache, build, dist

# 排除非运行期的文档、配置与设计源文件
source.exclude_patterns = Makefile, pytest.ini, tox.ini, *.pyc, *.pyo, *.pyd, *.md, *.txt, *.blend, *.psd, *.sketch, *.xcf

关键排查点：确保不要在 requirements 中写 requirements = . 或包含整个虚拟环境。只声明应用代码显式 import 的第三方库（例如 requirements = python3,kivy,requests），这样 python-for-android 就会仅编译所必需的库依赖，而不是将本机的开发辅助包（如 flake8、black、pytest）全盘塞进手机环境。

图 2：Python APK 依赖精简与构建优化 5 步实操流程

四、核心技巧三：裁剪 Python 运行时与无用标准库

Python 标准库设计之初面向桌面与服务器，内置了大量的测试套件和图形界面模块，这些在 Android 上几乎从不运行。默认情况下，打包程序会把它们全部打入 assets/private.mp3 或 assets/site-packages 中。

1. 剔除无用的标准库模块

python-for-android 支持通过黑名单（blacklist）过滤无用模块。可以在项目根目录下创建或编辑 blacklist.txt，将不使用的标准库列入其中：

# blacklist.txt 常见过滤名单示例
tkinter/*
turtle.py
idlelib/*
test/*
unittest/*
pydoc.py
pydoc_data/*
distutils/*
lib2to3/*
curses/*
ensurepip/*

在 buildozer.spec 中关联该黑名单文件：

p4a.blacklist = %(source.dir)s/blacklist.txt

2. 启用 Python 字节码编译并去除源码

在移动设备上，Python 可以直接执行预编译的 .pyc 文件，不需要保留人类可读的 .py 源码。通过设置环境变量 PYTHONOPTIMIZE=2，Python 解释器在编译字节码时会剥离 docstring（文档字符串）和 assert 断言语句，这能进一步削减 10% 左右的字节码体积：

# 编译时注入环境变量以优化字节码生成
export PYTHONOPTIMIZE=2
buildozer android debug

这样不仅减少了安装包体积，还能防止他人解压 APK 后直接查看和修改你的明文 Python 源码。

五、核心技巧四：动态链接库（.so）符号剥离与资源优化

当动态库与代码层面的优化完成后，剩余的大块头通常是 Native 动态库中的调试符号以及应用附带的静态资产（字体与图片）。

1. 使用 NDK 的 llvm-strip 剥离符号

构建 C 扩展时，编译器默认会保留详细的调试符号（符号表与行号信息），这对于本地崩溃分析有用，但对于线上安装包却是不必要的开销。使用 Android NDK 提供的 llvm-strip 工具可以安全地剔除这些信息：

# 示例：定位 NDK 路径并对打包产物或 .so 目录执行符号剥离
# （通常位于 $ANDROID_NDK_HOME/toolchains/llvm/prebuilt/.../bin/llvm-strip）
llvm-strip --strip-debug .buildozer/android/platform/build-*/build/libs_collections/*/lib/*.so

剥离调试符号后，很多原本几兆大小的 .so 文件会缩小 30% 到 50%，且不影响运行时的函数导出调用。

2. 中文字体子集化（Font Subsetting）

如果移动端界面需要显示中文，引入一份完整的中文字体（如中文字符集 GB2312 或常用 3500 字）往往高达 10MB 至 20MB。实际上，很多工具型应用只会用到界面固定的提示文本和常用汉字。利用 Python 的 fonttools 库，可以轻松提取常用字符子集：

# 安装字体处理工具
pip install fonttools

# 提取仅包含常用 3500 汉字及 ASCII 字符的精简字体文件
pyftsubset SourceHanSans-Regular.otf   --text-file=common_chinese_chars.txt   --output-file=SourceHanSans-Subset.otf

通过子集化处理，字体文件体积通常会从 18MB 骤降至 600KB 左右，这对 APK 是立竿见影的减肥。

图 3：优化手段减重效果与技术投入决策矩阵

六、排查与验证：使用分析工具建立体积监控闭环

在进行各项优化配置后，必须使用分析工具对输出产物进行精确度量，确认各部分的减重收益，并及时发现意外引入的冗余。

1. 命令行快速探查

无需启动复杂的集成环境，直接使用 unzip 与排序命令，就能找出 APK 中体积排名前 20 的大文件：

# 查看 APK 中占用最大的 20 个文件及路径
unzip -l bin/myapp-0.1-arm64-v8a-debug.apk | sort -n -k1 | tail -n 20

2. 使用 Android SDK 的 apkanalyzer 工具

Android SDK 自带的 apkanalyzer 能够直接输出各个分区的占比摘要：

# 输出 APK 各分卷占用摘要
apkanalyzer apk summary bin/myapp-0.1-arm64-v8a-debug.apk

# 分析 lib 原生库与 assets 资源详细分配
apkanalyzer files list bin/myapp-0.1-arm64-v8a-debug.apk

图 4：APK 瘦身诊断分析与持续发布闭环体系

七、常见注意事项与排坑指南

避免误删隐式依赖：在配置 blacklist.txt 时，一定要在手机或模拟器上启动应用并走完核心业务逻辑。某些三方库可能在特定逻辑下动态 import unittest 或 pydoc，如果发生 ImportError，只需将对应模块从黑名单中移除。
科学计算库的体积边界：如果应用依赖 numpy、scipy、pandas 等重型 C 扩展库，其包含的 OpenBLAS、LAPACK 底层线性代数库本身就具备 10MB 以上的体量。此时单架构过滤已是收益最高的手段，除非寻找纯 Python 实现或更轻量的运算库替代，否则不建议过度手工裁剪其内部动态库，以防底层符号丢失引发崩溃。
构建前清理残留缓存：修改了 buildozer.spec 中的排除项或架构后，最好执行一次 buildozer android clean，防止之前构建遗留的旧架构 .so 依然残留在打包临时目录中被重新打包。

总结

Python 打包 APK 体积庞大并不是无法解决的痼疾。通过限定单架构 ABI、精细化排除非运行期文件、裁剪标准库与优化字节码，以及对字体和动态库进行符号剥离这四套组合拳，即可在不破坏业务逻辑的前提下，将原本接近 100MB 的笨重 APK 精简至 20MB 左右的轻量级产物，大幅提升用户的下载意愿与启动性能。