文 3 的参考链接 2 也可以一看。

[crayon-6956a791bf902539923211 inline="true" ]C/C++: C:/Android/Sdk/ndk/27.0.12077973/build/core/build-binary.mk:418: warning: overriding recipe for target 'C:\code\doom\build\intermediates\cxx\Debug\5523b6rn/obj/local/arm64-v8a/objs-debug/lzma_1.9/C/7zDec.o'
C/C++: C:/Android/Sdk/ndk/27.0.12077973/build/core/build-binary.mk:418: warning: ignoring old recipe for target 'C:\code\doom\build\intermediates\cxx\Debug\5523b6rn/obj/local/arm64-v8a/objs-debug/lzma_1.9/C/7zDec.o'
C/C++: C:/Android/Sdk/ndk/27.0.12077973/build/core/build-binary.mk:418: warning: overriding recipe for target 'C:\code\doom\build\intermediates\cxx\Debug\5523b6rn/obj/local/arm64-v8a/objs-debug/lzma_1.9/C/7zDec.o.commands.json'
C/C++: C:/Android/Sdk/ndk/27.0.12077973/build/core/build-binary.mk:418: warning: ignoring old recipe for target 'C:\code\doom\build\intermediates\cxx\Debug\5523b6rn/obj/local/arm64-v8a/objs-debug/lzma_1.9/C/7zDec.o.commands.json'

不管是 overriding recipe for target 还是 ignoring old recipe for target，都没看懂是怎么回事。网上搜索到 SO 上的一篇帖子，说的也是含含糊糊，但似乎说到是跟目标重复有关。打开 build-binary.mk 脚本的看第 418 行是没有线索的，于是又去看工程里跟指定的对象 7zDec 相关的 makefile，这下就找到了问题，7zDec.c 这个要编译的源码文件被写了两回，显然就是导致了“overring”以及“ignoring”的“重复”的来源。

自适应图标是 Android O 引入的，也就是 Android 8（API level 是 26 的 Android 8.0 其 code name 是 O，而 API level 是 27 的 Android 8.1 也是）。

资源。为自适应图标做基础的资源类型也是相应新增的，叫做 AdaptiveIconDrawable。其定义形如：

[crayon-6956a791bfda5346701262 inline="true" ]<adaptive-icon>
  <background android:drawable="@[drawable|mipmap|color]/bg_foo"/>
  <foreground android:drawable="@[drawable|mipmap|color]/fg_bar"/>
</adaptive-icon>

两个 drawable 的大小都必须是 108dp，背景 drawable 必须不透明，而前景 drawable 可以包含透明区域。

遮罩。需要说明的是，尽管自适应图标的大小是 108dp，但是最终显示/渲染一个自适应图标时，系统/设备/启动器所使用的施加于其上用以控制可见区域的遮罩，其大小却只能是 72dp。也就意味着，一个自适应图标的上下左右四个边，均有尺寸为 18dp 的部分在通常情况下是不可见的。

遮罩的形状必须是外凸（convex）的，其形状边缘至中心点的最小距离是 33dp。这也是下图中直径为 66dp 的所谓圆形“安全区”的由来。

渲染。从 Android 8 开始，截止到 Android 12 之前，如果创建图标时使用的是 createWithBitmap 方法，系统（此处主要是指 Google/Android 官方的行为）会对传统图标“以示尊重”，原样渲染，如果位图中存在透明区域，要么保持透明，要么可能渲染为某种特定的背景色（如黑色）。而从 Android 12 开始，系统决定不再给予传统图标那样的优惠待遇，使其长久地破坏系统的视觉效果一致性，于是决定将其缩小，并放置在白色的背景层之上。那会缩小到什么程度呢？就是可以完全放置在安全区以内的程度（可以参见旧文：Android 对非自适应图标的处理）。

Medium 上有人写的两篇博客，对于理解、应用、设计自适应图标具有参考价值。而且其中还提到了上文提及的被遮罩排除的那部分可以有什么样的利用价值。

• https://medium.com/androiddevelopers/implementing-adaptive-icons-1e4d1795470e
• https://medium.com/google-design/designing-adaptive-icons-515af294c783

Android 官方对 Icon 类的文档在：https://developer.android.com/reference/android/graphics/drawable/Icon。

于是又向 grok 请教，而果然，还是它懂得多。给了几个方案，一个是分 sourceSet，这个不考虑；一个是安装后代码下载，也不考虑。另外还有俩。其一是，在构建脚本里写一个任务，而把所有的 assets 集中放到一个 source 目录中，当构建时，自动提前执行此任务，

[crayon-6956a791bff6e873028428 inline="true" ]android {
    // 其他配置...

    // 动态设置 assets 目录
    sourceSets {
        main {
            assets.srcDirs = ['src/main/assets_filtered']
        }
    }
}

task filterAssets(type: Copy) {
    description 'Copy assets based on includeLargeAssets flag'
    from 'src/main/assets'
    into 'src/main/assets_filtered'
    // 根据开关过滤文件
    if (!project.ext.includeLargeAssets) {
        exclude '**/*.largefile' // 假设大文件以 .largefile 结尾
    }
}

