Android Handler整体梳理以及热点问题解析

1.Handler整体概括

在Android开发中会经常在子线程中进行一些操作,当操作完成后会通过Handler发送一些数据到主线程,通知主线程做相应的操作,Handler原理:子线程 Handler 主线程 其实构成了线程模型中的经典问题 生产者-消费者 模型。 生产者-消费者模型:生产者和消费者在同一时间段内用同一个存储空间,生产者往存储空间添加数据,消费者从存储空间中取走数据。

Android Handler整体梳理以及热点问题解析

 

优点:保证数据生产消费的顺序(通过MessageQueue先进先出)-不管是生产者(子线程)还是消费者(主线程)都只依赖缓冲区(Handler),生产者和消费者之间不会相互持有,使他们之间没有任何耦合。

1.1Handler机制相关类

Handler:发消息和收消息

Looper:用于轮寻消息队列,一个线程只能有一个Looper

Message : 消息实体

MessageQueue : 消息队列用于存储信息和管理消息

ThreadLocal : 为每个线程提供单独的存储空间

ThreadLocalMap: ThreadLocal的内部类,set方法控制 对于每一个ThreadLocal只有一个value(looper)

Thread: 线程中持有一个threadLocals变量(ThreadLocal.ThreadLocalMap)

类图

Android Handler整体梳理以及热点问题解析

1.2创建Looper

子线程:子线程中如果需要自己创建Looper调用Looper.prepare()方法,然后调用Looper.loop()方法。

主线程: 主线程ActivityThread中的main方法已经为我们创建了Looper

public static void main(String[] args) {
    //省略其它代码.......
    Looper.prepareMainLooper(); //初始化Looper以及MessageQueue
    ActivityThread thread = new ActivityThread();
    thread.attach(false);
    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }
    if (false) {
        Looper.myLooper().setMessageLogging(new
                LogPrinter(Log.DEBUG, "ActivityThread"));
    }
    Looper.loop(); //开始轮寻
    throw new RuntimeException("Main thread loop unexpectedly exited");
}

Looper.prepareMainLooper()

public static void prepareMainLooper() {
    prepare(false); // 消息队列不允许quit,并创建Main Looper
    synchronized (Looper.class) {
        if (sMainLooper != null) {
            throw new IllegalStateException("The main Looper has already been prepared.");
        }
        sMainLooper = myLooper();
    }
}

prepare(boolean quitAllowed)

private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {//不为null表示当前线程已经创建了Looper
        throw new RuntimeException("Only one Looper may be created per thread");
        //每个线程只能创建一个Looper
    }
    sThreadLocal.set(new Looper(quitAllowed)); //将looper存储到ThreadLocal中,这样get的时候就不会为null,并且MessageQueue不允许quit
}

1.3创建MessageQueue以及Looper与当前线程绑定

private Looper(boolean quitAllowed) {
    mQueue = new MessageQueue(quitAllowed); //创建MessageQueue
    mThread = Thread.currentThread(); //当前线程绑定
}

MessageQueue的构造方法


MessageQueue(boolean quitAllowed) {
    mQuitAllowed = quitAllowed; //mQuitAllowed决定了队列是否可以销毁,主线程的队列不可以被销毁需要传入false,在MessageQueue的quit方法中判断的
    mPtr = nativeInit();
}

Looper.loop() 轮寻

public static void loop() {
    final Looper me = myLooper(); //通过sThreadLocal.get()方法获取ThreadLocal中保存的Looper对象
    if (me == null) {
        throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }
    final MessageQueue queue = me.mQueue; //把Looper对象中的消息队列取出

    // 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
        //刚创建的MessageQueue中是没有消息的,等到Handler sendMessage enqueueMessage后队列里才有消息。
        if (msg == null) {
            // No message indicates that the message queue is quitting.
            return;
            //return之后会执行ActivityThread中main的 throw new RuntimeException(“Main thread loop unexpectedly exited”)
            //接着整个主线程就会退出了。所以就是说,在主线程中当loop()方法没有轮询到消息的时候。主线程就直接退出了
            //所以在这里我们知道了Looper.loop()消息循环,一旦退出消息循环,那么应用也就退出了。
            // 什么时候在进入呢??????
        }
        // 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);// msg.target就是绑定的Handler,调用Handler的dispatchMessage去处理消息
        //后面代码省略......
    }
}

创建Handler

最常见的handler创建方式

Handler handler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
        super.handleMessage(msg);
    }
};

