切到深色模式，半个界面还亮着：夜间资源限定符怎么用

先把问题说清楚。深色模式（夜间模式）在系统层面早就不是新鲜事，几乎所有手机都能一键切换。但一个应用切过去之后，常见的画面是这样的：列表变黑了、标题变白了，可输入框还是雪白的，或者干脆背景黑了、字也黑了，整页像被泼了墨。

这两种现象看着像同一个问题，其实是两个完全不同的原因。前者是「有一处颜色没跟着换」，后者是「颜色换了，但换错了对象」。而它们共同的根源只有一个：颜色到底写在哪里。

这一篇只讲一件事——深色模式在安装包里究竟是怎么实现的，为什么改完之后总会剩几处发白，以及一个包在手边时，该按什么顺序去查、去改、去验收。全部操作都可以用「说一句话」的方式完成，官网是 www.apkeditor.cn。

一、先分清三种「没变黑」

动手之前，先看一眼漏的是哪一类，后面的动作完全不同。我们把它分成三档。

第一档，整页都没变。切到深色之后，这个界面从头到尾还是浅色。这种最常见的原因是它根本没参与主题：要么主题没声明跟随系统，要么这个界面用的是自己写死的一套颜色。

第二档，变了一部分。背景黑了，但某几个控件还是白底；或者文字白了，但某几处还是深灰。这种是局部写死——大部分颜色走了主题，个别地方硬编码。

第三档，全变了但看不清。背景和文字都换了，可是对比度不够：浅灰字压在深灰底上，或者图标在白底上消失了。这种不是「漏改」，是配色本身没做过深色版，只是把颜色反了一下。

把这三档分开，是因为它们的修法完全不同：第一档要动主题，第二档要动具体控件，第三档要重新配一套色值。如果混在一起处理，最常见的结果是改了一整天，问题从第一档变成了第二档。

二、深色模式在包里是「第二套文件」，不是「一次运算」

很多人以为深色模式是系统把界面颜色算了一遍。不是。它是提前准备好的第二套资源，系统在需要的时候去拿第二套。

在安装包的结构里，这套机制叫资源限定符。同一张图、同一个颜色，可以在不同的目录里各放一份，目录名后面挂一个后缀表示「只在某种条件下使用」。深色模式用的后缀是 -night。

于是同一个颜色的两份值，就分别住在两个地方：普通目录里的那份给浅色用，values-night 目录里的那份给深色用。系统切换时做的动作，只是「换一个目录去读」。

这个理解很关键，因为它直接给出了两个推论。推论一：如果某个地方的颜色不是从资源里读的，而是直接写在布局或代码里的字符串，那它永远只有一份，换目录也换不到它。推论二：如果 values-night 这个目录压根不存在，那么深色模式下读到的还是普通目录那份——表现就是「一切正常，只是没变黑」。

三、颜色可能住在四个不同的地方

要找漏掉的地方，先得知道颜色可能藏在哪。按「藏得深浅」排，一共四个地方。

第一个地方：颜色定义文件。这是最规矩的一处。颜色起一个名字，值写在这里；界面里只写名字。这种写法天生支持深色，因为只要多给一份深色目录的定义就行。

第二个地方：界面布局文件。有些地方图省事，直接在控件上写颜色值。只要写的是字面值而不是名字，它就固定了，深色下不会变。这是最常漏的一处，也是最好改的一处。

第三个地方：代码。有些颜色是运行时算出来再设上去的，比如根据状态变色、按数据画图表。这部分在布局文件里完全看不到，得进代码里找。

第四个地方：图片本身。这一处最容易被忽略，因为它不是「颜色」而是像素。一张白底的图，在深色界面里就是一块白补丁；一个深色的 logo，在深色背景上就消失了。这类问题改颜色改不掉，只能换图。

四个地方的排查成本差别很大：第一处改一个值就够，第二处要改若干控件，第三处要找到那段代码，第四处要重新出图。所以顺序应该是从一到四，先解决成本最低的，再决定值不值得往下走。

四、为什么「深色版」不是把颜色反过来

这是最多人误判的一步。看到一个界面变黑后不好看，第一反应是「把浅色版反一下不就行了」。反色在数学上没问题，在视觉上几乎一定出问题。

