android多线程编程详解,关于Handler ,Looper , Message , MessageQueue

时间:2021-11-09 17:29:57

本期的多线程主题与Android相关,侧重讲解在Android中如何用好多线程,需要你有Java的多线程基础。
首先我们思考几个问题,在Android应用中为什么要用多线程?为了解决哪些问题?或者为了实现哪些功能?有哪些好处?请先思考一分钟,再继续往下看。
学习而不思考就像吃东西而不嚼,要么无法下咽,要么尝不出味道,同时都会影响消化吸收。控制一下你那脱缰野马一样的好奇心吧,先思考再往下看。
————————————————飘过这条分隔线,我们继续——————————————————
1. 为什么要用多线程

这里列出几个原因:
a) 提高用户体验或者避免ANR
在事件处理代码中需要使用多线程,否则会出现ANR(Application is not responding),或者因为响应较慢导致用户体验很差。

android多线程编程详解,关于Handler  ,Looper , Message , MessageQueue

图1 ANR对话框


b) 异步
应用中有些情况下并不一定需要同步阻塞去等待返回结果,可以通过多线程来实现异步,例如:上一点中提到的,你的应用中的某个Activity需要从云端获取一些图片,加载图片比较耗时,这时需要使用异步加载,加载完成一个图片刷新一个,见下面图2、图3 。
c) 多任务
例如多线程下载。
后两点与Java中的多线程应用没有太大区别,不细说。
下面重点说明第一点,即如何减少事件响应的时间从而提高用户体验,以及如何避免ANR。
2. 为什么通过多线程可以提高用户体验、避免ANR
大家还记得我在群里说过的移动开发的“三不要”原则吗?即:不要让我想、不要让我等、不要让我烦。响应慢了用户需要等,等的次数多了就会烦,你的应用离被卸载不远了。
首先我们来了解一下Android应用程序的main线程,它负责处理UI的绘制,Android系统为了防止应用程序反应较慢导致系统无法正常运行做了一个处理,一种情况是当用户输入事件在5秒内无法得到响应,那么系统会弹出ANR对话框,由用户决定继续等待还是强制结束应用程序(另一种情况是BroadcastReciever 超过10秒没执行完也会弹出ANR对话框)。
即使你的程序中某个事件响应不超过5秒钟,人眼可以分辨的时间是0.1秒,小于0.1秒基本感觉不出来,超过0.2秒用户就能感觉到有点儿卡了,俗称打嗝现象,2秒以上就很慢了,用户体验会很差。有同学说我可以用进度条啊,但你的程序中不能到处都是进度条,否则那个圈圈会把用户转晕的,好像在对用户说,画个圈圈烦死你……
比如某些应用,它要显示很多图片,还好它是异步的,不过在图片加载完成前每个图片的位置上都有一个圈圈,让人看了很烦。你可以变通一下,图片加载成功之前显示一个默认的图片,加载成功后再刷新一下即可,何必弄那么多进度条呢?

android多线程编程详解,关于Handler  ,Looper , Message , MessageQueue

图2 加载图片完成前显示默认图片,加载完成后再刷新

android多线程编程详解,关于Handler  ,Looper , Message , MessageQueue

图3 加载图片完成前显示默认图片,加载完成后再刷新

android多线程编程详解,关于Handler  ,Looper , Message , MessageQueue

图4 转晕你,烦死你

事件处理的原则:所有可能耗时的操作都放到其他线程去处理。
Android中的Main线程的事件处理不能太耗时,否则后续的事件无法在5秒内得到响应,就会弹出ANR对话框。那么哪些方法会在 Main线程执行呢?
1) Activity的生命周期方法,例如:onCreate()、onStart()、onResume()等
2) 事件处理方法,例如onClick()、onItemClick()等
通常Android基类中以on开头的方法是在Main线程被回调的。
提高应用的响应性,可以从这两方面入手。
一般来说,Activity的onCreate()、onStart()、onResume()方法的执行时间决定了你的应用首页打开的时间,这里要尽量把不必要的操作放到其他线程去处理,如果仍然很耗时,可以使用SplashScreen。使用SplashScreen最好用动态的,这样用户知道你的应用没有死掉。
                                                                                          android多线程编程详解,关于Handler  ,Looper , Message , MessageQueue

图5 动态SplashScreen

