什么是最“耐死”的？ Android 上的组件？
我正在寻找最合适的类作为从我的活动调用的异步任务的调度程序。
我认为它可能是其中之一：
- Application 的子类；
- 服务的子类；
- 我自己的静态东西。
至于我 - 实施第三个选择更简单。但问题是它会比Service或Application更“耐死”吗？另外，很有趣的是，什么会活得更久——应用程序还是服务？我的猜测是，应用程序的生命周期与应用程序（Android 中的任务）进程的生命周期相同。
所以基本上我需要根据它们的“抗死亡”质量来排列这些选项，因为我想依赖最“静态”的东西。
更新：
最初这个问题是在 2010 提出的，当时 (1) Android 是开发人员的新平台，(2) Google 文档过于模糊（在某些情况下甚至是关于应用程序组件生命周期和整个应用程序流程生命周期的误导）。
I'm looking for the most suitable class to be a dispatcher for AsyncTasks invoked from my Activities.
I think it could be one of these:
- subclass of Application;
- subclass of Service;
- my own static stuff.
As for me - it's simlier to implement the 3rd choice. But the question is will it be more "death-resistant" than Service or Application? Also it's very interesting what will live longer - Application or Service? My guess is the Application lives as long as the app (task in terms of Android) process lives.
So basically I need to range those options by their "death-resistant" quality, because I'd like to rely on the most "static" thing.
UPDATE:
Originally the question was asked in 2010, when (1) Android was new platform for developers and (2) Google documentation was too vague (in some cases it was even misleading) about app components life-cycles and the entire app process life-cycle.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您绝对应该使用 Service。
这背后的主要原因 -
Service有自己记录的生命周期，而应用程序则没有。Application实例，就像任何静态变量一样，几乎可以随时被系统杀死，您不会收到任何回调，也无法停止此过程。因此，任何未保存的数据（所有静态变量）都将丢失。另一方面，
Service不能被系统静默杀死，至少应该先调用onDestroy()方法。通过这样的回调，您可以将状态保存到某些持久内存（如 SharedPreferences、文件、数据库等），并在下次应用程序或服务启动时恢复该状态。You should definitely use a Service.
The main reason behind this -
Servicehas it's own documented life-cycle, while Application doesn't.Applicationinstance, like any of your static variables, can be killed by system almost at any time, you will not receive any callback and can't stop this process. So, any unsaved data (all static variables) will be lost.On the other hand,
Servicecan't be killed by system silently, at leastonDestroy()method should be called first. Having such callback, you can save your state to some persistent memory (like SharedPreferences, file, database, etc) and restore that state next time your Application or Service starts.