★ FEATURED ARTICLE 先把手头这个需求放正地方看主题切换白天/黑夜和语言切换回调单拆开都不算难难的是两者经常一起出现而且都会被系统环境变化触发。用户在系统设置里把深色模式开了、把语言从中文切成英文App 切回前台那一刻所有界面既要换皮肤又要换文案处理不好就是闪屏、白屏、状态错乱三连。这篇我就从“为什么必须一起做”讲起把两套方案的资源组织、触发链路、回调机制、状态保护和实测坑位完整过一遍适合正在做设置页、SDK 接入或基础框架的同学参考。1. 先把需求拆明白两件事本质是同一件事1.1 主题切换到底改了什么白天黑夜模式业内一般直接叫浅色/深色模式。表面上看改的是页面的背景色、文字色实际上它改的是整套资源映射关系色板、图片资源、阴影圆角、状态栏图标明暗、键盘皮肤、WebView 背景甚至第三方组件的默认样式。Android 侧靠values-night资源目录 uiMode配置变更来切换iOS 侧靠 traitCollection dynamic color 来切换。切换的触发源有三个系统设置里的深色模式开关属于系统级触发App 内部的“跟随系统 / 浅色 / 深色”三选一选项属于应用级触发定时任务或地理位置的自动切换比如日落变深色属于业务级触发。三者最终都会落到同一个结果通知所有存活界面按新的模式重新取资源并重新渲染。1.2 语言切换到底改了什么语言切换改的是文案资源映射。原来 TextView 上显示的那串中文字符串在 Locale 变化之后应该换成英文/日文/其他语言的内容。但它真正动的东西比“换字符串”要多得多资源目录从values-zh切到values-enstrings.xml 全部重读日期格式化器、数字千分位、货币符号、时区显示全要跟着 Locale 走排版方向可能从 LTR 变 RTL中文切阿拉伯语这种极端情况布局要镜像已创建的 View 不会自动感知 Locale 变化必须靠系统回调触发刷新/重建。系统语言切换的来源也有两个用户在系统设置里改了语言系统级触发或者 App 内部提供了“应用内语言”选项应用级触发。无论哪种只要 Locale 变了所有已展示文本和依赖 Locale 的格式都得重刷。1.3 为什么要把两件事放到一起回调这是很多人忽略的关键点。主题和语言在业务上毫无关系但在工程实现上共享同一条链路系统环境变化 → 回调通知 → 全局刷新。如果把两套逻辑分开做会出现三个问题两次刷新重叠。用户切语言的时候大概率同时也在系统设置里看到深色模式开关即便不同时App 从后台回前台时也要统一检查一遍环境是否变化。分两套回调意味着同一个页面可能连续收到两次刷新指令导致闪屏、动画被打断。重建成本翻倍。很多团队的粗暴方案是检测到变化后调用recreate()/ 重建 RootViewController如果语言和主题各触发一次用户会肉眼看到页面连续重启两遍体验极差。状态恢复逻辑重复写。页面重建时往往要保存列表滚动位置、输入框内容、选中态这部分代码如果写在两处维护成本直接翻倍。正确的做法是抽象一个统一的环境状态Env把 themeMode 和 locale 作为两个属性任何来源的变化都先更新 Env再通过同一个回调通道广播给所有订阅者。业务方只关心“Env 变了我去刷新”不用关心到底是语言还是主题引起的也不需要担心重复刷新。2. 白天黑夜模式的落地资源组织与切换链路2.1 两套皮肤的资源设计别只想着放颜色先说资源层。浅色/深色模式的资源组织各家团队方案不完全一样但都逃不开这三个层次第一层基础色板。定义一组语义化颜色比如colorPrimary、colorBackground、textPrimary、textSecondary、dividerColor、surfaceColor。Android 在values/colors.xml和values-night/colors.xml各放一份iOS 用 Asset Catalog 里的 Any/Dark 色对或者代码里写UIColor { trait in ... }动态提供。关键是命名必须按“语义”而不是按“颜色”来比如不要叫white、black要叫bgPage、textTitle。否则业务方拿到black深色模式下根本没法用。第二层组件样式。按钮、输入框、卡片、弹窗的背景形状、边框、阴影这种做法通过 style 引用色板里的语义色。组件级样式的好处是业务方在 XML 或 SwiftUI/UIKit 中只写一次组件引用模式切换后控件自动按新资源重新渲染无需每个页面写一套。第三层动态图。深色模式下的图片不是简单的不透明图很多 UI 细节要单独设计。多语言场景更麻烦同一个图标中文环境下可能带汉字英文环境要换英文。所以图片资源建议按drawable-night-zh、drawable-night-en这种维度组织资源解析器会自动按当前模式语言选中最合适的文件。这块前期投入越高后面切模式越省心。注意渐变和自定义绘制是动态色的盲区。很多团队以为用了?attr/colorPrimary就万事大吉结果自定义 View 里直接写死Color.parseColor(#FFFFFF)或者LinearGradient的起始色写硬编码。排查这类问题很痛苦建议在代码评审时就约定业务层禁止出现裸色值统一走资源或主题属性获取。2.2 用户手动切换和跟随系统的优先级设计主题模式通常有“跟随系统”“仅浅色”“仅深色”三个选项。这里最容易出错的是优先级和持久化。优先级逻辑应该这样设计用户从未选过默认跟随系统系统变深色则 App 变深色用户明确选了浅色或深色App 强制使用用户选择忽略系统变化用户从“仅浅色”切回“跟随系统”立即读取当前系统模式并应用。存储上我用 DataStore / SharedPreferences 存一个枚举值比存布尔值合理因为以后可能加“日落自动切换”之类的新档位。每次 App 启动时读取存储决定初始化成哪个模式。Android 侧手动切换的代码路径很固定AppCompatDelegate.setDefaultNightMode( when (mode) { ThemeMode.FOLLOW_SYSTEM - AppCompatDelegate.MODE_NIGHT_FOLLOW_SYSTEM ThemeMode.LIGHT - AppCompatDelegate.MODE_NIGHT_NO ThemeMode.DARK - AppCompatDelegate.MODE_NIGHT_YES } )真正关键的细节在调用时机。这个 API 一调用Activity 会立即进入配置变更流程。如果当前页面有输入框未提交的内容、有正在播放的视频、有未保存的草稿直接重建会丢状态。稳妥的做法是先让用户操作落地到存储再延迟 50~100ms 触发切换给动画一个过渡时间同时避免在点击事件回调中直接触发重建带来的卡顿。实测中点击 Switch 后立刻setDefaultNightMode部分国产 ROM 上会出现短暂黑屏延迟一小段反而过渡自然。iOS 侧手动强制模式用overrideUserInterfaceStyle可以作用到单个控制器、单个 window 或者整个 App。启动阶段根据存储值设置 window 的overrideUserInterfaceStyle切换后需要重建整个 window 的 rootViewController否则已经存在的控制器不会自动刷新 trait。2.3 页面局部刷新的触发与防抖资源层准备好、切换链路通了接下来就是最实际的 UI 刷新性能问题。方案一整体重建。Android 上不声明configChanges系统在 uiMode 变化时自动重建 ActivityiOS 上手动切 overrideUserInterfaceStyle 后重新设置 rootViewController。优点是实现简单缺点前面说过连续变化会闪屏输入框状态和列表状态要额外恢复。方案二局部刷新。每个需要感知模式的页面注册环境回调收到变化后手动updateUI()只更新颜色、图标、文本。这个方案体验最好但要约定每个页面都得实现刷新方法漏一个就出现“一半深色一半浅色”的怪样子。我实际采用折中的策略栈顶页面做精细的局部刷新栈下面不可见的页面只记录状态等回到前台或重新显示时再刷新。这样既避免了不可见页面做无用功又不会丢状态。具体到 Android 的 Fragment就是在onResume里检查EnvCenter.current.themeMode和本地记录是否一致不一致就刷新iOS 则是viewWillAppear里同样做一次比对。防抖方面注册回调的组件建议做一个“合并刷新标记”收到回调后不立刻执行刷新而是 post 一个 60ms 的延迟任务期间如果再次收到回调就重置计时器。这样语言和主题同时变化时最终只刷新一次。class DebouncedRefresher(private val onRefresh: () - Unit) { private val handler Handler(Looper.getMainLooper()) private val runnable Runnable { onRefresh() } fun schedule() { handler.removeCallbacks(runnable) handler.postDelayed(runnable, 60L) } fun cancel() { handler.removeCallbacks(runnable) } }3. 系统切换语言回调完整链路与状态保护3.1 系统语言变化的两种来源必须分开监听先明确一点系统语言变化和 App 内主动切换语言回调路径不一样。系统级来源用户在系统设置里改了语言。Android 上如果 target SDK 较高且 Manifest 里声明了configChangeslocaleActivity 会走onConfigurationChanged没声明的话系统会直接重建 Activity。iOS 上系统语言变化后App 不会自动重建任何界面只会在 App 回到前台时让你有机会检测。实践中最稳的检测方案是监听UIApplication.didBecomeActiveNotification在回调里比较当前Locale.preferredLanguages.first和缓存值不一致就判定为语言变化。另外 iOS 也提供NSSystemLocaleDidChange通知但在 App 运行时实际触发频率不稳定不如“回前台比对法”可靠。应用级来源用户在 App 设置页里选了应用内语言。Android 官方推荐使用AppCompatDelegate.setApplicationLocales()AndroidX 自带的能力或者用LocaleManagerCompat拿到 LocaleManager 后调用setApplicationLocales。如果是老项目自己维护Locale.setDefault() 资源配置重写要特别注意手动改 Configuration 只影响后续创建的 View已存在的 View 依然显示旧语言所以必须主动触发页面重建。iOS 应用内切换语言本质是改变AppleLanguages键值然后手动刷新所有界面。有一个细节Bundle.main读取本地化文案是按系统语言来的应用内语言切换要自己维护一个Bundle子类重写localizedString(forKey:value:table:)把 key 转成当前应用语言对应的文案否则切换后系统组件比如系统相册选择器的按钮文字还是跟随系统语言走。3.2 全局刷新时的状态保护与重建策略无论哪个来源的语言变化最后都逃不过一个问题页面要不要重建理想方案是局部刷新TextView 的文本从资源里重读一遍即可。但现实是很多页面有复杂的标题栏、TabLayout、底部导航、弹窗、列表空态这些组件的标题和文案分散在代码各处局部刷新很可能漏改。所以在多数场景“重建当前页面栈”反而是更稳妥、代码更少的方案。重建时的状态保护我踩过几次坑后总结出一套固定流程在触发语言切换前遍历当前存活页面让页面把需要保留的状态写入 ViewModel 或 SavedState重建根界面对 Android 是 Activity 的recreate()或 Fragment 重建对 iOS 是重新设置 rootViewController在新页面创建完成后从 ViewModel 恢复状态如果重建过程中有网络请求进行中要保留原请求的引用或者用状态标记让回调不落在已销毁的页面上。这里面最容易忽略的是弹窗和键盘。语言切换时如果有 Dialog 或输入法弹出重建 Activity 会导致 Dialog dismiss、键盘收回。我的处理方式是切换前记录“有弹窗则先关闭有焦点则保存输入内容并解除焦点”切换完成后若有需要再重新弹起。输入框内容实际上都在 EditText 的 text 属性里重建前手动取出放进 ViewModel重建后塞回去亲测能保住 90% 的输入现场。override fun onSaveInstanceState(outState: Bundle) { super.onSaveInstanceState(outState) outState.putCharSequence(keyword, searchInput.text) outState.putInt(listPosition, recyclerView.getLayoutPosition()) }3.3 日期、数字、文案格式的隐藏坑换语言之后最容易被文案联调漏掉的是格式化类问题。页面上的时间戳、金额、数量如果不按新 Locale 重新格式化就会出现“语言切了但 12/24 小时制没变”“美元符号位置还是中国习惯”“千分位变成欧洲样式”这种怪相。这里给两个实践建议第一创建格式化对象时不要缓存全局单例。很多人为了方便在 Application 里初始化一个SimpleDateFormat或NumberFormat静态实例语言切换后它不会自动使用新 Locale必须重新创建。我通常把格式化对象放到 EnvCenter 里Locale 一变所有格式化器全部重新初始化业务方只通过EnvCenter.current.dateFormatter获取object EnvCenter { var current: Env Env.load() private set fun notifyEnvChanged() { val latest Env.load() if (latest ! current) { current latest listeners.forEach { it.invoke(current) } } } } data class Env( val themeMode: ThemeMode, val locale: Locale ) { val fullDateFormatter: SimpleDateFormat SimpleDateFormat(yyyy年M月d日, locale) }第二服务端下发的字符串也要走本地化。App 内很多文案是接口返回的比如运营位的标题、活动说明。语言切换后服务端缓存的旧文案在界面上不会变但这不算 bug重点是不要把它们当作本地化文案缓存要允许请求带Accept-Language头重新拉取或者展示时判断当前语言与请求时语言不一致就重新请求。4. 主题与语言联动的刷新机制统一回调中心设计与实现4.1 统一回调中心的分层职责既然前面确定了“主题和语言共用一条回调链路”那这个链路具体怎么设计我推荐分层结构环境状态层EnvCenter持有当前 themeMode locale负责持久化读写和初始化事件广播层EnvNotifier提供注册/反注册能力内部防抖合并页面生命周期层基类 Activity / Fragment / ViewController 自动注册监听在onResume或viewWillAppear检查状态并刷新业务刷新层业务页面实现接口onEnvChanged()在里面写真正的刷新逻辑。这样做的好处是业务页面完全不关心触发源。系统深色模式变化来了onEnvChanged()执行用户在 App 内切换语言执行的还是同一个onEnvChanged()。如果两个变化在几十毫秒内连续发生防抖机制把它们合并成一次回调。有一个代价原本只需要响应主题、不需要响应语言的页面也必须在onEnvChanged()里做一次空实现或判断。这是实现上最繁琐的部分但换来的收益是后续新增任何“环境类变化”比如字体大小、无障碍缩放都直接复用这条链路扩展性拉满。interface EnvObserver { fun onEnvChanged(env: Env) } object EnvCenter { private val observers CopyOnWriteArrayListEnvObserver() fun subscribe(observer: EnvObserver) { if (observers.contains(observer)) return observers.add(observer) // 注册后立即回调一次保证新页面创建时状态正确 observer.onEnvChanged(current) } fun unsubscribe(observer: EnvObserver) { observers.remove(observer) } fun notifyEnvChanged() { val latest Env.load() if (latest current) return current latest observers.forEach { it.onEnvChanged(latest) } } }4.2 生命周期绑定与监听取消的套路回调中心的监听注册最怕就是泄漏和重复回调。Android 上有两种常见错误一是全局静态注册但忘记在onDestroy反注册。Activity 实例被 Collect 持有导致内存泄漏。我统一在 BaseActivity 里用onStart注册、onStop反注册这样既保证运行时一定收得到回调又不会泄漏。要注意CopyOnWriteArrayList的遍历是弱一致的在回调里触发反注册不会抛 ConcurrentModificationException但同一对象重复注册可能收到多次回调所以注册入口要判重。二是Fragment 和宿主 Activity 同时注册。同一个 Fragment 重建时旧实例如果没注销新实例又注册了回调会执行两次导致列表被刷两遍或者动画重放。解决方式很简单注册要绑定到实例自身而不是类或模块class BaseFragment : Fragment(), EnvObserver { override fun onStart() { super.onStart() EnvCenter.subscribe(this) } override fun onStop() { super.onStop() EnvCenter.unsubscribe(this) } }iOS 侧用 NotificationCenter 的addObserver(forName:object:queue:using:)时返回的 observer token 必须在deinit里移除。Swift 中如果 block 里捕获了self又忘移除 token这个页面就永远释放不掉。这块我用一个Bag收集 token页面销毁时统一invalidate()。4.3 启动阶段的首次同步常被忽略统一回调还有一个隐蔽问题App 冷启动时Env 的初始值从存储里恢复但页面创建时机可能在存储恢复之前。如果玩家顺序不对页面拿到的是默认浅色 默认中文等 Env 加载完成之后如果没触发一次“伪变化”通知界面就一直保持错误状态。我的做法是EnvCenter 初始化完成后主动向所有已注册观察者补发一次当前 Env。也就是说注册即回调。这样无论注册发生在 Env 加载前还是加载后页面都能拿到最新状态。这行设计看似简单实际解决了冷启动白屏、首次进入页面语言不对、第三方 SDK 启动就创建页面等一堆问题。5. 常见问题与排查技巧实录5.1 切了系统语言页面纹丝不动八成原因是没有触发系统回调。Android 上常见于 Manifest 声明了configChanges却没有在onConfigurationChanged里做任何处理iOS 上常见于只监听了NSSystemLocaleDidChange而这个通知在某些系统版本上只在特定时机才发。排查建议按顺序做一遍确认 Manifest 的configChanges是否包含locale如果包含确认onConfigurationChanged里是否调用了EnvCenter.notifyEnvChanged()在 App 回前台入口Android 的onResume、iOS 的didBecomeActive加一次“当前语言 vs 缓存语言”比对不一致就主动通知检查资源目录名是否写错比如写成了values-en-rUS这种非法格式系统会静默忽略匹配不上文案继续显示旧语言。5.2 手动切换深色模式后状态栏图标还是黑色的状态栏图标的明暗是独立于页面背景的一套逻辑。Android 上要设置WindowInsetsControllerCompat的isAppearanceLightStatusBars浅色模式下状态栏图标用深色每次主题变化后这个值不会自动更新需要在onEnvChanged()里重新设置。val controller WindowInsetsControllerCompat(window, view) controller.isAppearanceLightStatusBars if (isLightTheme) true else false controller.isAppearanceLightNavigationBars if (isLightTheme) true else falseiOS 上则要实现preferredStatusBarStyle并在 trait 变化后调用setNeedsStatusBarAppearanceUpdate()。实测中如果用了自定义导航栏系统状态栏样式的判断会受导航栏背景影响最稳妥的方式是不要依赖系统自动推断直接在 Env 刷新方法里显式指定。5.3 深色模式切换瞬间出现白屏白屏的根源是窗口背景在主题切换那一刻还停留在浅色资源而 Activity 已经在按深色资源重建重建过程中的空白帧用了旧背景色。解决办法是给窗口设置与背景色一致的启动背景而不是默认白色。Android 上在values/themes.xml和values-night/themes.xml里分别给android:windowBackground指定color/bgPage同时把启动页也用同一个颜色兜底。iOS 上要检查 LaunchScreen 的背景色是否跟随模式变化如果 LaunchScreen 用系统背景色切换瞬间也会有白闪需要把 LaunchScreen 的背景设为动态色。5.4 语言切换后页面重建但状态丢了这个问题最典型的表现是列表滚回顶部、输入框内容清空、选中的 Tab 回到第一个。原因前面提过重建前的状态没有保存。排查时先看是哪种状态丢了列表位置丢失 →onSaveInstanceState里存的不是 RecyclerView 的位置而是 LayoutManager 的firstVisiblePosition恢复时要scrollToPositionpost补一次微调输入框丢失 → 不要在onSaveInstanceState里依赖 EditText 的自动保存部分自定义输入框解析不了手动取出 text 最稳Fragment 的当前 Tab 丢失 → 把 Tab 索引存进 ViewModel重建后根据索引恢复选中和懒加载流程。5.5 回调重复触发页面连续刷新两三次可能是注册链路重复 系统回调叠加导致的。建议把每次 Env 变化的来源打日志系统配置变更、手动切换、回前台比对、初始化补发。日志里带上调用栈很快能定位是哪个入口重复执行。防抖计时器也可以从 60ms 调到 200ms如果 200ms 内两个来源连续触发也能合并成一次刷新。5.6 Fragment 重建后回调失效Fragment 通过onStart/onStop注册反注册理论没问题但如果用show/hide方式切换 FragmentonStart/onStop不会被调用此时回调还挂着页面却能正常收到通知。如果希望隐藏页面不刷新要把注册生命周期改成setUserVisibleHint老 API或onHiddenChanged配合处理。反过来如果希望隐藏页面也刷新保持onStart注册即可。经验之谈写这套逻辑时最好的调试工具就是日志。注册、反注册、回调、刷新四步各打一条 log带上页面 hash。联调阶段多打日志不丢人上线前再统一收敛能省下大量排查时间。结尾我在实际做这个需求时有一个体会主题和语言切换的难点不在“知道怎么做”而在“把所有入口收敛到一条链路上”。只要环境状态单一、回调机制统一、页面刷新逻辑收敛后面加新页面、接新 SDK、支持更多语言都很顺反过来如果一开始图省事在系统回调里每次直接recreate()短期看很快上线长期就是每个页面都要额外处理状态丢失和闪屏越改越乱。最后再分享一个细节注册回调接口时不妨把“注册后立即执行一次”这个行为写进规范很多莫名其妙的“首次进入页面状态不对”问题都会自动消失。
阅读完成 · 觉得有帮助？
