让系统更新更“轻量”：将OTA更新分为“必选”与“可选”，由用户自行选择

🚀 核心构想：荣耀在发布小版本更新时，将更新内容分为“必选”与“可选”两类，可选功能封装为独立的内核模块，每个模块自带标签，用户可自行选择安装

目前系统更新通常是一个完整的包，用户只能选择“更新”或“不更新”。一旦更新，所有新增功能和优化都会被强制安装，长期下来系统可能会变得臃肿。

我的想法是：让用户拥有更多选择权，但同时也需要保证系统底层的稳定。这个选择权不是让用户随意拆分更新包，而是由荣耀预先划分好更新内容——一部分是必须更新的，另一部分是可选的。可选功能封装为相互独立的内核模块，每个模块在开发时就贴上对应的SoC模块标签和场景标签，让调度器能够快速识别和调用。

📐 具体如何实现？

荣耀在发布小版本更新时，将更新内容预先划分为两类：

第一类：必选包。 涉及系统安全补丁、核心驱动更新、关键漏洞修复等必须安装的内容。这部分用户无法选择，必须更新，保证所有用户系统底层的一致性和安全性。

第二类：可选包，独立内核模块封装。 新增的系统功能、界面优化等非核心内容，每个功能封装为一个独立的内核模块。每个模块自包含所有需要的代码和资源，不依赖其他模块，可以独立安装、运行和卸载。用户在更新页面看到的是一个功能清单，可以自由勾选需要的功能，不想要的可以不装。已安装的功能也可以在设置中单独卸载。

第三层：标签化调度，精准识别。 结合此前提出的“给内核代码贴标签”机制，每个独立模块在开发时就贴上对应的SoC模块标签和场景标签。工程师不需要逐行分析代码用途，只需要按照功能模块本身的设计目的，直接贴上对应标签。调度器根据标签快速定位和调用相关模块，无需运行时动态分析。

⚙️ 已安装的可选包能否删除？

可以。如果某个可选功能在更新后不再需要，用户可以在设置中“卸载更新”或“恢复出厂版本”。模块卸载时标签随之移除，不存在标签和代码不同步的问题。这让系统可以保持轻量，不会因为安装了不需要的功能而变臃肿。

💡 这个方案的好处是什么？

用户不再被动接受所有更新，而是可以根据自己的需求定制系统功能。不喜欢的功能可以不装，系统保持轻量，功耗和存储空间不会因为更新而不断膨胀。

独立模块为标签提供了天然的边界——每个模块功能明确、边界清晰，标签可以贴在整个模块层面。调度器不再需要在庞大的耦合代码中动态分析任务特征，而是直接根据标签查找对应的独立模块，调用路径更短，运行时开销更低。

同时，荣耀也能通过用户对可选包的选择，了解哪些功能更受欢迎，为后续产品规划提供数据支撑。

💎 总结

让OTA更新从“全量强制”升级为“必选兜底、可选自由”。独立内核模块实现功能的可插拔，标签机制实现调度的精准化。两者结合，既能让用户自由定制系统，又能让调度器高效运作。期待MagicOS团队能在这个方向上展开探索！
@性能研发陈立庚 @MagicOS流畅橙子 @性能_阿勇 @MagicOS流畅李同学

你写这么多，我就支持你一下

为了确保系统各功能协调以及稳定性，暂无法实现的

你这个想法很好但是我估计荣耀工程师是不会做的，因为太麻烦了

极客的操作方法，不适合普通用户，增加操作难度

是个厂家都不同意你的想法，没什么用

你这要求太高了，不是小厂能干的

我支持你。但 8000 可不依。