启动页改造的边界：改图与改时长各动哪一层，改完又该怎么验证

先交代主角。安卓修改大师智改工坊是一款 Windows 桌面工具：拖入安装包，用中文写需求，AI 在反编译出来的工程里改代码与资源，改完自动回编、对齐、签名、校验，然后可以一键装到手机或模拟器上拉起来看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

这篇谈的是它被问得最多的改造之一：启动页（Splash / 开屏）。需求通常只有两句 —— "把开屏那张图换成新的宣传图""把开屏停留时间延长一点"。听起来都是小事，但它们落在工程的两个完全不同的层上：换图是资源层的问题，改时长是代码层的问题；而且这两件事都取决于同一个前置条件 —— 你这个应用的启动页到底是用哪种方式实现的。 不先回答这个问题就动手，结果通常是三类：改完没变化、改完出现了第二个闪屏、或者改完启动变慢但页面还是原来那张。

所以这篇分四段走：先讲启动页的三种实现怎么分辨，再讲改图与改时长分别动哪一层，接着把"改完怎么验证"讲透 —— 这部分会用到工具的装机链路（装包、拉起、复核前台三步），最后给两个自家应用的实例和一份边界清单。启动页是一个动一下就能被所有用户看到的界面，它值得你多花十分钟把边界想清楚。

一、启动页其实有三种实现：先分辨，再动手

用户眼里的启动页是"打开应用时那一屏"，工程里它至少有三副面孔。分辨它们的过程不复杂，但必须做 —— 因为它决定了你后面所有的动作：

三种实现可以叠加：一个应用完全可能既有系统绘制的那一屏，又有自己的启动 Activity。这就解释了那个经典困惑 —— "我明明把启动页图换了，为什么打开时还是先闪一下旧图标？"因为那一下是另一层，不在你改的那个文件里。

三步分辨法：清单 → 布局 → 主题

1. 看清单里谁是入口：在 AndroidManifest.xml 里找带桌面启动 intent-filter 的那个 Activity。它是"第一屏"，记下它的名字和它挂的主题。如果这个入口 Activity 看起来就是主界面（名字很像 Main/Home），那启动页多半是"实现一"或"实现三" —— 它没有自己的页面，只是窗口背景。
2. 看入口有没有自己的布局：如果入口 Activity 明显是个"过渡页"（名字里常带 splash / welcome / launch / guide），就去布局目录里找它的布局文件，看里面是不是一张铺满的图。有布局 = 实现二，改图改的是这个布局引用的图片。
3. 看主题里窗口背景是什么：找到入口 Activity 用的主题，看它的窗口背景指向什么 —— 一张图、一段颜色、还是一层叠一层的列表（logo + 底色组合）。指向图片 = 实现一，改图改的是那张图；指向颜色或叠加层，就要连它引用的每一项一起看。

这三步的价值是：它让你在写需求之前就知道该说"改哪个文件"，而不是把"启动页换成新图"这种模糊的话丢出去。工具这边能帮你把定位变简单：导入包的时候，工作目录里的 aapt 会读出包名、应用名、版本、最低与目标 SDK，以及启动页组件名，写进这个项目的配置里。这个组件名后面还有第二个用处 —— 装机之后要靠它才能把应用准确地拉起来（第三章会讲）。

把分辨结果写进需求，一句话就能省掉一轮返工。下面这段可以直接照抄，把方括号里的内容按你的判断替换掉：

最后一句"不要改动其它元素与启动流程"是刻意加的：启动页改造里最危险的从来不是"没换成"，而是"顺手多改了" —— 比如把整个启动流程重排一遍、把跳转逻辑挪个位置。把"不许动什么"写清楚，和把"要改什么"写清楚一样重要。

二、改图：动的是资源层，稳妥的做法是"同路径同名替换"

