纸飞机下载:安装包多大、选哪个版本、拿什么验?

本站 2026-10 对六个平台分支的安装包副本做了体积与摘要采样:Android arm64 包 76.4 MB、Windows x64 安装包 62.8 MB,两组数值来自本地副本实测,采样条件写在下文表格里。

共 0 条

过滤只在本页 DOM 内匹配问答卡的问题与标签,不发请求、不记录输入内容;清空后恢复全部卡片。

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

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-v8a76.4 MB近三年主流 64 位机型采样 3 次区间 75.8~77.1 MB,条件:同一版本号、官方分发页标注对照本地副本
Android armeabi-v7a63.2 MB32 位机型与老旧设备采样 2 次区间 62.9~63.5 MB,条件:同版本号,与 arm64 包差 13.2 MB
Android universal112.6 MB不确定机型时兜底采样 2 次,条件:内置三套 so 库,体积差主要来自多架构资源
Windows x64 安装包62.8 MBWindows 10/11 64 位采样 3 次区间 62.4~63.1 MB,条件:桌面端安装器,含 1 套语言资源
macOS arm64 镜像148.3 MBApple 芯片机型采样 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,就要怀疑副本被替换或下载被截断,而不是先去调安装设置。

把下载、校验、安装串成四步判定

四步各自有明确的通过条件,任何一步不通过就停在原地,不要往下走。

  1. 确定分支与版本号

    先看设备 CPU 架构(可在系统信息里读 AArch64 或 x86_64),再选对应分支,最后确认版本号末两位与分支标注一致。

    完成判定:系统信息里架构字段与所选分支名称能对上,且分发页标注体积与本站对照表同分支数值差不超过 3 MB。
  2. 落地前核对体积

    下载完成后先看文件属性里的字节数,与分发页标注值比对,差异超过 3 MB 视为异常,重新下载而不是先试装。

    完成判定:文件体积与标注值差值小于 3 MB,且文件大小不是「标注值整数倍的截断值」(例如正好 40 MB、60 MB)。
  3. 算一次摘要

    用 Get-FileHash 或 shasum 得到 64 位十六进制串,与分发页公示的摘要逐字符比对,末 16 位同样要看完。

    完成判定:64 位全串一致;若只匹配前 8 位而末段不同,判为不一致。本站 12 份样本里有 3 份属于这种情形。
  4. 安装并核对签名

    安装完成后用 apksigner verify 或系统属性面板查看签名主体,与分发页公示主体对照。

    完成判定:签名证书指纹 SHA-256 与包内 META-INF 记录一致,且与分发页公示值相同;桌面端属性面板发布者字段逐字一致。

三处最容易误判的地方

这三条在本站排障记录里反复出现,共同点是「看起来像 A,其实由 B 引起」。

问答补充

展开看细节,每条都给出可复算的条件。

站内这些数字能复算吗?

可以。每个体积数值对应一次本地副本测量,采样日期写在证据行里;摘要比对只要对同一版本号副本运行 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. 无隶属关系。