企业官网建设流程全解析

上周一个朋友把手机截图甩过来，通知栏里挂着一条常驻通知，标题写着“Android 11 性能受到影响，要停用”，点进去又看到一句“请查看引导加载程序通知”，下面还跟着一个“停用”按钮。他的第一反应是：我是不是装了什么流氓软件在偷偷改我系统？第二反应是：这按钮到底能不能点？我让他先把手机放下，只用“看”的方式处理，别急着点那个按钮——因为这句话实际上不是一个问题，而是三个完全不同层级的提示被硬塞进了同一行文字里。搞混了层级，你就只能靠猜；分清层级之后，你会发现它能干什么、该不该停用，答案其实很明确。

这篇东西聊的就是这类场景：Android 11 设备上出现引导加载程序相关的常驻通知，以及其中那句容易让人心跳加速的“性能受到影响”。我尽量不讲空话，把通知的来源、系统完整性校验的链路、被降级的具体功能、以及“停用”之后的真实代价一条条拆开，方便你自己判断，而不是听谁一句“关了没事”就把按钮按下去。

1. 一条常驻通知里其实塞了三个互不相干的问题

1.1 “Android 11”出现的原因只是背景板

很多人看到通知里有系统版本号，第一反应就是“Android 11 的 bug”。这里得先泼盆冷水：Android 11 在这条通知里大概率只是环境信息，不是原因。Android 从 7.0 开始就引入了比较完整的启动完整性校验框架，到 Android 11（API 30）时，这套框架的可见提示做得更“啰嗦”了一些，尤其是对引导加载程序状态、块设备校验状态的表达，会通过系统服务以通知或弹窗的形式暴露给用户。

也就是说，如果同一台手机停在 Android 10 上，你未必会看到这么直白的一行字；升到 Android 11 之后，系统把原本藏在日志里的状态搬到了通知栏。它的变化不是“Android 11 让你的手机变慢了”，而是“Android 11 变得更愿意告诉你，你的手机现在的完整性校验状态是什么”。

这个区别很关键。把它当成“系统版本导致的性能问题”，你会去翻开发者选项、去关动画、去删后台，折腾一圈什么都没解决；把它当成“系统在向你汇报一个校验状态”，你才会去查引导加载程序、查验证模式，然后对症下药。

1.2 “性能受到影响，要停用”到底是谁在劝你

这句话的主语是被省略的，所以读起来特别吓人。补全之后大概是：某个组件或某项校验机制，现在处于“被停用”或“待停用”的状态，而这种状态可能会让设备的部分能力受到限制，是否要停用（或确认停用）？

这里有两种截然不同的语境，我可以靠一个小动作区分：看这句话出现在哪里。

第一种是系统框架的通知，出现在通知栏，通常带一个应用图标（可能是“系统”或者“设置”），点进去会跳到某个设置页面。这类通知的主语一般是系统服务，比如完整性校验相关的守护进程、验证服务、或者设备状态管理模块。

第二种是你手动操作时弹出的确认框。你在“设置 - 应用”里对一个系统组件点了“停用”，系统会弹一个二次确认，类似“停用此应用可能导致其他应用无法正常工作”。这种情况下，“性能受到影响”是系统在给你踩刹车，提醒你别乱停。

这两种情况处理方式完全不同：前者是“系统在报告状态”，你要做的是判断状态是否合理；后者是“你正在做危险操作”，你要做的是想清楚代价。很多人吃亏就吃亏在这里——把系统的状态汇报，当成了系统的求助信号，然后真的去把某个组件停用了。

1.3 “请查看引导加载程序通知”是系统塞给你的指路牌

这句话的措辞很有意思，它没解释原因，只给了一个指向：“去看引导加载程序那条通知”。这说明系统内部把这两个提示拆成了两条独立通知，一条是正文提到的这条（性能 / 停用相关），另一条是关于引导加载程序状态的。

系统的逻辑大概是这样：设备当前处于一个“完整性无法被验证”的状态（常见触发原因就是引导加载程序被解锁或被改写过），基于这个状态，某些依赖验证结果的功能会进入降级或待停用状态。第一条通知负责告诉你“有东西被降级了”，第二条通知负责告诉你“为什么被降级”。

所以正确的阅读顺序是：先去看引导加载程序那条通知，把根因搞清楚；再回头看这条“性能受到影响”的通知，判断它影响的是哪些具体能力。反过来读，你只会看到一个吓人的结论，却找不到原因，最后只能诉诸玄学。

