近日，多位Android开发者在使用Jetpack Glance组件开发应用小部件时，反馈了一个令人困惑的兼容性问题：当系统切换深色/浅色主题时，使用ImageProvider(Bitmap)方式加载的图像内容无法自动跟随更新，而使用ColorProvider定义的背景颜色却能完美响应。 这一行为差异不仅影响视觉一致性，也可能破坏精心设计的夜间模式体验。
问题复现：同一个Widget，两种表现
Jetpack Glance是Google官方推出的、用于构建Widget的全新声明式框架。其核心优势之一，就是能利用LocalTheme、LocalContext.current.isDarkTheme()等API感知系统环境变化，实现“无感切换”。
然而，根据开发者社区的反馈，当Widget中的UI元素使用ImageProvider（特别是ImageProvider(Bitmap)构造函数）时，系统主题的改变似乎“触发”了重绘逻辑——ColorProvider和文本颜色正确更新，但Bitmap图像却始终停留在最初加载的版本上。
以典型的时钟Widget为例：深色模式下，文字和背景变为白色+深色；浅色模式下，文字和背景变为黑色+浅色。如果Widget中央有一个动态生成的圆形图标（通过Bitmap绘制），问题就来了——背景和文字正常切换，但图标却“顽固”地保持原样，导致白天模式下图标与背景对比度过低，夜晚模式下又显得刺眼。
技术分析：为什么ColorProvider能工作？
要理解这一现象，需要探究Glance的内部渲染机制。
Glance的UI层基于Compose的“快照”系统。当系统主题变化时，框架会调用onStateDefinition或CompositionLocalProvider来重新组合UI树。ColorProvider本质上是返回一个颜色值，该值会根据当前主题的Colors对象动态计算。由于整个组合过程是新生成的，颜色值自然会跟随变化。
但ImageProvider(Bitmap)的处理路径不同。它接收的是一个已经实例化好的Bitmap对象。在Glance的底层渲染中，这个Bitmap通常会被缓存为“位图源”。当主题切换发生后，Bitmap对象本身并没有发生改变（它是一个特定的图像数据），不会像颜色那样被动态重新计算。更关键的是，Glance的“重新组合”步骤可能没有强制让这个外部Bitmap重新查询或更新。简单来说，ColorProvider返回的是“算法”，而ImageProvider(Bitmap)返回的是“定值”。
此外，这与Compose for Wear OS等平台的早期行为非常类似。在Compose中，如果直接使用第三方加载库（如Coil、Glide）的rememberAsyncImagePainter或BitmapPainter，系统主题的强制重组（重组合）通常能触发更新。但Glance小部件的渲染是发往另一个进程（SystemUI）的跨进程操作，更新链路的复杂程度更高。
影响与现状：对夜间模式适配构成挑战
这个问题对于追求极致自适应体验的开发者来说，是一个不小的“坑”。
目前，官方Issue追踪器中已有多条相关反馈。开发者提出的临时解决方案包括：
- 放弃直接使用Bitmap，转而使用
ImageProvider(R.drawable.xxx)。 如果是矢量图（Vector Drawable），系统可以自动进行色调分离（tinting），从而跟随主题。 - 手动触发
update。通过GlanceAppWidgetManager强制请求一次小部件更新，但这会牺牲性能和流畅度。 - 使用
AnimatedImageProvider或尝试“重建”Bitmap。 即在Content的LaunchedEffect中监听LocalTheme.isDarkTheme，当主题变化时，重新绘制一个新的Bitmap并通过ImageProvider返回。但这增加了内存压力。
结论：等待官方修复，建议先采用Workaround
截至发稿时，Google尚未就此问题发布正式的修复补丁。从代码库的提交记录看，相关开发团队已在关注“跨进程主题同步”的性能开销与正确性博弈。
对于正在准备适配Android 12+动态主题或全力拥抱Material You的开发者，最稳妥的建议是：对于需要随主题动态变化的复杂图形，优先使用基于资源的加载（ImageProvider(Res)）或纯Color方案。 若必须使用ImageProvider(Bitmap)，建议在Widget的Content中手动捕获一次主题状态，并在其变化时主动刷新。
Google的Jetpack生态一直强调“开发者体验”。希望这次“半跟随”的小插曲，能很快在下一个Glance版本中得到圆满解决。我们将持续关注该问题的官方进展。