创建方式2:在内部调用this(null, false)

public Handler(Callback callback, boolean async) {
    //前面代码省略......
    mLooper = Looper.myLooper(); //获取ThreadLocal中的looper对象,子线程中使用Handler需要调用Looper.prapare,或者使用getMainLooper来使用主线程looper
                                 //否则会抛出RunTimeException
    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;
}

创建Message

可以直接new Message,但是更好的方式是Message.obtain. 因为可以检查是否有可以复用的Message,避免过多的创建、销毁Message对象达到优化内存和性能的目的。

public static Message obtain(Handler h) {
    Message m = obtain(); //Message重载的obtain方法
    m.target = h; //Message的handler和我们的handler绑定
    return m;
}

obtain()

public static Message obtain() {
    synchronized (sPoolSync) { //同步锁,保证线程安全
        if (sPool != null) {
            Message m = sPool; //sPool就是Handler dispatchMessage后通过recycleUncheckd回收以复用的Message
            sPool = m.next;
            m.next = null;
            m.flags = 0; // clear in-use flag
            sPoolSize--;
            return m;
        }
    }
    return new Message();
}

Message和Handler的绑定

创建Message的时候可以通过Message.obtain(Handler h)这个构造方法进行绑定。当然在Handler中的enqueueMessage也进行了绑定,所有发送Message的方法都会调用此方法入队,所以在创建Message的时候可以不绑定

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
    msg.target = this; //Message和Handler 进行绑定
    if (mAsynchronous) {
        msg.setAsynchronous(true);
    }
    return queue.enqueueMessage(msg, uptimeMillis);
}

Handler发送消息

Handler发送消息的重载方法有很多,常用的主要有两个。1.sendMessage(Message), 它通过一系列重载方法的调用,sendMessage调用sendMessageDelayed,继续调用sendMessageAtTime,继续调用enqueueMessage,继续调用messageQueue的enqueueMessage方法,将Msg保存到消息队列中,最终由Looper取出,交给Handler的dispatchMessage进行处理。

dispatchMessage方法中,message中的callback是一个Runnable对象,如果callback不为空,则直接调用callback的run方法,否则判断Handler自己的mCallback是否为null,mCallback在Handler构造方法中初始化,在主线程中直接通过无参构造方法new出来的为null,所以会直接执行后面的handleMessage()方法。

public void dispatchMessage(Message msg) {
    if (msg.callback != null) {
        handleCallback(msg); //Msg中的Runnable是否为null, callback在message的构造方法中初始化或者时候使用handler.post(Runnable)时才不为null
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {//mCallback是一个callback对象,通过无参构造函数创建出来的handler该属性为null,所以不执行
                return;
            }
        }
        handleMessage(msg); //最终执行这里
    }
}
private static void handleCallback(Message message) {
    message.callback.run();
}

Handler处理消息

最后调用handleMessage(Message)来处理消息,整个Handler机制的流程就结束了。

总结

Handler sendMessage发送消息到消息队列MessageQueue, 然后looper调用自己的loop方*寻MessageQueue里面的每一个Message。当Message达到了可以执行的时候就开始执行,执行后调用Message绑定的Hander来处理消息。

整体流程如下图

Android Handler整体梳理以及热点问题解析

2.Handler中的难点问题

线程同步问题

Handler是用于线程之间通信的,但是它产生的根本不只是用于UI处理,而更多的是handler是真个app通信的框架,可以在ActivityThread里面感受到,整个app都是用它来进行线程见的协调。Handler是如何保证自己的线程安全的呢????

 

Handler机制里面最主要的类是MessageQueue,这个类是所有Message的存储仓库,消息的管理其实就两点:1.消息入库(enqueueMessage),2.消息出库(next)。所以只要在进出口确保线程安全就可以了。

