来自 Android14 的“酷炫惊喜动画”——记录一次安卓动画缓存问题的排查过程

摘要：本文针对 Android 14 系统中 Activity 过渡动画在应用覆盖安装后出现异常表现的问题，通过对 AOSP Android 13/14/15 三个版本 TransitionAnimation、AttributeCache、DefaultTransitionHandler 等核心模块的源码对比分析，揭示了根因------动画资源缓存从 system_server 进程迁移至 systemui 进程后，PACKAGE_REMOVED 广播的缓存清除逻辑被遗漏，导致旧缓存与新资源 ID 映射冲突。最终给出基于 aapt2 --stable-ids 的资源 ID 固定方案，从应用侧彻底规避该系统级缺陷。

1 问题背景与现象描述

Android 14 系统版本大规模推送后，1688 主客 APP 及 1688 商家版 APP 的线上用户反馈中出现了一类非预期的 Activity 过渡动画异常------页面切换时动画错乱，表现为动画资源与预期不匹配，以至于出现了令人啼笑皆非的"酷炫惊喜动画效果"

（新）异常过渡动画

2 问题定位与特征分析

通过对大量用户反馈样本的统计分析，提炼出以下关键特征维度：

维度	观测结果	推断意义
触发场景	覆盖安装（端内版本升级）	与包替换流程相关
发生时机	Activity 切换时，无特定业务集中性	系统级动画机制问题
设备厂商	华为、小米、OPPO、vivo、Samsung 等主流品牌均有	非厂商定制引入
系统版本	仅 Android 14	版本特异性，AOSP 行为变更引入
复现条件	复现用户必现，开发测试团队未复现	与运行时缓存状态相关
恢复手段	关机重启后恢复正常	进程级缓存失效可解决

基于上述特征，初步定位为：在 Android 14 系统上，应用覆盖安装后，存在概率性的动画资源缓存脏数据问题，该问题的生命周期与系统进程的存活周期一致。

通过 Google IssueTracker 提交 issue 并联系华米OV四大厂商确认：

Google 官方确认为 Android 14 系统已知缺陷，将在后续版本修复；
各厂商侧已陆续推出系统补丁（具体方案未公开），但由于系统更新覆盖率和用户升级率的限制，问题仍持续存在。

3 源码分析：三代动画缓存机制演进

为从根因层面理解该问题，本节对 Android 13、14、15 三个版本中 Activity 过渡动画的资源加载与缓存管理机制进行对比分析。

以下代码分析中，流程性调用链以链式路径形式呈现，核心差异点贴出关键源码并加以解释。

3.1 Android 13：`system_server` 进程内的完整缓存管理

基于 AOSP android-13.0.0_r3 分析

在 Android 13 中，Activity 切换动画完全在 system_server 进程内完成，由 AMS（ActivityManagerService）与 WMS（WindowManagerService）协作调度。其核心调用链路为：

在 TransitionAnimation#loadAnimationRes 中，动画资源的加载采用 AttributeCache 缓存优先策略 ------以 packageName 作为索引键查找已缓存的动画资源 Context：

java 复制代码

@Nullable
public Animation loadAnimationRes(String packageName, int resId) {
    if (ResourceId.isValid(resId)) {
        AttributeCache.Entry ent = getCachedAnimations(packageName, resId);
        if (ent != null) {
            return loadAnimationSafely(ent.context, resId, mTag);
        }
    }
    return null;
}

@Nullable
private AttributeCache.Entry getCachedAnimations(String packageName, int resId) {
    if (packageName != null) {
        // 系统资源（0x01xxxxxx）统一使用 DEFAULT_PACKAGE 索引
        if ((resId & 0xFF000000) == 0x01000000) {
            packageName = DEFAULT_PACKAGE;
        }
        return AttributeCache.instance().get(packageName, resId,
                com.android.internal.R.styleable.WindowAnimation);
    }
    return null;
}

