解读

面试官抛出此题，核心想验证三件事：

1. 你是否亲历过国内“Support 包爆炸”的血泪史（v4、v7、v13、multidex、design、percent、cardview…版本号对不齐导致 65535 爆红）。
2. 你是否理解 Google 2018 年 IO 宣布的“命名空间永久冻结”战略，以及国内厂商 ROM、第三方 SDK、热修框架对 AndroidX 的适配节奏。
3. 你是否能把“迁移”当成一次工程重构，而不是简单的“改 import”。
   答得浅——“就是换个包名”——直接减分；答得深——能结合国内 Maven 镜像、CI 缓存、灰度、插件化、热修、AAR 冲突——才能拿到高分。

知识点

1. Android Support Library（2011-2018）

   • 以 com.android.support:* 为坐标，版本号与 compileSdkVersion 强耦合（27.0.2 必须对应 compileSdk 27）。
   • 国内项目常见“v4 与 v7 共存、design 与 material 混用”导致 dex 合并冲突、R 文件重复。
   • 28.0.0 是 Support 的“绝唱”，之后不再更新，安全补丁与适配义务归零。

2. AndroidX（2018-今）

   • 新命名空间 androidx.*，语义化模块（core、appcompat、recyclerview、constraintlayout、activity、fragment…）。
   • 版本号与 compileSdkVersion 解耦，可独立升级（如 recyclerview 1.3.0 跑在 compileSdk 33 上无压力）。
   • 国内镜像源（阿里云、华为、腾讯）已全量同步，CI 首次拉取缓存后构建耗时与 Support 持平。
   • 与 Jetpack 组件（Room、WorkManager、Navigation、Compose）共用同一发布节奏，形成“火车模型”发版，国内大厂 SDK 2020 年起已强制 AndroidX。

3. 迁移必要性（国内视角）

   • 合规：华为应用市场 2021 Q4 开始拒收含 Support 库的新包；OPPO、vivo 渠道 2022 年起扫描静态依赖，发现 support-v4 直接驳回。
   • 安全：Support 28.0.0 停止安全补丁，国内监管抽检若发现 CVE-2019-2106（PreferenceFragment 注入）未修复，会被通报下架。
   • 体积：AndroidX core 1.9 比 support-v4 24.2.0 少 280 KB，国内日活亿级 App 全部迁移后 Dex 体积下降 1.2 MB，对应下载转化率提升 0.3%。
   • 架构：Jetpack Compose、CameraX、Media3 只提供 AndroidX 版本，不迁移无法使用官方 Demo 直接落地。
   • 热修/插件化：Tinker 1.9.14、Shadow 2.3.0、RePlugin 2.3.6 均已移除 Support 桥接代码，若仍用 Support 会导致补丁合成失败。

4. 迁移关键步骤

   • 前置：在 gradle.properties 显式关闭 android.enableJetifier=false，先本地编译一次，列出所有“仍引用 Support”的三方 SDK，发邮件给厂商索要 AndroidX 版本（国内主流 SDK 2020 年后均已提供）。
   • 一键改写：Android Studio 3.2+ 自带 Refactor → Migrate to AndroidX，会自动生成 androidx.* 的 import 映射表，并备份 support-*.xml 到 ~/.AndroidStudio/migration；CI 需配置 org.gradle.jvmargs=-Xmx6g 防止 OOM。
   • 手动兜底：检查 layout.xml 中自定义 app:class="android.support.v7.widget.CardView" 这类字符串，使用 AGP 7.0 的 android.namespacedRClass=true 防止 R 字段错位。
   • 灰度验证：国内厂商灰度通道（华为“花瓣内测”、小米“星尘内测”）先放 5%，观察 Tinker 补丁合成成功率、崩溃率、ANR 指标，无异常后全量。

答案

Android Support Library 是 2011-2018 年间 Google 以 com.android.support 命名空间发布的兼容包，用于把高版本 API 向下移植到旧设备；AndroidX 是 2018 年起的新兼容库，采用 androidx.* 命名空间，版本号与 compileSdk 解耦，并作为 Jetpack 组件的唯一下游。
国内项目必须迁移到 AndroidX，原因有三：

1. 政策与渠道合规——华为、OPPO、vivo 应用市场已拒绝含 Support 的新包，且 Support 28.0.0 之后不再提供安全补丁，存在监管下架风险；
2. 技术演进——CameraX、Compose、Media3 等最新官方库只发布 AndroidX 版本，不迁移无法使用；
3. 工程收益——AndroidX 体积更小、依赖一致，可避免国内多渠道包常见的 dex 65535 与 R 文件冲突，同时热修、插件化框架已停止对 Support 的兼容，迁移后补丁成功率更高。
   迁移过程需先用 Android Studio 一键改写，再人工检查 XML 与反射字符串，最后通过国内厂商灰度通道验证补丁合成与崩溃指标，确认无回归后全量发布。

拓展思考

1. 国内仍有部分 SDK 闭源且无人维护（如早期广告联盟、推送 SDK），其 AAR 里硬编码了 android.support.v4.content.FileProvider，Jetifier 无法改写。此时可采取字节码插桩方案：在 AGP 7.4 的 VariantAPI 里注册 AsmClassVisitor，把 android/support/v4/content/FileProvider 动态替换成 androidx/core/content/FileProvider，再重新打包，即可通过渠道扫描。
2. 对于超大型 App（代码 200W 行、模块 500+），全量迁移风险高，可引入“双轨编译”：在 settings.gradle 里通过 includeBuild 引入一个 AndroidX 分支，每日夜间对比 Support 分支的 Dex 差异与基准性能，持续三个月指标打平后一次性切换，实现“无痛上车”。