帮助页还是旧品牌：应用里那层网页到底怎么换

改包时最容易漏掉的一类界面，是那些其实是网页的界面。它们看起来和应用其他页面一模一样，有标题栏、有返回、有滚动的正文，但它本质是一张 HTML 页面，装在一个网页控件里。

所以改包的时候会出现一种很典型的场景：名字改了、图标改了、配色改了，点开「关于」还是旧品牌。因为在资源里怎么也搜不到，它不在那儿。

这一篇讲应用里的网页：它住在包的哪个位置、有哪几种加载方式、换内容有哪三条路、改了为什么不生效、以及改完怎么验。官网是 www.apkeditor.cn。

一、应用里哪些地方其实是网页

不是所有页面都是原生画的。一个中等规模的应用，往往有一半的「内容型界面」是网页。

最常见的是帮助与关于。使用说明、常见问题、版本说明、联系我们，这些内容改动频繁，用网页做最省事，改文案不用发版。代价是它们不在资源文件里，改名换皮的时候容易整个漏掉。

第二类是协议与声明。用户协议、隐私政策、儿童个人信息保护规则。这类页面在合规检查里是被明确要求的，而且经常需要随政策变化更新。它们一旦指向旧地址，就不是「不好看」，而是「打不开」。

第三类是活动与公告。首页顶部的横幅、弹窗公告、节日活动页。它们通常完全由服务端下发，应用里只有一个容器。这类页面一般不需要改包，但需要知道它们的存在，否则验收时会漏掉一个入口。

第四类是客服与反馈。在线客服、意见反馈、工单提交，很多是直接嵌入第三方页面。这类页面背后往往绑着账号体系，改包之后如果换了包名或签名，第三方那边可能认不出来，表现是页面能打开但一直转圈，或者提示参数错误。

第五类是嵌入的展示内容。新闻详情、商品图文、课件、说明书。它们的共同点是「内容长得像网页」，因为它们确实是用网页渲染的。

这五类有个共同点：它们的内容不在应用的资源文件里，所以「改名字」这类操作搜不到它们。判断一个页面是不是网页，最简单的办法是看它加载时有没有一段短暂的白屏或者进度条——网页控件初始化总需要一点时间，原生页面通常没有。

知道这一点之后，改包前的盘点就多了一栏：有没有内容型页面、它们从哪加载。这一栏填清楚，才不会出现「全都改完了，就剩一个协议页还是旧名字」。

二、网页在包里住在哪儿：三种住法

应用里的网页，来源只有三种。分清是哪一种，才知道该改哪儿。

第一种，住在包里。一串 HTML、CSS、JS 文件，放在应用的资源目录里，随安装包一起安装。它的特点是：断网也能打开，内容固定，改一次要重新发版。这类页面在包里能找到实体文件，是改包时最该关注的一种。

第二种，住在服务端。包里只有一个网页控件和一行地址，内容全部从远端拉取。它的特点是：内容随时可改，但没网就是白屏；而且地址一旦失效，页面就彻底打不开。

第三种，混合。包里放一份本地版本作为兜底，同时尝试从远端拉最新版本，拉到了就用远端的，拉不到就用本地的。这是体验最好的做法，也是改包时最容易出错的做法——因为你改的是本地那一份，用户看到的可能是远端那一份。

三种住法，在包里的痕迹完全不同。第一种能看到一堆网页文件；第二种只能看到一个网址字符串；第三种两者都有，而且往往还带一段判断逻辑。

所以判断方法很直接：在包里搜一搜有没有 .html 文件，再搜一搜有没有 http 开头的地址。两个都搜到，多半是第三种；只搜到前者是本地页；只搜到后者是远程页。这一步比直接打开应用点一遍更可靠，因为有些入口藏得深，点不到。

还有一个容易忽略的位置：网页文件不一定都在同一个目录。有些应用把活动页放在一个目录，把协议页放在另一个目录，还有的把帮助文档打包成一个压缩文件，启动时解压到本地。所以搜的时候不要只搜一个目录，要按文件类型整体搜一遍。

分清楚住法之后，改法就自然出来了：本地页换文件，远程页改地址，混合页两样都要处理，还要想清楚优先级。这三种改法的成本和风险完全不同，混着做必然出错。