缓存失效机制： AttributeCache 是 system_server 进程内的单例对象，随系统启动初始化。当收到 ACTION_PACKAGE_REMOVED 或 ACTION_PACKAGE_CHANGED 广播时，AMS 通过 forceStopPackageLocked 方法触发缓存清理：

java 复制代码

// AMS 接收包移除/变更广播
case Intent.ACTION_PACKAGE_REMOVED:
case Intent.ACTION_PACKAGE_CHANGED:
    // ...
    if (removed && killProcess) {
        forceStopPackageLocked(ssp, ...);
    }

@GuardedBy("this")
final boolean forceStopPackageLocked(String packageName, ...) {
    // ...
    if (doit) {
        if (purgeCache && packageName != null) {
            AttributeCache ac = AttributeCache.instance();
            if (ac != null) {
                ac.removePackage(packageName); // 按 package 索引清除缓存
            }
        }
    }
    return didSomething;
}

小结： Android 13 中，AttributeCache 的初始化、使用、清理均在 system_server 进程内闭环完成。覆盖安装/卸载重装/重启手机时，缓存均能被正确重置，确保资源一致性。

3.2 Android 14：进程迁移导致的缓存管理断裂

基于 AOSP android-14.0.0_r2 分析

Android 14 引入了全新的 Transitions 框架对 Activity 动画进行重构，将动画处理逻辑从 system_server 进程迁移至 systemui 进程。这是一次架构层面的重大变更。

Transitions 框架定义了 8 种 Handler（DefaultMixedHandler、KeyguardTransitionHandler、PipTransition、ActivityEmbeddingController、RecentsTransitionHandler、StageCoordinator、RemoteTransitionHandler、DefaultTransitionHandler），其生命周期为：start → pending → onTransitionReady → ready → play → active → finish。

Activity 常规过渡动画由 DefaultTransitionHandler 负责处理，其调用链路为：

最终仍然走到 TransitionAnimation#loadAnimationRes，同样依赖 AttributeCache 进行缓存读取。

关键问题：AttributeCache 是进程级单例。 当动画处理迁移至 systemui 进程后，该进程内需要独立初始化一份 AttributeCache 实例。审查 DefaultTransitionHandler 的初始化代码：

java 复制代码

private void onInit() {
    updateEnterpriseThumbnailDrawable();
    mContext.registerReceiver(
            mEnterpriseResourceUpdatedReceiver,
            new IntentFilter(ACTION_DEVICE_POLICY_RESOURCE_UPDATED),
            null, mMainHandler);

    AttributeCache.init(mContext);  // 仅初始化，无缓存清理注册
}

致命遗漏： systemui 进程中仅执行了 AttributeCache.init()，未注册 PACKAGE_REMOVED 广播监听，也未实现任何缓存清除逻辑。 而 system_server 进程中原有的 removePackage 逻辑仍然存在，但操作的是自身进程内的 AttributeCache 实例------一个在新架构下已不再参与动画加载的"幽灵缓存"。

根因总结：

复制代码

┌─────────────────────────────────────────────────────────────────────┐
│  覆盖安装 → 触发 ACTION_PACKAGE_REMOVED 广播                         │
│                                                                     │
│  system_server 进程：                                                │
│    AMS 收到广播 → forceStopPackageLocked                             │
│      → AttributeCache.removePackage(pkg)  ✅ 清除成功（但此实例已无用）│
│                                                                     │
│  systemui 进程：                                                     │
│    无广播监听 → AttributeCache 保留旧版本资源映射  ❌ 缓存脏数据残留    │
│                                                                     │
│  后果：新版本 APK 的 resource ID 重新分配后，与 systemui 中             │
│       缓存的旧 Context 产生映射冲突 → 加载到错误的动画资源              │
│                                                                     │
│  重启手机 → systemui 进程重启 → AttributeCache 重新 init → 恢复正常   │
└─────────────────────────────────────────────────────────────────────┘

