如果将数据保存到数据库中，在onPause（）或的onStop（）？ [英] When to save data to database, onPause() or onStop()?
问题描述
我知道这个问题已经被问了一百万次，我自己虽然我已经知道答案，而正确的是，只保证通话是在onPause（），所以你应该保存你的数据在那里。
不过，在Android的文档许多地方，他们一直建议不要干过重的活（如在数据库中写入数据）中的onPause（）方法，因为它会延迟活动之间的过渡。
根据表 Android开发者指南1
在onPause（）：该方法通常用于提交未保存的更改到持久性数据，停止动画和可消耗CPU等其他东西。它应该做任何它确实非常快，因为接下来的活动将不会被恢复，直到它返回。
Killable：YES
然后根据 Android开发者参考指南中的类似的表。
报告说，同样的事情，但：
Killable：pre-蜂窝
和他们增加一个小纸条，上面写着：
请注意，这些语义将开始蜂窝与那些针对现有的平台针对平台的应用程序之间略有变化。 与蜂窝启动，应用程序是不是在killable状态，直到它的onStop（）返回。这种影响时的onSaveInstanceState（包）可被称为（它可以安全地调用的onPause（后），并允许应用安全地等到的onStop（）来保存持久状态。
Killable
请注意，在上表中Killable栏目 - 为那些被标记为killable方法，在该方法在任何时候返回主办活动可能被系统杀死的过程中无正在执行其code另一条线路。
后的蜂窝（我不关心更早版本）： 那么，是不是确定假定任何Android设备（包括不同的ROMS）将确保在活动调用的onStop？这是做任何耗时的应用程序的存储写作最好的地方？
注：这是非常混淆，因为这里大多数的答案，网站，书籍，甚至是在线应用测试需要一个正确的答案，你应该把它保存在的onPause和NOT在的onStop 的
在将数据保存到数据库中，在onPause（）或的onStop（）？
无论是。他们几乎是一样的，尤其是在Android 3.0 +。
如果该接管前景中的活动是一个典型的全屏幕的活性，使较早的活性不再可见，的onPause（）和的onStop（）将被称为快速连续。
如果被接管前台活动的主题是更像一个对话框，在该在先活动仍清晰可见，的onPause（）将被调用，但没有的onStop（），直至作为活动不再是可见的（例如，用户现在presses HOME）。
大多数应用程序并不担心为主题的更像一个对话框的情况，在这种情况下的onPause（）和的onStop（ ）被称为后的下一个正确的，并且您可以派生的后台线程来保存你的数据在任何那些对你有意义。
不过，在Android的文档许多地方，他们一直建议不要干过重的活（如在数据库中写入数据）中的onPause（）方法，因为它会延迟活动之间的过渡。
同样是如此的onStop（），既是对这些方法被称为主应用程序线程上。
那么，是不是确定假定任何Android设备（包括不同的ROMS）将确保在活动调用的onStop？
两个的onPause（）和的onStop（）将有来自进程终止的角度看相同的特性。要么都有应该叫（正常情况下），或者两者都不是会被调用（比如，你崩溃，电池弹出手机的背面）。
这是做任何耗费时间的应用程序的存储写作最好的地方？
为的onPause（）或的onStop（）都很好地触发工作，在后台线程完成，坚持你的数据。如果preFER做的onStop的工作（），你是绝对欢迎这样做。就个人而言，我是一个的onPause（）的那种人。
I know this question has been asked a million times, I myself though that I already knew the answer and that the correct one was that the only guaranteed call is to onPause(), so you should save your data there.
However, in many places of android documentation they always suggest not doing heavy work (such as writing data in database) in the onPause() method as it will delay the transition between the activities.
According to Android Developer Guide in Table 1
onPause(): This method is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU, and so on. It should do whatever it does very quickly, because the next activity will not be resumed until it returns.
Killable: YES
Then according to Android Developer Reference Guide in the similar table.
It says the same thing but:
Killable: Pre-HONEYCOMB
And they add a little note that says:
Be aware that these semantics will change slightly between applications targeting platforms starting with HONEYCOMB vs. those targeting prior platforms. Starting with Honeycomb, an application is not in the killable state until its onStop() has returned. This impacts when onSaveInstanceState(Bundle) may be called (it may be safely called after onPause() and allows and application to safely wait until onStop() to save persistent state.
Killable
Note the "Killable" column in the above table -- for those methods that are marked as being killable, after that method returns the process hosting the activity may killed by the system at any time without another line of its code being executed.
FOR POST-HONEYCOMB (i dont care about earlier versions): So, is it OK to assume that any Android device (including different ROMS) will ensure a call to onStop on the activity? And this is the best place to make any time consuming storage writing of the App?
Note: This is extremely confusing as most answers here, sites, books, and even online android tests take as a correct answer that you should save it in onPause and NOT in onStop.
When to save data to database, onPause() or onStop()?
Either. They are nearly identical, particularly on Android 3.0+.
If the activity that is taking over the foreground is a typical full-screen activity, so that the earlier activity is no longer visible, onPause() and onStop() will be called in rapid succession.
If the activity that is taking over the foreground is themed to be more like a dialog, where the earlier activity is still visible, onPause() will be called, but not onStop(), until such time as the activity is no longer visible (e.g., user now presses HOME).
Most apps aren't worried about the "themed to be more like a dialog" scenario, in which case onPause() and onStop() are called one right after the next, and you can fork your background thread to save your data in whichever of those makes sense to you.
However, in many places of android documentation they always suggest not doing heavy work (such as writing data in database) in the onPause() method as it will delay the transition between the activities.
The same is true of onStop(), as both of those methods are called on the main application thread.
So, is it OK to assume that any Android device (including different ROMS) will ensure a call to onStop on the activity?
Both onPause() and onStop() will have the same characteristics from the standpoint of process termination. Either both should be called (normal case) or neither will be called (e.g., you crash, the battery pops out the back of the phone).
And this is the best place to make any time consuming storage writing of the App?
Either onPause() or onStop() are fine places to trigger the work, done on a background thread, to persist your data. If you prefer to do that work in onStop(), you are absolutely welcome to do so. Personally, I'm an onPause() kind of guy.
这篇关于如果将数据保存到数据库中，在onPause（）或的onStop（）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
