From 61d20a3cb098ea73eb8fc48e5e16dd6bbc4ed0e9 Mon Sep 17 00:00:00 2001 From: Omooo <869759698@qq.com> Date: Wed, 19 Aug 2020 13:56:32 +0800 Subject: [PATCH] Update --- blogs/Android/口水话/Binder.md | 2 +- blogs/Android/口水话/Handler.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/blogs/Android/口水话/Binder.md b/blogs/Android/口水话/Binder.md index 8ce8bd9..b7f68fe 100644 --- a/blogs/Android/口水话/Binder.md +++ b/blogs/Android/口水话/Binder.md @@ -44,7 +44,7 @@ Binder 驱动就会把这个请求交给 Binder 实体对象去处理,也就 到这里,已经讲完了 Client 端如何和 Binder 驱动进行交互的了,下面就讲 Service 端是如何和 Binder 驱动进行交互的。 -Service 端首先会开启一个 Binder 线程来处理进程间通信消息,也就是通过 new Thread 然后把该线程 joinThreadPool 注册到 Binder 驱动。注册呢也就是通过 BC_ECTER_LOOPER 命令协议来做的,接下来就是在 do while 死循环中调用 getAndExecuteCommand。它里面做的就是不断从驱动读取请求,也就是 talkWithDriver,然后再处理请求 executeCommand。在 executeCommand 中,就会根据 BR_TRANSACTION 来调用 BBinder Binder 实体对象的 onTransact 函数来进行处理,然后在发送一个 BC_REPLY 把响应结构返回给 Binder 驱动。Binder 驱动在接收到 BC_REPLY 之后就会向 Service 发送一个 BR_TRANSACTION_COMPLETE 协议表示 Binder 驱动已经收到了,在此同时呢,也会向 Client 端发送一个 BR_REPLY把响应回写给 Client 端。 +Service 端首先会开启一个 Binder 线程来处理进程间通信消息,也就是通过 new Thread 然后把该线程 joinThreadPool 注册到 Binder 驱动。注册呢也就是通过 BC_ENTER_LOOPER 命令协议来做的,接下来就是在 do while 死循环中调用 getAndExecuteCommand。它里面做的就是不断从驱动读取请求,也就是 talkWithDriver,然后再处理请求 executeCommand。在 executeCommand 中,就会根据 BR_TRANSACTION 来调用 BBinder Binder 实体对象的 onTransact 函数来进行处理,然后在发送一个 BC_REPLY 把响应结构返回给 Binder 驱动。Binder 驱动在接收到 BC_REPLY 之后就会向 Service 发送一个 BR_TRANSACTION_COMPLETE 协议表示 Binder 驱动已经收到了,在此同时呢,也会向 Client 端发送一个 BR_REPLY把响应回写给 Client 端。 需要注意的是,上面的 onTransact 函数就是 Service 端 AIDL 生成的 Stub 类的 onTransact 函数,这时一次完整的 IPC 通信流程就完成了。 diff --git a/blogs/Android/口水话/Handler.md b/blogs/Android/口水话/Handler.md index 31d992c..c59347e 100644 --- a/blogs/Android/口水话/Handler.md +++ b/blogs/Android/口水话/Handler.md @@ -20,6 +20,6 @@ Handler 消息机制比较简单: 然后就是核心逻辑了,在 Looper 的 loop 方法,它是一个死循环,里面做了三件事,调用 MessageQueue 的 next 方法取消息,然后通过 Message 的 target 也就是 handler 去 dispatchMessage 分发消息,最后回收消息。MessageQueue 的 next 也是一个死循环,首先会调用 nativePollOnce 函数,如果没有消息或者处理时间未到,就会阻塞在 Native 层的 pollOnce 函数,睡眠时间就是从 Java 层传过来的。不过其核心实现是在 pollInner 中,如果监听的文件描述符没有发生 IO 读写事件,那么当前线程就会在 epoll_wait 中进入休眠。如果当前线程有新的消息需要处理,就会被唤醒,然后沿着之前的调用路径返回到 Java 层,最后就是对新消息进行处理。 -看完源码,有两点可以参考,第一是获取 Message 最好通过 Message 的 obtain 获取,不要直接 new,因为 Message.obtain 会从缓存里面去取。第二是可以使用 IdleHandler 在消息队列空闲时提前做一些操作。这个我在项目中也有用到,再点击消息中心图标时,会跳到 h5 页面,并且在 url 后面加密拼接 uid 和 phone number,这一加密操作是同步的,所以就可以通过 IdleHandler 提前做这一操作,并且返回 false,表示只做一次。 +看完源码,有两点可以参考,第一是获取 Message 最好通过 Message 的 obtain 获取,不要直接 new,因为 Message.obtain 会从缓存里面去取。第二是可以使用 IdleHandler 在消息队列空闲时提前做一些操作。这个我在项目中也有用到,在点击消息中心图标时,会跳到 h5 页面,并且在 url 后面加密拼接 uid 和 phone number,这一加密操作是同步的,所以就可以通过 IdleHandler 提前做这一操作,并且返回 false,表示只做一次。 下面在简单说下设置同步分隔栏,即 MessageQueue.postSyncBarrier()。同步分隔栏的原理其实很简单,本质上是通过创建一个 target 成员为 null 的 Message 并插入到消息队列中,这样在这个特殊的 Message 之后的消息就不会被处理了,只有当这个 Message被移除后才会继续执行之后的 Message。最经典的实现就 ViewRootImpl 调用 scheduleTraversals 方法进行视图更新时使用,它通过 Choreographer postCallback 把 Message 设置成异步消息避免被分割,把 doTraversal 封装成一个 Runnable,在真正执行时才会移除这个分隔栏。这样做的原因是,doTraversal 的操作是通过 Handler 进行处理的,然鹅这个消息队列却是主线程公用的,比如四大组件的各个生命周期的调用,显然视图绘制这个无疑是最高优先级的,所以在这之前,要确保队列中其他同步消息不会影响到它的执行。 \ No newline at end of file