在哪里保存了onSaveInstanceState包?

时间:2011-11-11 09:31:32

标签: android

我想知道方法onSaveInstanceState(Bundle outState)的包“outState”存储在何处。

是存储在内存中还是存储在设备存储中?

我担心存储在捆绑包中的数据的安全性。

5 个答案:

答案 0 :(得分:9)

要仅为应用程序生命周期(即临时)存储数据,请使用onSaveInstanceState(Bundle)活动事件

此数据仅在应用程序关闭之前保留在内存中,只要此活动在应用程序的当前生命周期内开始,数据就会可用。

说明:如果数据由活动A存储在此处,则应用程序显示不同的活动或旋转屏幕(因此关闭A)然后返回到A,可以检索数据以填充控件。但是,如果应用程序关闭并再次打开,数据将会消失,控件将恢复为默认值。

使用示例:存储用户输入的文本和构成订单,博客条目,消息等的选择......

注意:

重要的是要注意只有Activity被销毁和重新创建,而不是整个应用程序! Android应用程序可以包含许多活动,服务和ContentProviders!如果应用程序关闭(例如,通过按“后退”按钮,则所有值都将消失.soredInstaceState仅用于在销毁/重新创建活动时保留临时数据,而不是应用程序本身。

如果要永久保存数据,则需要将其另存为“首选项”或ContentProvider /数据库。

答案 1 :(得分:7)

我不认为任何恶意后台进程都可以获取应用程序的捆绑数据。没有记录Android如何处理Bundle数据。在您的应用程序被清理时,它可能会也可能不会写入磁盘,而后台则是。但是,鉴于我们不知道这些数据是否保存到磁盘,如果是,那么,鉴于我们不知道哪里,几乎可以肯定没有读取访问该部分的数据。磁盘,我不担心某些第三方进程能够恢复该数据。

因此,我不清楚您认为曝光是什么。虽然我可能会遗漏一些东西。 但是,在回答你的问题时,它绝对是在你的应用程序存活的内存中,并且如果你的应用程序是背景的,它可能会或可能不会写在隐藏的地方,但我们不会'知道,因为谷歌没有告诉我们。

在收集内存时,应用程序会将其与应用程序一起销毁。

答案 2 :(得分:4)

以下是outState捆绑数据保存位置的详细答案:

  

...捆绑是一种IPC机制,因此不会进入文件系统。但是现在涉及到P了-这是哪个过程?那该数据处理了什么?我需要为此担心吗?事实证明,这些实例状态束被存储在活动管理器服务中。此服务在Android源代码中的com.android.server.am包下实现。回想一下,活动是一个又一个地堆叠在一起的,Android称这些堆叠为“任务” ...这些任务中的每一个都在内部用 TaskRecord 类的对象表示。此类包含 ActivityRecord 对象的数组,每个对象管理一个Activity的状态。 ActivityRecord包含名为icicle的Bundle类型的成员。此icicle-bundle是已保存的实例状态,它实际上存储在活动管理器服务的内存空间中

来源:https://www.linkedin.com/pulse/android-onsaveinstancestate-bundle-secret-safe-daniel-pietsch/

答案 3 :(得分:4)

documentation已更新,并准确指示状态已序列化到磁盘:

保存的实例状态包既保留配置更改又使进程终止,但由于 <tr *ngFor='let moloc of moratoriumswithlocs'> <td>{{moloc.Id}}</td> <td>{{moloc.SystemId}}</td> <td>{{moloc.DateEffective | date:'shortDate'}}</td> <td>{{moloc.DateExpiration | date:'shortDate'}}</td> <td>{{moloc.StateAbbreviation}}</td> <td>{{moloc.County}}</td> <td>{{moloc.City}}</td> <td>{{moloc.Zip}}</td> <td>{{moloc.ReasonId}}</td> </tr> 将数据序列化到磁盘而受到存储量和速度的限制。

您还可以找到一个表格,将不同的方法与保留UI状态进行比较

Option for preserving UI state

来源:https://developer.android.com/topic/libraries/architecture/saving-states

答案 4 :(得分:1)

我的猜测是在内存中,但保护数据的最佳方法是不信任系统并对其进行加密。永远不要相信客户端(在这种情况下客户端是操作系统)。

修改

要清楚,我不是说加密捆绑。相反,我说任何敏感数据都不应该放入捆绑中。如果必须将自定义数据放入捆绑包中,请对其进行加密。

但最终你应该尽可能地保留客户端上的敏感数据。这与电子商务网站仅显示信用卡的最后4位数的原因相同。