【功能建议】应用分身数据残留目录处理机制

一、背景

当前 MagicOS (版本号 10.0.0.150(SP1C00E139R103P1H2) ) 中，用户首次使用应用分身功能后，文件管理中会生成“应用分身数据”目录。该目录受系统保护，无法直接删除。


二、问题

1. 用户关闭所有应用分身后，“应用分身数据”目录依然保留，无法删除。
2. 手动删除内部子文件夹后，在无应用分身开启的状态下，系统会在重启和某些不确定的时间自动重建某些子目录（见附图），该重建行为在手机重启后必现，造成反复残留。
3. 对于追求系统整洁、功能“用完即走”的用户，此现象体验不佳且不优雅。


三、建议

方案〇：静默隐藏，不改变系统机制，仅优化用户感知
（该方案是了解一些情况后补充的，个人推荐此方案）

如果是涉及安卓系统底层机制的问题，暂时无法从根本上解决，是否可考虑优化用户层面的直观感受和体验，具体如下：
1. 所有应用分身关闭时（类似方案三逻辑，由于只是隐藏，也不用二次弹窗提示风险了），文件管理中隐藏“应用分身数据”目录，其底层机制的存在与否对用户透明，无感知。
2. 用户使用应用分身时，在文件管理中恢复该目录的显示。

该方案应该是性价比最高的，效果好，可行性强，副作用可控。

方案一：在 “设置 > 应用 > 应用分身” 页面中，增加 “清空所有分身数据”（示例名称仅供参考） 功能选项

触发条件：
系统检测到所有应用分身开关均已关闭，所有分身应用均已卸载。

执行流程：
1. 用户点击“清空所有分身数据”。
2. 弹出确认窗口，提示操作不可恢复。
3. 可考虑加入强制等待机制（如 X 秒确认倒计时）。
4. 确认后，彻底删除“应用分身数据”整个目录及全部内容。

预期效果：
1. 文件管理器中“应用分身数据”目录彻底消失。
2. 不再有自动重建的子文件夹。
3. 用户可感知“功能停用后系统恢复干净状态”。

方案二：在 “设置 > 应用 > 应用分身” 页面中，增加 “开启应用分身功能”（示例名称仅供参考）总开关

1. 总开关关闭时，禁用所有应用分身功能（隐藏或置灰每个应用的分身开关），删除“应用分身数据”目录及其全部内容（若此前存在）。
2. 总开关开启时，恢复功能（每个应用分身开关显示并允许控制），重新创建应用分身数据目录（当开启了某个应用的分身时）。
3. 关闭总开关前，系统自动检测是否存在未卸载的分身应用，若有则提示用户先清理，类似方案一的触发条件。

方案三：所有应用分身关闭时自动清理

1. 当最后一个此前被开启的应用分身开关关闭时，自动执行上述清理逻辑，删除“应用分身数据”目录及全部内容，至少在用户直观体验和文件系统上恢复到首次使用“应用分身”前的状态。
2. 无需用户额外操作，实现“关闭即清理，用完即消失”。
3. 用户主动关闭所有应用分身，已说明不再需要这些数据，风险可控。
4. 如确有风险担忧，可以在用户关闭最后一个应用分身时，增加二次确认弹窗，是否彻底清理所有分身数据，进一步控制风险。
5. 该方案应该是最符合用户直觉和预期的。


四、价值

1. 功能完整性： 功能的“进入”与“退出”逻辑应当对称。开启时创建资源，关闭后释放资源，这是产品设计的基本常识。当前“应用分身数据”目录无法随功能停用而自动清理，属于产品生命周期管理上的不完整。

2. 用户体验： 目录残留且反复自动重建的行为，持续消耗用户精力，给系统洁癖用户带来长期困扰。提供明确的清理入口或自动清理机制，让用户感知“功能完全不存在了”，而非“功能不在但痕迹一直在”，符合“用完即走”的正常认知。

3. 产品运营： 优化此功能可避免用户在该方面潜在的提问与反馈，降低客服压力，同时提升系统精致度与用户口碑。


五、补充说明

用户关闭分身功能的心理模型是“将系统恢复到此功能从未被开启的状态“。而目前目录及子文件夹的残留和自动重建，与这一预期严重不符，给用户造成“系统有清理不掉的脏东西”的负面感知，持续消耗信任。建议提供手动或条件自动的“彻底关闭”机制，完成功能的生命周期闭环。


请产品及系统研发团队评估此建议，感谢。