提示：任何一条明确提到引导加载程序（bootloader）、验证状态、完整性校验的系统通知，都不建议在没搞清楚来源前直接点“停用”。停用按钮解决的是“提示”，不是“状态”。

2. 引导加载程序解锁之后，系统实际丢掉的不是算力

2.1 从开机第一屏到 vbmeta：完整性校验是怎么走的

要理解这条通知，得先知道 Android 开机时那几秒钟发生了什么。简化成一条链路就是：引导加载程序先验证下一级引导程序，再验证内核和分区表，然后由 vbmeta（验证启动元数据）分区里的描述符，去校验 system、vendor、boot 这些关键分区的哈希值是否和官方签名一致。整条链路通过之后，系统才会把设备标记为“受验证启动”状态。

这个状态在系统里是可以读出来的，几个关键属性大致是：

orange就是绝大多数“解锁过引导加载程序”的设备所处的状态。这个状态下系统不会阻止你开机，但它会非常诚实地告诉每一个来查询的组件：我这台机器的完整性，我证明不了。

而“证明不了”这三个字，就是后面所有降级行为的源头。

2.2 dm-verity 与 IO：那句“性能受影响”最容易被误读的地方

这里要重点讲一个特别容易被误读的点，因为它直接关系到“性能”两个字。

Android 的块级完整性校验（dm-verity）做的事情是：在读取系统分区数据块的时候，顺带算一遍哈希，和预先存好的校验树对比。这是读取路径上的额外计算，所以它确实会给存储 IO 带来一点开销。开销大小取决于设备闪存速度和 CPU，通常在个位数百分比，日常使用基本感觉不到，但在大文件连续读取这种场景下能测出来。

于是就有了一个流传很广的说法：“关掉 dm-verity，IO 会变快。”这个说法在纯数值层面不假，很多第三方方案也确实是这么做的。但代价是：块级校验整个链路失效。系统一旦发现校验被关闭，会把它记录下来，并影响后续一系列依赖完整性的能力。

更有意思的是反过来的情况。有些设备在解锁引导加载程序之后，会触发分区结构或校验路径的变化，导致系统在某段时间里的 IO 表现确实不如锁定状态。这种差异在分区块随机读写上偶有体现，原因通常不是“解锁让闪存变慢”，而是校验路径、分区映射方式或者厂商的调度策略发生了变化。

所以“性能受到影响”这句话，最可能指的是这三层意思中的一层：一，校验机制本身的开销发生了变化；二，因为校验状态异常，某些功能被系统主动降级；三，系统在提醒你，如果你继续停用某个组件，会导致更多功能不可用。至于是哪一层，得靠后文的实测和定位来判断，不能靠猜。

2.3 真正被降级的是受保护通路，不是算力

把话说明白：解锁引导加载程序不会让你的 CPU 降频，不会让你的 GPU 少算几个三角形，也不会让内存变慢。它是软件层面的状态变化，不碰硬件频率。

用户能感知到的“变慢”，绝大多数来自这几条受保护通路的降级：

• 受保护内容的高清播放通路。部分流媒体应用在检测到设备完整性无法验证时，会主动降到较低清晰度档位。画质下降会被很多用户描述成“变卡了”“变模糊了”。
• 支付类应用的风控校验。这类应用通常会在启动时做一轮设备状态检查，检查不通过时会限制部分功能，或者反复弹验证。用起来就是“怎么老是要我验证一遍”。
• 部分游戏的画质与帧率档位。一些手游会在启动时读取设备状态，据此决定画质档位和帧率上限。注意，这不是“性能不够”，是“策略上不给”。
• 通知通道的优先级降级。这一点很多开发者踩过坑：厂商推送通道在消息下发前后会走一轮签名校验，如果设备状态异常导致校验降级，消息仍然能到，但可能从悬浮通知降级为普通通知栏消息，甚至延迟到达。用户感知就是“消息怎么不弹了”。

把这四条放一起看，你会发现它们有一个共同点：**都不是算力问题，都是信任问题。**系统或应用在“无法确认这台设备是否可信”时，选择了保守策略。而通知里那句“性能受到影响”，是对这堆保守策略的一个非常粗糙的概括。

3. 动手之前先定位：把这条通知的出处揪出来

3.1 不装任何工具的三条反查路径

在处理之前，先把“是谁发的”搞清楚。三条路径，从最简单到最彻底：