原因在于人眼对亮度的感知不是线性的。纯白背景上的纯黑文字，反过来是纯黑背景上的纯白文字，对比度会高到刺眼；而浅灰卡片上的深灰文字反过来，就变成了深灰卡片上的浅灰文字，对比度低到看不清。同样是反色，一个过头，一个不够。

所以真正做过深色版的团队，用的是一套独立配好的色值，遵循几条很朴素的规则：背景不用纯黑，用很深的灰；卡片比背景再浅一点点；主文字用接近白的浅灰，次文字再压暗一档；分隔线几乎看不见但确实存在。

为什么背景不用纯黑？因为纯黑和纯白一样是极端值，OLED 屏幕上纯黑背景配白字，滚动时会有明显的拖影感，长时间看眼睛更累。深灰留出的一点余量，正好让卡片、弹窗、浮层这些层次有机会被表达出来。

顺带说一个深色模式特有的坑：阴影失效。浅色界面里靠投影区分层次，深色界面里投影投在深色背景上几乎看不见。所以深色版要靠「表面颜色更浅一档」来分层，而不是靠阴影。这也是为什么直接反色的界面看起来总像糊成一片——层次全靠阴影，而阴影没了。

五、最容易漏的五处，按出现频率排

我们把自家应用和客户交付里出现过的漏点做了个统计，前五名很稳定。

第一处，输入框与搜索框。它们的背景常常被单独设成白色，因为浅色下「白底输入框」看起来干净；而文字颜色是跟随主题的。深色下就变成了白底白字，看起来像输入框消失了。

第二处，弹窗与底部菜单。很多弹窗是自绘的圆角容器，背景色写死成白色。列表变黑了，一点按钮弹出来的还是雪白一块，视觉冲击特别强。用户对弹窗变白的容忍度远低于对列表的容忍度。

第三处，下拉刷新与加载态。这类控件的颜色往往在代码里设，或者用的是默认值。深色下不是白底就是白字，而且只在「正在加载」那一秒出现，自测时最容易错过的就是它。

第四处，启动瞬间的窗口背景。应用还没画出第一帧时，系统先显示窗口背景。这个背景通常是一张白图或一个白色值，深色下就变成点开应用先闪一下白。它只存在半秒，但用户每次打开都会看到。

第五处，图片与插画。白底的商品图、白底的二维码、深色的 logo，在深色界面上要么是一块补丁，要么直接消失。这一类不是颜色问题，改色值改不掉，只能为深色单独准备一份图。

这五处加起来，基本覆盖了「改完还是觉得不对」的九成情况。它们的共同点是：都不在「主界面」上，都在主界面之外的边角时刻出现——所以只看一眼首屏，永远发现不了。

六、第一个实例：门店端的盘点页，夜班看不见数字

这是自家一个门店管理应用的真实返工。它的库存盘点页要在仓库里用，夜班灯光暗，同事们一直要求深色模式。

以前的做法很笨：手动反编译，在颜色定义文件里加一份深色值，再一个一个界面去看哪里没跟上。改到第三个界面时发现输入框是白底，改完输入框发现下拉刷新还是白的，改完下拉刷新发现弹窗是白的。一个盘点页改了整整两天，而且改完还漏了启动时那一闪。

现在的做法是一句话：把这个应用在深色模式下所有写死白底的地方找出来，换成跟随主题的颜色，并补一份深色配色；弹窗、输入框、下拉刷新、启动背景这四处必须一起改。

改完的验证按三步走。第一步，系统切深色，把盘点页从列表滚到底，看有没有哪一行突然变白；第二步，故意输错一次数量，把错误提示弹窗逼出来，看弹窗底色；第三步，杀掉进程重新打开，看启动那半秒有没有白闪。

三步里第三步最容易被跳过，也最容易出问题。因为窗口背景只在冷启动时用得上，热启动、从后台切回来都看不到它。我们自己第一次改完就是漏了这一步，交付当天同事说「打开的时候闪一下白」，又返工了一次。

七、第二个实例：培训端的图表，深色下全糊在一起

第二个例子不一样，它不是漏改，是改了但没改对。