3.3 Android 15：官方修复------补全 `systemui` 侧的缓存失效机制

基于 AOSP android-15.0.0_r9 分析

Google 在 Android 15 中修复了该问题。动画处理的整体架构与 Android 14 一致，差异在于 DefaultTransitionHandler 的初始化逻辑：

java 复制代码

private void onInit() {
    updateEnterpriseThumbnailDrawable();
    mContext.registerReceiver(
            mEnterpriseResourceUpdatedReceiver,
            new IntentFilter(ACTION_DEVICE_POLICY_RESOURCE_UPDATED),
            null, mMainHandler);

    // 关键变更：使用封装方法完成初始化 + 包监听注册
    TransitionAnimation.initAttributeCache(mContext, mMainHandler);
}

TransitionAnimation 中新增 initAttributeCache 静态方法：

java 复制代码

public static void initAttributeCache(Context context, Handler handler) {
    AttributeCache.init(context);
    AttributeCache.instance().monitorPackageRemove(handler);  // 注册包移除监听
}

AttributeCache 内部新增 PackageMonitor 广播接收器：

java 复制代码

void monitorPackageRemove(Handler handler) {
    if (mPackageMonitor == null) {
        mPackageMonitor = new PackageMonitor(mContext, handler);
    }
}

static class PackageMonitor extends BroadcastReceiver {
    PackageMonitor(Context context, Handler handler) {
        final IntentFilter filter = new IntentFilter(Intent.ACTION_PACKAGE_REMOVED);
        filter.addDataScheme(IntentFilter.SCHEME_PACKAGE);
        context.registerReceiverAsUser(this, UserHandle.ALL, filter,
                null, handler);
    }

    @Override
    public void onReceive(Context context, Intent intent) {
        final Uri packageUri = intent.getData();
        if (packageUri != null) {
            final String packageName = packageUri.getEncodedSchemeSpecificPart();
            AttributeCache.instance().removePackage(packageName);
        }
    }
}

修复本质： 在 systemui 进程内补全了 ACTION_PACKAGE_REMOVED 广播的监听，当应用被覆盖安装（先 remove 再 install）时，systemui 进程中的 AttributeCache 能够正确清除对应 package 的资源缓存，避免新旧资源 ID 映射冲突。

4 实验验证

4.1 实验设计

参数	配置
环境	Android Studio，Pixel 9 模拟器，API 34（Android 14）
被测应用	1688 商家版 App
对照版本	v4.0.3（旧）→ v4.1.0（新）
验证链路	真实用户反馈路径：首页 → 代发货组件 → WindvaneActivity（H5 页面）

4.2 资源 ID 对比

从两个版本 APK 的 resources.arsc 中提取目标 anim 资源的 Entry ID：

版本	`in_from_right`	`alpha_out`
v4.0.3	`0x7f01006b`	`0x7f01001f`
v4.1.0	`0x7f010071`	`0x7f01001f`

in_from_right 的 Entry ID 从 0x006b 后移至 0x0071，表明 v4.1.0 中在 anim 资源类型段内新增了 6 个资源条目（0x006c ~ 0x0071），导致 aapt2 重新分配了该资源的 ID。

4.3 缓存冲突复现

若 systemui 中已缓存 v4.0.3 的资源映射，当 v4.1.0 请求加载 in_from_right（新 ID 0x7f010071）时，缓存中 0x7f010071 对应的实际是 v4.0.3 中的 loading_anim 资源。

将 loading_anim 作为 enter animation 组装为 Transition 进行验证，观察到的动画效果与用户反馈完全一致------确认了缓存冲突假设。

5 解决方案

5.1 方案选型

鉴于该问题的根因在 AOSP 系统层，应用侧无法干预 systemui 进程的缓存行为，可行的规避策略是：确保应用跨版本升级时，动画资源的 ID 保持稳定不变，从而消除 ID 冲突的前提条件。

