一台给孩子上网课的小新 Pad Plus 卡到想换：TB-J607F 系统体检与精简实录

家里这台联想小新 Pad Plus（TB-J607F）是给孩子上网课、平时用微信的。6GB 内存，按理说不该卡，但最近的情况是：开个相机要等两三秒，切回微信经常白屏重载，孩子上着课喊着「卡了」。

最初的念头很直接——9008 线刷，降回 ZUI 12.6。后来花了半个晚上做体检，结论变了：这台机器根本不需要刷机，问题不在系统版本上。最后全程只用 ADB 做完，可用内存从 1.17 GiB 回到 2.63 GB，顺手还从 81GB 存储里挖回了 14GB。

记录一下，顺便把几个差点踩进去的坑写清楚。文末还附了一段跟精简本身没什么关系的插曲——给孩子找一个能用的 ChatGPT——因为那才是这台机器真正把我耗到半夜的地方。

一、先说结论：这台机器不该刷机

想刷机的理由很朴素：「新系统拖老硬件，降回老版本就快了」。但查完这台机器的状态，这条路性价比极低：

ro.boot.flash.locked       = 1        （BL 已上锁）
ro.boot.verifiedbootstate  = green    （官方未篡改）
ro.boot.veritymode         = enforcing
ro.boot.vbmeta.device_state= locked

三层原因：

1. BL 是锁的，而且是「干净」的锁。 verifiedboot 是 green，说明 boot 分区没被改动过。这台机器将来要保修、要送修，这个状态是有价值的——刷机等于把它换成一个 9008 的未知状态。
2. 跨大版本回退有 ARB 风险。 TB-J607F 出厂是 ZUI 12.6（Android 11），现在跑 ZUI 14（Android 12）。从 12 降回 11 属于跨大版本回退，遇到防回滚（anti-rollback）就是硬砖，而且 9008 包必须严格匹配国行版本，海外包不能混用。
3. 最关键的：卡顿的根因不在系统版本。 我拿到数据之后发现，这台机器是「31 天没重启 + 一批被系统白名单强制常驻的垃圾后台」，不是「ZUI 14 太重」。刷机解决不了这两件事。

所以方向定为：免刷机的 ADB 深度精简 + 冻结系统更新，9008 作为兜底但基本用不上。

二、确认机器的底子

接上 ADB 先读设备信息，这些数据后面判断「该不该动」都要用：

型号      Lenovo TB-J607F / product: LenovoTB-J607F_PRC
系统      ZUI 14.0.428 / Android 12 / SDK 31
构建      TB-J607F_CN_OPEN_USER_Q00012.0_S_ZUI_14.0.428_ST_230411（2023-04-12）
内存      MemTotal 5,598,928 kB ≈ 5.34 GiB（标称 6GB）
存储      /data 共 104G，已用 81G，剩 23G（79%）
开机时长  31 天 1 小时

顺手把电池也查了，因为「卡」有时候是电池老化导致的降频：

满电容量  6961 mAh / 设计 7701 mAh ≈ 90.4%
循环次数  191
health    2（良好）
温度      24.4°C

这一项直接排除了硬件嫌疑。 90% 的健康度、191 次循环，电池才刚到中年，卡顿跟它没关系。如果这里显示 70% 出头，那思路就得完全换一套。

三、环境准备：Windows 上的两个坑

电脑上没有 adb，用 winget 装官方的：

winget install --id Google.PlatformTools --accept-source-agreements --accept-package-agreements

装完会有两个坑：

坑一：PATH 不会立刻生效。 安装器写了环境变量，但当前这个 shell 读不到，adb 依然「不是内部或外部命令」。要么重开终端，要么直接用绝对路径：

%LOCALAPPDATA%\Microsoft\WinGet\Packages\Google.PlatformTools_*\platform-tools\adb.exe

坑二：PowerShell 执行策略是 Restricted。 我写了个 .ps1 采集脚本，双击跑、命令行跑都直接退出、连报错都不给（exit code 1，零输出），一开始以为是脚本写错了。真相是被执行策略拦了。用进程级放行，只影响当前进程、不改系统设置：

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

插上没反应，先别怀疑驱动

第一次插线，adb devices 是空的。注意这里有个重要的区分：