这个培训应用里有一个学习进度页，用几种颜色的柱状图表示不同科目的完成度。浅色下五根柱子颜色分明，切到深色之后，五根柱子还在，但看上去像一根粗柱子——因为深色背景吸掉了颜色之间的差异。

原因不在代码，在配色。那五根柱子用的是五种中等明度的颜色，压在浅色背景上对比明显；压在深色背景上，五种颜色的明度差被背景吃掉了，只剩下很接近的色相差别。人眼对色相的分辨远不如对明度敏感。

改法是重新配一组「为深色而生」的颜色：整体提亮一到两档，并且让五根柱子之间拉开明度差，而不是只拉色相差。同时给柱子加一层很淡的描边，让边界在深色背景上站得住。

这件事的教训是：深色模式不是「把背景改黑」，而是「在深色背景下重新做一次配色设计」。凡是靠颜色区分信息的地方——图表、标签、状态点、优先级标记——都要重新检查一遍。它们在浅色下越好看，在深色下越容易失效。

验证方法也很直接：切到深色，把屏幕亮度调到最低，然后眯起眼睛看。如果还能分辨出五根柱子，配色就过关；如果糊成一片，说明明度差不够。这个土办法比任何取色工具都准。

八、谁决定要不要变黑：三种策略

深色模式到底听谁的，是个必须先定的问题。不定下来，后面所有验收都是空的，因为同一个界面在「跟随系统」和「强制深色」下表现可能不同。

第一种，跟随系统。系统切了它才切，应用自己不提供开关。这是最省事也最不容易出错的做法，适合大多数工具类、内部类应用。

第二种，应用内自己给一个开关。用户可以在应用里单独选择浅色、深色或跟随系统。它比第一种多一份「用户的选择要记住」的存储，也多一份「记住之后要不要覆盖系统」的判断。这一份判断如果写反了，就会出现「系统明明切了深色，应用还是白的」。

第三种，强制某一种。应用固定用深色或固定用浅色，完全不管系统。有些品牌类应用会这么做，为了统一视觉。代价是用户没法自己选择，在深夜打开会很刺眼。

还有一种容易被误认成深色模式的东西：系统对未适配应用的自动反色。它会把没做深色版的界面强行算一遍，颜色往往发灰、发紫，图片也会被反得奇怪。看到「像是变了但又不太对」，八成是撞上了这个，而不是你的深色版生效了。

判断方法很简单：找一个确定没做深色版的老应用，切到深色看看它——如果它也被「变黑」了，说明系统开了自动反色。这个功能会让所有验收结论都不可信，所以验收前第一件事是先确认它关掉。

九、状态栏那一行小图标，是最容易翻车的地方

界面主体都改对了，还有一种情况会让人抓狂：顶部状态栏看不见了。

状态栏这块区域由系统画，应用只能告诉它「我要什么颜色的底」和「我的图标该用深色还是浅色」。底和图标必须成对设置：浅底配深图标，深底配浅图标。

多数翻车是这样发生的：应用把状态栏背景改成了深色，但图标还是深色——于是时间、电量、信号全都隐进背景里，用户以为手机坏了。这种问题比界面变白严重得多，因为它影响的是「还能不能正常用手机」。

反过来也一样。如果应用为了好看把状态栏背景设成白色，而图标也是白的，同样看不见。关键是成对，而不是某个值好不好看。

还有一个更隐蔽的情况：有的界面自己设了状态栏，有的界面没设。于是在同一个应用里，从 A 页跳到 B 页，状态栏图标会突然从浅变深或者从深变浅。这类不一致，用户说不清，但会觉得这个应用「有点毛糙」。

处理原则只有一条：把状态栏的底与图标当成一对，在主题层统一声明，而不是在每个界面里各写一遍。写在主题里，所有页面自然一致；写在各页面里，迟早会漏一个。

十、界面里嵌了网页，网页不知道你切了深色

很多应用里都有内嵌网页：帮助中心、活动页、协议、报表。这些页面在深色模式下往往还是白的，而且特别显眼，因为它们是整页的白。

原因很直接：网页是另一套渲染引擎画的，它不读安装包里的颜色资源。应用切了深色，网页完全不知道。

有三条路可以走，成本从低到高。