三、换内容的三条路，各自适用什么场景

知道网页住在哪儿，接下来是换。三条路，按代价从小到大排。

第一条，直接替换包里的网页文件。把旧的 HTML 和它依赖的样式、脚本、图片一起换成新的，文件名和目录结构保持不动。这条路最适合「只是换个品牌、换段文案」，改动小，风险低，不需要动任何代码。

这条路有两个必须遵守的约束。一是文件名要和原来一致，因为代码里可能写死了文件名；二是相对路径不能变，页面引用的图片、样式如果换了目录层级，页面就会变成没有样式的纯文本。

第二条，改加载的地址。如果页面是从远端加载的，包里存的只是一个网址，把这个网址换成新的就行。这条路适合「内容搬到新域名」或者「换成自己的页面」。

改地址有两个坑。一是地址可能不止一处：首页有一个，设置页有一个，客服页还有一个，改了一处还有三处。二是新地址必须能正常访问，包括证书有效、不是明文 http、没有被网络策略拦。这三点任何一点不过，用户看到的就是一片空白。

第三条，改加载逻辑。这是最重的一条，适合「本地页和远端页的优先级要调整」或者「要加一个兜底」。它需要动代码，风险也最高，因为改错之后可能连本地兜底页都打不开。

三条路的排序很清楚：能换文件就不改地址，能改地址就不动逻辑。因为代价是递增的：换文件只影响一个页面，改地址影响所有引用它的入口，动逻辑影响整个加载流程。

有一个例外值得单独说：如果目标是把「指向别人域名」的页面换成「自己的页面」，最稳的做法不是改地址，而是换成本地文件。因为本地文件不依赖网络、不依赖对方服务是否还在、也不会有证书问题。代价是内容不能随时更新，但对协议页、帮助页这类低频变化的内容来说，这个代价可以接受。

四、文件明明换了，为什么还是旧的

换本地网页文件，最常见的失败是「换了但没生效」。打开还是旧内容，甚至重启应用也没用。原因通常有四个。

第一个，改的不是真正加载的那一份。包里可能有两份同名文件，一份在根目录，一份在子目录；也可能有一份是压缩包，应用启动时才解压。你改的是解压前的那份，应用读的是解压后的那份，或者反过来。

第二个，缓存。网页控件会把加载过的页面、样式、脚本缓存起来，下次直接从缓存读。所以同名的文件即使内容变了，也可能还是旧的。换文件时给文件加一个版本后缀，或者让页面引用带版本号的资源，能绕开这个问题。

第三个，远端优先。这就是前面说的混合模式。本地那份只是兜底，只要远端能拉到，本地永远不生效。这种情况下改本地文件等于没改，必须同时改远端，或者调低远端的优先级。

第四个，装错了包。这个听起来蠢，但真实发生过很多次：改完的包没装上，手机上还是旧的；或者装上了，但桌面上有两个同名图标，点开的是旧的。验收的第一步永远是确认「我打开的是刚装的那个」。

四个原因里，第三个最隐蔽，因为它不报错、不提示、也不异常。你改的文件确实在包里，只是没被用到。判断方法很简单：把网络断掉再打开页面。如果断网之后显示的是新内容，说明原来加载的是远端；如果断网之后打不开，说明它本来就依赖网络。

还有一个提醒：换了本地文件之后，一定要重新打包。有些改包工具会先把包解开，改完不自动回编，于是就出现了「文件改了、包没变」的情况。这一条属于流程问题，但它在真实项目里出现的频率不比技术问题低。

把这四条记成一句话：「换了没生效」不是玄学，只有四种可能：改错文件、缓存、远端优先、装错包。按这个顺序查，一般十分钟内能定位。

五、改远端地址的四个坑

改一个网址看起来是最简单的操作，实际上它比换文件更容易翻车，因为失败的方式更沉默。

第一个坑：新地址是明文 http。较新的系统默认不允许应用访问明文 http 的地址，尤其是从 https 页面里发起请求的时候。结果是页面一片空白，日志里可能有一行被拦的记录，但界面上一句提示都没有。换成 https 是最省事的解法，如果对方没有 https，那就该考虑换成本地文件。