具体手段为使用 aapt2 的 --stable-ids 选项（官方文档），对关键动画资源的 ID 分配进行固定化约束。

5.2 存量问题处置

主链路动画固定 ：优先固定 BaseActivity 等主链路页面切换使用的动画资源 ID，确保核心用户体验不受影响。
逐 case 补齐：对用户反馈中出现过的异常场景，逐个固定涉及的动画资源 ID。预期 case 数量有限。
对齐策略：固定 ID 时，应对齐当前线上用户量最大的版本中的 ID 映射，最大化覆盖受益用户群。
灰度策略 ：App 发版灰度阶段，可选择仅提醒 B 版本（安装了已修复版本的前置版本）用户升级，或提醒所有非 Android 14 设备之外的用户。

5.3 增量迭代规范

针对后续新增动画资源的场景：

前置条件：当应用的 Android 14 设备活跃用户占比 ≥ 设定阈值时，启用该规范；
触发场景 ：新增核心动画文件（res/anim/ 下）；
固定策略（顺延法） ：以当前版本 anim 类型段中末尾资源的 Entry ID 为基准，新增资源从下一个 ID 顺延固定。确保固定的 ID 在历史版本的 resources.arsc 中无对应条目，从而杜绝映射冲突。

示例：当前末尾 anim 资源 ID 为 0x7f010108，新增资源依次固定为 0x7f010109、0x7f01010a ...

5.4 方案局限性说明

--stable-ids 方案本质上是"应用侧 workaround"，更多见于插件化框架中对资源 ID 的管控需求。其局限在于：需要维护一份 stable-ids 映射文件并纳入构建流程管理，增加了一定的工程复杂度。但在系统侧修复无法全量覆盖用户的现实约束下，这是可控成本最低的确定性解法。

6 总结与思考

本文从一个线上动画异常的用户反馈出发，通过系统化的特征分析定位到 Android 14 的 system_server → systemui 架构迁移中 AttributeCache 缓存管理的逻辑缺失。核心发现包括：

架构迁移的副作用 ：Android 14 将 Activity Transition 处理从 system_server 迁移至 systemui，但未同步迁移缓存失效逻辑，导致 PACKAGE_REMOVED 广播无法清理 systemui 进程中的资源缓存。
资源 ID 动态分配的脆弱性 ：aapt2 默认按资源条目顺序分配 Entry ID，任何资源文件的增删都会导致后续资源 ID 位移，在缓存未被正确清理的场景下触发冲突。
厂商方案的覆盖局限：各厂商通过系统补丁在 ROM 层面修复了该问题，但受制于系统 OTA 推送覆盖率和用户升级意愿，无法保证全量修复。

技术启示：

对于系统级问题的定位，应优先建立完整的复现条件假设，通过源码分析验证假设，最终以实验佐证结论，形成"假设 → 分析 → 验证"的闭环。
在面对依赖外部系统行为的问题时，优先选择应用侧可自主控制的确定性方案（如资源 ID 固定），而非依赖外部修复承诺。

本文分析基于 AOSP 公开源码，实验基于 Android Studio 模拟器环境。

来自 Android14 的“酷炫惊喜动画”——记录一次安卓动画缓存问题的排查过程

1 问题背景与现象描述

2 问题定位与特征分析

3 源码分析：三代动画缓存机制演进

3.1 Android 13：system_server 进程内的完整缓存管理

3.2 Android 14：进程迁移导致的缓存管理断裂

3.3 Android 15：官方修复------补全 systemui 侧的缓存失效机制

4 实验验证

4.1 实验设计

4.2 资源 ID 对比

4.3 缓存冲突复现

5 解决方案

5.1 方案选型

5.2 存量问题处置

5.3 增量迭代规范

5.4 方案局限性说明

6 总结与思考

3.1 Android 13：`system_server` 进程内的完整缓存管理

3.3 Android 15：官方修复------补全 `systemui` 侧的缓存失效机制