第一条，让网页自己适配。网页里可以声明「跟随系统的深色偏好」，写法是在样式里加一段媒体查询。这条路最干净，但要求你能改网页。如果网页是别人提供的，这条路走不通。

第二条，给网页注入一段样式。在页面加载完成后，应用往网页里塞一段覆盖样式，把背景和文字颜色改掉。这条路能救急，但很脆：网页一改版，注入的样式就可能失效，或者把某些元素改成看不见。我们只用它做过临时方案。

第三条，让系统去处理。较新的系统提供一个开关，可以让渲染引擎对网页做自动变暗。效果取决于网页本身的写法，复杂的页面会出现图片被压暗、彩色块变脏的情况。

怎么选？能改网页就走第一条；不能改、又必须深色统一，就走第三条并把期望值放低；第二条只在「明天就要交付」的时候用，并且要在交付说明里写清这是个临时措施。临时方案最怕的不是它不好，是没人记得它是临时的。

十一、图片在深色下有两类问题

前面提过图片不是颜色问题，这里单独说，因为它值得一套自己的处理办法。

第一类：白底的图。商品图、证件照、二维码、扫描件，绝大多数是白底。放在深色界面上，每一张都是一块亮斑。这类图不能靠改颜色解决，只能换。

换法有几种，代价不同。最彻底的是为深色单独出一套图，放进对应的夜间资源目录，名字不变——系统会自己挑那一份，代码一行都不用改。这是最规矩的做法。

其次是给图加一个容器。不改图，而是给显示图片的容器加一层浅色底，让白底图和背景之间有个过渡。成本最低，效果也最一般，适合图片很多、又来不及重出的场合。

第二类：深色的 logo 与图标。这类正好和白底图相反：它们在浅色下清楚，在深色下看不见。处理办法同样是备一份浅色版，放进夜间目录。

注意一个细节：给夜间目录放图，图片的名字和目录结构必须与原来那份完全对应。名字对不上，系统就找不到它，表现还是「没变」——这和资源索引表那一层是同一件事：图片是靠名字被找到的，不是靠位置。

判断要不要为深色单独出图，有个简单标准：如果这张图的主要作用是「传达图像内容」，值得出一份；如果只是「一块装饰底」，那就改颜色或换一张纯色，不必维护两套。维护两套图是有长期成本的，能少一套就少一套。

十二、真动手时，顺序比技术更重要

把上面这些串起来，一次完整的深色改造其实是五步，而顺序错了会多绕一倍的路。

第一步，先定策略。跟随系统，还是给用户开关？这一步决定主题怎么声明，也决定验收时切的是系统开关还是应用内开关。很多返工的起点就是这一步没定。

第二步，补一份深色配色。不是反色，是重新配一档：背景、卡片、主文字、次文字、分隔线、强调色，六个位置各给一个值。这一步只动一个文件，却解决了一半界面。

第三步，扫一遍写死的颜色。把布局里直接写值的控件找出来，换成引用颜色名。这一步最枯燥，但收益最直接——换完之后，同一个界面在两种模式下会自动一致，不用维护两份。

第四步，处理四处边角：状态栏、弹窗、启动窗口背景、内嵌网页。这四处不在主界面上，漏了不会被自己发现，一定会被用户发现。

第五步，按清单验收。不是「看一眼变黑了没有」，而是逐项过，下面会给一张表。

这五步里，第三步最值得多说一句。扫写死的颜色不是「看到白底就改白底」，而是「看到字面值就换成引用」：白底要换，黑字也要换，那个看起来没问题的浅灰分隔线同样要换。原因是深色下这套浅色值全都站不住，而它们平时因为「看着还行」从来没被人注意过。判断标准只有一条：这个值是名字还是数字。是数字就换掉。

为什么顺序不能换？因为第三步的改动量最大，如果在配色还没定的时候就去扫写死的颜色，扫完还要跟着配色再调一遍。先定色、再扫色，是唯一不返工的顺序。

十三、七个问题，都是改深色时真被问过的

1. 深色模式下要不要重新做一套图？看图的用途。内容图（商品、证件、截图）值得做；装饰图不值得，改颜色或换纯色更快。判断标准是「这张图有没有信息量」。

2. 只做深色、不做浅色行不行？可以，但要有理由。有些夜间使用的工具类应用确实可以只做深色。不过要注意，系统设置里用户可能强制浅色，你的应用会显得格格不入。

