Android Handler消息派发机制源码分析

注:这里只是说一下sendmessage的一个过程,post就类似的
如果我们需要发送消息,会调用sendMessage方法

public final boolean sendMessage(Message msg) { return sendMessageDelayed(msg, 0); }

这个方法会调用如下的这个方法

public final boolean sendMessageDelayed(Message msg, long delayMillis) { if (delayMillis < 0) { delayMillis = 0; } return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis); }

接下来设定延迟时间,然后继续调用sendMessageAtTime方法

public boolean sendMessageAtTime(Message msg, long uptimeMillis) { MessageQueue queue = mQueue; if (queue == null) { RuntimeException e = new RuntimeException( this + " sendMessageAtTime() called with no mQueue"); Log.w("Looper", e.getMessage(), e); return false; } return enqueueMessage(queue, msg, uptimeMillis); }

这里获得了消息队列,检查队列是否存在,然后返回enqueMessage的方法的执行结果,这个结果是说明消息能否进入队列的一个布尔值

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) { msg.target = this; if (mAsynchronous) { msg.setAsynchronous(true); } return queue.enqueueMessage(msg, uptimeMillis); }

这里是对消息进行入队处理,下面就是在MessageQueue中对消息进行入队

boolean enqueueMessage(Message msg, long when) { if (msg.target == null) { throw new IllegalArgumentException("Message must have a target."); } if (msg.isInUse()) { throw new IllegalStateException(msg + " This message is already in use."); } synchronized (this) { if (mQuitting) { IllegalStateException e = new IllegalStateException( msg.target + " sending message to a Handler on a dead thread"); Log.w(TAG, e.getMessage(), e); msg.recycle(); return false; } msg.markInUse(); msg.when = when; Message p = mMessages; boolean needWake; if (p == null || when == 0 || when < p.when) { // New head, wake up the event queue if blocked. msg.next = p; mMessages = msg; needWake = mBlocked; } else { // Inserted within the middle of the queue. Usually we don't have to wake // up the event queue unless there is a barrier at the head of the queue // and the message is the earliest asynchronous message in the queue. needWake = mBlocked && p.target == null && msg.isAsynchronous(); Message prev; for (;;) { prev = p; p = p.next; if (p == null || when < p.when) { break; } if (needWake && p.isAsynchronous()) { needWake = false; } } msg.next = p; // invariant: p == prev.next prev.next = msg; } // We can assume mPtr != 0 because mQuitting is false. if (needWake) { nativeWake(mPtr); } } return true; }

就是对传递过来的消息进行一些封装然后放到队列中,至此我们的sendMessage处理完毕,返回的结果是进队是否成功的布尔值,那么究竟消息之后是如何被处理的呢?
我们可以看到在Handler构造的时候记录了一个Looper对象,也记录了一个回掉函数

public Handler(Callback callback, boolean async) { if (FIND_POTENTIAL_LEAKS) { final Class<? extends Handler> klass = getClass(); if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) && (klass.getModifiers() & Modifier.STATIC) == 0) { Log.w(TAG, "The following Handler class should be static or leaks might occur: " + klass.getCanonicalName()); } } mLooper = Looper.myLooper(); if (mLooper == null) { throw new RuntimeException( "Can't create handler inside thread that has not called Looper.prepare()"); } mQueue = mLooper.mQueue; mCallback = callback; mAsynchronous = async; }

这里的myLooper方法返回的是当前线程关联的一个Looper对象

public static @Nullable Looper myLooper() { return sThreadLocal.get(); }

当Looper实例化了以后会执行自己的prepare方法然后执行loop方法,loop方法就是不断的读取消息队列中的消息然后执行相应的操作的方法,因为是在其他线程中执行的循环所以不会影响其他线程

public static void loop() { final Looper me = myLooper(); if (me == null) { throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread."); } final MessageQueue queue = me.mQueue; // Make sure the identity of this thread is that of the local process, // and keep track of what that identity token actually is. Binder.clearCallingIdentity(); final long ident = Binder.clearCallingIdentity(); for (;;) { Message msg = queue.next(); // might block if (msg == null) { // No message indicates that the message queue is quitting. return; } // This must be in a local variable, in case a UI event sets the logger Printer logging = me.mLogging; if (logging != null) { logging.println(">>>>> Dispatching to " + msg.target + " " + msg.callback + ": " + msg.what); } msg.target.dispatchMessage(msg); if (logging != null) { logging.println("<<<<< Finished to " + msg.target + " " + msg.callback); } // Make sure that during the course of dispatching the // identity of the thread wasn't corrupted. final long newIdent = Binder.clearCallingIdentity(); if (ident != newIdent) { Log.wtf(TAG, "Thread identity changed from 0x" + Long.toHexString(ident) + " to 0x" + Long.toHexString(newIdent) + " while dispatching to " + msg.target.getClass().getName() + " " + msg.callback + " what=" + msg.what); } msg.recycleUnchecked(); } }

在循环中如果读取到了消息,就会执行dispatchMessage方法,然后分派完消息之后再执行一次recycleUnchecked方法来重用这个Message,我们看到dispatchMessage方法

public void dispatchMessage(Message msg) { if (msg.callback != null) { handleCallback(msg); } else { if (mCallback != null) { if (mCallback.handleMessage(msg)) { return; } } handleMessage(msg); } }

这里看到直接执行了一个handlerMessage方法,这个方法是一个回调方法,我们是必须实现的,否则Handler什么都不会做,为什么呢?还记得刚刚说构造Handler的时候我们记录了一个CallBack的回掉吗?Handler中的这个handlerMessage方法是一个空方法,如果我们重写了这个方法,在回调的时候就会执行我们先写下的代码,也就是接收到消息之后要做什么。

public interface Callback { public boolean handleMessage(Message msg); } public void handleMessage(Message msg) { }

这里简单说下整个过程: 
当我们实例化一个Handler的子类并重写handleMessage方法之后,这个时候系统已经帮我们做了几个事情 
1.实例化了一个消息队列MessageQueue 
2.实例化了一个关联的Looper对象,并让Looper不断的读取消息队列
3.把我们重写的handleMessage方法记录为我们需要回调的方法 
当我们执行Handler的sendMessage方法的时候,系统会把我们传过去的Message对象添加到消息队列,这个时候如果Looper读取到了消息,就会把消息派发出去,然后回调handleMessage方法,执行我们设定的代码。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持脚本之家。

时间: 2024-07-30 10:28:21

Android Handler消息派发机制源码分析的相关文章

Android Handler消息派发机制源码分析_Android

注:这里只是说一下sendmessage的一个过程,post就类似的 如果我们需要发送消息,会调用sendMessage方法 public final boolean sendMessage(Message msg) { return sendMessageDelayed(msg, 0); } 这个方法会调用如下的这个方法  public final boolean sendMessageDelayed(Message msg, long delayMillis) { if (delayMill

Android点击事件派发机制源码分析_Android

概述  一直想写篇关于Android事件派发机制的文章,却一直没写,这两天刚好是周末,有时间了,想想写一篇吧,不然总是只停留在会用的层次上但是无法了解其内部机制.我用的是4.4源码,打开看看,挺复杂的,尤其是事件是怎么从Activity派发出来的,太费解了.了解Windows消息机制的人会发现,觉得Android的事件派发机制和Windows的消息派发机制挺像的,其实这是一种典型的消息"冒泡"机制,很多平台采用这个机制,消息最先到达最底层View,然后它先进行判断是不是它所需要的,否则

Android点击事件派发机制源码分析

概述 一直想写篇关于Android事件派发机制的文章,却一直没写,这两天刚好是周末,有时间了,想想写一篇吧,不然总是只停留在会用的层次上但是无法了解其内部机制.我用的是4.4源码,打开看看,挺复杂的,尤其是事件是怎么从Activity派发出来的,太费解了.了解Windows消息机制的人会发现,觉得Android的事件派发机制和Windows的消息派发机制挺像的,其实这是一种典型的消息"冒泡"机制,很多平台采用这个机制,消息最先到达最底层View,然后它先进行判断是不是它所需要的,否则就

Android消息循环机制源码深入理解

Android消息循环机制源码 前言: 搞Android的不懂Handler消息循环机制,都不好意思说自己是Android工程师.面试的时候一般也都会问这个知识点,但是我相信大多数码农肯定是没有看过相关源码的,顶多也就是网上搜搜,看看别人的文章介绍.学姐不想把那个万能的关系图拿出来讨论. 近来找了一些关于android线程间通信的资料,整理学习了一下,并制作了一个简单的例子. andriod提供了 Handler 和 Looper 来满足线程间的通信.例如一个子线程从网络上下载了一副图片,当它下

React Native Android入门实战及深入源码分析系列(1)——Hello world

转载需注明出处:http://blog.csdn.net/minimicall?viewmode=contents 从今天起,我要分析React Native for Android的源码. 本系列主要是从使用和源码分析的角度来一步步的剖析React Native Android.当然,因为我对IOS不了解,所以,我只能分析安卓了. 首先来一个Hello world. 对于Rn 安卓的开发环境,本着不重复造轮子的思想,我就不再这里介绍了. 1. 创建一个工程 首先,我们需要创建一个Rn工程,通过

React Native Android入门实战及深入源码分析系列(2)——React Native源码编译

本文为老曾原创,转载需注明出处:http://blog.csdn.net/minimicall?viewmode=contents 在上一节中,我们通过一个相册的制作来学习了React Native编写.这一节我们需要开始学习React Native的源码. 学习源码,从编译源码开始. 首先,我们需要把代码从github中克隆下来. https://github.com/facebook/react-native.git 然后,我们可以切换到它的稳定分支,2016-03-30是我的操作时间,这个

android(安卓)手机铃声设置源码分析

代码其实没有几行,这里简单记录下学习的过程. Android系统启动时会扫描系统与SD卡中的对媒体文件,分别存入数据库sqlite中,以contentProvider的形式对外提供服务 路径:/data/data/com.android.providers.media/databases/XXX... 可以看到有2个db文件, 一个是系统的,一个是sd卡里的 用SQLite Expert打开internal.db,部分截图如下: 这里面记录了音频audio.视频video.图片images的相关

writeback机制源码分析

writeback相关数据结构 与writeback相关的数据结构主要有: 1,backing_dev_info,该数据结构描述了backing_dev的所有信息,通常块设备的request queue中会包含backing_dev对象. 2,bdi_writeback,该数据结构封装了writeback的内核线程以及需要操作的inode队列. 3,wb_writeback_work,该数据结构封装了writeback的工作任务. 各数据结构之间的关系如下图所示: 下面对各个数据结构做简要介绍.

Android源码分析-点击事件派发机制

转载请注明出处:http://blog.csdn.net/singwhatiwanna/article/details/17339857 概述 一直想写篇关于Android事件派发机制的文章,却一直没写,这两天刚好是周末,有时间了,想想写一篇吧,不然总是只停留在会用的层次上但是无法了解其内部机制.我用的是4.4源码,打开看看,挺复杂的,尤其是事件是怎么从Activity派发出来的,太费解了.了解Windows消息机制的人会发现,觉得Android的事件派发机制和Windows的消息派发机制挺像的