分辨清楚之后，改图这件事其实很朴素：找到那张图现在在哪儿，把新图用同样的文件名放回同一个位置。 之所以强调"同路径同名"，是因为启动页的图往往被好几处引用（主题的窗口背景、启动 Activity 的布局、有时还有一个深色的专用版本），路径和名字不动，所有引用都不需要改，改动面自然最小、风险最低。反过来，如果你把图改名成 brand_new_splash.png，就得把所有引用它的地方一起找出来改，漏一处就是"没改成"甚至回编报错。

"同路径同名替换"里有四个细节要交代清楚，它们都是"看起来换了、实际不对"的常见来源：

细节	为什么重要	建议
格式与尺寸	旧图可能是切片图（会随着拉伸出现拉伸纹）或矢量风格	新图尽量沿用旧图的格式与比例；不确定时按最长边放大一档
深浅两套	有些包给深色模式准备了另一张启动图	需求里点明"深浅色两套启动图一起换"
分层结构	启动页常是"底色 + logo + 标语"叠出来的多层	先数清叠了几层，逐层确认换哪层、留哪层
多密度目录	同一张图在多个密度目录里各有一份	要么全部替换，要么按原尺寸等比生成，别只换一份

这四个细节合起来，就是"改图"这件事的完整清单。它们都不难，难的是"想起来" —— 尤其是最后一条：屏幕上显示的是系统按设备密度挑出来的那一份，你只替换了其中一份，就会出现"我这台看着换了、同事那台还是旧的"这种最难解释的现象。智改工坊在这类细节上的处理方式是：重活（翻找、替换、生成多份尺寸）交给 AI，选择（换哪张、换哪层、要不要保留旧素材）留给你，需求里写清楚即可。

三、改时长：为什么"延长启动页"必须看实现才敢做

这是本文最想讲清楚的一段。用户提"把开屏时间从 1 秒多延长到 3 秒"时，心里的期待很具体：希望用户多看一会儿新的宣传图。但这句话能不能做、怎么做，完全取决于启动页是哪种实现：

为什么这里要反复强调"看实现才敢做"？因为在不该动的那一层动手，会得到三种典型的坏结果：

• 改不动：在资源里翻半天找不到"1.5 秒"这个数，因为它根本不在资源里；或者改了一个数字，发现另有一处入口走的是完全不同的路径。
• 改成"启动页之后白屏一会儿"：把延时加错了位置 —— 比如加在跳转之后、或者加到主界面的初始化里，用户看到的是图先消失、界面再晚到，观感比原来更差。
• 改成"每次回前台都要等"：延时被放在了每次可见都会被触发的回调里，于是从后台切回来也要重看一遍开屏图。用户对这件事的容忍度极低，几乎是"一眼差评"级别的体验问题。

所以正确的做法是：先问实现，再决定要不要做。 在智改工坊里，这件事可以很自然地拆成两步需求。第一步先"问清楚"：请 AI 确认这个应用的启动页是独立的启动页面还是主题的窗口背景，如果是独立页面，停留时间在哪个文件里控制、当前大约是多少毫秒。第二步才是"改"：确认是代码里的延时之后，再提出"把停留时间延长到 N 秒，并且确保只在冷启动时生效，从后台切回不触发"。把"探路"和"施工"分成两次对话，是启动页这类需求最稳的姿势 —— 因为这个领域里，"我以为"和"实际是"之间的差距，往往比你想象的大。

如果实现是"窗口背景"，能不能把它改造成"有延时"？

技术上当然能：给启动阶段插一段"先显示一张图、等一会儿再进入主界面"的逻辑 —— 但那已经不是在改启动页，而是在给应用增加一个新的启动环节。它的代价要提前讲明白，供你判断值不值：一是要动到启动流程本身（谁先出现、谁后出现），二是清单里可能需要增删入口声明，三是凡是从别处进入应用的所有路径都要重新确认一遍（有的入口会绕过你新加的环节，有的则会重复触发）。做对了没人夸，做漏了一处就是"有两个不同的开屏"。所以我们的建议始终是：为了"让用户看久一点"而改造启动流程，通常不划算；把该说的信息放进图里、或者放进应用内的一次提示，才是省事又稳妥的做法。