1. 长按通知。Android 11 长按通知会展开通知渠道信息，能看到应用名和渠道名。渠道名往往非常有信息量，比如“设备状态”“系统完整性”“安全提示”这类字样，基本就能确定来源范围。
2. 点通知里的“设置”图标（齿轮）。会直接跳到该通知对应的渠道设置页，页面顶部会显示应用名。如果应用名是“系统”“设置”“系统服务”，说明是框架层发的；如果是某个具体应用的包名，那就是那个应用自己发的。
3. 进“设置 - 应用”，打开“显示系统应用”，然后按最近使用时间排序，看有没有你不认识的系统组件在后台活动。这一步只能做粗略筛查，别在这条路径上做删除操作。

三条路径都走完，你大概率已经知道这条通知是系统框架发的，还是某个具体应用发的。这个结论决定了后面所有的处理方式。

3.2 adb dumpsys notification 的实战用法

如果想看得更彻底，adb 是最省事的办法。把通知服务的完整状态 dump 出来，能直接看到每条通知对应的包名和通知渠道 ID。命令大概是这样：

# 把通知服务状态导出到电脑本地文件，方便搜索 adb shell dumpsys notification --noredact > notif.txt # 在文件里搜关键字，找到对应记录 grep -n "引导\|性能\|bootloader\|integrity\|verity" notif.txt # 只想快速看当前活动通知的精简列表 adb shell dumpsys notification --noredact | grep -E "pkg=|channelId=|NotificationRecord"

--noredact这个参数很关键，不加它部分字段会被打码，你搜不到内容。另外不同厂商对 dumpsys 输出做过裁剪，个别机型上字段名可能不一样，但pkg=和channelId=这两个基本都在。

拿到包名之后，顺手确认一下这个包当前是启用还是停用状态：

# 查看指定包的启用状态 adb shell dumpsys package <包名> | grep -i "enabled\|stopped\|suspended" # 列出所有被禁用/停用的包，对照看它有没有在里面 adb shell pm list packages -d

这两条命令组合起来用，能帮你判断“这个组件已经被停用了吗”，还是“它正在正常工作，只是发了条通知”。别小看这个区别，很多人以为自己停用了，其实压根没成功，然后一直在错误的方向上排查。

提示：pm disable-user这类命令会改变系统状态，执行前务必确认包名。停用错了组件，轻则功能异常，重则无法进入系统桌面。不确定的时候，先备份，再动手。

3.3 常见来源与对应含义对照

下面这张表是我在实际排查中见过最多的几类来源，列出来方便对照。注意，不同厂商、不同机型的命名会有差异，包名只是参考，重点是它在系统里承担什么职责。

判断顺序建议是：先看包名是不是系统框架或厂商安全组件，再看通知渠道名是不是和完整性、设备状态相关，最后才考虑是不是第三方应用在“蹭词”。第三类和第四类的处理方式完全不一样，前者需要理解状态，后者直接关掉就行。

4. “停用”按下去之后，代价清单一览

4.1 可以放心停用的：只影响提示本身

有一类东西是可以放心处理的：纯粹的提示载体。比如某些厂商在系统里加的通知转发组件，它只负责把系统状态包装成一条更好看的通知，停用它不会改变底层的校验状态，只会让这条提示消失。

判断方法：停用前后，去看那几个关键属性有没有变化。

adb shell getprop ro.boot.verifiedbootstate adb shell getprop ro.boot.veritymode adb shell getprop ro.boot.flash.locked

如果停用之后这几个值没变，说明你停的只是“喇叭”，不是“报警器”。这种情况风险可控。

但要提醒一句：有些厂商会把提示和功能耦合在同一个组件里，停用之后提示没了，某个功能也顺带没了。所以停用之后，最好把常用的几个功能都点一遍——尤其是支付、视频播放、系统更新检查，确认没被牵连。

4.2 不能停的：停了之后 OTA 与支付一起崩

下面这几类，我的建议是不要动：

• 系统更新相关组件。完整性校验状态和系统更新是强耦合的。校验链路断了之后，OTA 包在下载或安装阶段就可能被拒绝，表现为“检查更新失败”“下载后无法安装”。更麻烦的是，有些设备在状态异常时会把更新通道整个降级，你连更新包都拿不到。
• 完整性校验服务本体。停用它，系统确实不报警了，但所有依赖校验结果做决策的应用会进入“结果未知”状态。不同应用对未知状态的处理策略不同，有的直接拒绝启动，有的反复弹验证。最后你会得到一台“不报警但到处提示”的手机。
• 安全元数据相关服务。这类组件一旦被停用，受保护内容的播放通路基本就废了，视频降清晰度是常态。
• 厂商推送通道的系统组件。停用它，你的消息推送可能直接延迟或丢失。这个问题在开发者那边特别常见，用户端看到的是“这应用怎么不推消息”，其实是被自己顺手停用的组件干掉了。

