android 源码之message机制

messagequeue的数据结构

• 链表

class MessageQueque{
    Message messages;
}

class Message{
    Message next;// 实现queue
    Bundle data; // 跨进程通信
    Runnable callBack; // 回调
    int flag; // 基础类型
    long when; // 消息设置的执行时间
    Handler target; // 用于与messagequeue交互
}

• MessageQueue 如何实现queue的结构的

class MessageQueue{
    Message mMessages; // queue 的head
    bool enqueueMessage(Message msg, long when){
        // 加入队列
        // 1.check message的合法性
        // 2.以下在同步锁内完成
        // 2.1 设置message的状态
        // 2.2 遍历链表 根据消息的when值按照时间的先后顺序，将message 插入到链表中
        //// 2.2.1 插入到头部，1）队列为空，2）新消息要立即处理 when = 0, 3.messge的when<头部消息执行的时间
        //// 2.2.2 插入到队列中间位置，根据执行时间先后顺序
        // 2.3 判断是否要通过epoll唤醒线程执行队列里任务
        // 2.3 判断条件needWake与mBlocked相关，只有在block的时候才出发唤醒线程.具体赋值逻辑在next中
        // 需要wakeup的情况
        // 情况1：当前enque的msg可以处于消息queue的头部，或者当前queue为空, 且当前queu处于block状态
        // 情况2：queue的头部为屏障，且插入的消息是最早的异步消息
    }
    
    Message next(){
        // 从队列中找一个任务执行
        // 个人觉得这是message Handler最核心的部分
        // 1. mPtr 校验， mPtr对应的是native的一个对象指针(对应地址)
        // 2. 进入一个大循环
        for(;;){
            //[开始步骤]
            if(nextPollTimeoutMillis!=0){
                // 分析见[]
                Binder.flushPendingCommands();
            }
            
            // epoll 会被挂起，具体底层逻辑后面详细说明
            nativePollOnce(prt,time); nextPollTimeoutMillis);
            
            // 同步执行
            synchronized(this){
                // 1.1 如果当前设置了同步屏障， 则取第一条异步消息
                // 1.2 否则直接取第一条消息
                // 2.1 如果消息执行的时间还未到达， 计算执行时间nextPollTimeoutMillis
                // 2.2 从链表上剔除了message，并且返回message，执行后续的callback
                mBlocked = false; // 找到可执行的消息设置为false
                // 3 处理IdleHanlder的逻辑
                // 3.1 如果没有，会将就继续到[开始步骤]
                mBlocked = true; // 注意此时block会被设置为true
                // 3.2 如果有，执行空闲回调， nextPollTimeoutMillis = 0 
                // 立马执行 继续执行[开始步骤]
            }
            
        }
    }
}

Binder搞事情之flushPendingCommands 分析
Binder.flushPendingCommands() 对应会去调用c层

android_os_Binder_flushPendingCommands(){
    // IPCThreadState 是用于进程间通信的
    IPCThreadState::self()->flushCommands();
}

进一步回调用talkwithDirver

status_t IPCThreadState::talkWithDriver(bool doRecive){
    binder_write_read bwr;
    /*省略前奏*/ 
    // doRecive 为false时只写，不读
    if (doReceive && needRead) {
        bwr.read_size = mIn.dataCapacity();
        bwr.read_buffer = (long unsigned int)mIn.data();
    } else {
        bwr.read_size = 0;
        bwr.read_buffer = 0;
    }
    
    // 当同事没有输入输出的时候则直接返回
    if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;
    /*省略部分不紧要代码*/
    do{
        // ioctl 内核api，通过内核操作binder驱动读写
        if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
            err = NO_ERROR;
    }while(err == -EINTR);
    
    return err;
}

总结：调用flushPendingCommands，是为了及时处理binder线程里面的写操作

class Looper{
    public static void loop(){
        // 脑补一个黑人问号？ 为什么是static修饰的. 原因是可以通过ThreadLocal 获取到当前线程looper从而获取到任务队列Messagequeque. 当然也是用synchronized{}变成一个成员变量
        // Binder.clearCallingIdentity(); // call 1
        // final long ident = Binder.clearCallingIdentity(); // call 2
        // 为什么这里要调用两次why, 特么第一感觉是bug？世纪谜题
        // 调用这一句大概意思就是，以下的调用都是在执行本进程的方法
        for(;;;){
            // 循环，从队列中获取要执行的任务
            Message msg = queque.next(); //对，没错,block住了, 这里回答了为什么不是死循环，不会死循环造成cpu 100%
            
            if(msg != null){
                // 之前一坨代码可以忽略，重点就这一句
                // [Looper#]target 是一个hanlder对象, ===>Handler dispatchMessage
                // 看源码之前可以猜一猜，
                // 1.首先肯定是Runnable, callbackrun 执行掉, 2.或者交给Handler 自己处理handleMessage处理
                msg.target.dispatchMessage(msg);
            }
            // 下面又在搞事情，clearCallingIdentity 又来一发，什么鬼
            final long newIdent = Binder.clearCallingIdentity();
            
            // 回收消息
            msg.recycle()；
        }
    }
}

//搞事情之 Binder.clearCallingIdentity() 分析
看Binder.java 里面有
restoreCallingIdentity()与之对应

去c层验证一下吧

android_util_Binder.cpp{
    static jlong android_os_Binder_clearCallingIdentity(JNIEnv* env, jobject clazz){
            return IPCThreadState::self()->clearCallingIdentity();
    }
}

IPCThreadState 是每个Zygote进程fork的子进程都会有一个ProcessState, IPCThreadState，用与创建binder线程
进行线程之间通信, 这里面保存着Identity(PID, UID)

int64_t IPCThreadState::clearCallingIdentity()
{
    int64_t token = ((int64_t)mCallingUid<<32) | mCallingPid;
    clearCaller();
    return token;
}

这里的返回值为token 保存了当前进程的uid 和 pid， 高32位为uid, 低32位为pid

总结: 这个方法的作用是 重置当前进程里的Identity, 将当前的进程中保存的(PID，UID)换成当前的PID UID, 只有这样在校验权限的时候才可以有权限调用本进程的方法
关于权限的最终校验的是在ActivityMananger 中的checkComponentPermission可以具体去看，这里不展开了

class Handlder{ 
    // 对，没错跟想象的一样
    public void dispatchMessage(){
        // 1 有callback ，callback处理
        // 2 没有的话交给handleMessage 处理
    }
}

• 同步屏障
  MessageQueue.java postSyncBarrier()
  Message.java setAsynchronous()

set synBarier, 作用，可以调整messagequeu 消息的优先级
message消息的优先级一般是按照，when， 执行时间进行排序

在某些情况下，需要调整优先于同步消息执行，设置的方法就是
使用同步屏障， postSyncBarrier， 然后将消息设置为setAsynchronous。
这样messagequeue 在next()方法里，就会忽略前面的普通同步消息，优先执行异步消息

使用案例：
ViewRootImpl.java

    void scheduleTraversals(){
        // ....
        // 先设置一个同步屏障        
        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
        mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    }

Choreographer.java

     public void postCallbackDelayed(int callbackType,
            Runnable action, Object token, long delayMillis) {
        //省略不紧要的
        postCallbackDelayedInternal(callbackType, action, token, delayMillis);
    }
    
    // 设置为同步消息
    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);
            }
        }
    }