// 确保在编译前执行过滤任务
preBuild.dependsOn filterAssets

示例代码如上，一眼可以看懂，就不再多说了，这也不是当前需求的最佳解决办法。老夫看中的是最后一种（虽简单、但够用）：使用 aaptOptions 块中的 ignoreAssetsPattern 语句定义过滤规则。

[crayon-6956a791bff73965997613 inline="true" ]android {
    // 其他配置...

    // 定义一个开关（可以从命令行或默认值控制）
    ext {
        excludeLargeAssets = project.hasProperty('excludeLargeAssets') ? project.getProperty('excludeLargeAssets').toBoolean() : false
    }

    // 生成 BuildConfig 字段
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
            buildConfigField "boolean", "EXCLUDE_LARGE_ASSETS", "${excludeLargeAssets}"
        }
        debug {
            buildConfigField "boolean", "EXCLUDE_LARGE_ASSETS", "${excludeLargeAssets}"
        }
    }

    // 配置 aaptOptions，根据 excludeLargeAssets 动态设置 ignoreAssetsPattern
    aaptOptions {
        ignoreAssetsPattern excludeLargeAssets ? '!large/**' : ''
    }
}

ignoreAssetsPattern 的参数用的是 AAPT2 的通用模式匹配语法规则：

• 模式格式：由逗号（ ,）分隔的多个规则，每个规则可以是：
  • 忽略模式：以 ! 开头，表示忽略匹配的文件或目录。
  • 包含模式：不以 ! 开头，表示只包含匹配的文件（但在 ignoreAssetsPattern 中很少使用，因为其主要用途是忽略）。
• 通配符：
  • *：匹配文件名中的任意字符（不包括路径分隔符 /）。
  • **：匹配任意字符，包括路径分隔符（用于匹配子目录）。
  • ?：匹配单个字符。
