问题:使用Local Service不外乎就是启动服务的时候开个线程让它自己跑起来,如果不使用Local Service,直接使用Thread,有何本质上的区别?或者换句话说,为什么值得使用Local Service?我能想得到的一个理由是:使用Local Service的App,能够让OS视为后台进程而不至于那么容易被kill掉。除此之外呢?
答:
作者:rlei
链接:https://www.zhihu.com/question/19591125/answer/15998566
来源:知乎
著作权归作者所有,转载请联系作者获得授权。
链接:https://www.zhihu.com/question/19591125/answer/15998566
来源:知乎
著作权归作者所有,转载请联系作者获得授权。
把Service等同于thread或process是一个非常常见的误解。需要强调又强调的第一点是,Android的Service是一个Context,并不必然等于一个额外的thread。如果你有仔细看文档(Service | Android Developers),里面专门强调
为什么强调说"longer running"的"component"? 非常明显,这里是和Activity这种活跃周期相对短暂的component对比而言。一旦用户切换到其他应用,当前Activity就必须pause, stop甚至被destroy,不能在后台处理其他事务。需要强调的事,严格来说你仍然可以在activity里创建自己的worker thread或async task之类做后台的事情,但这样做没有任何保障——因为一旦你所有的activity都被切换到了后台,系统随时可能kill掉你的process,你的后台任务随时可能悄无声息的死掉。
Activity为什么这样设计?Windows下面的窗口在最小化的时候不是一样可以处理消息或者继续运行吗?这是另外一个话题,不过回答也很简单:这是移动设备,内存/电池都有限。
对你的应用而言,通过在manifest里声明Service,把需要后台相对长期运行的逻辑放在Service里,你便获得了这样的保障:只要系统内存不是极端不够用,你的Service一定不会被kill掉。对系统而言,当看到一个进程里有Service在运行,这个进程就具有较高的优先级,会在内存不足被杀的行列里排得比较靠后。
可是前面不是强调了Service并不等于process或thread吗?为什么上面又在说杀进程什么的?这里再次强调,你可以把Service看成一砣代码,用来在后台做些事情,仅此而已。至于这砣代码在哪里运行,完全是取决于你自己的喜好。你的local service,如果不建立worker thread,仍然是在你的应用进程的主线程即UI线程里运行。如果你不想阻塞UI线程,你就建一个worker thread。但这些细节,Android framework并不怎么care,它只知道你声明了一个service,然后在你的manifest里面找到这个service是声明在哪个process里运行,那么这个process就不容易被kill。
什么时候选择local service(即不指定额外的进程),什么时候选择remote service(额外的进程)?通常我们会把真的需要长期运行的service(例如IM之类)放在单独的进程里,这样UI所在的进程在必要的时候仍然可以被系统kill掉来腾出内存。而local service通常用来处理一些需要短期运行但仍然超出activity活动周期的任务,打个比方,发送短信或彩信。这样的任务执行完以后,service就可以stop自己,仍然不妨碍整个UI进程被回收掉。
- A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
- A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).
为什么强调说"longer running"的"component"? 非常明显,这里是和Activity这种活跃周期相对短暂的component对比而言。一旦用户切换到其他应用,当前Activity就必须pause, stop甚至被destroy,不能在后台处理其他事务。需要强调的事,严格来说你仍然可以在activity里创建自己的worker thread或async task之类做后台的事情,但这样做没有任何保障——因为一旦你所有的activity都被切换到了后台,系统随时可能kill掉你的process,你的后台任务随时可能悄无声息的死掉。
Activity为什么这样设计?Windows下面的窗口在最小化的时候不是一样可以处理消息或者继续运行吗?这是另外一个话题,不过回答也很简单:这是移动设备,内存/电池都有限。
对你的应用而言,通过在manifest里声明Service,把需要后台相对长期运行的逻辑放在Service里,你便获得了这样的保障:只要系统内存不是极端不够用,你的Service一定不会被kill掉。对系统而言,当看到一个进程里有Service在运行,这个进程就具有较高的优先级,会在内存不足被杀的行列里排得比较靠后。
可是前面不是强调了Service并不等于process或thread吗?为什么上面又在说杀进程什么的?这里再次强调,你可以把Service看成一砣代码,用来在后台做些事情,仅此而已。至于这砣代码在哪里运行,完全是取决于你自己的喜好。你的local service,如果不建立worker thread,仍然是在你的应用进程的主线程即UI线程里运行。如果你不想阻塞UI线程,你就建一个worker thread。但这些细节,Android framework并不怎么care,它只知道你声明了一个service,然后在你的manifest里面找到这个service是声明在哪个process里运行,那么这个process就不容易被kill。
什么时候选择local service(即不指定额外的进程),什么时候选择remote service(额外的进程)?通常我们会把真的需要长期运行的service(例如IM之类)放在单独的进程里,这样UI所在的进程在必要的时候仍然可以被系统kill掉来腾出内存。而local service通常用来处理一些需要短期运行但仍然超出activity活动周期的任务,打个比方,发送短信或彩信。这样的任务执行完以后,service就可以stop自己,仍然不妨碍整个UI进程被回收掉。