android多线程编程详解,关于Handler  ,Looper , Message , MessageQueue

图6 静态SplashScreen


当用户与你的应用交互时,事件处理方法的执行快慢决定了应用的响应性是否良好,这里分两种情况:
1) 同步,需要等待返回结果。例如用户点击了注册按钮,需要等待服务端返回结果,那么需要有一个进度条来提示用户你的程序正在运行没有死掉。一般与服务端交互的都要有进度条,例如系统自带的浏览器,URL跳转时会有进度条。
2) 异步,不需要等待返回结果。例如微博中的收藏功能,点击完收藏按钮后是否成功执行完成后告诉我就行了,我不想等它,这里最好实现为异步的。
无论同步异步,事件处理都可能比较耗时,那么需要放到其他线程中处理,等处理完成后,再通知界面刷新。
这里有一点要注意,不是所有的界面刷新行为都需要放到Main线程处理,例如TextView的setText()方法需要在Main线程中,否则会抛出CalledFromWrongThreadException,而ProgressBar的setProgress()方法则不需要在Main线程中处理。
当然你也可以把所有UI组件相关行为都放到Main线程中处理,没有问题。可以减轻你的思考负担,但你最好了解他们之间的差别,掌握事物之间细微差别的是专家。把事件处理代码放到其他线程中处理,如果处理的结果需要刷新界面,那么需要线程间通讯的方法来实现在其他线程中发消息给Main线程处理。
3. 如何实现线程间通讯
在Android中有多种方法可以实现其他线程与Main线程通讯,我们这里介绍常见的两种。
1) 使用AsyncTask
AsyncTask是Android框架提供的异步处理的辅助类,它可以实现耗时操作在其他线程执行,而处理结果在Main线程执行,对于开发者而言,它屏蔽掉了多线程和后面要讲的Handler的概念。你不了解怎么处理线程间通讯也没有关系,AsyncTask体贴的帮你做好了。不过封装越好越高级的API,对初级程序员反而越不利,就是你不了解它的原理。当你需要面对更加复杂的情况,而高级API无法完成得很好时,你就杯具了。所以,我们也要掌握功能更强大,更*的与Main线程通讯的方法:Handler的使用。


2)
使用Handler
这里需要了解Android SDK提供的几个线程间通讯的类。

2.1 Handler
Handler
在android里负责发送和处理消息,通过它可以实现其他线程与Main线程之间的消息通讯。
2.2 Looper
Looper
负责管理线程的消息队列和消息循环
2.3 Message
Message
是线程间通讯的消息载体。两个码头之间运输货物,Message充当集装箱的功能,里面可以存放任何你想要传递的消息。
2.4 MessageQueue
MessageQueue
是消息队列,先进先出,它的作用是保存有待线程处理的消息。
它们四者之间的关系是,在其他线程中调用Handler.sendMsg()方法(参数是Message对象),将需要Main线程处理的事件添加到Main线程的MessageQueue中,Main线程通过MainLooper从消息队列中取出Handler发过来的这个消息时,会回调Handler的handlerMessage()方法。

除了以上两种常用方法之外,还有几种比较简单的方法
3) Activity.runOnUiThread(Runnable)
4) View.post(Runnable)
View.postDelayed(Runnable, long)
5) Handler.post
Handler.postDelayed(Runnable, long)
4.
利用线程池提高性能
这里我们建议使用线程池来管理临时的Thread对象,从而达到提高应用程序性能的目的。
线程池是资源池在线程应用中的一个实例。了解线程池之前我们首先要了解一下资源池的概念。在JAVA中,创建和销毁对象是比较消耗资源的。我们如果在应用中需要频繁创建销毁某个类型的对象实例,这样会产生很多临时对象,当失去引用的临时对象较多时,虚拟机会进行垃圾回收(GC),CPU在进行GC时会导致应用程序的运行得不到相应,从而导致应用的响应性降低。

资源池就是用来解决这个问题,当你需要使用对象时,从资源池来获取,资源池负责维护对象的生命周期。

了解了资源池,就很好理解线程池了,线程池就是存放对象类型都是线程的资源池。

 

下面是地址

Handler+ExecutorService(线程池)+MessageQueue模式+缓存模式 (详细的不能在详细的讲解)

http://www.eoeandroid.com/thread-210082-1-1.html