Android开发中,一个Application,运行在一个进程中。这个Application的各种组件(四种组件),通常是运行在同一个进程中的。但是,并不是绝对的。由于某种需求,比如,你可以设置AppA的组件Activity_A,运行在另外一个进程(ProcessB),通过设置Activity_A的属性android:process来实现。
另外,由于某种需求,你也可以实现,将多个Application的组件,运行在同一个进程中。比如,AppA的组件ContentProviderA,AppB的组件Service,AppC的组件Activity_C,这三个组件可以设置运行在一个独立的进程中processTogether.只要设置相同的Linux 用户ID(android:sharedUsereId)。
这是关于进程和组件方面的关系。这些信息,与接下来的资源回收有关。当系统内存不足的时候,系统会按照进程的优先级来kill部分进程,优先级越低的进程,优先被Kill掉,而当某个进程被kill掉时,那么,在该进程中运行的组件,也会被销毁掉。
而进程的优先级,又是由运行在该进程中的组件的状态所决定。
进程的优先级,类型定义:
【
A process that is required for what the user is currently doing. A process is considered to be in the foreground if any of the following conditions are true:
Activity
that the user is interacting with (the Activity
‘s onResume()
method has been called).Service
that‘s bound to the activity that the user is interacting with.Service
that‘s running "in the foreground"—the service has called startForeground()
.Service
that‘s executing one of its lifecycle callbacks (onCreate()
, onStart()
, or onDestroy()
).BroadcastReceiver
that‘s executing its onReceive()
method.Generally, only a few foreground processes exist at any given time. They are killed only as a last resort—if memory is so low that they cannot all continue to run. Generally, at that point, the device has reached a memory paging state, so killing some foreground processes is required to keep the user interface responsive.
A process that doesn‘t have any foreground components, but still can affect what the user sees on screen. A process is considered to be visible if either of the following conditions are true:
Activity
that is not in the foreground, but is still visible to the user (its onPause()
method has been called). This might occur, for example, if the foreground activity started a dialog, which allows the previous activity to be seen behind it.Service
that‘s bound to a visible (or foreground) activity.A visible process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.
A process that is running a service that has been started with the startService()
method and does not fall into either of the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about (such as playing music in the background or downloading data on the network), so the system keeps them running unless there‘s not enough memory to retain them along with all foreground and visible processes.
A process holding an activity that‘s not currently visible to the user (the activity‘s onStop()
method has been called). These processes have no direct impact on the user experience, and the system can kill them at any time to reclaim memory for a foreground, visible, or service process. Usually there are many background processes running, so they are kept in an LRU (least recently used) list to ensure that the process with the activity that was most recently seen by the user is the last to be killed. If an activity implements its lifecycle methods correctly, and saves its current state, killing its process will not have a visible effect on the user experience, because when the user navigates back to the activity, the activity restores all of its visible state. See the Activities document for information about saving and restoring state.
A process that doesn‘t hold any active application components. The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it. The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.
】
5种类型的进程。从中,可以得到与实际工作有关系的信息是:
1.Service是会被销毁的;它跟Activity一样,都是会被销毁掉的。所以,在系统调用onDestroy方法时,要保存数据,如果你想让操作过的数据持久化的话。
2.如果一个Service,你想提高它的优先级,不想让它所在的进程被提前kill掉,当系统资源不足时,那么,让该Service所在的进程类型是Forground process,是一种方法。那么,也就是说,在Service中调用startForground()方法。(Android系统在评定一个进程的优先级时,是尽量往高优先级评定的,比如,只要该进程中的组件,具备了Froground process定义的特征,那么,该进程就会被评定为Froground Process)
3.其它方面,上述信息,可以指导实际的工作。
数据持久化方面
既然,Activity,Service都是会销毁的,那么,就必然要考虑,在工作没有完成的情况下,如何保存已经完成的工作,也就是保存相关的数据。
对于Service,则是在onDestroy方法中,添加保存数据的逻辑。如,启动一个线程,将数据写到数据库中;或者,直接采用writeObject的方法,保存对象的数据;或者,将数据,写到文件系统中。
对于Service,如果,再次启动的时候,要恢复上次的工作情况,则是从保存的区域读取过去保存的数据,然后,再继续。
对于Activity,系统则提供了比较多回调方法如下图:
假定,Activity_A在AppA中运行;Activity_B在AppB中运行。
1.当当前屏幕中的Activity_A被其他Activity_B取代了,系统会回调被取代Activity的onSaveInstanceState()方法,在该方法中,保存用户实现了操作数据。
2.因为,Activity_A是不可见的,那么,相应它所运行的进程AppA也具备低优先级。当系统内存不足时,AppA就被系统kill掉。
3.用户再次启动AppA,因为,Activity_A实现了onSaveInstanceState()方法,该方法在Activity_A不可见时,系统会回调,也就是保存了Activity_A的状态。
那么,在重新创建Activity_A时,onCreate方法的的state参数,是不会为空的,系统已经为你保存了该State,在你实现onSaveInstanceState()方法时。
所以,系统对待Activity,比对待Service要好,帮Activity保存了一个状态;而Service,则没有。在Service中,用户要保存数据,是要自己写到数据库或者文件系统中去。
全文完。
引用资料:
http://developer.android.com/guide/components/processes-and-threads.html
http://developer.android.com/guide/components/services.html
http://developer.android.com/guide/components/activities.html
Activity与Service的回收,布布扣,bubuko.com
原文:http://www.cnblogs.com/ttylinux/p/3922986.html