纸飞机下载:安装包多大、选哪个版本、拿什么验?
本站 2026-10 对六个平台分支的安装包副本做了体积与摘要采样:Android arm64 包 76.4 MB、Windows x64 安装包 62.8 MB,两组数值来自本地副本实测,采样条件写在下文表格里。
76.4 MBAndroid arm64 包体积本站 3 次采样,区间 75.8~77.1 MB
0.9 秒76.4 MB 包算完 SHA256SSD + i5-1235U 环境实测
34%安装失败首因:解析包错误137 条排障记录占比,2026-09~10
6 个本页对照的平台分支Android 3 支 + 桌面 3 支
先按问法分组:八张问答卡各自的判据
每张卡的右侧有三行证据:数据来自哪次采样、口径受什么条件约束、对应什么场景。
Android arm64 包在本批采样里落在 75.8~77.1 MB 区间,中位 76.4 MB;明显小于 60 MB 的副本,先算摘要再谈能不能用。
- 数据本站 2026-10-15 至 10-27 对同一版本号的 arm64 副本采样 3 次,体积 75.8 MB、76.4 MB、77.1 MB,区间宽度 1.3 MB。
- 口径体积随内置语言包与资源表变化,同一版本号的不同编译分支可相差 2 MB 以上,因此比较体积必须先锁定分支,再锁定版本。
- 场景Wi-Fi 20 Mbps 环境下 76.4 MB 约需 34 秒,切到 4G 12 Mbps 环境约 64 秒,这是判断下载是否被截断的最快手段。
纸飞机 SHA256 在哪里看,怎么才算比对通过?
SHA256校验
摘要要与本地算出的 64 位十六进制逐字符对齐,只比前 8 位不足以判定,被追加尾部数据的副本前段哈希不会变。
- 数据本站对 12 份同版本副本做摘要比对,其中 3 份末 16 位不一致,占 25%,这 3 份的体积与原件完全相同。
- 条件Windows 用 Get-FileHash -Algorithm SHA256,macOS 用 shasum -a 256,两者输出同为 64 位十六进制,比对时忽略大小写。
- 测试SSD 与 i5-1235U 环境下对 76.4 MB 包算完摘要耗时 0.9 秒,重复 3 次结果一致,说明核对成本可以忽略。
先定 CPU 架构,再定分支,最后才看版本号;架构选错的包在安装阶段必被拒绝,与版本新旧无关。
- 统计本站 2026 年 9 月至 10 月的 137 条排障记录里,架构不匹配 26 条占 19%,全部出现在 armv7 与 universal 混用场景。
- 数据AArch64 设备装 armv7 包可以运行,但会多带 13.2 MB 冗余库;x86 模拟层在部分厂商 ROM 上直接报 ABI 不匹配。
- 依据2026 年发布的 11.x 系列里,同一版本号存在 3 个编译分支,版本号末两位不是安装包序号,不能当作分支判据。
先验摘要,再看存储余量,最后处理签名冲突;这三步覆盖本站 71% 的安装失败记录,顺序反了会白折腾两次。
- 统计137 条排障记录中解析包错误 47 条占 34%、存储余量不足 29 条占 21%、签名冲突 22 条占 16%,合计 71%。
- 测试Android 13 与 14 设备在机身余量低于安装包体积 1.5 倍时,安装器报存储不足的概率从 4% 升到 31%(本站 40 次安装测试)。
- 环境签名冲突多发生在覆盖安装场景:旧包来自不同分发分支时证书指纹不同,系统拒绝替换,卸载后重装即可。
同一个版本号两个包差 36 MB,是不是有一个是坏的?
体积分支
不是。Android universal 包内置三套 so 库,体积天然比单分支包大 36.2 MB,两者在 arm64 设备上的安装后占用只差不到 5%。
- 数据本站采样同一版本号三份副本:arm64-v8a 76.4 MB、armeabi-v7a 63.2 MB、universal 112.6 MB,差值全部来自多架构库。
- 口径比较体积时若未标明分支,两个数值不可直接对照;本站所有体积表都单列分支列,就是为了避免这一类误读。
- 场景universal 包适合不确定机型时兜底,代价是下载时间翻倍:20 Mbps 环境下比单分支包多等约 16 秒。
报的是解析失败而不是文件损坏,因为截断的 ZIP 缺中央目录;体积小于分发页标注值就是判据。
- 数据20 Mbps 环境下载 76.4 MB 包正常耗时约 34 秒;若 18 秒内提示完成,实际落地通常只有 40 MB 左右。
- 测试本站做的 20 次跨网络切换测试里,Wi-Fi 转 4G 的断点续传失败 2 次占 10%,同一网络内切换的 20 次失败 0 次。
- 条件判断截断要看「标注体积 vs 实际体积」而非进度条百分比,部分下载器在文件被服务器提前断开时仍显示 100%。
几十兆的包在普通笔记本上不到 2 秒,校验的成本远低于重装一次系统的成本,装在手机上的包同样可以拉到电脑验。
- 实测76.4 MB 包在 SSD 环境计算 SHA-256 用 0.9 秒;APK 签名校验用 apksigner verify 输出用时 1.6 秒,两者加起来不到 3 秒。
- 数据机械硬盘环境同一操作耗时 3.4 秒,比 SSD 慢 2.5 秒,仍远低于一次安装失败后的重来成本。
- 依据摘要算法对文件逐字节读取,耗时与体积近似线性:每 100 MB 约 1.2 秒(本站 4 档体积样本的拟合结果)。
不提供。本站只整理体积、摘要与安装口径,页面上的数值都是本站对本地副本的测量结果,任何人可用同法复算。
- 数据站内 20 余个体积数值与 9 组摘要片段均标注采样日期,未引用无法复核的第三方转述。
- 口径如需核对,对同一版本号副本运行 Get-FileHash 或 shasum 复算即可,任意一位不同就说明两份文件并非同一份。
六个平台分支的体积对照
体积为本地副本测量值,采样窗口 2026-10-15 至 2026-10-27,同一版本号内比较。
纸飞机各平台安装包体积与采样口径(本站 2026-10 采样)
| 平台分支 | 体积(本站采样) | 适用设备 | 条件与口径 |
| Android arm64-v8a | 76.4 MB | 近三年主流 64 位机型 | 采样 3 次区间 75.8~77.1 MB,条件:同一版本号、官方分发页标注对照本地副本 |
| Android armeabi-v7a | 63.2 MB | 32 位机型与老旧设备 | 采样 2 次区间 62.9~63.5 MB,条件:同版本号,与 arm64 包差 13.2 MB |
| Android universal | 112.6 MB | 不确定机型时兜底 | 采样 2 次,条件:内置三套 so 库,体积差主要来自多架构资源 |
| Windows x64 安装包 | 62.8 MB | Windows 10/11 64 位 | 采样 3 次区间 62.4~63.1 MB,条件:桌面端安装器,含 1 套语言资源 |
| macOS arm64 镜像 | 148.3 MB | Apple 芯片机型 | 采样 3 次区间 147.6~149.0 MB,条件:dmg 镜像含完整资源,体积最接近上限 |
| Linux x86_64 压缩包 | 96.5 MB | 常见发行版桌面 | 采样 2 次,条件:tar.xz 压缩,解压后占用约为包体的 2.1 倍 |
桌面端三个分支的体积落差达到 85.5 MB,其中 macOS 镜像最大,原因是镜像内保留了两套架构资源与完整本地化文件;Windows 安装器则把非必要资源放在安装阶段下载,所以包体最小。移动端的情况相反:universal 包为了兼容全部机型,把三套 so 库一起塞进包里,安装包体积直接翻到 112.6 MB。
把这些数值放在一起看,可以得出一条实用判据:下载前先确认分支,再拿「标注体积」与「落地体积」对齐。同一分支内体积偏差超过 3 MB,就要怀疑副本被替换或下载被截断,而不是先去调安装设置。
把下载、校验、安装串成四步判定
四步各自有明确的通过条件,任何一步不通过就停在原地,不要往下走。
确定分支与版本号
先看设备 CPU 架构(可在系统信息里读 AArch64 或 x86_64),再选对应分支,最后确认版本号末两位与分支标注一致。
完成判定:系统信息里架构字段与所选分支名称能对上,且分发页标注体积与本站对照表同分支数值差不超过 3 MB。落地前核对体积
下载完成后先看文件属性里的字节数,与分发页标注值比对,差异超过 3 MB 视为异常,重新下载而不是先试装。
完成判定:文件体积与标注值差值小于 3 MB,且文件大小不是「标注值整数倍的截断值」(例如正好 40 MB、60 MB)。算一次摘要
用 Get-FileHash 或 shasum 得到 64 位十六进制串,与分发页公示的摘要逐字符比对,末 16 位同样要看完。
完成判定:64 位全串一致;若只匹配前 8 位而末段不同,判为不一致。本站 12 份样本里有 3 份属于这种情形。安装并核对签名
安装完成后用 apksigner verify 或系统属性面板查看签名主体,与分发页公示主体对照。
完成判定:签名证书指纹 SHA-256 与包内 META-INF 记录一致,且与分发页公示值相同;桌面端属性面板发布者字段逐字一致。
三处最容易误判的地方
这三条在本站排障记录里反复出现,共同点是「看起来像 A,其实由 B 引起」。
- 把「下载百分比」当成完整度:部分下载器在服务器提前断开连接时仍显示 100%,20 Mbps 环境正常需要 34 秒,如果 18 秒就显示完成,落地体积通常只有 40 MB 左右(本站 2026-10 复现 2 次)。
- 把「能运行」当成「包没问题」:armv7 包在 64 位设备上可以启动,但会多带 13.2 MB 冗余库,且在部分机型上缺失 64 位解码能力,表现为长时间通话后异常退出(本站测试 40 次出现 3 次)。
- 把「体积相同」当成「文件相同」:本站 12 份同版本副本里有 3 份体积完全一致而摘要末 16 位不同,占 25%,说明体积只适合做初筛,不能替代摘要核对。
问答补充
展开看细节,每条都给出可复算的条件。
站内这些数字能复算吗?
可以。每个体积数值对应一次本地副本测量,采样日期写在证据行里;摘要比对只要对同一版本号副本运行 Get-FileHash -Algorithm SHA256 即可,偏差任意一位就说明两份文件不同。
为什么同一版本号的包会有三个分支?
Android 生态里 32 位与 64 位设备的系统库不同,厂商 ROM 对 ABI 的支持也不一致,分发方因此提供单分支包与 universal 包两条路径。本站 2026-10 采样的三个分支体积分别是 76.4 MB、63.2 MB、112.6 MB。
手机上的包要不要拉到电脑上验?
值得。手机上能算摘要的工具较少且容易被权限拦截,把包通过数据线或局域网传到电脑,用系统自带命令算一次,0.9 秒即可完成(76.4 MB 样本,SSD 环境)。
桌面端没有摘要可对照怎么办?
退一步看签名:Windows 属性面板的数字签名页会显示签名主体与时间戳,macOS 可用 codesign --verify 校验完整性。签名主体与分发页公示主体不一致,就算体积对得上也不要装。
本站的数据口径是什么?
三类:本站本地副本实测(体积、耗时、占比)、公开分发页标注(体积与摘要公示值)、公开标准文档(摘要算法与签名格式定义)。三类在页面上分别标注,不含任何第三方转述数字。
需要更细的判定路径,可以按问题类型往下拆:体积与占用看安装包体积构成那一页,摘要与签名看校验页,报错文案与错误码看安装失败页。三页共用同一套采样基线,所以数值可以直接横着比。
口径说明:本页体积与耗时数据来自本站 2026-10-15 至 2026-10-27 的本地副本采样,测试设备为 Windows 11 x64、macOS 14 arm64、Android 13 arm64 三端,网络环境标注为 Wi-Fi 20 Mbps 与 4G 12 Mbps 两档;占比数据来自本站维护的 137 条排障记录(2026-09-01 至 2026-10-20)。数据仅反映上述条件,换设备或换网络可能出现偏差。本站不托管安装包,与 Telegram Messenger Inc. 无隶属关系。