3. 改了颜色资源，为什么没生效？先确认颜色的引用链断了没有：界面引用的颜色名，和颜色定义文件里的名字是否完全一致。名字对不上时不会报错，只会默默用默认值。

4. 切换后要不要重启应用？多数情况下不需要，系统会通知界面重绘。但涉及窗口背景这类「只在创建时读一次」的东西，冷启动才看得到变化，这也是验收必须杀掉进程重开的原因。

5. 深色下字体要不要换？一般不用。但深色背景下细字重会显得更细、更虚，正文可以适当加半档字重，标题不受影响。

6. 深色模式的配色能不能直接用设计稿里的值？能，但要现场核对。设计稿常在明亮环境、高亮度屏幕上做，实际手机的自动亮度会让它偏暗，所以最终要以真机为准。

7. 老用户升级后，深色开关的默认值该是什么？建议跟随系统。用户第一次升级不该被强行改成深色或浅色，跟随系统是唯一不会让人意外的默认值。

这七个问题里，第三和第四个是纯操作层面的，也是实际卡住人最多的两个。它们共同的特点是：不报错。深色这件事几乎所有的坑都不报错，只会「看起来不对」。

十四、验收清单：七处看完才算改完

按这张表走一遍，比随机点二十个界面有效得多。

看哪里	怎么触发	不对长什么样	常见原因
首屏与列表	滚到底，看有没有突然变白的一行	背景与卡片色	局部写死
输入框与搜索框	点进去输入一段文字	白底白字	写死白底
弹窗与底部菜单	触发一次确认与一次选择	整块雪白	自绘容器
下拉刷新	下拉一次，看那两秒	白色进度条	代码里设色
冷启动	杀掉进程再打开	闪一下白	窗口背景
状态栏	看时间与电量是否还看得见	图标与底同色	未成对设置
内嵌网页	打开帮助页或活动页	整页白	不读资源

这张表有个特点：七项里有五项需要「主动触发」才会出现。输入框要打字，弹窗要点击，下拉要拉一下，冷启动要杀进程，网页要跳过去。只看首屏能发现的问题，不到全部的一半。

还有一条经验：两台设备各看一遍。不同厂商对深色模式的实现细节不完全一样，尤其是状态栏和自动反色这两块。在自家手机上完美、在同事手机上发白，是这类改动最常见的翻车方式。

十五、什么情况下不该做深色

不是所有应用都值得做深色。老老实实不做，比做了但处处漏要好。

第一种，界面只有一两个静态页。比如一个纯展示的介绍页，做完深色收益很小，维护成本却一样：每次改版都要记得改两套。收益小、成本固定，这种事通常不该做。

第二种，大量依赖第三方界面组件。如果界面里一半以上是别人的页面、别人的弹窗、别人的网页，你能改的只有自己那部分，结果就是一半黑一半白，比全白更难看。

第三种，图片是绝对主角的应用。相册、看图、设计类工具，界面越黑越不干扰内容——这类其实应该做。反过来，如果图片全是白底的文档、票据、扫描件，深色下满屏亮斑，做了反而不如不做。

第四种，交付时间只剩一天。深色这件事的坑都在边角，一天时间只够改主界面，剩下的边角会在接下来两周里一个个被用户发现。与其交一个半成品，不如明确告诉对方「这一版没做，下一版排进去」。

判断可以做之后，还有一个更实际的问题：值不值得现在做。我们的经验是看使用场景——如果这个应用会在夜里、在暗处、在床上被打开，那就值得；如果只在白天的办公室里用，优先级可以往后放。

十六、一次返工的账：深色改造做了三轮

把前面两个实例的时间线摊开，这一轮深色改造前后用了三天，其中两天是返工。

第一天，主界面。补了深色配色，扫掉了列表和详情页写死的白底，切过去看着很顺。当天下午交付给对方试用，晚上收到三条反馈：输入框看不见、报错弹窗是白的、打开时闪一下白。三条反馈分别对应前面说的第一、第二、第四处。

第二天，边角。改输入框、改自绘弹窗、给启动窗口补一份深色背景。改完再试，看着没问题了。但这次漏了状态栏——因为测试的同事手机状态栏图标本来就是浅色，恰好和深色背景撞上了，他自己没看出来。

