Too*_*eve 2 android android-lifecycle
我经常看到帖子指出文件写入应该在后台线程中完成，即使应用程序正在关闭（onStop ) - 即使该工作对应用程序至关重要。
我对此很困惑。当然，这是 Android应该（或许必须）宽松地给予应用程序完成时间的onStop唯一一个 UI 调用。关键。
我担心在后台线程上执行关键工作不会通知操作系统该工作很关键并且需要完成。
与此相关的有几个方面：
----- 是什么困扰着我；我写这个问题的原因-----
onStop 返回的信号是否不会onStop向 Android 表明该应用程序已完成关键操作，并且即使 Android 立即终止该应用程序，该应用程序在恢复时也将正常运行？（换句话说，在我看来，[在后台线程中完成关键工作]的建议是错误的。我试图以某种方式找到证据。这就是我写这个问题的原因。）
----- 是否存在任何支持背景方法的证据？-----
有证据表明，如果我遵循建议并在后台线程中完成工作，Android 在决定是否可以终止应用程序时会考虑该正在运行的线程的存在。[如果我正在编写一个移动操作系统，我不会太重视后台线程的存在。我怀疑大多数复杂的应用程序都有后台线程仍在运行。]
有证据表明延迟返回onStop最多 200 毫秒是不好的。
----- 或者是否存在任何证据表明可以在前台执行此操作？-----
----- 或者大型应用程序编写者做什么？-----
注意：我看到了很多意见。我不需要再听任何意见了。寻找证据。
注意：我对创建 Android 将继续运行的某些服务或其他解决方案的建议不感兴趣。我并不是在谈论足够长的工作来证明这一点。我说的是每个重要的应用程序在被告知要终止时所做的普通工作。
更新：我很欣赏到目前为止两个回复中提供的信息，但我觉得有一个要点被忽视了：
onStop与所有其他 UI 回调之间有一个至关重要的区别：
当应用程序从 onStop 返回时，返回行为是应用程序向操作系统发出的一个声明，表明该应用程序现在可以被安全地终止。 正确的？这不就是onStop的本质吗？
因此，从逻辑上讲，应用程序在完成所有关键工作之前不应从 onStop 返回。
（是的，显然应该设计应用程序，以便能够尽快完成关键工作。但我们不要失去这里的要点。如果你返回，你就是在告诉操作系统它现在可以安全地杀死你。如果它确实立即杀死了你，并且你的应用程序状态被搞乱了，因为你在未完成的后台线程上完成了这项工作，那么你的方法就有缺陷。不是吗？ 我正在尝试看看出了什么问题在我的分析中......）
更新 #2 在与 @CommonsWare 的讨论中（请参阅他的答案下的评论），我了解到IntentService 可以完成我想要的任务，并且不需要向用户询问任何额外的权限。
我本来想到的是iOS，它对后台工作非常严格。我相信任何此类方案都需要 iOS 下的额外应用程序许可。我避免额外的应用程序权限，以免吓跑任何用户。
因此，作为一名经验丰富的 iOS 应用程序开发人员，但作为一名经验较少的 Android 开发人员，我不知道自己需要的答案是：
因为 IntentService 会继续运行，而且启动成本不高，也不需要额外的应用权限，所以使用 IntentService 启动后台工作没有“缺点”，可以让 onStop 及时返回，同时确保关键工作完毕。
我已经接受了CommonsWare的回答。
更新#3根据 @zgc7009 在评论中的问题以及我的回复评论，我还应该确保所有关键信息始终被持久存储。请参阅这些评论，了解直到 onStop 之前未存储的内容的详细信息，这导致我发布了这个问题。这种不断更新的方法的优点是，即使应用程序崩溃了，它也会有所帮助。
注意：即使应用程序消失，用于保存关键信息的机制仍然必须保证完成（为了可靠性）。[或者至少是数据不会被半途改变的“交易保证”。]我可能会使用 IntentService 作为实现这一目标的一部分。（我们的数据是序列化的 XML，因此我们的代码需要运行，直到完成关键数据的序列化，并刷新并关闭该本地文件。）
即使应用程序正在关闭（onStop）
onStop()是 上的一个方法Activity。当 Activity 不再可见时，它将被调用。这可能与应用程序是否“关闭”有任何关系。例如，从一个活动转换到另一个触发器onStop()，配置更改也是如此（默认情况下）。
当然，onStop 是 Android 应该（也许必须）宽松地给予应用程序时间来完成关键工作的一个 UI 调用。
这不是“宽大”的问题。onStop()在主应用程序线程上调用。您在主应用程序线程上执行的任何操作都会占用该线程，从而阻止 Android 在该线程上执行其他工作。由于 UI 是由主应用程序线程驱动的，因此在您占用主应用程序线程期间，您的 UI 将被冻结onStop()。
请注意，这并不是 所独有的onStop()。任何占用主应用程序线程的地方都是 UI 被冻结的地方。Android 开发人员采用术语“jank”来专门表示这种行为。
您可能会觉得 200 毫秒的 UI 冻结是完全可以接受的。其他开发商可能不会。用户可能会也可能不会。
但这在 onStop 期间重要吗？在 onPause 期间这会很糟糕，但是 onStop 呢？
在很多情况下，确实如此。仅仅因为该onStop()Activity 不再位于前台并不意味着您的所有Activity 都不位于前台，除非您只有一个 Activity 并且这不是配置更改。
Android 在决定是否可以终止应用程序时会考虑该正在运行的线程的存在
它不会，除非该线程由 a 管理Service（在这种情况下，Android 会考虑该线程Service，而不是线程）。
为了扭转局面，我对您拥有的任何证据非常感兴趣，表明 Android 将在onStop()被调用后约 200 毫秒内终止您的进程。否则，您的线程将毫无问题地运行完成。
我对我所见过的讨论 onStop 不同性质的文档的失败特别感兴趣
那是因为onStop()在其他人眼中并没有什么不同。欢迎您相信它是不同的，但请不要指望其他人会“重新整理”已经写过的有关 Android 应用程序开发的内容，以适应您的世界观。
有证据表明，将 onStop 返回延迟最多 200 毫秒是不好的。
“不好”是一个主观的描述。可以说明的是：
onStop()在主应用程序线程上调用（为了证明这一点，请记录线程 ID）
占用主应用程序线程会阻止该线程上完成其他工作（这是线程运行方式的基础）
Android 的目标是在 60fps 的基础上更新 UI，即~16ms/帧
~200ms 相当于 60fps 下的 ~12 帧（长分割）
当应用程序从 onStop 返回时，返回行为是应用程序向操作系统发出的一个声明，表明该应用程序现在可以被安全地终止。
“应用程序”不会从onStop(). onStop()是 上的一个方法Activity。一个应用程序可能有零个、一个或多个活动。onStop()与移动到后台的应用程序松散相关，但onStop()也会在其他情况下被调用，如本答案前面所述。
如果你回来，你就告诉操作系统它现在可以安全地杀死你
您假设未能返回onStop()将使您的进程永远存活。onStop()是一个咨询事件，告诉您“嘿，您的活动已移至后台”。onStop()从负责终止进程以释放系统 RAM 的操作系统进程返回的速度并不重要。
| 归档时间： |
|
| 查看次数： |
160 次 |
| 最近记录： |