android中的进程和线程

来源:互联网 发布:大数据登录页面素材 编辑:程序博客网 时间:2024/04/30 02:53

参考文档http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle

当一个应用的组件开始运行,并且这个应用没有其它的组件在运行,系统会为这个应用启动一个新的Linux进程,这个进程只有一个线程.默认情况下,一个应用的所有组件都运行在一个进程和线程(主线程)中.如果一个应用的组件开始运行,并且已经存在这个应用的线程了(因为这个应用的另一个组件已经运行了),于是这个组件就会在这个已有的进程中启动并且运行在同一线程中.然而,你完全可以安排不同的组件运行于不同的进程,并且你可以为任何程序创建另外的线程.


进程

默认下,同一个应用的所有组件都运行在同一个进程中并且大多数程序不必改变这一状况.然而,如果你非要与众不同,也可以通过修改manifest文件实现.

manifest文件中的所有支持android:process属性的那些项(<activity>,<service>, <receiver>, <provider>)都可以指定一个进程,于是这些组件就会在这个进程中运行.你可以设置这个属性使每个组件运行于其自己的进程或只是其中一些组件共享一个进程.你也可以设置android:process以使不同应用的组件们可以运行于同一个进程—假如这些应用共享同一个用户ID并且有相同的数字证书.

<application>元素也支持android:process属性,用于为所有的组件指定一个默认值.

Android可能在某些时刻决定关闭一个进程,比如内存很少了并且另一个进程更迫切的需要启动时.进程被关闭时,其中的组件们都被销毁.如果重新需要这些组件工作时,进程又会被创建出来.

当决定关闭哪些进程时,Android系统会衡量各进程与用户的紧密程度.例如,比起一个具有可见的activity的进程,那些所含有的activity是全部不可见的进程更容易被关闭.如何决定一个进程是否被关闭,取决于进程中运行的组件们的状态.决定关闭进程的规则将在下面讨论.

进程的生命期

Android系统会尽量维持一个进程的生命,直到最终需要为新的更重要的进程腾出内存空间。为了决定哪个该杀哪个该留,系统会跟据运行于进程内的组件的和组件的状态把进程置于不同的重要性等级。当需要系统资源时,重要性等级越低的先被淘汰。

重要性等级被分为5个档。下面列出了不同类型的进程的重要性等级(第一个进程类型是最重要的,也是最后才会被杀的):

1前台进程


用户当前正在做的事情需要这个进程。如果满足下面的条件,一个进程就被认为是前台进程:

这个进程拥有一个正在与用户交互的Activity(这个ActivityonResume()方法被调用)

这个进程拥有一个绑定到正在与用户交互的activity上的Service

这个进程拥有一个前台运行的Service — service调用了方法startForeground().

这个进程拥有一个正在执行其任何一个生命周期回调方法(onCreate(),onStart(),onDestroy())的Service

这个进程拥有正在执行其onReceive()方法的BroadcastReceiver


通常,在任何时间点,只有很少的前台进程存在。它们只有在达到无法调合的矛盾时才会被杀--如内存太小而不能继续运行时。通常,到了这时,设备就达到了一个内存分页调度状态,所以需要杀一些前台进程来保证用户界面的反应

2可见进程

一个进程不拥有运行于前台的组件,但是依然能影响用户所见。满足下列条件时,进程即为可见:

这个进程拥有一个不在前台但仍可见的Activity(它的onPause()方法被调用)。当一个前台activity启动一个对话框时,就出了这种情况。

3服务进程

一个可见进程被认为是极其重要的。并且,除非只有杀掉它才可以保证所有前台进程的运行,否则是不能动它的。

这个进程拥有一个绑定到可见activityService

一个进程不在上述两种之内,但它运行着一个被startService()所启动的service

尽管一个服务进程不直接影响用户所见,但是它们通常做一些用户关心的事情(比如播放音乐或下载数据),所以系统不到前台进程和可见进程活不下去时不会杀它。


4后台进程

一个进程拥有一个当前不可见的activity(activityonStop()方法被调用)

这样的进程们不会直接影响到用户体验,所以系统可以在任意时刻杀了它们从而为前台、可见、以及服务进程们提供存储空间。通常有很多后台进程在运行。它们被保存在一个LRU(最近最少使用)列表中来确保拥有最近刚被看到的activity的进程最后被杀。如果一个activity正确的实现了它的生命周期方法,并保存了它的当前状态,那么杀死它的进程将不会对用户的可视化体验造成影响。因为当用户返回到这个activity时,这个activity会恢复它所有的可见状态。


5空进程

一个进程不拥有入何active组件。

保留这类进程的唯一理由是高速缓存,这样可以提高下一次一个组件要运行它时的启动速度。系统经常为了平衡在进程高速缓存和底层的内核高速缓存之间的整体系统资源而杀死它们。


