标签归档:源码分析

从Invalidate到Draw的辗转历程

以android Q的源码为例子,一步步分析invalidate的调用流程。

在写自定义控件的时候时常会用到 invalide 方法,都知道调用 invalide 后会回调Draw方法,但其中的辗转历程鲜有人知,为了搞清这个流程,我从android Q 源码入手分析了整个调用流程。在此记录一下,省得以后忘了

1.App Call SufaceFlinger

1.任何的View的invalidate方法最终都会调用到ViewRootImpl.java的invalidate()或者invalidateChildInParent,区别只是mDirty的大小,这个mDirty表示这个区域需要重绘

frameworks/base/core/java/android/view/ViewRootImpl.java

2.scheduleTraversals的实现如下

frameworks/base/core/java/android/view/ViewRootImpl.java

3.这里需要注意的是一个插入同步屏障的过程,插入同步屏障后,只有异步的消息才能在MessageQeue循环,app这边 Handler之类的全部失去效果,所以在Traversals执行或者取消的时候会马上移除,如下所示 查看更多

从最上层到驱动层看Android Conetext.getSystemService究竟做了什么

曾经好奇为什么同样是binder接口,Conetext.getService为什么可以直接获取,而不需要像bindeService一样异步回调,今天终于从能够从上层源码到binder驱动源码,彻底了解这一过程,同时分析binder接口在调用的时候,底层究竟是如何实现的。

1.从getSystemService 到native的getContextObject

ContextImpl.java

SystemServiceRegistry.java

SYSTEM_SERVICE_FETCHERS是一个hasmap,键值是一个抽象类,ServiceFetcher,它在初始化的时候实现,见如下代码

registerService 的作用就是把CachedServiceFetcher 放到 SYSTEM_SERVICE_FETCHERS 中,这样每次取服务时都可以从这个缓存获取,因此我们第二次getSystemService时性能是非常高的,时间复杂度位O(1),然后所有系统服务端最终都会调用到这一步 查看更多

Android MessageQueue中的同步屏障

Message中有一个方法叫Message.setAsynchronous,表示发送异步消息,然而他需要插入同步屏障才能生效,那什么是同步屏障呢?

一般来说,Message如果按顺序进行发送的,并不是设置delay的话,运行都是同步的,然而在某些特殊时期,为了提高某个消息的优先级,防止中途插入的Message导致任务调度延迟,会使用异步Message,当调用postSyncBarrier之后,之后的任意同步消息都不再执行,期间只能执行异步消息,直到移除了同步屏障。

插入屏障:MessageQueue.postSyncBarrier

往链表里插入了一个奇怪的msg,他的target为null

消息循环:MessageQueue.next

遍历消息,也就是忽略所有非异步消息,只取出异步消息 查看更多