• 显示 unauthorized → 线是通的，只是没点「允许」，去平板点弹窗
• 什么都没有，且设备管理器里也找不到 Android 设备 → 电脑压根没看见它，问题在物理链路

我当时是第二种。查了 Windows 的设备枚举，USB 上只有键鼠、蓝牙适配器和集线器，一个 Android 接口都没有。这种时候换驱动是白费功夫，按命中率排：换数据线（最常见，很多线只有电源针脚）→ USB 用途选「传输文件」而不是「仅充电」→ 关掉再打开 USB 调试 → 直插主机后置口别过 Hub。

这台最后就是换了根线就好了，插上立刻出现 unauthorized，平板上点「一律允许」即可。

四、体检：三个数字决定了方向

真正让我改变主意的，是这三个数：

MemAvailable   1,226,048 kB ≈ 1.17 GiB（占总量 21.9%）
Swap 已换出    2,029,772 kB ≈ 1.94 GiB
ZRAM 物理占用  662,156 kB

6GB 的机器只剩 1.17 GiB 可用，而且 3GB 的 swap 已经用掉三分之二，ZRAM 实打实压了 662MB 物理内存——这是典型的长时间不重启导致的堆积，不是内存泄漏。

然后用 ps 看谁在吃内存，结果很反直觉：

微信其实是冤枉的。 它只有个 0.6MB 的推送进程在跑，真正的大户是 QQ（103MB）、夸克（53MB）和联想自己那几个后台。

还有个细节值得记：dumpsys deviceidle whitelist 里，bugtogo、xlog、sdac、uface 赫然在列。进了这个白名单的包，系统不会让它休眠，等于强制常驻。这类包清掉的收益，比清普通应用高得多。

五、清预装：哪些能停，哪些千万别动

原则和清手机预装一样：pm disable-user --user 0，用户级停用，不碰系统分区，随时可恢复。

A 档：纯后台，零功能损失

B 档：第三方预装

Vivaldi、网易云音乐、酷安、Google Earth、Trello、ChatGPT、Synology DS video、OPlayer、hhvideo、微软远程桌面——这些都是可以停的第三方预装。

但要保留的也有一批：应用商店（停了好歹装不了软件）、Sketchbook（画画）、Office 的 OneNote 和 OfficeHub（看课件）。

补一句后话：这份清单后来动过两次。com.vivaldi.browser 和 com.quark.browser 都在里面，但清完才发现，这台机器上能打开 ChatGPT 网页版的只剩 Vivaldi，夸克又得留着给孩子扫题——两个最后都从脚本和 manifest 里撤了出来，改成用 appops 限制后台。原因写在第十一节。

⚠️ 三个差点犯的错

这三个是这次最有价值的教训，比清掉多少包重要：

1. 差点把默认输入法停了。 com.baidu.input 在预装列表里看着就像冗余，但 settings get secure default_input_method 显示它就是当前默认输入法。停了孩子直接打不了字，而且很多精简教程会漏掉这条。判断方法很简单：先查默认输入法是谁。

2. 差点把教育 App 当预装清了。 com.gkid.crazyrope、com.drpanda.chineseacademy.b2b、com.tiantianlexue...、com.weicai.mokaoMasterPro、com.tal.publish.book、com.putao.block.cn 这些名字看着都像垃圾包，实际上全是学习类应用，很可能是孩子正在用的。名字长得像广告 SDK 的教育 App，一个都没动。

3. 安全中心和天骄学堂是红线。 com.zui.safecenter（安全中心）停了会导致权限管理和开机异常；com.lenovo.lfh.tianjiao.tablet 是天骄学堂本体，正是孩子上课用的东西。这两个连碰都不碰。

顺便说个反直觉的点：「平行视界」在 ZUI 14 是 framework 层能力（ActivityEmbedding），根本没有独立包名。 我一开始担心停掉某个包会毁掉分屏，查完发现压根不存在这个包，不用担心误伤。

六、可逆性比精简本身更重要

我做了一件事，事后觉得是最值的：写脚本而不是手敲命令。

脚本里除了冻结列表，还硬编码了一份保护名单，执行前先做二次拦截——即使以后手滑把 com.zui.safecenter 加进数组，也会被 [SKIP-PROTECTED] 挡掉。每次执行成功一个包，就往 debloat_manifest.txt 追加一行，回滚时读这个文件逐个 pm enable：

