我正在开发的android应用程序覆盖了Application类,将轻量级状态(用户名、gps位置等)存储在静态变量中。此状态的大部分在启动活动的OnCreate中设置(从首选项检索用户名,运行location listener )。依赖启动活动来初始化Application类是否安全?是否存在在不创建启动活动的情况下重新创建Application类的情况?
出现这个问题是因为在手机休眠几个小时后,我在恢复应用程序时遇到了访问Application类中的变量的空指针异常(在手机进入睡眠之前,应用程序被留在了前台)。有没有可能在手机休眠和唤醒手机时,进程被终止,应用程序类被重新创建,堆栈中的顶部活动被恢复,但launch activity.onCreate没有运行,因此应用程序类没有被初始化?
请注意,我曾尝试通过强制应用程序停止使用设置/管理应用程序来测试这些类型的场景。然而,我不能重现这个问题。在下一次运行时,将创建应用程序类,然后是启动activity.onCreate。
是否可以安全地假设应用程序类实例将在进程期间存在,并且当创建应用程序类时,它等同于“重新启动”应用程序。从一个新的活动堆栈开始(堆栈上的第一个活动是启动活动)?
发布于 2011-01-03 23:28:09
不是的。您的整个应用程序可以在任务堆栈完好无损的情况下被终止和重新创建;这使得系统可以回收需要它的设备上的内存,同时仍然向最终用户呈现多任务的无缝错觉。从文档中:
后台活动(对用户不可见且已暂停的活动)不再关键,因此系统可以安全地终止其进程,以便为其他前台或可见进程回收内存。如果它的进程需要终止,当用户导航回活动(使它再次在屏幕上可见)时,它的onCreate(捆绑包)方法将使用它之前在onSaveInstanceState(捆绑包)中提供的savedInstanceState来调用,以便它可以在用户上次离开它时以相同的状态重新启动。
也就是说,进程(应用程序所关联的)可以终止,但随后可以重新启动,单个活动应该有足够的信息来根据它们在终止之前保存的内容重新创建自己,而不依赖于其他活动在进程中设置的全局状态。
考虑将需要活动初始化的持久共享状态存储在SharedPreference或SQLite数据库中,或者将其作为额外意图传递给需要它的活动。
发布于 2013-11-27 12:41:29
您可以通过运行应用程序的killing the process
来测试该场景。
步骤1.打开你的应用程序,然后按Home
按钮将其隐藏在后台。
步骤2.调用adb shell
步骤3.输入命令su
(必须获得根权限才能杀死进程)
步骤4. ps
(列出所有正在运行的进程ID并找到您的进程ID)
步骤5. kill 1234
(假设您的应用程序在进程1234上运行)
第6步。然后,返回到您的设备并再次单击启动图标。您可能会发现活动堆栈上的最后一个活动是重新打开的。您可能还会发现该活动调用了onRestoreInstanceState()
方法。
发布于 2015-02-05 19:03:23
简而言之:在YourApplication.onCreate
中进行初始化,而不是一些LaunchActivity
要检查的文档:
依靠启动活动来初始化应用程序类是否安全?
可以,只要您记住应用程序可以存在更长时间,该活动和活动可能会被终止并重新创建。我不确定复活的活动将获得什么意图:启动或查看(对于活动因过于繁重而被终止,同时有长时间运行的服务绑定到应用程序的情况)
是否存在在不创建启动活动的情况下重新创建应用程序类的情况?
是,如果最后一个可见活动不是LaunchActivity
检查Android application lifecycle and using of static
有没有可能在手机休眠和唤醒手机时,进程被终止,应用程序类被重新创建,堆栈中的顶部活动被恢复,但launch activity.onCreate没有运行,因此应用程序类没有初始化?
如果有几个不同的活动启动了A,B,C,然后他们整个过程都被杀死了,那么我认为Android操作系统很好,只创建应用程序和C活动,而A和B会在访问时重新具体,也就是在返回到它们时。
是否可以安全地假设应用程序类实例将在进程、
是
,并且当创建应用程序类时,它等同于“重新启动”应用程序。从新的活动堆栈开始(堆栈上的第一个活动是启动活动)?
我不确定何时会首先调用重启启动活动。
而是最后一个,即用户应该看到的那个。
https://stackoverflow.com/questions/4585627
复制相似问题