第二个坑：证书。https 地址不代表能访问。证书过期、证书链不完整、域名和证书不匹配，都会让请求失败。这三种情况在浏览器里可能会给一个「继续访问」的选项，但在应用内的网页控件里通常是直接失败，没有选项。

第三个坑：跳转。新地址可能不是最终地址，它会跳一次甚至几次。如果代码里对地址做了白名单校验，跳转之后的新地址不在白名单里，就会被拦下来。表现是页面在加载中停住，或者直接空白。

第四个坑：地址写了多处。前面提过，但值得单独强调。同一个页面可能在首页、设置页、帮助页各有一个入口，各自写着同一个地址。改的时候只改了其中一处，于是「有的地方能打开，有的地方打不开」，这种半好半坏的状态最容易被误判成偶发问题。

四个坑里，前两个是「能不能通」，后两个是「有没有改全」。前者要在动手之前就验证：拿一台干净设备，在浏览器里打开新地址，确认能出内容；后者要在改完之后搜一遍：用旧地址的关键片段全局搜，看还有几处残留。

还有一个实践上的建议：把地址集中到一处。如果条件允许，把所有远端页面地址放到一个配置里，改的时候只改一处。这件事的成本很低，收益是「以后不会再出现漏改一处」。已经写散了的项目，也可以借这次改包顺手收拢。

六、换本地页，别只换那个 html

一个网页不是单个文件。它有样式、有图片、有字体、有脚本，这些都要跟着一起换，否则页面能打开，但长得不像样。

样式表是最容易漏的。很多人只替换了 HTML，样式还是旧的，于是新页面的结构配上旧样式，出来的效果是错位的：卡片挤在一起，标题字号不对，颜色也和新的品牌不一致。页面「能打开」和「看起来对」，是两件事。

图片要一起看。旧页面里的图可能是旧 logo、旧产品截图。只换 HTML 不换图，等于品牌换了一半。而且图片的文件名常常带哈希或者尺寸后缀，替换的时候要对着引用关系逐个确认，不能凭名字猜。

字体要特别注意。网页里的字体是单独加载的，如果新页面用了一个应用里没有的字体，表现会是「字体回退」——看起来能用，但字重、字距和设计稿不一样。更糟的情况是中文显示成方块，那就是字体文件没带上，或者声明的字体名和文件名对不上。

脚本要谨慎。网页里的脚本可能和应用之间有交互，比如关闭页面、调用支付、回传结果。换页面的时候如果把这些交互删掉了，页面本身没问题，但功能断了。这种断法很隐蔽，因为点开页面一切正常，只有走到最后一步才发现回不去。

所以换本地页的正确顺序是：先列清单，把 HTML、样式、图片、字体、脚本全部列出来；再逐个替换，保持文件名和目录结构；最后在断网状态下打开一遍，看有没有缺东西。断网这一步很关键，因为它能立刻暴露出「某个资源还在从网上拉」的问题。

还有一个细节：编码。中文页面如果保存成了错误的编码，打开就是一堆乱码。这在替换文件时很常见，因为编辑器默认编码和原文件可能不一样。替换之前先看一眼原文件的开头有没有编码声明，保存时保持一致。

七、第一个实例：协议页换成自己的，用户点开还是旧条款

我们自己维护的门店经营管理平台，做过一次合规整改：把原来指向第三方的用户协议页，换成公司自己的版本。

做法很直接：在包里找到那个网页文件，替换成新的，重新打包，装上测试。测试机上是新的，一切正常。于是发了出去。

第二天，有客户反馈：点开用户协议，还是旧的那份。我们第一反应是不可能，因为测试机明明是新的。让客户截图，确实是旧条款。

排查下来，原因是混合加载。那个页面在包里有一份本地文件作为兜底，同时每次打开会先去拉一个远端地址，拉到了就用远端的。我们换的是本地那份，而远端那份还在，所以只要网络正常，用户看到的永远是远端。测试机之所以是新的，是因为它当时连着内网，拉不到远端，走了兜底。

这个细节让整件事变得很典型：测试环境和真实环境的差异，恰好把问题藏了起来。如果测试机当时连着外网，一眼就能看到。