第三天，状态栏与被忽略的网页。把状态栏的底和图标成对声明，又发现帮助中心那个内嵌网页整页是白的。网页是第三方提供的，改不了，只能先用系统的自动变暗兜住，并在交付说明里写明这是临时措施。

这三天里，真正写代码的时间不到一天，另外两天全在「发现」上。而发现之所以慢，不是因为问题难，是因为没有人按清单逐项触发——全靠使用者碰巧撞见。

如果重来一次，省下来的不是技术，是流程：先做那份七行验收表，把七处挨个触发一遍，第一天就能把三处边角一起发现。深色改造的返工里，八成不是「不会改」，而是「不知道还有这里」。

顺便说一句成本：这一轮三天的活，用一句话描述需求、让工具按颜色引用统一替换，前面「扫写死颜色」那一步可以压到几十分钟。省下来的时间不会消失，它会自动流向验收——而验收恰恰是这件事上最该多花时间的地方。

十七、把这件事写成一句能执行的话

如果要把深色改造交给别人做，一句话里必须带四个信息，少一个就会返工。

反例：「做一下深色模式」。这句话什么都没说清：跟随系统还是给开关、要改哪些界面、边角四处算不算、怎么验收。

正例：「这个应用跟随系统深色。补一份深色配色（不要反色），把布局里写死的白底全换成颜色引用；状态栏的底和图标要成对、弹窗和启动窗口背景要一起改；验收按首屏、输入框、弹窗、下拉、冷启动、状态栏、帮助页七处走，手机和平板各一台。」

这个正例里，四样东西齐了：策略（跟随系统）、范围（配色加写死颜色）、边角（四处点名）、验收（七处加两台设备）。而它们正好对应前三天的三次返工。

还有一个小技巧：把「不要什么」也写进去。比如「不要动图片资源」「不要改主题的默认值」。改动范围越大，越要说清边界，否则执行的人会顺手把不该动的也动了。

最后，把验收标准写进需求，而不是留在自己脑子里。「看着变黑了」不是标准，「七处逐项过、两台设备都过」才是。标准写得越具体，交付时的争论越少。

十八、两套资源怎么才能长期不跑偏

深色做完了，真正的问题才开始：三个月后改版，谁记得还有一套深色要同步改？

第一个办法，让浅色和深色共用同一批颜色名。名字只有一套，值有两份。这样任何人改界面时，看到的永远是名字，不会只改一份。这是最省心的结构，代价是前期要把颜色名整理干净。

第二个办法，把「深色下检查一遍」写进改版流程。不是靠记忆，是靠流程里的一行字。凡是没写进流程的检查项，第三次改版时一定会被跳过。

第三个办法，把验收表的七项固化成一个固定动作。谁改的界面谁自己走一遍，走完在交付说明里写一句「七项已过」。一句话的成本极低，但它让「没检查」变成了一件需要解释的事。

反过来说，最容易跑偏的结构是：浅色一套颜色名，深色另起一套名字，两套各改各的。这种情况下，界面里引用的是哪一套，改版的人自己都说不清，最后必然出现「浅色改了、深色没改」。

如果已经跑偏了怎么办？不用一次全理顺。挑改动最频繁的那两三个界面，把它们的颜色引用统一到同一批名字上，其余的先不动。治理这件事，从最常改的地方开始，收益最大。

十九、三句话说完这件事

第一句：深色是第二套文件，不是一次运算。所以颜色必须从资源里读；写死的值永远不跟着变。

第二句：改的顺序是先定色、再扫色、最后补边角。顺序反了，配色一变就要全部重扫。

第三句：验收要主动触发七处，别只看首屏。输入框、弹窗、下拉、冷启动、状态栏、内嵌网页、两台设备。

再补一句：如果只记一件事，记「不报错」。深色这件事所有的坑都不会报错，只会看起来不对。所以它靠的不是排错能力，是清单。

这也解释了为什么它总被低估：看起来只是「把背景改黑」，实际上是一次跨资源的整体校验。看起来越简单的事，越容易在没人注意的地方留下十处白斑。

二十、三个反直觉的结论

