MiTV4X 瘦身战役：929MB 内存上的十五次卸载，与一个重启即失效的 ADB 开关

一台 2016 年前后的小米电视，720p、Android 6.0、内存 929MB。它在客厅里跑了这么多年，卡顿的原因从来不是玄学——这一晚，ADB 连线打通之后，所有数字都摊在了桌面上。

一、连通：从端口全关到 unauthorized

起点是连接被拒绝（10061）。ping 得通（6-45ms，TTL=64），说明电视在线；但 5555、5556、5557、5037、5038、8009 端口全部关闭——电视端的网络 ADB 调试没有启用。adb 工具本身没问题，就在本机 Android SDK 目录下。

开启开发者选项后，端口开放了，连接建立，但设备显示 unauthorized。屏幕上弹着一个带 RSA 指纹的「是否允许 USB 调试」对话框，需要遥控器点「允许」，顺便勾上「一律允许使用这台计算机进行调试」，以后就不用每次授权。

授权通过，设备信息读出来：小米电视 MiTV4X，Android 6.0。

二、体检：107MB 空闲是最大瓶颈

全量检测采集了设备信息、存储、内存和完整包列表。结论比预想的紧：

项目	现状
型号 / 系统	小米 MiTV4X，Android 6.0，720p
内存	总共 929MB，空闲仅约 107MB
存储	/system 剩 54MB（偏紧），/data 剩 2.9GB（充足）
应用	73 个系统应用 + 3 个第三方

内存占用排行一拉出来，病灶非常清楚：桌面 tvhome 82MB、系统框架 30MB、语音 22MB、应用商店 18.5MB、MiVideo 播放器 17MB、搜狗输入法 15.7MB、小米图库 15MB、米家 12MB、系统升级 12MB、商城 10.7MB。

核心问题是广告/统计/推送类后台服务常驻内存——小米电视广告四件套：tvpush 推送 5.7MB、tvqs 质量数据上报 9MB、cloudcontrol 云控 3.6MB、statistic 统计埋点，合计约 20MB 常驻并持续联网。加上商城、游戏中心、米家等非必要应用。

一个重要的认知校准写在动手之前：卸载系统应用不会释放 /system 空间——APK 在只读分区，pm uninstall --user 0 只是对当前用户移除、可随时恢复。收益是内存、隐私和广告减少，不是磁盘。

三、三个梯队的判决

第一梯队：安全卸载 14 个，建议全做——推送服务、质量上报、云控、统计埋点、电视商城、商城插件、首页网页推荐内容、支付两个、小米钱包、游戏中心两个、小米音乐、使用手册、日历。这些都是纯广告/商业/统计向，删了不碰任何观看功能。

第二梯队：按使用习惯决定——米家（家里没有小米智能设备就删）、语音控制（遥控器没有麦克风按键、从不用语音就删，但删了遥控器语音键会失效）、唱歌服务、闹钟/录屏/天气。

建议保留：搜狗输入法（删了搜索时无法打字）、应用商店（以后装 app 要用）、屏保（删了可能影响待机行为）。

绝对不要动：桌面、设置、SystemUI 两个、mitv.service、mstar.tv.service、mstar.factorymenu.ui 工程菜单、所有 providers、账号、三个播放器、mediaexplorer（U盘/文件管理）、webview、系统升级、解码器、lockscreen、remotecontroller.service、投屏五件套。动了电视可能起不来或功能残缺。

执行与回退方法也一并写好：卸载用 pm uninstall --user 0，任何应用出问题，重启后用 pm install-existing <包名> 就能恢复单个包，不会变砖。

四、十五次卸载，与重启后的意外

十五个包全部卸载成功，重启前已验证生效。重启命令发出，然后出了状况：设备没回来。

电视网络已通但 ADB 端口还没起来。MAC 地址 18:BB:26 确认还是那台小米电视，但重启七分多钟了 5555 仍被拒绝。持续 ping 60 秒——零丢包，没有重启循环，系统是正常运行的，只是 ADB 服务没起来。小米电视服务端口 6095 正常开放，进一步确认系统本身健康，没有变砖。

结论是：卸载全部成功，电视系统运行正常，但 ADB 开关重启后被重置了。这是小米电视的已知行为——「ADB 调试」开关重启后不会保留，每次电视重启后都需要重新打开，部分固件版本的设计如此。

五、持久化改造的失败

主人不服气：把 ADB 设置成重新开机不会自动回到关闭。

连上之后看到当前 ADB 开启状态下的设置项：persist.adb.tcp.port=5555、persist.service.adb.enable=1、settings global adb_enabled=1。先把所有持久化开关都设上，包括开发者选项总开关 developer_status，然后重启做关键验证。

重启 200 秒后，ADB 仍未自动恢复。再查设置项，发现里面没有小米专属的 ADB 开关状态——它的开关状态不走 settings 数据库，所以重启就丢。试着拿 root（有些电视固件是 userdebug 版可以直接 adb root），拿不到。又发现了小米电视专用的开机脚本 /init.mitv.rc，ADB 的启动逻辑大概率在里面，但 init 脚本是 root 权限，读不了。

最终判决：这个固件是故意在每次开机时重置 ADB 开关的（安全设计）。persist.adb.tpu.port、persist.service.adb.enable、adb_enabled、developer_status 全部设上也没用，开关状态存在只有电视自己应用能读的位置。

所以这台机器的最终状态是：卸载优化是持久的、不受重启影响（预期释放约 30-40MB 常驻内存，砍掉全部推送/统计/云控后台联网，开机后桌面更干净流畅），但 ADB 每次断电重启后必须手动重开一次——电视 → 设置 → 账号与安全 → ADB 调试。屏幕上不需要再弹授权框，RSA 密钥已保留。

六、顺带读了一个项目

过程中还读了一个 GitHub 项目：Universal Android Debloater（0x192/universal-android-debloater），Rust 加 Iced 写的跨平台图形工具，20.2k Star，通过 ADB 给非 root 安卓设备卸载预装应用。

它的工作方式值得一说：没有 root 权限时无法真正删除系统应用，UAD 是通过 adb shell pm uninstall --user 0 为当前用户移除，本质是「禁用」而非物理删除，所以随时可以恢复，刷机或系统更新后名单需要重跑一遍。

但对这台 MiTV4X 有两个不适用的点：一是 UAD 的名单主要面向手机，电视专属包名覆盖有限；二是电视上误删包的后果比手机更麻烦——没有 recovery 界面可进，只能线刷。所以最终走的是手工逐包路线：先导出完整列表、挑出确认多余的包、再逐个处理。作者那句 “Use at your own risk” 在电视上的分量，比在手机上重得多。

929MB 的机器上，每一兆都是真的。这一晚拿到的不是”更快”，而是一份精确到包名的账本，和一条关于这台固件边界的确定认知。