修法有两步。第一步，把远端那份也换掉，或者让它指向新的地址。第二步，把远端的优先级调低，让本地文件成为默认，远端只在需要更新时覆盖。第二步更重要，因为它决定了「以后再有类似改动，会不会又只改了一半」

这件事之后，我们加了一条规矩：凡是改内容型页面，验收时必须在「联网」和「断网」两种状态下各打开一次。联网看远端，断网看本地，两边都对，才算改完。一条规矩，两种状态，成本是两分钟。

八、第二个实例：帮助页指向旧域名，全部打不开

另一个实例是现场巡检端。有一次域名调整，主站从旧域名迁到新域名，应用里的接口地址跟着改了，功能都正常。

上线一周后，客服反馈：帮助中心打不开，一直白屏。我们打开一看，确实是白的。查了一下，帮助页的地址还写着旧域名。

为什么漏了？因为那个地址不在接口配置里。接口地址集中在一个配置文件里，改的时候一次就改完了；而帮助页的地址是写在某个界面代码里的一个字符串，它不在配置里，也不在资源文件里，搜「旧域名」的时候，如果只搜配置目录，就搜不到它。

更麻烦的是它的失败形态。旧域名已经停了，请求直接失败，页面白屏，没有任何提示。用户看到的是「点了一下，什么都没有」，会以为是自己网络的问题。

修起来很快：把那个字符串改掉，重新打包。但这件事暴露了两个问题。

第一个问题是「地址散落」。一个应用里的地址应该只有一处来源，不管是接口、页面、客服还是协议。散落之后，每次域名调整都会漏几个，而且漏掉的往往是最不常被点开的那些。帮助页、协议页、关于页，恰好都属于「最不常被点开」这一类。

第二个问题是「失败没有提示」。网页打不开时，界面应该给一句「页面加载失败，请检查网络后重试」，而不是一片空白。空白让用户无法判断，一句提示至少让他知道不是自己的问题。这一条和前面讲权限时的结论是同一个：可理解的失败，用户能接受。

所以我们后来的做法是：域名调整时，用旧域名的关键片段全局搜一遍整个包，包括代码、资源、网页文件、配置，把所有残留列出来逐个处理；同时给所有网页入口加一个统一的失败页。两个动作，一个治根，一个治标，缺一个都不够。

九、深色模式下，那一屏网页还是白的

应用切了深色模式，原生界面都变暗了，点开「关于」或者「帮助」，突然跳出一整屏白，刺眼。这不是网页写错了，是它压根不参与应用的深色模式。

原因很简单：网页的配色是由网页自己的样式决定的，不读应用的资源文件。应用的深色模式靠的是资源的限定符机制，而网页活在另一个体系里，两边不共享。

所以网页要支持深色，只有三条路。一是给网页单独写一套深色样式，由应用在加载时告诉它当前是深色还是浅色；二是网页自己根据系统的深色设置切换，这需要网页里写一段判断；三是干脆让网页用中性配色，比如浅灰底配深灰字，在两种模式下都不刺眼。

第三条最省事，也最容易被接受。它不是完美的深色模式，但它不会在夜里闪一下白光。对于「关于」「帮助」这类低频页面，这个折中往往就够了。

除了底色，还有三处要一起看。一是文字颜色，如果网页里把文字写成了深灰，深色底上就看不清；二是图片，白色背景的产品图在深色页面里会变成一个亮块；三是输入框和按钮，它们的边框和填充也要跟着调。

还有一个细节容易被忽略：网页加载的那一瞬间。网页控件的背景默认是白的，页面还没渲染出来的时候，用户看到的就是一块白。把控件的背景色设成和页面底色一致，能消掉这一下闪烁。这一行设置，比改一堆样式都管用。

验收的时候，深色模式这一项要单独走一遍：切到深色，依次打开每一个网页入口，看有没有闪白、有没有看不清的字、有没有变成亮块的图。三个都过，才算这一屏跟上了。

十、网页和原生之间那座桥，别改塌了

应用里的网页，很少是纯静态的。它要和外面打交道：拿到登录状态、知道用户是谁、点了按钮能返回、能上传照片。这些往来靠一座桥，桥两端各有一套约定。