# 先预览，什么都不改
.\zui14_debloat.ps1 -Level AB

# 真正执行
.\zui14_debloat.ps1 -Level AB -Apply

# 全量回滚
.\zui14_debloat.ps1 -Rollback

冻结完先做了一次红线校验，确认 13 个关键包里没有一个被误伤，才敢重启。这一步别省。

七、效果：重启后才是真实水平

优化前后三项核心指标：可用内存翻了一倍半，Swap 占用几乎清零，存储释放 14 GB。

冻结 31 个包之后重启，静置 2 分钟再测：

可用内存 +1.74 GiB，翻了一倍半；swap 占用降了 92.6%，ZRAM 几乎归零。

这里必须强调「重启」这一步。 冻结包带来的收益里，有相当一部分其实是重启本身给的——31 天不重启，swap 和 ZRAM 里全是历史包袱，不清空的话只冻结包是看不到这个数字的。两台机器同样的精简，一台重启一台没重启，测出来的数可能差一倍。

桌面渲染抽了一次 dumpsys gfxinfo：Janky frames 0（0.00%），50 分位 7ms，90/95/99 分位都是 17ms，Missed Vsync 0。

不过这个数据要打个折说清楚：重启后桌面没被操作过，样本只有 4 帧，只能说明「没有掉帧」，不能当压测结论。顺带提一句，输出里的 50th gpu percentile: 4950ms 是 Android 在没有 GPU 帧记录时的占位值，不是真实的 4950 毫秒延迟，别被它吓到。

八、81GB 存储去哪了：微信一个人吃掉 30GB

内存搞定了，顺手查存储。这块的发现比内存更让人意外。

先看 /sdcard，总共才 29.4 GB：

Android      21.0 GB（其中 Android/data 20.6 GB）
Pictures      5.26 GB
DCIM          1.68 GB
Movies         638 MB
Download       326 MB

但 /data 用了 81GB。差了 50 多个 G，说明大头不在用户可见的目录里。

答案在 dumpsys diskstats——它会把已经安装的每个包的 APK 体积、应用数据、缓存分别列成三个数组。把包名和数值按下标对齐，得到了真相：

微信一个应用占了 30.5 GB，接近总占用的 37%。 而且它 29.2 GB 的主体在 /data/data/com.tencent.mm，不在 /sdcard——所以只看 sdcard 目录永远找不到这个大头，它连 /sdcard/Android/data/com.tencent.mm 里都只有 5 GB。

⚠️ diskstats 有缓存，别被它骗了

清理完之后我再看了一次 dumpsys diskstats，数字一模一样，一点没变。当时以为自己操作失败了，白折腾一趟。

真相是 diskstats 的分应用数据有缓存延迟，不是实时刷新的。验证空间变化只认 df 和 du：

adb shell df -h /data                                  # 总账
adb shell du -sk /storage/emulated/0/Android/data/xxx  # 单个目录

九、无损清缓存：腾出 14GB

缓存和数据的区别，是这一步安全的前提。pm trim-caches 清的是各应用的 cacheDir，账号、登录态、聊天记录都在主数据区，不在缓存目录里。

# 彻底清掉两个已经冻结、不再使用的应用数据
adb shell pm clear com.netease.cloudmusic
adb shell pm clear com.coolapk.market

# 全机缓存回收（把每个应用的 cacheDir 都扫一遍）
adb shell pm trim-caches 999G

trim-caches 这类操作是逐个应用调 freeStorage，机上两百多个包扫下来只花了 9 秒。结果：

一共腾出 14 GB，存储占用从 79% 降到 65%。微信那边被清掉约 2.9 GB，全是缓存，打开后聊天记录、登录态都在，只是看过的缩略图要重新加载一次。

十、几个通用的坑，记下来备用