反过来，"把已有的延时改短"风险要低得多 —— 去掉一段等待、或者把 1.2 秒改成 1 秒，属于同一处的参数调整，不改变流程结构。如果你的目标是"别让用户等"，这条路径是通的；如果目标是"让用户多看一会儿"，请回到上面那段话再想一遍。

如果你确实需要一个"多停一会儿"的开屏，除了改延时，还有一种替代思路值得先考虑：把"要看更久"换成"内容更值一看"。开屏图本身能不能承载一点有用的信息（新版本亮点、内测提示、巡检同事要记住的一条安全提醒）？当那张图有内容时，用户不会介意多看半秒；而单纯为了延长而延长，得到的往往只有抱怨。技术上的克制，有时候就是产品上的加分 —— 这也是我们在讲"边界"时最想传达的态度：不是所有能改的都应该改。

这里也顺带说清工具在"等待"这件事上的一个设计，它和启动页无关，但同属"启动类"的体感问题：AI 在项目目录里完成修改后会留下一个标志文件，主窗口每 2 秒轮询一次，读到就自动弹打包窗口 —— 等待是自动衔接的，不需要你盯着看；同时它也设了等待上限（一小时），避免某个异常让流程永远挂着。知道这个机制，你就不会在"改到一半"时误以为程序卡住了：看一眼项目目录里那个标志文件在不在，就知道 AI 那边进行到哪一步了。

四、改完怎么验证：装机链路的三道复核

启动页有一个很讨厌的性质：它只在冷启动时出现，而且一瞬就过去了。 你让同事"帮我打开看看"，得到的回答通常是"没看清"。所以验证这件事必须靠可重复的流程，而不是靠人眼盯。智改工坊的装机链路恰好给出了一套可以照抄的复核办法，我们把它拆成三步讲。

第一道：装包本身要确认真的装上去了

打好的包要装到设备上，走的是 adb 安装。这里有几个现实问题值得知道，因为它们决定了你"看到的到底是哪个包"：设备上如果装着一个版本号更高的同名应用，直接覆盖会失败，此时需要允许降级覆盖安装（数据保留）；如果那个包被标记成"仅测试"，安装需要额外带上允许测试包的开关；最需要警惕的是签名不一致 —— 这种情况下是装不上去的，必须先卸载旧的那个（会清掉它的数据）。工具对前两种会自动换一种装法重试，对签名冲突会明确告诉你要先卸载，就是为了避免"以为装上了、其实还是旧包"。

顺带说一个跟本章相关的细节：覆盖安装不会清除应用已有的缓存与数据。对启动页改造来说，这意味着"上一版可能被缓存的资源"不一定被清掉；如果你改完看不到变化，卸载重装一次是最干净的对照实验。

第二道：拉起应用要"指名道姓"，而不是碰运气

装完包要验证效果，就得把应用拉起来。这里工具做了一个刻意的选择：用 am start 指定组件名来拉起，而不是用过去常用的 monkey 随机启动。原因很实际：较新的系统镜像里已经没有 monkey 这个命令了，更麻烦的是 —— 它失败时的退出码仍然是 0，只看退出码会把它当成"启动成功"，于是表现就是"装上了但没打开"，你以为改失败，其实是根本没拉起来。

"指名道姓"里的"名"从哪来？三档取：项目配置里记着导入时读出的启动页组件名（最准）；拿不到时问设备（cmd package resolve-activity 让系统告诉你这个包的入口是谁）；都不行才退回用 monkey 碰一碰（只当老设备兼容）。启动命令本身是 am start -W -n 包名/组件名 —— 那个 -W 让命令等到启动结果再返回，输出里会带一列启动耗时的数字，工具会读其中的状态行判断这次启动成不成功。

第三道：复核前台应用到底是不是它

这是最容易被跳过、也最不该跳过的一道：命令返回成功，不等于应用真的出现在用户眼前。 有些机型会拦一下、有些情况下它会自己退到桌面。所以工具在拉起之后还会问系统一次"现在前台是谁"，确认置顶的那个确实是我们的包；不是的话不判定为失败，只在诊断日志里记一笔。这三道复核的意义是：把"我以为它起来了"变成"系统说它起来了"。

