Android 应用程序类生命周期 [英] Android Application Class Lifecycle

问题描述

我正在开发的 android 应用程序覆盖了 Application 类以在静态变量中存储轻量级状态(用户名、gps 位置等).此状态的大部分设置在启动活动的 OnCreate 中(从首选项检索用户名，位置侦听器运行).依靠启动活动来初始化应用程序类是否安全?是否有可能在不创建 Launch 活动的情况下重新创建 Application 类的情况?

The android app I am working on overrides the Application class to store lightweight state (username, gps location, etc) in static vars. Most of this state is set in OnCreate of the launch activity (username retrieved from prefs, location listener runs). Is it safe to rely on the launch activity to initialize the Application class? Are there any cases where the Application class might be re-created without the Launch activity also being created?

问题出现是因为我在手机休眠几个小时后(在手机进入休眠状态之前应用程序留在前台)在恢复应用程序时，我在访问应用程序类中的变量时遇到了空指针异常.是否有可能在电话睡眠和唤醒电话时进程被终止，应用程序类被重新创建，堆栈中的顶部活动被恢复，但启动 activity.onCreate 没有运行，因此应用程序类没有初始化?

The question comes up because I ran into a null pointer exception accessing a variable in the Application class on resuming the app after the phone was asleep for several hours (the app was left in the foreground before phone went to sleep). Is it possible that the process was killed while the phone was asleep and on waking the phone, the Application class was re-created, the top activity in the stack was resumed, but the launch activity.onCreate wasn't run thus the Application class wasn't initialized?

请注意，我已尝试通过强制应用停止使用设置/管理应用程序来测试这些类型的场景.但是，我无法重现该问题.下次运行时，将创建 Application 类，然后启动 activity.onCreate.

Note that I have tried to test these kinds of scenarios by Forcing the App to stop using Settings / Manage applications. However, I'm not able to recreate the problem. On the next run, the Application class is created, followed by the launch activity.onCreate.

假设 Application 类实例与进程存在的时间一样长，并且当 Application 类被创建时它相当于重新启动"应用程序，即.从一个新的活动堆栈开始(堆栈上的第一个活动是启动活动)?

推荐答案

没有.您的整个应用程序可以在任务堆栈完好无损的情况下被终止和重新创建；这让系统可以在需要它的设备上回收内存，同时仍然向最终用户呈现多任务处理的无缝假象.来自文档:

No. Your entire application can be killed and recreated with the task stack intact; this lets the system reclaim memory on devices that need it while still presenting a seamless illusion of multitasking to the end user. From the docs:

一个后台活动(一个活动对用户不可见，并且已暂停)不再关键，因此系统可以安全地终止其进程以回收内存其他前台或可见进程.如果它的进程需要被杀死，当用户导航回活动(使其在再次屏幕)，它的 onCreate(Bundle)方法将被调用savedInstanceState 它以前有提供onSaveInstanceState(Bundle) 以便它可以在相同状态下重新启动用户上次离开时​​.

A background activity (an activity that is not visible to the user and has been paused) is no longer critical, so the system may safely kill its process to reclaim memory for other foreground or visible processes. If its process needs to be killed, when the user navigates back to the activity (making it visible on the screen again), its onCreate(Bundle) method will be called with the savedInstanceState it had previously supplied in onSaveInstanceState(Bundle) so that it can restart itself in the same state as the user last left it.

也就是说，进程(应用程序与之绑定)可以被终止然后重新启动，并且各个活动应该有足够的信息来根据他们在被终止之前保存的内容重新创建自己，而不依赖于全局状态由其他活动在流程中设置.

That is, the process (which the Application is tied to) can be killed off but then restarted, and the individual activities should have enough info to recreate themselves from what they've saved before being killed, without relying on global state set in the process by other Activities.

考虑将需要由 Activity 初始化的持久共享状态存储在 SharedPreference 或 SQLite 数据库中，或者将其作为额外的 Intent 传递给需要它的活动.

Consider storing persistent shared state that needs initialization by an Activity in either a SharedPreference or SQLite database, or passing it to Activities that need it as an Intent extra.

这篇关于Android 应用程序类生命周期的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！