桥的左边是网页。它通过一段约定的调用，向应用要东西：「给我当前用户」「关掉这个页面」「开始上传」。右边是应用。它收到请求，处理完再把结果回传给网页。

改包的时候，这座桥是最容易被改塌的地方，因为它不出现在界面上。页面还在，样式也对，只是某些按钮点了没反应。

三种常见的塌法。第一种，网页换了、桥的调用没跟着换。新的页面用了另一套调用名，应用那边还在等旧名字，于是点了没反应。第二种，应用的桥被删了。有些人觉得那几行代码是给旧页面用的，改包时顺手删了，结果新页面靠它工作。第三种，两边都改了但对不上。看起来都改对了，实际上参数顺序或者格式不一致，传过去的值是空的。

还有一种更隐蔽的：桥需要校验来源。有些实现会检查发起调用的页面地址，只允许来自特定域名或特定本地路径的调用。你把页面从远端换成本地文件，来源变了，桥就拒绝服务了。这种塌法最难查，因为页面完全正常，只是所有交互静默失败。

所以改网页的时候，要多问一句：这个页面上有没有需要和应用交互的地方？有的话，改完之后把每一个交互点都点一遍：返回、上传、提交、关闭、跳转外部。五个动作，五分钟，能避免一轮「按钮点了没反应」的投诉。

如果条件允许，最稳的做法是只换内容，不换骨架：保留原来的页面结构和脚本，只替换掉里面显示的文字、图片、配色。这样桥的部分一行不动，风险最小。只有在必须整页重做的时候，才去碰桥。

十一、验收六项：两种网络、两种模式

网页这一类改动，验收的关键在于「环境组合」。同一个页面，在四种环境下可能是四种结果。下面这六项，缺一项就等于漏一条路径。

第二项最容易被跳过。很多人验网页的时候，手机连着网，一切正常，就认为改完了。而本地兜底那份根本没被加载过——它只在断网时才出现，也恰恰是最容易出问题的一份，因为它需要所有资源都在包里。

第三项也是常被忽略的一项。弱网下最糟的体验不是打不开，是一直转圈。转圈让用户不知道要不要等，也不知道是不是自己网络的问题。给一个明确的超时提示，比加载得更快更有价值。

第五项对应的是前面说的「地址散落」。同一个页面在四个入口各有一份地址，是真实存在的情况。验的时候不要只从最常走的那条路进，把「关于」「帮助」「设置」「我的」都点一遍。

十二、七个问题，都和「这一屏打不开」有关

问题一：怎么判断一个页面是网页还是原生？看加载：有短暂白屏或进度条的，多半是网页。也可以在包里搜有没有对应的网页文件，或者搜地址。最快的办法是断网打开：断网就白屏的，一定是网页。

问题二：为什么我改了包里的网页文件，界面上还是旧的？四种可能：改错文件（有解压副本）、缓存、远端优先、装错包。按这个顺序查，十分钟内能定位。

问题三：远端页面能不能直接换成本地页面？技术上可以，把地址换成本地路径，文件放进包里。但要确认三件事：页面不需要服务端数据、页面不依赖域名校验、页面里的交互桥还认这个新来源。

问题四：页面白屏，但没有任何报错，怎么查？先分两种：断网试试，能打开说明是远端问题；打不开说明是本地资源缺失。然后看是不是明文 http 被拦、证书有问题、或者跳转被白名单挡住。

问题五：协议页必须用网页做吗？不一定。协议这类内容变化不频繁、格式简单的页面，用原生页面做反而更稳：不依赖网络、能跟随深色模式、能被搜索到。用网页的唯一好处是「不发版就能改」，如果这个好处用不上，就没必要。

问题六：网页里的中文显示成方块怎么办？字体没带上，或者声明的字体名和文件名不一致。先确认字体文件在包里，再确认样式里的字体名拼写对得上。两步都能查出来。

问题七：换网页会不会影响应用体积？会，但通常不大。一个纯文字的帮助页连同样式和图片，一般只有几百 KB 到一两 MB。需要注意的是图片：如果把十几张未压缩的大图塞进去，体积会明显变大，而这种变大完全可以避免。