跟据进程中当前活动的组件的重要性,Android会把进程按排在其可能的最高级别。例如,如果一个进程拥有一个service和一个可见的activity,进程会被定为可见进程,而不是服务进程。

另外,如果被其它进程所依赖,一个进程的级别可能会被提高—一个服务于其它进程的进程,其级别不可能比被服务进程低。

因为拥有service的进程比拥有后台activitie的进程级别高,所以当一个activity启动一个需长时间执行的操作时,最好是启动一个服务,而不是简单的创建一个工作线程。尤其是当这个操作可能比activity的生命还要长时。例如,一个向网站上传图片的activity,应该启动一个service,从而使上传操作可以在用户离开这个activity时继续在后台执行。使用一个service保证了这个操作至少是在"服务进程"级别,而不用管activity是否发生了什么不幸。这同样是广播接收者应该使用service而不是简单地使用一个线程的理由。

线程


当一个应用被启动,系统创建一个执行线程,叫做"main"。这个线程是十分重要的,因为它主管向用户界面控件派发事件。其中包含绘图事件。它也是你的应用与界面工具包(android.widgetandroid.view包中的组件)交互的地方。于是main线程也被称为界面线程。


系统不会为每个组件的实例分别创建线程。所有运行于一个进程的组件都在界面线程中被实例化,并且系统对每个组件的调用都在这个线程中派发。 结果,响应系统调用的方法(比如报告用户动作的onKeyDown()或一个生命周期回调方法)永远在界面线程中进行。


例如,当用户触摸屏幕上的一个按钮时,你的应用的界面线程把触摸事件派发给控件,然后控件设置它的按下状态再向事件队列发出一个自己界面变得无效的请求,界面线程从队列中取出这个请求并通知这个控件重绘它自己。


当你的应用在响应用户交互时需执行大量运算时,这种单线程的模式会带来低性能,除非你能正确的优化你的程序。特别的,如果所有事情都在界面线程中发生,执行比如网络连接或数据库请求这样的耗时操作,将会阻止整个界面的响应。当线程被阻塞时,就不能派发事件了,包括绘图事件。从用户的角度看,程序反应太慢了。甚至更糟的是,如果界面线程被阻塞几秒钟(大5秒钟吧),用户就户抱怨说程序没反应了,用户可能因而退出并删掉你的应用。


此外,Andoid界面不是线程安全的。所以你绝不能在一个工作线程中操作你的界面—你只能在界面线程中管理的你的界面。所以,对于单线程模式有两个简单的规则:

1不要阻塞界面线程

2不要在界面线程之外操作界面。


工作线程

由于上述的单线程模式,不要阻塞你的界面线程以使你的应用的界面保持响应是非常重要的,那么如果你有不能很快完成的任务,你应把它们放在另一个线程中执行(后台线程或工作线程)

例如,下面是的代码是响应click事件,在另外一个线程中下载一个图片并在一个ImageView中显示它:

[java] view plain copy
  1. public void onClick(View v) {  
  2.     new Thread(new Runnable() {  
  3.         public void run() {  
  4.             Bitmap b = loadImageFromNetwork("http://example.com/image.png");  
  5.             mImageView.setImageBitmap(b);  
  6.         }  
  7.     }).start();  
  8. }  

第一眼,这看起来能很好的工作,因为它创建了一个新线程来进行网络操作。然而它违反了第二条规则:不要在界面线程之外操作界面—它简单的在工作线程中修改了ImageView。这会导至未定义的异常出现,并且难以调试追踪。


为了能改正这个问题,Android提供了很多从其它线程来操作界面的方法。下面是可用的方法们:

1 Activity.runOnUiThread(Runnable)

2 View.post(Runnable)

3 View.postDelayed(Runnable,long)


例如,你可以用View.post(Runnable)来修正上面的问题:

[java] view plain copy
  1. public void onClick(View v) {  
  2.     new Thread(new Runnable() {  
  3.         public void run() {  
  4.             final Bitmap bitmap = loadImageFromNetwork("http://example.com/image.png");  
  5.             mImageView.post(new Runnable() {  
  6.                 public void run() {  
  7.                     mImageView.setImageBitmap(bitmap);  
  8.                 }  
  9.             });  
  10.         }  
  11.     }).start();  
  12. }  

现在这个实现终于是线程安全的了:网络操作在另一个线程中并且ImageView在界面线程中改变。

然而,随着操作的复杂性的增加,这样的代码会变得复杂和难于维护。处理主线程的复杂操作以及处理主线程中发送的消息,你可以在你的主线程中考虑一下使用Handler。可能最好的操作,还是继承AsyncTask类,它简化了UI与主线程之间交互的操作。


0 0