1. 系统相机的组件名不是通用名。 com.android.camera.CameraLauncher 在 ZUI 14 上会静默失败，正确的是 com.zui.camera/.CameraLauncher。判断方法：pm resolve-activity --brief -c android.intent.category.LAUNCHER com.zui.camera。
2. 熄屏状态下 am start 是无效的。 我拉起微信和相机都没反应，一开始怀疑是精简把组件搞坏了。查 dumpsys power 才发现 mWakefulness=Dozing——屏幕是灭的，Activity 根本进不了前台。先 input keyevent KEYCODE_WAKEUP + wm dismiss-keyguard 再测。
3. 想限制后台，appops 比 disable 合适。 夸克要留着给孩子看网盘动画和扫题，不能停，但可以按住： bash adb shell cmd appops set com.quark.browser RUN_IN_BACKGROUND ignore adb shell cmd appops set com.quark.browser RUN_ANY_IN_BACKGROUND ignore
4. 停用不等于清数据。 pm disable-user 只是让包不跑，占的空间一点没少。冻结之后要单独 pm clear 才能真回收——但 pm clear 会连登录态一起清，前提是确认这个应用不再用了。

十一、插曲：孩子要的 ChatGPT，比精简本身更难伺候

精简完第二天，孩子说想用 ChatGPT 对答案。我以为是「装个 App」的事，结果在这台机器上绕了整整一圈，最后的落点是浏览器里的一个网页快捷方式。

这段值得单独记，因为它把「预装应用」的另一面翻了出来：有些包不是垃圾，是残次品。

1. 机上那个 ChatGPT，根本没有启动入口

平板上确实装着 com.openai.chatgpt，版本 1.2026.265。点开没反应，也不报错——就是什么都不发生。

先确认它到底能不能被启动：

adb shell pm resolve-activity --brief -c android.intent.category.LAUNCHER com.openai.chatgpt
# 无输出

再用 dumpsys package 翻它的 intent-filter，真相出来了：MainActivity 只挂了 MAIN 加分享用的 SEND，唯独没有 android.intent.category.LAUNCHER。系统里没有任何入口能把它拉起来。

两条命令互相印证：

adb shell am start -n com.openai.chatgpt/.MainActivity
# Error: Activity class {...} does not exist.

adb shell monkey -p com.openai.chatgpt 1
# No activities found to run, monkey aborted.

再去看 minSdkVersion——29。而同一版本的官方包要求 32。这是个被改过的包：把 minSdk 强行压到 29 好让它能在 Android 12 上装进去，顺手把启动入口弄没了。

判断一个包能不能用，别信它在应用列表里存不存在，只信 pm resolve-activity --brief -c android.intent.category.LAUNCHER——有输出才算有入口。

2. 官方版装不上：差一个 SDK 版本号

那就装官方的。结果撞在另一堵墙上：官方 ChatGPT 客户端从 1.2026.2xx 起把 minSdk 提到了 32（Android 12L），而这台机器是 SDK 31（Android 12）。

按版本号往回翻，一个一个试：

这条路是死的，而且不是「下载渠道不对」那种死。 官方客户端从某个版本起就不再支持 Android 12 了，再往下翻只会翻到更早的改包。

（顺带：查 minSdk 根本不用装机试，aapt dump badging xxx.apk | grep sdkVersion 一分钟出结果。我是装了两轮才想起来查。）

3. 安装过程的两个坑

pm install 读不了 /sdcard。 直接 pm install /sdcard/Download/chatgpt.apk 会失败——system_server 没有 FUSE 权限，看不到用户存储里的路径。先拷进 /data/local/tmp 再装：

adb push chatgpt.apk /data/local/tmp/
adb shell pm install -r -d /data/local/tmp/chatgpt.apk

被安装校验拦。 报错信息不一定直白，但可以先关掉 ADB 安装校验再试：

adb shell settings put global verifier_verify_adb_installs 0

4. 退回网页版，又被夸克拦了一次

客户端没戏，那就用网页版。孩子平时开夸克，结果 chatgpt.com 直接给一屏：

此网站可能包含不适合你浏览的内容

夸克把它拦了。这是浏览器的内容风控，不是网络问题——同一台机器、同一个 WiFi，换 Vivaldi 打开就完全正常，账号还登着，历史对话都在。

这里有个回头看挺讽刺的地方：我在 B 档里把 Vivaldi 列进了「可以停的第三方预装」，清完才需要用上它。它后来被从脚本和 manifest 里撤了出来，必须保持启用——这台机器上唯一能稳定打开 chatgpt.com 的就是它。

5. ⚠️ 添加到主屏失败：被一个看不见的 AppOp 拦了