十三、一次返工的账：两分钟能验的事，花了两天解释

把第七节那个协议页的事故算一遍账，比例很有意思。

修复成本：十分钟。找到远端那份换掉，重新打包。排查成本：一天。怀疑过缓存、怀疑过没装上、怀疑过客户看的是别的入口，最后靠对比断网和联网的显示差异才定位。解释成本：一天。因为协议页涉及合规，客户很在意「你给我的到底是不是有效版本」，需要出具说明。

三笔加起来两天多，而如果验收时多做一件事——断网打开一次——整件事不会发生。这一件事的成本是两分钟。

这就是这一类问题的成本结构：验证的成本极低，漏掉的代价极高。因为网页的加载路径有分叉（本地/远端），而默认路径往往是最常走的那条，测试时自然也走那条。漏掉的分支不是难验，是想不到要验。

后来我们把这条经验变成了一个固定动作：凡是网页类的改动，验收单上必须有两行——「联网打开，显示正确」「断网打开，显示正确」，并且写清在哪个入口验的。没有这两行，验收不算完成。

这件事还有个副产品值得说。它让我们意识到「环境差异」是一类系统性的漏测来源。不止网络，还有深色模式、不同的系统版本、不同的屏幕尺寸、有没有登录。每一项都是一条分支，而默认状态永远只覆盖其中一条。把「分支清单」写下来，比每次靠记忆去想去要可靠得多。

十四、本地页还是远端页，五条判断

改包时经常会遇到一个选择题：这一屏内容，放本地还是留在远端？答案不是「哪个先进」，而是看五件事。

第一，内容多久变一次。一天一变的活动页，必须放远端，否则每次改都要发版；一年不变的关于页，放本地更稳，因为它不会有证书、域名、网络这些问题。

第二，断网时要不要能看。协议、帮助、常见问题这类内容，用户很可能在没网的时候想看一眼。放本地，断网也能打开；放远端，断网就是白屏。这一条往往比第一条更重要。

第三，内容是否涉及合规。用户协议、隐私政策这类页面，一旦打不开就是合规问题。本地有一份兜底，等于多一层保险。哪怕平时走远端，本地那份也必须存在且是最新的。

第四，包体积能不能接受。纯文字的页面很小，几十 KB；带图带视频的页面可以到几十 MB。纯文字放本地，重内容放远端，这是最常见的组合。

第五，谁来维护。如果内容由运营维护，他们不会改包，那只能放远端；如果内容由开发维护，改动随版本走，放本地更省事。这一条决定了长期成本，比技术因素更现实。

五条判断合起来，会得到一个很常见的结论：协议和帮助放本地，活动和公告放远端，其余按体积和维护方决定。这个结论既不新奇也不复杂，但它能避免「全都放远端」导致的一批白屏，也能避免「全都放本地」导致的每次改文案都要发版。

十五、把「把那几个页面换掉」写成一句能执行的话

「改包的时候顺手把帮助和协议页也换一下」——这句话谁听了都会点头，但没人知道该换哪几个、换到什么程度。

一句能执行的话：这次换皮涉及四个内容型页面：关于、帮助、用户协议、隐私政策；四个页面在包里都有本地文件，路径分别是各自的目录，文件名保持不变；每个页面的样式、图片、字体一起换，字体沿用包里已有的那一份，不新增；换完把四份都设成本地优先，远端地址暂时关掉；验收时联网打开、断网打开各一次，再从「我的」和「设置」两个入口各进一次，确认四个页面显示的都是新内容。

这句话里有五个必须写清的点。第一，哪几个页面，写具体名字，不要写「相关页面」。第二，文件在哪、叫什么，写清路径，避免改错副本。第三，换到什么程度，样式和图片一起换，还是只换文字，差别很大。第四，优先级怎么定，这是决定「改了会不会生效」的关键。第五，从哪几个入口验，因为同一页面可能有多个入口。

还可以加一条：「如果某个页面是远端加载，先确认它能不能换成本地。」这一步经常能省掉后面一堆问题——本地文件不会证书过期、不会被网络策略拦、不会因为对方停服而白屏。