把这三道复核连起来，你会得到一个很朴素但很值钱的结论：启动页改造的风险不在"改"，而在"确认"。 改一个引用的路径是几分钟的事，把它确认到"所有机型、所有入口、冷启动都正确"才是真正的工作量。工具能替你把打包、装包、拉起、前台复核这条链条自动化，剩下的判断交给你 —— 这也正是它设计上的分工。

另外，打包本身也值得知道一点"账"：出包会依次在项目的 build 目录里留下三个中间产物 —— 未签名的、对齐过的、最终签名的，全过程写进项目的打包日志里。为什么要留三个？因为一旦某一环出问题，你能立刻看出卡在哪：回编失败说明资源或代码有问题，对齐失败说明包结构有问题，签名失败说明密钥或参数有问题；而"校验"那一步会打印签名证书信息，用来自证"这个包确实签上了"。打包过程中窗口是不给关的 —— 这不是煞有介事，而是为了避免你在等待时误以为程序已经跑完或者已经卡死。出问题先看日志，比反复重打包快得多。

五、边界与坑：启动页改造的六条经验

在讲实例之前，先把这些年踩过的坑收成六条，条条都能省你一轮装机：

一、桌面图标 ≠ 启动页图。 两者是两套完全独立的资源，换了开屏图不会换桌面图标，反过来也一样。

二、分层启动页要"整层"处理。 底色 + logo + 标语叠出来的开屏，只换其中一层，剩下的旧元素会露出来，观感比不改更糟。

三、深色模式可能有另一张图。 改完请切到深色模式再看一次冷启动。

四、多密度目录别只换一份。 否则换出来的效果会随设备"随机"变化。

五、改图不要改名。 引用链上的名字一变，就得把所有引用一起找出来改，风险翻倍。

六、"延长时长"要问清楚才做。 见第三章：先确认是独立启动页，再动代码，并确保只在冷启动时生效。

这六条里，第一条和第三条是"看一眼就能确认"的低成本检查，建议养成习惯：换完开屏图，顺手看一眼桌面图标是不是还是原来那个（确认自己没有误动图标资源），再切一次深色模式冷启动看一眼。把这两个"顺手"做成肌肉记忆，启动页改造就基本不会再出意外了。

还有一个观感层面的细节常被忽略：启动页的底色与状态栏是否连成一体。顶部的状态栏如果和开屏图不是一个颜色，会在屏幕顶端切出一道突兀的色带 —— 这在深色底的图上尤其明显。处理办法有两种：把状态栏设成与开屏底色一致（并在深色模式下同样保持一致），或者干脆让开屏图延伸到状态栏下面。这件事不属于"换图"，但用户对它的感知比你想的强，值得在需求里补上一句。

还有一条工程上的小知识，和"改完为什么样式文件多了一条"有关：智改工坊在每次出包之前，会往工程的样式文件里写入一个标记样式（名字固定，内容是把时间、账号、机器码、程序版本、应用名与包名编码成一段字符串）。它是"这个包是谁、什么时候打出来的"的凭证，写在回编之前、会一起编进包里；如果写不进去只记一条日志、不会拦下打包。所以你如果打开工程看到多出来的那条样式，不用奇怪 —— 那是打包流程留下的标记，不是改坏了。

六、两个自家改包实例：从"装三四次"到"一眼确认"

下面两个例子都出自身边同事的日常：改的是自家与内部应用、自有素材，重点看"以前怎么做 / 现在一句话怎么做 / 改完怎么验证"这三步。

实例一：给内部「门店盘点」应用换掉启动页背景图。

这是公司给门店同事用的盘点工具，启动页背景是上一版的活动宣传图，现在要换成新一版。以前的做法很典型：反编译之后先在资源目录里找到那张图（这一步常常要在几百个文件里翻，图名还可能是 bg_splash_v2 这种既不带 splash 规律、也没人记得的名字）；按原尺寸导出并覆盖；回编、对齐、签名；装到测试机上打开看效果。最耗时的恰恰是最后一步：启动页一闪而过，装三四次才能确认到底换的是哪一张，而且每次都要手动重新走一遍装包流程。