网页版能用之后，孩子嫌每次要开浏览器、翻书签麻烦，让我「加到主屏」。点了「添加到主屏幕」，桌面没多出图标，也不报错、不弹窗。

这种「点了没反应」只能看日志：

adb logcat -d | grep -iE "shortcut|pinshortcut"

抓到关键的一行：

requestPinShortcut or Widget Denied by AppOps for com.vivaldi.browser

requestPinShortcut() 需要 CREATE_SHORTCUT 这个 AppOp，而 Vivaldi 在这台机器上是被默认拒的。注意它不是运行时权限——所以在「权限」页面的普通权限列表里根本找不到它，也不会弹窗，用户侧的感受就是「点了没反应」。

第一反应当然是用命令改：

adb shell cmd appops set com.vivaldi.browser CREATE_SHORTCUT allow

命令不报错，但 cmd appops get 一看还是 deny。 ZUI 对「桌面快捷方式」这个 AppOp 做了额外保护，ADB 改不进去。

最后是在设置里点开的：设置 → 应用 → Vivaldi → 权限 → 把「在桌面上创建快捷方式」改为允许，回浏览器重新点「添加到主屏幕」，图标才落到桌面上。

这条值得单独记：AppOps 里的项不一定都能用 cmd appops set 改，尤其是带 UI 开关的那几个（桌面快捷方式、悬浮窗、自启动）。命令不报错、改完却毫无变化时，别在命令行里耗，去设置里找那个开关，三十秒的事。

6. 还有一个绕不开的东西：学习模式

这台机器开着 ZUI 的学习模式（家长管控）：有密码、每天限 3 小时（learn_mode_total_used_time=10800）、网页访问还开了限制。孩子用 ChatGPT 的时间照样被这个时长扣着，换浏览器也绕不过去。

这个我没动。给孩子的设备，「能用」和「放开」是两件事：前者是我该干的活，后者得家长自己定。

十二、留个后路

所有改动只有 pm disable-user 和 appops，没有碰系统分区，也没有刷任何东西，所以全都能回退。脚本的 -Rollback 会读 manifest 逐个恢复。

现在实际冻结的是 29 个包，不是第七节实测那时的 31 个——Vivaldi 和夸克后来为了第十一节的需求被撤了出来，两个都改成用 appops 限制后台。

留了一份完整的体检报告（优化前后对比、每个包的功能说明、验收记录、回滚方法），以后想复现或者换设备照抄流程都有据可查。

还有两条建议：

• 每 7–10 天重启一次。 这次最大的收益来源其实是重启，不是精简。这条不用装任何软件，成本为零。
• 别长期开着 USB 调试。 尤其是给孩子用的设备，调试口开着等于把系统接口交出去了。用完就在开发者选项里关掉，顺手点一下「撤销 USB 调试授权」，把调试选项总开关也关了，孩子找不到入口。

最后

这台机器的硬件其实一点都不差：6GB 内存、90% 的电池健康、191 次循环，还年轻得很。它卡，是因为两年里装了太多不需要的东西，又 31 天没重启过，swap 和 ZRAM 里堆满了历史垃圾。

一开始我满脑子想的是「刷个老系统让它重生」，最后发现最有效的一步根本不是刷机，是重启。刷机的代价是把一台 verifiedboot 还是 green 的干净机器，换成一个 9008 状态未知的机器，还要赌 ARB 不炸——而收益，可能还不如先看一眼哪些包在白名单里强制常驻。

还有个意外收获。我原本以为「预装应用」只有两种：能用的和垃圾。清完才发现还有第三种——装得上、跑不起来、也没有入口的残次品。它占着空间、在应用列表里躺着，但你永远点不开它。这种包比垃圾更麻烦，因为垃圾你至少能确认它没用，残次品却会让人以为自己装错了或者机器坏了。

老设备的价值不在于跑得动最新的东西，而在于把它的能力边界摸清楚，然后在边界内用得舒服。这次折腾最大的收获，其实是弄明白了「卡」到底卡在哪：不是系统太重，是后台太多，外加一个 30GB 的微信。至于孩子要的 ChatGPT，折腾到最后落成桌面上的一个网页图标——也算给「精简」补了个反面：不是所有东西都该被清掉，清之前最好先弄清它到底是什么。