我们内部现在的做法，是把这类需求写成一张小表：页面名、当前加载方式、要改成什么、验证入口。四列，五行，写起来十分钟。但它把「顺手改一下」变成了一件有边界的事。

十六、网页里的图片，比文字更容易漏

换文字容易，因为文字能被搜索到。换图片难，因为图片里有没有旧品牌，搜索是搜不出来的。

一个内容型页面里，图片往往出现在四个位置。一是页头的 logo；二是文中的配图，比如产品截图、门店照片；三是页脚的二维码，很多应用在关于页放一个「关注我们」的二维码，扫出来是旧主体的公众号；四是分享卡片图，页面被分享出去时显示的那张缩略图。

第四个最容易被忘，因为它不在页面里。它通常写在一段页面头部信息里，指向一个图片地址，用户点开页面看不到它，但一分享出去就出现了。所以「页面看着都换了，分享出去还是旧 logo」这种情况非常常见。

还有一类更隐蔽：文字型的 logo。它看着像图片，其实是字体渲染出来的文字，或者是用样式拼出来的。这类 logo 无法靠换图解决，要去改文字或者改样式。反过来，图片型的 logo 看着像文字，其实是一张图，搜索文字也搜不到。两种情况都要靠肉眼过一遍，不能只靠搜。

尺寸也是个小坑。同一张 logo 常常有多个尺寸的版本，分别给不同分辨率的屏幕用。只换了其中一个，在高分屏上看到的还是旧的那张。替换时把同名的几个版本一起换掉，比事后追查快得多。

所以换网页里的图，最可靠的办法是把页面完整地看一遍，从上到下、从左到右，看见图就停一下，问一句「这张图里有没有旧品牌」。这个过程五分钟，比搜十次字符串有效。

我们内部现在的做法是：换皮验收时，让一个没参与改动的人打开页面，只看图不看字，指出所有还带着旧品牌的地方。不参与改动的人没有「我已经改过了」的心理预设，往往一眼就能看到当事人看不见的那几张。

十七、三句话，把这件事收住

第一句：应用里那些看起来像页面的东西，很多是网页，它们不在资源文件里。所以改名字、改配色的时候搜不到它们，必须按网页的路径去找：包里有没有网页文件，有没有写死的地址。

第二句：本地页换文件，远端页改地址，混合页两样都要改，还要想清楚谁优先。三条路的成本差别很大，混着做必然出错。而「改了不生效」的原因，永远在这四种里：改错文件、缓存、远端优先、装错包。

第三句：网页的验收要看环境组合，不是看一次打开。联网一次、断网一次、深色一次、每个入口一次、每个交互点一次。少验一条分支，就多一次「用户那里打不开」。

三句合起来是一件事：网页是应用里的一块飞地，它跟外面共享屏幕，但不共享规则。知道这一点，改包的时候就不会漏掉它，也不会用原生页面的思路去改它。

十八、附：一页速查

下面这张表把全文压成八行，改到网页类页面的时候可以对着看。

最后补一句：上面这些动作，最好和改包放在同一条流程里。改完网页、回编、对齐签名、真机预览，一次走完，比改一半再回头找要稳。安卓修改大师智改工坊把这些环节收在一次操作里，产品介绍页在 这里。

十九、用过的人怎么说

这一篇里的两个实例，都是我们自己维护的应用：一个门店经营管理平台，一套现场巡检端。网页这类界面的麻烦之处在于它「看起来是应用的」，所以改包时很容易被当成原生界面去找，找了一圈没有，就以为不用改。文中的三种住法、三条改法和六项验收，都是为了把这个盲区补上。

合规提醒：本文所有实例均针对自有版权或已获授权的应用，用于企业内部维护、白牌交付与合法定制。替换页面内容时，请勿移除或伪造用户协议、隐私政策等法定告知内容，也不要用他人页面冒充自有内容。改包前请确认你对目标应用拥有相应权利。

一个应用里最不常被点开的页面，往往是最需要认真对待的页面。因为用户点开它的时候，通常是在找答案，而不是在逛。

安卓修改大师智改工坊能做的，是把改包之后那一串动作一次落到位：换文件、回编、对齐签名、真机预览，改完当场就能联网断网各看一遍。说清楚，就够了。