• 示例：
  • !large/**：忽略 assets/large/ 目录及其子目录下的所有文件。
  • *.txt：理论上表示只包含 .txt 文件，但由于 ignoreAssetsPattern 主要用于忽略，这种用法不常见。
  • !large/*.png,*.txt：忽略 assets/large/ 下的所有 .png 文件和 assets/ 根目录下的所有 .txt 文件。

当在一台 Android 设备（貌似是 OPPO A9s，Origin 3）上进行相关操作后，发现了一个有趣的现象。一个需要提前了解的信息是，从某个大版本的 Android 开始，拥有 install shortcut 权限的第三方 app 如果向桌面创建了新的快捷方式，该快捷方式的图标的右下角会自带一个创建者 app 的小图标，系统称之为 badge。似乎是为了向用户明确表明两个信息：第一，这是个快捷方式而非 app；第二，这个快捷方式的创建者是哪个 app。这种完全是工程师化的思维其实在用户那里并不受欢迎，事实上是，无数的用户都在搜索消除掉该 badge（可译为“徽章”）的方法。这是一个系统级别的限制，即便是浏览器创建 PWA 的快捷方式到桌面，也不能例外。

可是例外偏偏就发生了。就在上述提到的那台设备上，经由浏览器创建的一个快捷方式，一开始的时候，能够看到它的图标右下角带着 Chrome 的图标，神奇的是，过了几天后，那个“屈辱性”的 Chrome badge 竟然消失了！也就是说，它似乎被系统认可为一个 app 而不再仅仅是个快捷方式了！但它的几个兄弟姐妹快捷方式就无此殊荣。

三太爷已经接触 Android 系统有些年头了，一时也没想明白为何会出现此现象。只好求助 Grok，在其解释下才能够白其中缘由。AI 一般针对某个问题会给出几个可能的答案，而经过验证，可以确信准确的答案就是这个：

经过了解，这种 WebAPK 必须是具有 Google 移动服务（GMS）的设备才支持，并没有办法从其它切入点进行干预。这恐怕也是 Google 的 Android 霸权的一种体现。

一个 PWA 快捷方式，如何才能进化成功，转变为一个 WebAPK 安装后的 app，必须满足一定的标准，例如：

• 提供有效的 manifest.json 文件，包含 name、short_name、start_url 和至少一个符合要求的图标（通常为 512×512 或更大的 PNG 图标，支持 maskable 图标以适配 Android 自适应图标）。
• 使用 HTTPS 协议。
• 注册了 Service Worker 以支持离线功能。
• 设置了 display 属性为 standalone 或 fullscreen。

示例 manifest.json：

[crayon-6956a791c0368503998276 inline="true" ]{
  "name": "My PWA",
  "short_name": "PWA",
  "start_url": "/",
  "display": "standalone",
  "icons": [
    {
      "src": "icon-512.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "any maskable"
    }
  ],
  "background_color": "#ffffff",
  "theme_color": "#000000"
}

用户通过支持 WebAPK 的浏览器（如 Chrome）访问 PWA 网站，点击“添加到主屏幕”选项（通常在浏览器的“三点菜单”中），浏览器最初可能会创建一个带有浏览器角标的快捷方式。

重点来了：浏览器检测到 PWA 满足 WebAPK 要求后，会将 manifest.json 和其他元数据发送到 Google 的云端铸造服务器（WebAPK Minting Server）。服务器根据 PWA 的配置生成一个轻量级 APK 文件（WebAPK），并签名后返回给设备。设备静默安装这个 WebAPK，替换原有的快捷方式。新图标不再带有浏览器角标，看起来像原生应用。

你看，决定权完全在远端。事实上，变成了 WebAPK 的那个快捷方式，其目标 app 是 YouTube，正是 Google 自家的 app，而其它的几个就无此待遇了。

核心概念

• System Bars（系统栏）：统称状态栏和导航栏。
• Edge-to-Edge（边到边）：指应用的内容可以绘制到屏幕的边缘，延伸到系统栏的后面。这是现代 Android UI 的推荐做法。
• Insets（边衬区）：系统栏、挖孔、手势区域等占用的空间。应用需要响应 Insets 来避免内容被遮挡。
• Window Flags：用于控制窗口的各种属性，包括系统栏的可见性和行为。
• System UI Visibility Flags（View 层级）：在旧版本中用于控制系统栏的可见性和布局的标志。
• WindowInsetsController：较新的 API，用于更细致地控制系统栏的外观和行为。
• WindowCompat.setDecorFitsSystemWindows(window, false)：启用 Edge-to-Edge 的关键方法。

演进历程和控制方法

Android 4.0 (API 14) 及之前 – 基本控制

• 状态栏：默认可见且不透明。
• 导航栏：物理按键为主，部分设备开始出现虚拟导航栏。
• 控制方式：
  • 通过 AndroidManifest.xml 中的 android:theme 设置主题，例如 @android:style/Theme.NoTitleBar.Fullscreen 来隐藏状态栏和标题栏。
  • 通过 Window.addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN) 动态隐藏状态栏。
  • 通过 Window.clearFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN) 动态显示状态栏。
  • 导航栏的控制非常有限。

Android 4.1 (API 16) – “System UI Visibility” 和精细化控制

• 引入了 View.setSystemUiVisibility() 和一系列 SYSTEM_UI_FLAG_* 常量，允许更灵活地控制系统栏。
• 关键 Flags：
  • SYSTEM_UI_FLAG_FULLSCREEN：隐藏状态栏（类似 FLAG_FULLSCREEN）。
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION：隐藏导航栏。用户与屏幕交互后，导航栏会重新出现。
  • SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN：即使状态栏可见，应用内容也会布局到状态栏下方。开发者需要处理状态栏遮挡。
  • SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION：即使导航栏可见，应用内容也会布局到导航栏下方。开发者需要处理导航栏遮挡。
  • SYSTEM_UI_FLAG_LAYOUT_STABLE：与 LAYOUT_FULLSCREEN 或 LAYOUT_HIDE_NAVIGATION 结合使用，当系统栏显示/隐藏时，保持布局稳定，避免内容跳动。
  • SYSTEM_UI_FLAG_IMMERSIVE：与 HIDE_NAVIGATION 和 FULLSCREEN 结合，当用户从屏幕边缘滑动时才显示系统栏，提供更沉浸的体验。
  • SYSTEM_UI_FLAG_IMMERSIVE_STICKY： IMMERSIVE 的变体，系统栏在短暂显示后会自动再次隐藏，更适合游戏或视频播放。
• 状态栏着色：非常有限，通常是黑色或白色。

Android 4.4 (API 19) – Translucent System Bars (半透明系统栏)

• 允许将状态栏和导航栏设置为半透明。
• 控制方式：
  • 在主题中设置 android:windowTranslucentStatus 和 android:windowTranslucentNavigation 为 true。
  • 或者通过代码 Window.addFlags(WindowManager.LayoutParams.FLAG_TRANSLUCENT_STATUS) 和 Window.addFlags(WindowManager.LayoutParams.FLAG_TRANSLUCENT_NAVIGATION)。
• 注意：应用内容会自动延伸到半透明系统栏的下方，需要配合 fitsSystemWindows="true" 或手动处理 Insets 来避免内容遮挡。
• 问题： fitsSystemWindows 属性的行为有时比较复杂和难以预测，尤其是在嵌套布局中。

Android 5.0 (API 21) – Material Design 和着色控制

• 状态栏着色：引入了 Window.setStatusBarColor(int color) 和 Window.setNavigationBarColor(int color)，允许开发者设置系统栏为任意不透明颜色。
  • 需要在主题中或代码中先添加 Window.addFlags(WindowManager.LayoutParams.FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS) 并清除 FLAG_TRANSLUCENT_STATUS / FLAG_TRANSLUCENT_NAVIGATION。
• fitsSystemWindows 的改进：行为更加一致，但仍是处理 Insets 的主要（且有时棘手）方式。
• Light Status Bar（浅色状态栏图标）：
  • SYSTEM_UI_FLAG_LIGHT_STATUS_BAR (API 23+)：当状态栏背景为浅色时，可以将状态栏图标（时间、电量、通知图标）变为深色，以保证可见性。

Android 6.0 (API 23) – Light Status Bar （正式引入）

• 如上所述，正式引入 SYSTEM_UI_FLAG_LIGHT_STATUS_BAR。

Android 8.0 (API 26) – Light Navigation Bar（浅色导航栏图标）

• 引入 SYSTEM_UI_FLAG_LIGHT_NAVIGATION_BAR：当导航栏背景为浅色时，可以将导航栏按钮（返回、主页、概览）变为深色。
  • 需要设备制造商支持，并且导航栏是半透明或透明的。

Android 9 (API 28) – Display Cutouts（屏幕挖孔/刘海屏）

• 随着刘海屏和挖孔屏的出现，需要处理这些区域。
• windowLayoutInDisplayCutoutMode：在主题或窗口属性中设置，控制内容如何与挖孔区域交互：
  • default：默认行为，内容在竖屏时不会延伸到挖孔区域。
  • shortEdges：允许内容在竖屏和横屏时都延伸到屏幕短边上的挖孔区域。
  • never：内容永远不会延伸到挖孔区域。
• WindowInsets.getDisplayCutout()：获取挖孔区域的详细信息和安全边距。

Android 10 (API 29) – Gesture Navigation（手势导航）和 Edge-to-Edge 强制

• 手势导航成为主流：系统导航栏变为一个细条或者完全隐藏，通过手势操作。这对应用UI布局提出了新的要求，因为底部和侧边的手势区域可能与 UI 元素冲突。
• Edge-to-Edge 变得更加重要：Google 开始强烈推荐应用采用 Edge-to-Edge 设计。
• 强制 Edge-to-Edge 的开端：如果 targetSdkVersion >= 29，系统会更倾向于让应用内容延伸到系统栏后面，即使没有显式设置 LAYOUT_FULLSCREEN 或 LAYOUT_HIDE_NAVIGATION。
• Mandatory Gesture Areas：引入了系统手势区域的概念，应用应避免在这些区域放置关键交互元素。使用 WindowInsetsCompat.Type.systemGestures() 或 WindowInsetsCompat.Type.mandatorySystemGestures() 获取这些区域的 Insets。

Android 11 (API 30) – WindowInsetsController 和更一致的 API

• 废弃 View.setSystemUiVisibility()：这个 API 因为其复杂性和难以理解的行为而被废弃。
• 引入 WindowInsetsController：提供了一套更现代化、更直观的 API 来控制系统栏的可见性、行为和外观。
• WindowCompat.getInsetsController(window, view) 获取控制器。
• hide(WindowInsets.Type.statusBars()) / hide(WindowInsets.Type.navigationBars())
• show(WindowInsets.Type.statusBars()) / show(WindowInsets.Type.navigationBars())
• setSystemBarsBehavior(BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE)：类似于 IMMERSIVE_STICKY。
• BEHAVIOR_SHOW_BARS_BY_TOUCH：用户触摸即显示。
• BEHAVIOR_SHOW_BARS_BY_SWIPE：用户滑动边缘显示。
• setSystemBarsAppearance(APPEARANCE_LIGHT_STATUS_BARS, APPEARANCE_LIGHT_STATUS_BARS)：控制状态栏图标颜色。
• setSystemBarsAppearance(APPEARANCE_LIGHT_NAVIGATION_BARS, APPEARANCE_LIGHT_NAVIGATION_BARS)：控制导航栏图标颜色。
• WindowCompat.setDecorFitsSystemWindows(window, false)：成为启用 Edge-to-Edge 的标准方法。当设置为 false 时，应用内容会延伸到系统栏后面。开发者必须使用 setOnApplyWindowInsetsListener 来处理 Insets。

Android 12 (API 31) 及之后 – 默认启用 Edge-to-Edge（针对特定情况）

• 系统进一步推动 Edge-to-Edge。
• 对于使用手势导航且 targetSdkVersion >= 31 的应用，系统可能会默认强制应用以 Edge-to-Edge 方式运行。

Android 15 (API 35) – 默认启用 Edge-to-Edge（全面）

• targetSdk 升级到 35 后，应用会默认启用 edge-to-edge 显示。这意味着 WindowCompat.setDecorFitsSystemWindows(window, false) 的行为成为默认，开发者必须处理 Insets。

现代（推荐）的控制方法 (API 30+)

1. 启用 Edge-to-Edge：在 Activity 的 onCreate 方法中， super.onCreate() 之后， setContentView() 之前调用： WindowCompat.setDecorFitsSystemWindows(window, false)

2. 处理 Insets：使用 ViewCompat.setOnApplyWindowInsetsListener 来获取系统栏、挖孔、手势区域等的大小，并相应地调整你布局中视图的 padding 或 margin。

[crayon-6956a791c05f9385922341 inline="true"  class="language-kotlin" lang="kotlin"]ViewCompat.setOnApplyWindowInsetsListener(yourRootViewOrSpecificView) { view, windowInsets ->
    val systemBarsInsets = windowInsets.getInsets(WindowInsetsCompat.Type.systemBars())
    val displayCutoutInsets = windowInsets.getInsets(WindowInsetsCompat.Type.displayCutout())
    val imeInsets = windowInsets.getInsets(WindowInsetsCompat.Type.ime()) // 软键盘

    view.updatePadding(
        left = systemBarsInsets.left + displayCutoutInsets.left,
        top = systemBarsInsets.top + displayCutoutInsets.top,
        right = systemBarsInsets.right + displayCutoutInsets.right,
        bottom = systemBarsInsets.bottom + displayCutoutInsets.bottom // 或 imeInsets.bottom 当键盘弹出时
    )

    // 或者只处理特定方向，例如只为顶部 AppBar 添加状态栏高度的 padding
    // appBar.updatePadding(top = systemBarsInsets.top)
    // bottomNav.updatePadding(bottom = systemBarsInsets.bottom)

    WindowInsetsCompat.CONSUMED // 或者返回修改后的 insets
}

[/crayon]

3. 控制系统栏可见性和外观（ WindowInsetsController）：

[crayon-6956a791c05fd995772102 inline="true"  class="language-kotlin" lang="kotlin"]val insetsController = WindowCompat.getInsetsController(window, window.decorView)

// 隐藏状态栏
insetsController?.hide(WindowInsetsCompat.Type.statusBars())
// 显示状态栏
insetsController?.show(WindowInsetsCompat.Type.statusBars())

// 设置状态栏图标为深色 (当状态栏背景为浅色时)
insetsController?.isAppearanceLightStatusBars = true
// 设置导航栏按钮为深色 (当导航栏背景为浅色时)
insetsController?.isAppearanceLightNavigationBars = true

// 控制系统栏在隐藏后的行为 (例如滑动边缘显示)
insetsController?.systemBarsBehavior = WindowInsetsControllerCompat.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE

[/crayon]

4. 设置系统栏颜色：即使内容延伸到系统栏后面，你仍然可以为它们设置半透明或透明的背景色，以获得更好的视觉效果。 在主题 themes.xml（推荐 values-v21 及以上）：

[crayon-6956a791c0601134651217 inline="true"  class="language-xml" lang="xml"]<item name="android:statusBarColor">@android:color/transparent</item>
<item name="android:navigationBarColor">@android:color/transparent</item>

[/crayon]
或者代码中（需要在 FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS 被设置后）：

[crayon-6956a791c0605242939255 inline="true"  class="language-kotlin" lang="kotlin"]window.statusBarColor = Color.TRANSPARENT
window.navigationBarColor = Color.TRANSPARENT

[/crayon]
如果你希望系统栏有一个半透明的遮罩效果（例如在深色模式下），可以使用类似 #80000000（50% 透明度的黑色）的颜色。

总结和最佳实践

• 拥抱 Edge-to-Edge：这是现代 Android 应用的趋势。
• 使用 WindowCompat.setDecorFitsSystemWindows(window, false) 启用它。
• 核心是处理 Insets：使用 ViewCompat.setOnApplyWindowInsetsListener 和 WindowInsetsCompat.Type.*。
• 使用 WindowInsetsController (API 30+) 控制系统栏的可见性、行为和图标颜色。
• 避免使用废弃的 View.setSystemUiVisibility()。
• 为系统栏设置透明或半透明背景色，以配合 Edge-to-Edge 设计。
• 在不同设备和 Android 版本上充分测试，特别注意有挖孔和使用手势导航的设备。
• 利用 Material Components：许多 Material Design 组件（如 AppBarLayout、 BottomAppBar、 CoordinatorLayout）已经内置了对 Insets 的良好处理。

这个演进过程确实比较复杂，但理解了这些核心概念和 API 的变化，就能更好地掌控应用的视觉表现，并提供更沉浸的用户体验。

在之前的产品中，实现了动态切换 app 主题（主要是整体色调）的功能，在 app 中实际应用多年，此后一直没有再变过需求，因此代码也一直维持没动。它工作得很好。不过，这份代码不止存在于实战 app 中，它还存在于一个测试工程里，问题，就是从测试工程里开始暴露的。

通常来说，对于任何一个工程师，测试工程都不会只有一个，而是会有一堆。“俺也一样”。这些代码短期无用，抛弃可惜。于是老夫就计划把它们拢到一个工程里，上一段提到的那个测试工程，被我选定为了基础工程，至于其它测试工程，只把其中的技术点并入到基础工程中后就要废弃了。一次合并某个 Activity 后，要查看一下相同的代码在原先的工程中和迁移后的工程中表现是否保持一致，发现略有不同：原先的测试工程中的 Activity，显示了 ActionBar，而合并到基础工程中以后，ActionBar 不显示了。由于 ActionBar 是集成环境的向导生成框架代码时的自动产物，也没有实际用到，所以当时只是感觉奇怪了一下，也就没有深究。

可问题前两天又一次出现了，这次是迁移了另一个 Activity。跟前次不同的在于，这个 Activity 里有的操作入口在菜单里，而菜单的入口在 ActionBar 上。可这 ActionBar 不明不白地玩儿失踪，我还怎么测功能？到 manifest 里面修改 theme 属性，指定为明确的带有 ActionBar 的主题，一点作用都没有。在 onCreate 里使用 getSupportActionBar 方法检查，把把都是返回 null。这时，我突然想到了那个一直被忽略的 ThemeManager。到 Application 类里一看，果然有它的初始化，注释掉之后，ActionBar 回来了。再一查，它掌控的数十个不同色调的主题，都派生于一个以系统的 NoActionBar 系的主题为父主题的基础主题。

真相终于大白。ThemeManager 监控了 app 内所有 Activity 的生命周期，在创建之初就会一视同仁地将主题设置为它自己的，而没有顾及要兼容 Activity 原先主题内 ActionBar 的有无。当我询问 AI 可以怎么解决时，AI 的第一反馈是：你可以创建一批带有 ActionBar 的主题供 ThemeManager 使用。一下把我惊呆了，几十个呢，全都复制一遍？就是改个根主题？幸亏老夫还没傻糊涂，又变着法儿问了一次，于是有了以下的几个选择。

Q：之前为了能够切换主题色，做了数十个主题，都是以 NoActionBar 为基础的，现在要兼容带有 ActionBar 的，难道只能把这几十个主题都复制一份，而仅仅是把 parent 改成另一个？

A：你的顾虑非常合理！不需要为每个 NoActionBar 主题手动复制一份带 ActionBar 的变体。以下是高效且可维护的解决方案：

方案一：使用主题继承 + 覆盖属性（推荐）

1. 定义基础主题层级

<!-- 基础主题（无 ActionBar） -->
<style name="Theme.App.Base" parent="Theme.Material3.Light.NoActionBar">
    <item name="colorPrimary">@color/primary</item>
    <!-- 其他通用属性 -->
</style>

<!-- 带 ActionBar 的基础变体 -->
<style name="Theme.App.Base.WithActionBar" parent="Theme.Material3.Light">
    <!-- 继承所有基础属性 -->
    <item name="colorPrimary">@color/primary</item>
</style>

2. 动态生成主题

在代码中通过 主题叠加 动态生成最终主题：

public static void applyTheme(Activity activity) {
    boolean needActionBar = hasOriginalActionBar(activity);
    int baseTheme = needActionBar ? R.style.Theme_App_Base_WithActionBar 
                                : R.style.Theme_App_Base;

    // 动态创建叠加主题
    ContextThemeWrapper wrapper = new ContextThemeWrapper(
        activity, 
        baseTheme
    );
    
    // 应用当前颜色配置
    TypedArray ta = wrapper.obtainStyledAttributes(new int[]{
        R.attr.colorPrimary,
        R.attr.colorSecondary
    });
    int colorPrimary = ta.getColor(0, Color.BLACK);
    ta.recycle();

    // 设置到 Activity
    activity.setTheme(baseTheme);
    if (needActionBar) {
        activity.getWindow().setStatusBarColor(colorPrimary);
    }
}

方案二：使用  ThemeOverlay 动态覆盖

1. 定义 ActionBar 覆盖层

<!-- 覆盖层：添加 ActionBar 支持 -->
<style name="ThemeOverlay.AddActionBar" parent="">
    <item name="windowActionBar">true</item>
    <item name="windowNoTitle">false</item>
</style>

2. 动态组合主题

// 获取当前主题资源 ID（假设是某个 NoActionBar 主题）
int currentTheme = R.style.Theme_App_Red_NoActionBar; 

// 创建动态主题配置
ContextThemeWrapper wrapper = new ContextThemeWrapper(
    activity,
    currentTheme
);

// 如果需要 ActionBar，叠加覆盖层
if (needActionBar) {
    wrapper.applyStyle(R.style.ThemeOverlay_AddActionBar, true);
}

// 应用到 Activity
activity.setTheme(wrapper.getTheme());

方案三：使用 XML 的  parent 链式继承

1. 利用抽象中间层

<!-- 所有主题的抽象父级 -->
<style name="Theme.App.Abstract" parent="">
    <item name="colorPrimary">@color/primary</item>
    <!-- 其他共享属性 -->
</style>

<!-- 具体实现层 -->
<style name="Theme.App.Red" parent="Theme.App.Abstract">
    <item name="colorPrimary">@color/red</item>
</style>

<!-- 运行时动态决定最终 parent -->
<style name="Theme.App.Red.Final" parent="Theme.App.Red">
    <!-- 空实现，由代码决定 parent -->
</style>

2. 代码中动态指定parent

// 在 ThemeManager 中
int finalParent = needActionBar 
    ? android.R.style.Theme_Material 
    : android.R.style.Theme_Material_NoActionBar;

// 通过反射动态修改 parent
Resources.Theme theme = activity.getTheme();
try {
    Field mThemeResId = theme.getClass().getDeclaredField("mThemeResId");
    mThemeResId.setAccessible(true);
    mThemeResId.set(theme, R.style.Theme_App_Red_Final);
    
    Field mTheme = theme.getClass().getDeclaredField("mTheme");
    mTheme.setAccessible(true);
    ((ResourcesImpl.ThemeImpl)mTheme.get(theme)).setBase(finalParent);
} catch (Exception e) {
    // 降级处理
}

对比方案优劣

A：在 Android 中，如果你想在 LayoutInflater 加载布局时拦截并动态修改布局，可以通过自定义 LayoutInflater.Factory2 来实现。Factory2 允许你在布局加载过程中拦截视图的创建，并对其进行修改或替换。

实现步骤

1. 自定义 LayoutInflater.Factory2:
   • 通过实现 LayoutInflater.Factory2 接口，你可以在视图创建时拦截并修改布局。
2. 设置自定义 Factory2:
   • 将自定义的 Factory2 设置到 LayoutInflater 中，使其生效。
3. 在 onCreateView 中拦截视图创建:
   • 在 onCreateView 方法中，你可以根据需要修改或替换视图。

示例代码

在 LayoutInflater.Factory2 的 onCreateView 方法中将 TextView 替换为 ImageView。以下是实现这一功能的完整示例。

1. 自定义 LayoutInflater.Factory2

import android.content.Context;
import android.util.AttributeSet;
import android.view.LayoutInflater;
import android.view.View;
import android.widget.ImageView;
import android.widget.TextView;

public class CustomLayoutInflaterFactory implements LayoutInflater.Factory2 {

    private final LayoutInflater.Factory2 originalFactory;

    public CustomLayoutInflaterFactory(LayoutInflater.Factory2 originalFactory) {
        this.originalFactory = originalFactory;
    }

    @Override
    public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
        // 拦截视图创建
        View view = null;

        // 如果视图是 TextView，替换为 ImageView
        if ("TextView".equals(name)) {
            // 创建 ImageView
            view = new ImageView(context, attrs);
            // 设置 ImageView 的属性（例如设置图片资源）
            ((ImageView) view).setImageResource(R.drawable.ic_launcher_foreground); // 替换为你的图片资源
        }

        // 如果不需要拦截，调用原始的 Factory2
        if (view == null && originalFactory != null) {
            view = originalFactory.onCreateView(parent, name, context, attrs);
        }

        return view;
    }

    @Override
    public View onCreateView(String name, Context context, AttributeSet attrs) {
        return onCreateView(null, name, context, attrs);
    }
}

2. 设置自定义 Factory2

在你的 Activity 中设置自定义的 Factory2：

import android.app.Activity;
import android.os.Bundle;
import android.view.LayoutInflater;

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        // 设置自定义的 LayoutInflater.Factory2
        LayoutInflater inflater = LayoutInflater.from(this);
        if (inflater.getFactory2() == null) {
            inflater.setFactory2(new CustomLayoutInflaterFactory(inflater.getFactory2()));
        } else {
            // 如果已经设置了 Factory2，可以替换或包装它
            inflater.setFactory2(new CustomLayoutInflaterFactory(inflater.getFactory2()));
        }

        super.onCreate(savedInstanceState);

        // 加载布局
        setContentView(R.layout.activity_main);
    }
}

3. 测试布局 (activity_main.xml)

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <TextView
        android:id="@+id/textView"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Original TextView" />

    <Button
        android:id="@+id/button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Click Me" />
</LinearLayout>

4. 添加图片资源

确保在 res/drawable 目录下有一个图片资源（例如 ic_launcher_foreground.png），用于替换 TextView。

运行结果

• 原本的 TextView 会被替换为 ImageView，并显示指定的图片资源。
• 其他视图（如 Button）不受影响。

关键点

1. 替换逻辑：
   • 在 onCreateView 方法中，通过判断 name 是否为 "TextView"，决定是否替换为 ImageView。
   • 使用 new ImageView(context, attrs) 创建 ImageView，并保留原始的属性（如 layout_width 和 layout_height）。
2. 属性传递：
   • AttributeSet attrs 包含了 XML 中定义的属性（如 android:layout_width 和 android:layout_height），这些属性会自动应用到新创建的 ImageView 上。
3. 图片资源：
   • 通过 setImageResource 方法为 ImageView 设置图片资源。

注意事项

• 属性兼容性：
  • 如果 TextView 有一些 ImageView 不支持的属性（如 android:text），这些属性会被忽略。
  • 如果需要保留某些属性，可以手动解析 AttributeSet 并应用到 ImageView。
• 性能：
  • 拦截布局加载会增加一定的性能开销，尤其是在布局复杂的情况下。
• 适用范围：
  • 这种方式适用于全局替换特定视图的场景，例如主题切换、动态换肤等。

通过这种方式，你可以灵活地将 TextView 替换为 ImageView，并实现更复杂的布局动态修改。

Q：在 Android 下想使用代码动态生成一个布局 XML，然后再用 layout inflator 把它加载成视图树，有可行的办法吗？

A：在 Android 中，你可以通过代码动态生成布局 XML，然后使用 LayoutInflater 将其加载为视图树。以下是具体步骤：

1. 动态生成布局 XML

你可以使用 XmlPullParser 或直接构建 XML 字符串来生成布局。

2. 使用 LayoutInflater 加载布局

将生成的 XML 字符串解析为 XmlResourceParser，然后通过 LayoutInflater 加载。

示例代码

import android.content.Context;
import android.util.Xml;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.LinearLayout;
import android.widget.TextView;
import org.xmlpull.v1.XmlPullParser;
import java.io.StringReader;

public class DynamicLayout {

    public static View createDynamicLayout(Context context) {
        // 动态生成 XML 布局字符串
        String xmlLayout = "<LinearLayout xmlns:android=\"http://schemas.android.com/apk/res/android\" "
                + "android:layout_width=\"match_parent\" "
                + "android:layout_height=\"match_parent\" "
                + "android:orientation=\"vertical\">"
                + "<TextView "
                + "android:id=\"@+id/textView\" "
                + "android:layout_width=\"wrap_content\" "
                + "android:layout_height=\"wrap_content\" "
                + "android:text=\"Hello, Dynamic Layout!\" />"
                + "</LinearLayout>";

        try {
            // 将 XML 字符串解析为 XmlPullParser
            XmlPullParser parser = Xml.newPullParser();
            parser.setInput(new StringReader(xmlLayout));

            // 使用 LayoutInflater 加载布局
            LayoutInflater inflater = LayoutInflater.from(context);
            View view = inflater.inflate(parser, null);

            // 获取并操作视图
            TextView textView = view.findViewById(R.id.textView);
            textView.setText("Dynamic Layout Loaded!");

            return view;
        } catch (Exception e) {
            e.printStackTrace();
        }

        return null;
    }
}

使用示例

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    // 创建动态布局
    View dynamicLayout = DynamicLayout.createDynamicLayout(this);

    // 将动态布局添加到 Activity 的根视图
    if (dynamicLayout != null) {
        setContentView(dynamicLayout);
    }
}

关键点

• XmlPullParser: 用于解析 XML 字符串。
• LayoutInflater: 用于将 XML 布局转换为视图树。
• 动态生成 XML: 你可以根据需要生成不同的 XML 布局字符串。

注意事项

• 动态生成的 XML 必须符合 Android 的布局规范。
• 这种方式适合简单布局，复杂布局建议使用静态 XML 文件。

通过这种方法，你可以在运行时动态生成并加载布局。

出于洁癖使然，兵分两路，互有联系却又互不干涉，所谓低耦合。一路是消费侧，也就是说集成使用了 VasDolly 插件的项目。这一侧三太爷也花了点心思，因为出发点是在 VasDolly 本身原地踏步的情况下，也要把它的潜力挖掘出来，敲骨吸髓式利用。另一侧则是供给侧，如果 VasDolly 内部作了改良，那消费侧的花活就可以消停一二。这一侧改动的难点不是实现层面的，而是设计层面的，如何优雅地兼容之前的接口/约定/协议，同时扩展出新的能力。

今天抽了一小会儿工夫，看了一下 VasDolly 在 GitHub 上的 PR，共有三个：一是增加了渠道别名的支持，二是增加了产品变体的支持，三是一个 bug fix（作者自称）。

渠道别名的支持不算强需求。嵌入到安装包体内的渠道号，直接使用 huawei 这样的字串并非不可，只不过实践中，大家都不愿这么直接暴露出去，所以通常会写成 90001 这种代码。但是这样的代码放到文件名里，供人肉眼检索辩识的话，就会差那么一点，所以就有了文件名里使用渠道别名的需求。在三太爷的衡量之下，当然不愿把 VasDolly 改的面目模糊，而是宁可额外多一个重命名各个渠道包的善后步骤。事实上也确实已经这么做了。

看到支持产品变体（product flavor）的这个 PR 的时候还是吃了一惊的，颇以为忙忙叨叨实现了个别人已经实现的功能。再一看代码，差别就出来了。这位仁兄只是在输出结果文件时发现存在产品变体名称的话，多产生一级子目录，免得不同产品变体的输出文件名相同的话互相覆盖。当然了，三太爷的方案想得比这个完善，由此不再担心白忙活。

最后的那个 bug fix，一开始只是肉眼 review 了一下代码。对一个函数的返回结果进行检查，原来的代码是使用 == null 判空， PR 里改作了 .isEmpty 判空。假如说，在充分相信双方都曾运行代码覆盖到所处条件的话，三太爷其实更倾向于两者相与（&&），而不是后者直接替换掉前者。后来又到 IDE 里看了一眼，发现原版的判空总是 false，所以人家的修改完全正确且合适，老夫甚至把他的修改同步到了自己的修改版里了，毕竟还多发现了一处也应该同样修改的地方。

这么看下来，真正在老夫之前为该项目提交的有实质提升的改进并不多。老怀颇慰。

把它构建并发布到了本地，又在实际项目中引用进来初步测了一下，还没有出错。过几天实际跑一下发版看看结果。