我正在与其他一些开发人员一起开发一个 android 项目，并且引发了一个错误，即垃圾收集中没有保留实例状态：
实际的错误报告：
该应用程序有一个带有一堆片段的活动。如果在开发人员选项中选中“不保留活动”并且用户单击任何更改可见片段的按钮，然后导航离开应用程序然后返回，它会将应用程序重新启动到其原始状态而不是最后一个状态.
该项目的另一位开发人员提出了以下担忧：
“实例的保存会导致应用程序的内存大小膨胀。由于可绘制对象的数量，应用程序的内存大小已经太高了。
没关系，如果应用程序在用户一段时间未使用后重新启动。”
我的理解是 savedInstance Bundle 实际上被写入物理内存，这不正确吗？上面的引用是一个有效的问题吗？
我的理解是 savedInstance Bundle 实际上被写入物理内存，这不正确吗？
我将“写入物理内存”解释为“写入文件系统上的文件”（又名“持久化”）。
实例状态Bundle不持久。Android 5.0+ 为您提供了一个不同的钩子，用于PersistableBundle持久化并因此在重新启动后仍然存在。
但是，实例状态Bundle会跨越进程边界传递到核心操作系统进程。如果您的进程终止，则可以使用该数据，但用户在您的任务仍然存在时返回到您的应用程序（例如，通过最近的任务列表）。
上面的引用是一个有效的问题吗？
唯一可以被这里的人合理评估的引用是：
实例的保存会导致内存中的应用程序膨胀
在 中保存一个字节Bundle将比在 . 中保存零字节消耗更多的内存Bundle。因此，从数学上讲，报价是准确的。关键是保持Bundle小。由于其他原因（IPC 调用限制为 1MB），它们无论如何都不能变得太大。小实例状态Bundles应该不是问题。
正确编码的保存实例状态将在后台一次存活数周，并且只需要几个字节，最坏的情况是几个 k 的 ram。
您的其他开发人员有学习曲线问题。
InstanceState 保存您重新创建应用程序当前对用户的外观所需的内容。让我们使用井字游戏的类比。你有九个职位。每个位置都是 xo 或空白。你拯救了轮到谁。十个字符串在这里没有膨胀，这不是火箭科学。
屏幕上有 10 个可绘制对象的应用程序的 InstanceState。您将可绘制对象保存为 jpg 甚至 bmp 格式的外部存储。然后将可绘制对象的名称保存在 instanceState 中。1000 个字符的实例状态没有膨胀，这是计算机科学 1k 来重新启动一个非常复杂的应用程序。
SaveinstanceState 不是臃肿的软件，它是一个很棒的应用程序。