先比较字节数，不要先比较标签
一个文件的内容没有改变，不同软件却可能显示不同的大小。这不一定是下载损坏，往往是计量单位不同。十进制 MB 使用 1,000,000 字节；二进制 MiB 使用 1,048,576 字节。
因此，一个恰好包含 100,000,000 字节的文件，是 100 MB，也约等于 95.3674 MiB。两种显示都可以是正确的，前提是单位标注清楚。问题通常出在软件使用二进制计算，却只写了含糊的“MB”。
从字节开始复算
MB = bytes / 1,000,000
MiB = bytes / 1,048,576
GB = bytes / 1,000,000,000
GiB = bytes / 1,073,741,824使用文件体积换算器输入整数个字节，可以同时查看两种进制。工具使用整数运算计算关键比例，避免大整数输入先被浮点数近似处理。
显示小数会产生舍入，所以把显示值乘回单位基数后，未必恰好得到原始字节数。需要判断文件是否一致时，应比较精确字节数和文件摘要，而不是截图里的两位小数。
下载体积和安装占用不是同一个指标
APK 是归档格式，其中某些文件经过压缩。下载大小主要描述传输的内容，而安装后会涉及代码、资源、运行时生成内容和应用数据。应用启动后又可能创建缓存或下载额外资源。
因此，不能只凭安装包从 40 MB 变成 35 MB，就断言设备节省了 5 MB 的总存储。也不能拿系统设置里的应用总占用，直接与商店显示的下载大小相减，并把差值全部称为垃圾缓存。
设计一次公平的体积比较
- 固定应用版本、设备架构和语言，避免比较不同 split 组合。
- 固定测量阶段：下载前、刚安装、首次启动后或完成同一操作后。
- 分别记录安装包字节数、应用本体、用户数据和缓存。
- 记录联网状态，以及是否触发资源下载。
- 在报告中统一单位，并保留原始字节数。
一次测量只说明当时的设备状态。后台同步和缓存策略可能改变后续占用，需要长期结论时，应设计重复测量而不是只截一张图。
给读者一份不容易误解的结果
推荐写成“压缩 APK：100,000,000 bytes（100 MB / 95.37 MiB）”，并说明测量工具。若讨论的是清理效果，则写出清理前后同一指标的差值，以及是否包含应用自行重新生成的缓存。
清理完成后的可用空间可能受到其他进程影响。若应用宣称清理了很多文件，但系统可用空间变化很小，应检查重复计数、文件仍被进程持有、统计口径和同步时机，而不是直接把任意一个数值当作最终事实。