做完几轮深色之后，有三件事和最初的判断正好相反。

第一，界面越简单的应用，深色越难做对。复杂界面有设计规范、有组件库、有人盯着，颜色都走同一套引用；简单的界面往往是东拼西凑出来的，颜色一半写死、一半引用，翻起来特别费劲。

第二，深色做得好的标志，是「看不见深色」。用户不该注意到「这个应用做了深色模式」，他只该觉得夜里看着不刺眼。一旦某个地方让他停下来想了一下，那处就是漏的。

第三，最该花时间的不是改，是列清单。改一个颜色是一分钟的事，找到「还有哪五处要改」可能要一整天。所以深色改造的真实成本，几乎全部在发现上。

把这套清单真正用起来，还有一个前提：改完能立刻在真机上看到。安卓修改大师智改工坊做的事情就是把「改一句、装一台、看一眼」这个循环压到最短——配色改了、写死的颜色换掉了、状态栏成对了，一句话就能回编对齐签名，装回手机直接切深色看效果。产品介绍页在 https://www.apkeditor.cn/ai-version.aspx。

这三条合起来指向同一个做法：先想清楚要查哪几处，再动手。清单越具体，改起来越快；反过来，边改边找，一定会返工。这也是为什么前面那张七项验收表，比任何技术细节都值得先抄下来。

二十一、还有两处常被忘：截图与分享卡片

深色改造做完，还有两个地方露出的是「另一套界面」，很容易被忽略。

第一处，应用内的分享卡片。把内容分享到聊天工具时，会生成一张带标题、缩略图和底色的卡片。这张卡片的颜色往往取自某个固定配置，不会跟着深色模式变。结果就是：应用里是深色，分享出去在对方那里是一张亮白卡片。它不影响使用，但影响观感的一致性。

第二处，应用自己截的图。有些应用会提供「保存当前页」或「生成报告图」的功能，这些图是运行时画的。如果画布背景是写死的白色，深色模式下截出来的图就是白底黑字，和你在屏幕上看到的不一样，用户会觉得「截图截错了」。

这两处的共同点是：它们都是「输出」，不是「界面」。界面被人盯着看，输出被存下来、发出去。所以它们的问题不会被当场发现，而是在别人那里被发现。

处理办法很简单：分享卡片和截图背景，读同一个颜色名，跟着深色一起变；如果业务上要求分享卡片始终白底（便于在聊天里阅读），那就在需求里写明「这一处固定白底」，写明和漏掉是两件完全不同的事。

二十二、附：一页速查

把整篇压成一张表，改之前对着看一遍。

主题	关键做法	一句话提醒
颜色住在哪	颜色定义 / 布局 / 代码 / 图片	从一到四顺序查
深色怎么生效	换一个资源目录去读	不是反色运算
配色六位置	背景 卡片 主文字 次文字 分隔线 强调色	背景不用纯黑
必查五处	输入框 弹窗 下拉刷新 启动背景 图片	都不在主界面上
状态栏	底与图标成对声明	写在主题层
内嵌网页	能改就改，不能改就自动变暗	临时方案要写明
验收七项	首屏 输入框 弹窗 下拉 冷启动 状态栏 网页	主动触发
长期维护	一套颜色名，两份值	写进改版流程

二十三、用过的人怎么说

这篇里所有实例都来自我们自己维护的应用——门店端、培训端、还有几个内部工具。写出来的目的不是证明什么，是把那些「不报错、只是看起来不对」的地方提前列清楚，让下一个做深色的人少走两天弯路。

合规提醒：本文所有实例均针对自有版权或已获授权的应用，用于企业内部维护、夜间场景适配与合法定制。请勿将改包能力用于破解他人付费应用、绕过安全机制或规避授权校验。改包前请确认你对目标应用拥有相应权利，并保留原包与签名材料以备回退。

深色模式这件事，说到底是一次「把所有颜色的出处理一遍」的机会。理完之后你会发现，界面里那些说不清为什么好看、为什么难看的地方，大多是因为颜色来得不明不白。安卓修改大师智改工坊做的事很简单：把你想改的那句话，落成包里真正变掉的那几处文件——不管是一份配色、五处白底，还是那一行状态栏。说清楚要什么，剩下的交给它。