boolean enqueueMessage(Message msg, long when) {
    if (msg.target == null) {  //msg必须有绑定的Handler,否则不允许入列
        throw new IllegalArgumentException("Message must have a target.");
    }
    if (msg.isInUse()) { //当前的msg是否已经有其它Handler在使用
        throw new IllegalStateException(msg + " This message is already in use.");
    }
    synchronized (this) { //添加同步锁,保证在同一时刻只有一个Msg插入到MessageQueue中
        if (mQuitting) { //当前的Thread时候已经被销毁
            IllegalStateException e = new IllegalStateException(
                    msg.target + " sending message to a Handler on a dead thread");
            Log.w("MessageQueue", 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;
}

synchronized锁是一个内置锁,也就是由系统控制锁的lock unlock时机。

sychronized(this) 说明对所有调用MessageQueue对象的线程来说,他们都是互斥的,然而在我们Handler里面,一个线程是对应着一个唯一的Looper对象,然而Looper中又只有一个唯一的MessageQueue,所以我们主线程就只有一个MessageQueue对象,也就是说,所有的子线程向主线程发送消息的时候,主线程一次都只会处理一个消息,其它都需要等待,这样消息队列就不会出现混乱。

next函数

Message next() {
    //上面代码省略.......
    for (;;) {
        if (nextPollTimeoutMillis != 0) {
            Binder.flushPendingCommands();
        }

        nativePollOnce(ptr, nextPollTimeoutMillis);

        synchronized (this) {  //读取消息时加锁,锁仍然是MessageQueue对象
            // Try to retrieve the next message.  Return if found.
            final long now = SystemClock.uptimeMillis();
            Message prevMsg = null;
            Message msg = mMessages;
            if (msg != null && msg.target == null) {
                // Stalled by a barrier.  Find the next asynchronous message in the queue.
                do {
                    prevMsg = msg;
                    msg = msg.next;
                } while (msg != null && !msg.isAsynchronous());
            }
            if (msg != null) {
                if (now < msg.when) {
                    // Next message is not ready.  Set a timeout to wake up when it is ready.
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else {
                    // Got a message.
                    mBlocked = false;
                    if (prevMsg != null) {
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    msg.next = null;
                    if (false) Log.v("MessageQueue", "Returning message: " + msg);
                    return msg;
                }
            } else {
                // No more messages.
                nextPollTimeoutMillis = -1;
            }

            // Process the quit message now that all pending messages have been handled.
            if (mQuitting) {
                dispose();
                return null;
            }

            // If first time idle, then get the number of idlers to run.
            // Idle handles only run if the queue is empty or if the first message
            // in the queue (possibly a barrier) is due to be handled in the future.
            if (pendingIdleHandlerCount < 0
                    && (mMessages == null || now < mMessages.when)) {
                pendingIdleHandlerCount = mIdleHandlers.size();
            }
            if (pendingIdleHandlerCount <= 0) {
                // No idle handlers to run.  Loop and wait some more.
                mBlocked = true;
                continue;
            }

            if (mPendingIdleHandlers == null) {
                mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
            }
            mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
        } //锁结束
        //省略 后面代码........
}

enqueueMessage 和 next 函数,它们都使用了synchronized(this), 保证next函数和enqueueMessage函数能够实现互斥,保证多线程访问的时候messageQueue的有序进行

消息机制之同步屏障

同步屏障,view绘制中用 同步屏障

在Handler机制中,线程的消息都是放在同一个MessageQueue里面,取消息的时候是互斥取消息,而且只能从头部取消息,而添加消息是按照消息的执行的先后顺序进行排序的。这时候存在一个问题,同一个时间范围内的消息,如果它是需要立刻执行的,怎么处理?? 按照常规的方法,我们需要等待队列轮寻到这条消息的时候才能执行,那就不符合需求了。所以需要给这条消息开一个绿色通道,这个绿色通道就是同步屏障的概念。

同步屏障是什么?

屏障字面意思就是阻碍的意思,同步屏障就是阻碍同步消息,只让异步消息通过。

如何开启同步屏障?

 /**
     * @hide
     */
    public int postSyncBarrier() {
        return postSyncBarrier(SystemClock.uptimeMillis());
    }

    private int postSyncBarrier(long when) {
        // Enqueue a new sync barrier token.
        // We don't need to wake the queue because the purpose of a barrier is to stall it.
        synchronized (this) {
            final int token = mNextBarrierToken++;
            //在消息池获取msg
            final Message msg = Message.obtain();
            msg.markInUse();
            
            //就是这里!!!!! 初始化msg对象的时候,并没有给target赋值,因此target == null
            msg.when = when;
            msg.arg1 = token;

            Message prev = null;
            Message p = mMessages;
            if (when != 0) {
                while (p != null && p.when <= when) {
                    // 如果开启同步屏障的时间(假设为T)T不为0,且当前的同步消息里有时间小于T的,则prev也不为null
                    prev = p;
                    p = p.next;
                }
            }
            if (prev != null) { // invariant: p == prev.next
                msg.next = p; //如果prev不为null,执行顺序就是prev -> msg -> p
                prev.next = msg;
            } else {
                msg.next = p; //如果prev为null,执行顺序就是msg-> p
                mMessages = msg;
            }
            return token;
        }
    }

可以看到,Message对象初始化的时候并没有给target赋值,因此 target == null的来源就找到了。一条target == null的消息就进入了消息队列

那么开启了同步屏障之后,所谓的异步消息又是如何被处理的呢??

Handler消息机制,消息最终处理是在消息轮寻器Looper#loop()中,而loop()循环中会调用MessageQueue#next从消息队列中取出消息。

Message next() {
        // Return here if the message loop has already quit and been disposed.
        // This can happen if the application tries to restart a looper after quit
        // which is not supported.
        final long ptr = mPtr;
        if (ptr == 0) {
            return null;
        }
        int pendingIdleHandlerCount = -1; // -1 only during first iteration
        //如果nextPollTimeoutMillis=-1, 一直阻塞不会超时
        //如果nextPollTimeoutMillis=0, 不会阻塞,直接返回
        //如果nextPollTimeoutMillis>0, 最长阻塞nextPollTimeoutMillis毫秒(超时)
        // 如果期间有程序唤醒会立即返回
        int nextPollTimeoutMillis = 0;
        for (;;) {
            if (nextPollTimeoutMillis != 0) {
                Binder.flushPendingCommands();
            }
            nativePollOnce(ptr, nextPollTimeoutMillis);
            synchronized (this) {
                // Try to retrieve the next message.  Return if found.
                final long now = SystemClock.uptimeMillis(); //获取系统开机到现在的时间
                Message prevMsg = null;
                Message msg = mMessages; //当前链表的头节点
                //关键点!!!!!!!!!!!!!! 如果target == null,那么他就是屏障,需要循环遍历一直往后找到第一个异步消息
                if (msg != null && msg.target == null) {
                    // Stalled by a barrier.  Find the next asynchronous message in the queue.
                    do {
                        prevMsg = msg;
                        msg = msg.next;
                    } while (msg != null && !msg.isAsynchronous());
                }
                if (msg != null) {
                    //如果有消息需要处理,先判断时间有没有到,如果没有到的话设置一下阻塞时间,场景如常用的postDelay
                    if (now < msg.when) {
                        // Next message is not ready.  Set a timeout to wake up when it is ready.
                        //计算出离执行时间还要多久,然后赋值给nextPollTimeoutMillis
                        //表示nativePollOnce方法要等待nextPollTimeoutMillils时长后返回
                        nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                    } else {
                        // Got a message.
                        mBlocked = false;
                        if (prevMsg != null) {
                            prevMsg.next = msg.next;
                        } else {
                            mMessages = msg.next;
                        }
                        msg.next = null;
                        if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                        msg.markInUse();
                        return msg;
                    }
                } else {
                    // No more messages.
                    nextPollTimeoutMillis = -1;
                }

                // Process the quit message now that all pending messages have been handled.
                if (mQuitting) {
                    dispose();
                    return null;
                }

                // If first time idle, then get the number of idlers to run.
                // Idle handles only run if the queue is empty or if the first message
                // in the queue (possibly a barrier) is due to be handled in the future.
                if (pendingIdleHandlerCount < 0
                        && (mMessages == null || now < mMessages.when)) {
                    pendingIdleHandlerCount = mIdleHandlers.size();
                }
                if (pendingIdleHandlerCount <= 0) {
                    // No idle handlers to run.  Loop and wait some more.
                    mBlocked = true;
                    continue;
                }

                if (mPendingIdleHandlers == null) {
                    mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
                }
                mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
            }

            // Run the idle handlers.
            // We only ever reach this code block during the first iteration.
            for (int i = 0; i < pendingIdleHandlerCount; i++) {
                final IdleHandler idler = mPendingIdleHandlers[i];
                mPendingIdleHandlers[i] = null; // release the reference to the handler

                boolean keep = false;
                try {
                    keep = idler.queueIdle();
                } catch (Throwable t) {
                    Log.wtf(TAG, "IdleHandler threw exception", t);
                }

                if (!keep) {
                    synchronized (this) {
                        mIdleHandlers.remove(idler);
                    }
                }
            }

            // Reset the idle handler count to 0 so we do not run them again.
            pendingIdleHandlerCount = 0;

            // While calling an idle handler, a new message could have been delivered
            // so go back and look again for a pending message without waiting.
            nextPollTimeoutMillis = 0;
        }
    }

从上面就可以看出,当消息队列开启同步屏障的时候(即标识为msg.target == null),消息机制在处理消息的时候有限处理异步消息,这样同步屏障就起到了一种过滤和优先级的作用。

Android Handler整体梳理以及热点问题解析

如上图所示,在消息队列中有同步消息和异步消息(黄色部分)以及一道墙---同步屏障(红色部分)。有了同步屏障的存在,msg_2和msg_M这两个异步消息就可以优先处理,而后面的msg_3等同步消息则不会被处理。那么这些同步消息什么时候被处理??? 就需要先移除这个同步屏障removeSyncBarrier

同步屏障应用场景

更新View时相关的消息即为异步消息,需要优先处理

void scheduleTraversals() {
        if (!mTraversalScheduled) {
            mTraversalScheduled = true;
            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier(); //开启同步屏障
            //发送异步消息
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
            if (!mUnbufferedInputDispatch) {
                scheduleConsumeBatchedInput();
            }
            notifyRendererOfFramePending();
            pokeDrawLockIfNeeded();
        }
    }

postCallback最终走到

private void postCallbackDelayedInternal(int callbackType,
            Object action, Object token, long delayMillis) {
        if (DEBUG_FRAMES) {
            Log.d(TAG, "PostCallback: type=" + callbackType
                    + ", action=" + action + ", token=" + token
                    + ", delayMillis=" + delayMillis);
        }
        synchronized (mLock) {
            final long now = SystemClock.uptimeMillis();
            final long dueTime = now + delayMillis;
            mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);

            if (dueTime <= now) {
                scheduleFrameLocked(now);
            } else {
                Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
                msg.arg1 = callbackType;
                msg.setAsynchronous(true); //设置为异步消息类型
                mHandler.sendMessageAtTime(msg, dueTime);
            }
        }
    }

这样就开启了同步屏障,并且发送了异步消息,这样系统就会有限处理这些异步消息。

最后,在处理完成后需要移除同步屏障

void unscheduleTraversals() {
        if (mTraversalScheduled) {
            mTraversalScheduled = false;
            mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier); //移除同步屏障
            mChoreographer.removeCallbacks(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
        }
    }

一个线程有几个Handler

一个线程可以有n个Handler,可以new很多个,没有限制。

一个线程可以有几个Looper

一个线程只允许有一个looper,在子线程中创建looper的方法Looper.prepare 创建的looper对象保存在当前线程的ThreadLocal的ThreadLocalMap中(threadlocal, looper)键值对的形式存储下来。

同一个线程再次调用prepare时会抛出异常,并且map中存储时对于key threadlocal只有唯一的一个looper与之对应

Handler内存泄漏原因?为什么其它内部类没有说过这个问题

在java中非静态内部类默认可以访问外部类的所有变量和方法,因为非静态内部类持有了外部类的引用。还有匿名内部类

当我们在Activity中实现一个非静态Handler内部类,来处理一些延时事件,这种情况下就会出现内存泄漏的情况

当Activity销毁时,Handler还有延迟消息没有处理完,这时候因为Handler持有activity的引用,导致activity无法被回收,造成内存泄漏

 //匿名内部类    
    Handler handler=new Handler(){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    };
 
 //非静态内部类
    protected class AppHandler extends Handler {

        @Override
        public void handleMessage(Message msg) {
            switch (msg.what) {
                // TODO: 2019/4/30  
            }
        }
    }

解决方法:

1.在activity销毁时,清空Handler中正在执行或未执行的Callback和Message

// 清空消息队列,移除对外部类的引用
    @Override
    protected void onDestroy() {
        super.onDestroy();
        mHandler.removeCallbacksAndMessages(null);
    }
  
    //Handler源码中removeCallbacksAndMessages()注释含义
    /**
     * Remove any pending posts of callbacks and sent messages whose
     * <var>obj</var> is <var>token</var>.  If <var>token</var> is null,
     * all callbacks and messages will be removed.
     */
    public final void removeCallbacksAndMessages(Object token) {
        mQueue.removeCallbacksAndMessages(this, token);
    }

2.声明为静态内部类,静态内部类不会持有外部类的引用,所以不会影响GC时activity的回收,然后在静态内部类中手动持有activity的弱引用,这样gc的时候即使被持有也会被回收

private static class AppHandler extends Handler {
        //弱引用,在垃圾回收时,被回收
        WeakReference<Activity> activity;

        AppHandler(Activity activity){
            this.activity=new WeakReference<Activity>(activity);
        }

        public void handleMessage(Message message){
            switch (message.what){
                //todo
            }
        }
    }

3.即使内存泄漏了,在handler处理完后,下次GC时也会回收本次未被回收的内存

其它内部类中一般不会有延时的操作,所以没有遇到过内存泄漏的问题

主线程中可以直接new Handler, 子线程中如果想new Handler需要做哪些准备

1.因为主线程在ActivityThread的main函数中已经做了prepare,并且主线程的MessageQueue是不允许退出的

2.子线程中new 一个handler之前,需要Looper.prepare 这里面会创建一个looper对象,并将这个looper对象和当前子线程绑定

Looper.loop

Looper.quitSafely

子线程中处理完了消息就要调用quit 来跳出loop循环

Loop死循环为什么不会导致应用卡死

应用卡死也就是ANR的原因有两点:5s内没有响应输入的事件,比如按键或者屏幕触摸等,2.广播接收器处理超时 10s内没完成

首先我们需要知道,每一个应用都有一个属于自己的虚拟机,也就是说每个应用都有自己的Main函数,这个main函数就是ActivityThread.java中的main函数

为什么每个应用都有自己的main函数?

当我们在launcher界面开启一个app时,系统会用zygote给我们分配一个虚拟机,应用就运行在这个虚拟机上,之后执行的就是ActivityThread的main函数,在main函数中创建主线程的Looper对象

之后就Looper.loop一直轮寻整个主线程的消息

当MessageQueue中没有消息时,会阻塞在queue.next(),在next()函数中阻塞在nativePollOnce(ptr, nextPollTimeoutMillis)

这时不会导致ANR,这里就涉及到Linux pipe/epoll nativePollOnce()被阻塞时,主线程会释放CPU资源,进入休眠状态. 直到下个消息到达或者有事务发生,会通过pipe管道写入数据来唤醒主线程工作,就可以继续工作了.

这里主线程进入休眠状态和死循环是有区别的.

死循环是指主线程死锁在这里,一直执行某一块代码,无法再响应其他事件.

休眠状态是指在内核状态里,主线程被挂起,线程状态转移到休眠状

很多线程有很多Handler往MessagQueue添加数据,MessageQueue如何确保线程安全的

MessageQueue队列入队enqueueMessage和出队next都使用了同步锁 synchronized,并且锁对象是同一个 this也就是当前的MessageQueue对象

所以首先 入队和出队 不会同一时间发生,然后就是多个线程同时enqueueMessage时也不会出问题

使用Message时该如何创建它

使用Message的obtain方法,因为可以检查是否有可以复用的Message,避免过多的创建、销毁Message对象达到优化内存和性能的目的

并且obtain方法内也添加了同步锁,保证了线程安全

HandlerThread存在的意义

HandlerThread是Thread的子类,就是一个线程,只是它在自己的线程里面帮我们创建了Looper

优点:

1.使用方便,方便初始化,方便获取线程looper, 在HandlerThread的run方法中做了prepare, 获取looper对象,和loop()的操作,不需要自己操作

2.保证了线程安全

用法:

public class MainActivity extends AppCompatActivity {
    private HandlerThread myHandlerThread ;
    private Handler handler ;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //创建一个线程,线程名字:handler-thread
        myHandlerThread = new HandlerThread( "handler-thread") ; //这里就避免自己new thread并且获取looper对象更容易
        //开启一个线程
        myHandlerThread.start();
        //在这个线程中创建一个handler对象
        handler = new Handler( myHandlerThread.getLooper() ){
            @Override
            public void handleMessage(Message msg) {
                super.handleMessage(msg);
                //这个方法是运行在 handler-thread 线程中的 ,可以执行耗时操作
                Log.d( "handler " , "消息: " + msg.what + "  线程: " + Thread.currentThread().getName()  ) ;
            }
        };
        //在主线程给handler发送消息
        handler.sendEmptyMessage( 1 ) ;
            new Thread(new Runnable() {
            @Override
            public void run() {
             //在子线程给handler发送数据
             handler.sendEmptyMessage( 2 ) ;
            }
        }).start() ;
    }
    @Override
    protected void onDestroy() {
        super.onDestroy();
        //释放资源
        myHandlerThread.quit() ;
    }
}

 

 

上一篇:Handler中Looper死循环为什么不会导致应用卡死?


下一篇:花了几天研究Handler消息机制的成果