沙箱里的应用是怎么跑起来的——GBox 日常使用的底层逻辑

装完之后，日常使用层面理解四个现象就够了。它们都源于同一个事实：应用跑在 GBox 的容器里，不在系统里。

现象一：从桌面点图标，先「顿」一下

桌面图标是沙箱应用的入口，点击后实际发生的是：系统拉起 GBox 容器 → 容器恢复应用运行状态 → 应用界面出现。比原生应用多一层容器加载，所以启动略慢。这不是卡顿故障，是结构使然；启动明显变慢甚至超时的另说，见闪退排查。

现象二：应用「记得」上次的进度

社区用户对沙箱方案的普遍观察是：应用退出后再打开，会保留上一次的使用状态——正在看的视频、写一半的文档都还在。容器为每个应用维持运行态，这和原生应用的后台驻留是两套机制，效果上接近。

现象三：沙箱数据与系统互不干扰

沙箱内的应用数据（登录态、文件、缓存）留在容器里，与系统里装的同名应用互不相通：

• 手机上原本装过的微信，与沙箱里再装的微信，是两份独立数据；
• 反过来，沙箱内的应用也读不到系统相册、文件（除非权限弹窗明确授权）；
• 这既是隔离的好处（干净、可控），也是「为什么沙箱里找不到我手机里的文件」的原因。

现象四：卸载 GBox = 一锅端

沙箱内所有应用、数据、登录态随 GBox 卸载一起消失。由此推出的操作纪律：

• 重要数据定期走云端：邮件、聊天记录备份、文档同步都交给账号体系，见卸载备份页；
• 升级用覆盖安装，不要「卸了重装」解决问题——数据会清零，见覆盖升级页；
• 想清空重来但保留 GBox 本体的，用「重置沙箱」，见重置专页。

和系统共存的方式

GBox 本体作为一个普通应用存在：占一份存储、受系统省电策略管理、可以在应用管理里查看与设置——这就是为什么后台权限那两项设置如此重要：系统随时可以按策略杀掉它，两项设置就是给它上白名单。

理解这四条，沙箱的所有行为都变得可预测。接下来看推荐应用分区——日常使用的主入口。