第1章 Google Play更新机制全景：核心更新方式、文件交付类型、与帧率的关联

本课程为参数测试型课程，第一章节作为全景概述，为后续29章的具体参数实验建立统一的概念框架和术语体系。本章主要阐明Google Play应用更新的三种核心方式、两种文件交付类型，以及它们如何在底层引发CPU、I/O和内存波动，最终体现为游戏或应用的帧率抖动。

1.1 核心更新方式

Google Play支持三种更新策略，其触发场景和资源消耗各有不同，是帧率测试的核心自变量。

更新方式	触发条件	用户感知	对帧率的典型影响
增量更新（Patch）	版本差异较小，仅下载bsdiff/HDiffPatch生成的补丁包	下载量小，更新快	解压补丁时CPU峰值高，偶现微卡顿
完整更新（Full APK）	版本差异大、补丁失败或首次安装	下载量大，更新慢	安装器占用磁盘I/O，后台解压导致帧率下降
流式安装（Streaming Install）	Android 10+使用APK Signature Scheme v4，支持边下边用	可提前进入应用	后台持续I/O读取，前台帧率受文件访问竞争影响

1.2 文件交付类型

Google Play允许开发者选择两种交付格式，直接影响运行时资源的加载策略。

• APK（Android Package Kit）：传统单一包体，所有资源打包在一个文件中。更新时替换整个APK，安装时间相对较长。
• AAB（Android App Bundle）：按需分发，仅下载运行所需的分模块（base、feature、configuration splits）。更新时只需交付变更的模块，增量更细粒度。

1.3 与帧率的关联路径

更新机制对帧率的影响并非直接，而是通过下述三个中间变量传导：

1. CPU峰值占用：补丁解压、dex/so重写、资源重打包均会拉升CPU使用率，挤占渲染线程时间片。
2. I/O竞争：安装器在安装或更新过程中持续读写存储，而游戏/应用在运行中也需要加载纹理、模型、声音文件，两个I/O流冲突将导致渲染线程等待。
3. 内存抖动：更新时的临时文件、解压缓存和模块加载会触发频繁的GC或swap，引起帧率周期性下跌。

这三条路径共同决定了在“更新中”和“更新后首帧”两个关键测试窗口内的帧率表现。

1.4 更新影响帧率的逻辑结构

下图展示了Google Play更新方式、文件交付类型到帧率影响的核心传导路径。

1.5 参数含义与测试条件概览

从本章开始，本课程所有参数测试均围绕下表定义的核心参数展开：

参数名	含义	可取值范围	默认值
update_mode	更新方式类型	patch / full / streaming	patch
delivery_format	文件交付格式	APK / AAB	APK
storage_type	存储类型	UFS 2.2 / UFS 3.1 / eMMC 5.1	UFS 2.2
cpu_core_lock	是否锁定CPU核心频率	locked / unlocked	unlocked
test_scene	测试场景	idle（空载）/ loading（加载）/ combat（战斗）	loading

在正式进入参数实验前，请确认测试设备已关闭自动更新、暂停系统OTA，并使用以下命令监控更新过程中的系统资源：

# 监控CPU使用率（每隔500ms采样）
adb shell top -d 0.5 -o PID,CPU%,NAME | grep -E '(game|installer|downloader|installd)'

# 监控I/O wait和磁盘读写字节
adb shell iostat -x 1 10

# 监控内存和GC事件
adb shell dumpsys meminfo com.your.game.package | grep -E '(PSS|Heap|GC)'