Android中的内存管理

先从我们刚接触Android的一些疑惑开始：
1. 我们退出了全部Activity后，应用还在后台运行。为什么不能真正的退出应用？
2. 似乎线程也能完成service的功能，为什么不能用线程代替service？

要回答第一个问题，就要从Android的内存管理机制说起。
Android的内存管理有一些不同寻常，如同Java或.net，Android有自己的运行时状态和虚拟机(Dalvik)去管理程序内存。但不像其它框架(比如Java，程序打开时该程序的进程开始，程序退出时该程序的进程也就结束)，android同时也管理进程的生命周期。Android会通过停止或杀死低优先级的进程来确保高优先级的进程能够正常工作。换句话说进程的清理是由Android说了算的，它会在系统遭遇性能瓶颈时去杀死低优先级的进程以确保系统和高优先级进程能够正常运行，而不是简单的程序退出后该程序的进程也同进结束。在Android中如果系统有足够的可用内存，那么应用的进程就不会被销毁，效果就是你在重新运行该应用时速度会很快。
 
每一个Android的应用都运行在一个独立的进程和虚拟机实例中，所有的应用进程都由Android运行时环境进行统一管理（在需要的时候停止或杀死某个进程）。
 
前面提到了一个概念：进程的优先级。Android进程的优先级主要划分为：活动进程或前台进程（Foreground）、可见进程、已启动的服务进程（Service）、后台进程、空进程。其中前台进程优先级最高，空进程优先级最低。文章最后附有所有进程优先级的详细解释。
 
那么现在我们来回答第二个问题：为什么应用中启动的后台线程不能代替Service。
一个应用变为不可见后（比如所有Activity都退出）就会从可见进程变为后台进程，如果系统没有足够的内存去运行更高优先级的进程，后台进程就很有可能被销毁。在应用中启动的线程其实是由应用进程派生的，如果应用进程被销毁那么其派生的所有线程也会一并被销毁。通过前面关于进程优先级的介绍我们可以见到，服务进程的优先级大于后台进程。事实上服务进程（Service）会被看做前台进程，有很高的优先级，除非前台进程或和用户交互的可见进程没有内存可用，服务进程是不会被销毁的。
 
说到这里我们应该已经明白了，我们的应用一旦变为后台进程，那么当内存告急时，我们的应用进程很可能被销毁以释放内存给更高优先级的进程，其派生的线程也当然一并被销毁。所以有可能你在应用中启动的想长时间运行的一个后台线程莫名其妙的就消失了。但Service有很高的优先级，一般不会发生这种情况。
 
当然Service还有其它的作用，比如进程间通信和其封装的一些功能，生命周期管理等。那是另外一个话题了。
 
附：进程优先级说明：
 
Active Processes Active (foreground) processes are those hosting applications with components currently interacting with the user. These are the processes Android is trying to keep responsive by reclaiming resources. There are generally very few of these processes, and they will be killed only as a last resort.

Active processes include:

Activities in an “active” state; that is, they are in the foreground and responding to user events. You will explore Activity states in greater detail later in this chapter.
Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.
Services that are executing an onStart, onCreate, or onDestroy event handler.
Visible Processes Visible, but inactive processes are those hosting “visible” Activities. As the name suggests, visible Activities are visible, but they aren’t in the foreground or responding to user events. This happens when an Activity is only partially obscured (by a non-full-screen or transparent Activity). There are generally very few visible processes, and they’ll only be killed in extreme circumstances to allow active processes to continue.