我个人的判断标准很简单：**如果某个组件的名字里带“校验”“验证”“完整性”“安全”“更新”这几个词，默认不动。**这些组件存在的意义就是做判断，停掉判断本身，并不会让世界变得更好。

4.3 想清净又不破坏功能的三种折中做法

如果你只是不想看见这条常驻通知，又不想破坏功能，有三条折中路线，按侵入性从低到高：

**第一条是关通知渠道，不停组件。**进“设置 - 应用 - 对应应用 - 通知”，把那条常驻通知所在的渠道单独关掉。组件功能还在，只是不打扰你。这是我最推荐的做法，几乎零风险。

**第二条是降低通知优先级。**部分系统支持把通知设为“静默”或“不显示在状态栏”，只保留在下拉列表里。这样你既知道它还在，又不会被它打扰。Android 11 的通知渠道体系对这类控制支持得挺细，值得花两分钟调一调。

**第三条是接受现状，把根因处理掉。**如果你确实需要完整性校验通过的状态，那就得回到引导加载程序层面处理——重新锁定引导加载程序，或者把设备恢复到官方状态。这条路的代价是所有非官方改动可能失效，操作前必须确认自己的数据备份是否完整。

三条路线里，第三条是唯一能真正让通知消失的，前两条只是让它不吵你。选哪条，取决于你为什么要解锁引导加载程序。如果只是当年为了玩某个功能解的锁，现在早就不用了，那第三条划算；如果设备本来就跑在非官方状态上，那老老实实走第一条。

5. 性能到底掉没掉：一次可复现的对比测试

5.1 别用娱乐跑分，盯这四个指标

“性能受到影响”这句话，最容易引发无意义的跑分对比。我的经验是，整机跑分对这类问题几乎没有参考价值，因为跑分测的是算力上限，而这条通知影响的是策略和通路。真正值得盯的是这四个：

1. 应用冷启动耗时。用am start -W就能拿到，数值稳定，重复性好，是最直观的“日常变没变慢”指标。
2. 滚动掉帧率。用dumpsys gfxinfo拿 janky frames 占比，反映的是渲染流畅度，跟 IO 和调度策略的变化关系很大。
3. 存储顺序读写速度。这是唯一可能被校验机制直接影响的指标，值得单独测一轮。
4. 待机电流。用dumpsys batterystats观察，校验机制、后台服务状态变化有时会体现在功耗上。

这四个指标覆盖了“用户能感知的慢”和“机制层面的开销”，比跑分靠谱得多。

5.2 用几条 shell 命令搭一个最小基线

先测冷启动。要点是每次都强制停止应用，保证是冷启动：

# 冷启动并输出耗时，重复 5 次取中位数 for i in 1 2 3 4 5; do adb shell am force-stop com.example.app adb shell am start -W -n com.example.app/.MainActivity | grep TotalTime sleep 3 done

TotalTime是这次启动的总耗时，包含进程创建、Application 初始化、首帧绘制。对比时一定用同一个应用、同一条路径、同样的等待间隔，否则数据没有可比性。

再看渲染：

# 重置统计，滑动几屏，再读取掉帧数据 adb shell dumpsys gfxinfo com.example.app reset # 手动在手机上滑动 10 秒左右 adb shell dumpsys gfxinfo com.example.app | grep -A3 "Janky frames"

Janky frames会给出掉帧数量和百分比，这个数字比任何“感觉”都可靠。

最后是 IO：

# 顺序写入测试，写入 512MB 并强制落盘 adb shell "time dd if=/dev/zero of=/data/local/tmp/t.bin bs=1M count=512 conv=fsync" adb shell rm /data/local/tmp/t.bin # 顺序读取测试 adb shell "time dd if=/data/local/tmp/t.bin of=/dev/null bs=1M count=512"

如果设备上的 shell 没有time命令，可以用两次date +%s前后取差，秒级精度对几百 MB 的读写来说够用了。测试前记得确认存储空间并且测完删掉临时文件。

5.3 实测结论与两个常见误判

我在几台不同机型上做过这类对比，结论比较一致：

**冷启动和掉帧率基本看不出差异。**同一应用在锁定状态和解锁状态下，冷启动耗时差异通常在误差范围内波动，掉帧率也没有稳定可复现的差别。这说明“算力”确实没被影响。

**IO 差异存在但很小，而且方向不一定。**在部分机型上，解锁后顺序读取略有变化，但幅度通常在个位数百分比，且不同机型方向不一致。指望靠“关掉校验机制”换来明显 IO 提升，实测里我没见过。