现在一句话：把自家的包拖进安卓修改大师智改工坊，需求写"把启动页背景图换成附件里这张新版宣传图，保持原来的显示比例与格式；如果这个包在深色模式下有另一张启动图，也一并替换成同一张"，把新图作为附件加进去、写好用途（附件那一栏要求每个文件的用途说明不少于 10 个字，就是为了避免"这个文件是干嘛的"只能靠猜）。点「立刻修改」，AI 改完会在项目目录留下标志文件，主窗口每 2 秒轮询一次，读到就自动弹出打包窗口；打包四步（回编、对齐、签名、校验）跑完，产物落在项目的 build 目录里，可以选择「保存 APK」（默认名是"应用名_版本号_signed.apk"）或直接「打开所在文件夹」。

改完怎么验证？在打包窗口勾上"打包后自动运行"：程序会用 adb 找到手机或模拟器，把包装上并拉起 —— 手机这边走投屏，模拟器这边把窗口提到最前面。因为启动页一瞬即逝，工具做了三道把关：先按项目里记的启动页组件名用 am start -W -n 拉起（拿不到就问设备要入口），再用系统查询复核一次"前台现在是不是它"。当你盯着一闪而过的画面拿不准时，"系统说它确实到前台了"这句话本身就很有用 —— 它让你确定看的是刚打出来的那个包。

实例二：给自家「巡检打卡」把开屏停留时间从 1.2 秒延长到 2 秒。

这是公司内部给巡检同事用的工具应用。新一版开屏图上加了三条安全提醒，产品同学担心"1.2 秒根本来不及看"，想延长到 2 秒左右。这个需求的难点不在改，而在先确认它能不能改：这个应用的启动页是独立的启动页面（有自己的布局、有跳转逻辑），还是只是主题的窗口背景？前者才能改时长，后者根本没有"时长"这个参数。

所以第一步不是提改动，而是提问题：在需求框里写"请先确认这个应用的启动页是独立页面还是窗口背景；如果是独立页面，停留时间由哪个文件控制、当前约为多少毫秒；如果是窗口背景，请说明为什么不能通过资源调整停留时间"。AI 回过来确认：它是一个独立的启动 Activity，跳转前有一处延时，当前值是 1.2 秒量级。得到这个答案之后才动手：把延时改到 2 秒，并且明确要求"只在冷启动时生效，从后台切回不再显示；同时确认所有进入应用的路径都经过同一个入口"。

验证这一步，这次比"看图"更严格：把应用彻底退出，用工具拉起，重复三次看停留时间是否稳定；再切到后台、切回前台，确认不会再看一遍开屏；最后从另一条路径进入应用，确认入口一致。这三项都过了才算收工。整个过程里，需求原文会被记进这个项目的历史，下次要"按这条思路给另一个内部应用也改一遍"，点一下历史里的「选择」把需求填回输入框即可 —— 省下的正是重新组织话术的时间。

七、用户评价：他们的启动页改造体验

下面几位的看法来自内部试用与交流群的交流整理，谈的是他们的用法与感受：

八、结语：先分辨，再动手，最后用系统的话确认

把这篇收成三句话：启动页有三种实现，改图前先分辨；改图动资源（同路径同名、深浅与多密度一起换），改时长动代码（而且只在独立启动页这一种实现里存在）；验证靠流程不靠眼睛 —— 装包、拉起、复核前台三道走完，再用冷启动与深色模式各看一次。 启动页是每个用户都会看到的界面，它配得上这套仪式感。

于是你打开安卓修改大师智改工坊时的体验，就是那句口号说的样子：只需说话，就能让应用变成你想要的样子 —— 把自家安装包拖进来，用中文说清"换哪张图、换哪几层、要不要动时长"，AI 改完自动回编、对齐、签名、校验，再一键装到设备上拉起、复核，整套动作在同一个窗口里跑完。

产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。