**真正稳定的差异在功能可用性上。**受保护内容播放、支付类应用的验证行为、部分游戏的画质档位，这些在两种状态下的差别是肉眼可见且百分百可复现的。这才是那条通知想表达的东西。

两个常见误判要特别提醒：

• **误判一：把“应用主动降级”当成“手机变慢”。**视频降清晰度、游戏锁帧率，这些是策略选择，不是性能下降。你可以通过对比同一网络下的清晰度档位来验证。
• **误判二：把“刚解锁那段时间的异常”当成常态。**引导加载程序状态刚发生变化后，系统可能在做一次全量校验或重建索引，这段时间的 IO 和功耗会偏高。等一两天再测，数据往往就回到正常水平了。

6. 三类人的处理路线

6.1 只想安安静静用手机的

这类用户的核心诉求是：别吵我，功能别坏。那你的路线就是关通知渠道，不动组件。

具体操作是：长按那条常驻通知，进入通知设置，把对应渠道关掉或设为静默。然后去“设置 - 应用”里确认没有任何系统组件处于“已停用”状态（尤其注意“显示系统应用”之后的列表）。如果发现有人替你停用过某个组件，能恢复的尽量恢复。

还有一件事值得做：检查开发者选项里有没有被改过的开关，尤其是和“验证”“完整性”“后台限制”相关的。很多时候通知不是自己冒出来的，是早前某次折腾留下的状态。

至于那句“性能受到影响”，对这类用户来说最实际的判断方式是：日常用起来卡不卡？视频能不能正常高清播放？支付有没有频繁失败？三个都没问题，就别去折腾了。

6.2 解锁过 BL 的爱折腾用户

如果你明确知道自己解锁过引导加载程序，那这条通知就是系统在给你做状态汇报，不存在“处理掉它”的选项，只有“接受它”和“消除根因”两条路。

接受它，就是按上一节的方式关掉通知渠道，同时把这几个属性记在心里，遇到应用异常时先查它们：

adb shell getprop ro.boot.verifiedbootstate adb shell getprop ro.boot.veritymode adb shell getprop ro.boot.flash.locked

消除根因，就是重新锁定引导加载程序或恢复官方状态。操作之前必须确认：数据备份完整、当前系统与应用版本能对上、知道怎么在异常时进恢复模式。这条路的风险不在于操作本身，而在于很多人备份做得不完整，恢复之后才发现某些应用的本地数据没了。

我个人建议是：**在解锁状态下，把“受保护内容无法高清播放”和“部分应用需要额外验证”当成已知前提，而不是故障。**心态摆正了，你才不会每天去跟这条通知较劲。

6.3 做应用和推送通道的开发者

最后一类人是从开发视角看这件事的。如果你的应用有推送、有设备风控、有内容保护需求，那这个状态你必须处理。

推送这块最典型的坑是：设备完整性校验状态异常时，消息下发前后的签名校验可能走降级路径，结果就是消息仍然送达，但从悬浮通知变成了普通通知，或者被延迟批量下发，甚至点击通知无法跳转到指定页面。用户端反馈是“你们推送有问题”，实际上是设备状态导致的通道差异。

我的建议是三条：第一，推送到达之后做一次本地校验，确认关键字段完整，不要假设通道一定按最高优先级送达；第二，通知点击跳转的目标页面要做兜底，收到无法识别的参数时给一个合理的默认页，而不是白屏；第三，在日志里把这个状态标记出来，排查问题时能一眼看出是不是设备侧的原因。

另外，做设备风控时不要把“完整性不可验证”直接等同于“恶意设备”。这个状态在正常用户里也有一定比例，一刀切拒绝会伤到真实用户。更稳的做法是分级处理：低风险场景放行，高风险场景增加一次验证，而不是直接封功能。

最后分享一个我自己踩过的坑。我最早遇到这类通知时，第一反应是去开发者选项里找开关，翻了一圈没找到，又去装了各种“系统优化”类应用，结果通知没消失，反而多装了几个常驻后台的东西，续航明显变差。后来才明白，这条通知压根不是靠“优化”能解决的，它是系统在校验链路走不通之后给出的一个诚实结论。

现在的做法是：看到这类提示，先花五分钟把来源查清楚，再看它影响了哪几项具体能力，最后才决定是关通知、停组件，还是动根因。绝大多数情况下，关掉通知渠道就够了——你要的是不被打扰，不是让系统失去判断能力。手机这东西，报警器响的时候，先看看是哪里在冒烟，别急着把报警器拆了。