androidview源码

Ⅰ android - View 绘制流程

我们知道，在 Android 中，View 绘制主要包含 3 大流程：

Android 中，主要有两种视图： View 和 ViewGroup ，其中：

虽然 ViewGroup 继承于 View ，但是在 View 绘制三大流程中，某些流程需要区分 View 和 ViewGroup ，它们之间的操作并不完全相同，比如：

对 View 进行测量，主要包含两个步骤：

对于第一个步骤，即求取 View 的 MeasureSpec ，首先我们来看下 MeasureSpec 的源码定义：

MeasureSpec 是 View 的一个公有静态内部类，它是一个 32 位的 int 值，高 2 位表示 SpecMode（测量模式），低 30 位表示 SpecSize（测量尺寸/测量大小）。
MeasureSpec 将两个数据打包到一个 int 值上，可以减少对象内存分配，并且其提供了相应的工具方法可以很方便地让我们从一个 int 值中抽取出 View 的 SpecMode 和 SpecSize。

一个 MeasureSpec 表达的是：该 View 在该种测量模式（SpecMode）下对应的测量尺寸（SpecSize）。其中，SpecMode 有三种类型：

对 View 进行测量，最关键的一步就是计算得到 View 的 MeasureSpec ，子View 在创建时，可以指定不同的 LayoutParams （布局参数）， LayoutParams 的源码主要内容如下所示：

其中：

LayoutParams 会受到父容器的 MeasureSpec 的影响，测量过程会依据两者之间的相互约束最终生成子View 的 MeasureSpec ，完成 View 的测量规格。

简而言之，View 的 MeasureSpec 受自身的 LayoutParams 和父容器的 MeasureSpec 共同决定（ DecorView 的 MeasureSpec 是由自身的 LayoutParams 和屏幕尺寸共同决定，参考后文）。也因此，如果要求取子View 的 MeasureSpec ，那么首先就需要知道父容器的 MeasureSpec ，层层逆推而上，即最终就是需要知道顶层View（即 DecorView ）的 MeasureSpec ，这样才能一层层传递下来，这整个过程需要结合 Activity 的启动过程进行分析。

我们知道，在 Android 中， Activity 是作为视图组件存在，主要就是在手机上显示视图界面，可以供用户操作， Activity 就是 Andorid 中与用户直接交互最多的系统组件。

Activity 的基本视图层次结构如下所示：

Activity 中，实际承载视图的组件是 Window （更具体来说为 PhoneWindow ），顶层View 是 DecorView ，它是一个 FrameLayout ， DecorView 内部是一个 LinearLayout ，该 LinearLayout 由两部分组成（不同 Android 版本或主题稍有差异）： TitleView 和 ContentView ，其中， TitleView 就是标题栏，也就是我们常说的 TitleBar 或 ActionBar ， ContentView 就是内容栏，它也是一个 FrameLayout ，主要用于承载我们的自定义根布局，即当我们调用 setContentView(...) 时，其实就是把我们自定义的布局设置到该 ContentView 中。

当 Activity 启动完成后，最终就会渲染出上述层次结构的视图。

因此，如果我们要求取得到子View 的 MeasureSpec ，那么第一步就是求取得到顶层View（即 DecorView ）的 MeasureSpec 。大致过程如下所示：

经过上述步骤求取得到 View 的 MeasureSpec 后，接下来就可以真正对 View 进行测量，求取 View 的最终测量宽/高：

Android 内部对视图进行测量的过程是由 View#measure(int, int) 方法负责的，但是对于 View 和 ViewGroup ，其具体测量过程有所差异。

因此，对于测量过程，我们分别对 View 和 ViewGroup 进行分析：

综上，无论是对 View 的测量还是 ViewGroup 的测量，都是由 View#measure(int widthMeasureSpec, int heightMeasureSpec) 方法负责，然后真正执行 View 测量的是 View 的 onMeasure(int widthMeasureSpec, int heightMeasureSpec) 方法。

具体来说， View 直接在 onMeasure(...) 中测量并设置自己的最终测量宽/高。在默认测量情况下， View 的测量宽/高由其父容器的 MeasureSpec 和自身的 LayoutParams 共同决定，当 View 自身的测量模式为 LayoutParams.UNSPECIFIED 时，其测量宽/高为 android:minWidth / android:minHeight 和其背景宽/高之间的较大值，其余情况皆为自身 MeasureSpec 指定的测量尺寸。

而对于 ViewGroup 来说，由于布局特性的丰富性，只能自己手动覆写 onMeasure(...) 方法，实现自定义测量过程，但是总的思想都是先测量 子View 大小，最终才能确定自己的测量大小。

当确定了 View 的测量大小后，接下来就可以来确定 View 的布局位置了，也即将 View 放置到屏幕具体哪个位置。

View 的布局过程由 View#layout(...) 负责，其源码如下：

View#layout(...) 主要就做了两件事：

ViewGroup 的布局流程由 ViewGroup#layout(...) 负责，其源码如下：

可以看到， ViewGroup#layout(...) 最终也是通过 View#layout(...) 完成自身的布局过程，一个注意的点是， ViewGroup#layout(...) 是一个 final 方法，因此子类无法覆写该方法，主要是 ViewGroup#layout(...) 方法内部对子视图动画效果进行了相关设置。

由于 ViewGroup#layout(...) 内部最终调用的还是 View#layout(...) ，因此， ViewGroup#onLayout(...) 就会得到回调，用于处理 子View 的布局放置，其源码如下：

由于不同的 ViewGroup ，其布局特性不同，因此 ViewGroup#onLayout(...) 是一个抽象方法，交由 ViewGroup 子类依据自己的布局特性，摆放其 子View 的位置。

当 View 的测量大小，布局位置都确定后，就可以最终将该 View 绘制到屏幕上了。

View 的绘制过程由 View#draw(...) 方法负责，其源码如下：

其实注释已经写的很清楚了， View#draw(...) 主要做了以下 6 件事：

我们知道，在 Activity 启动过程中，会调用到 ActivityThread.handleResumeActivity(...) ，该方法就是 View 视图绘制的起始之处：

可以看到， ActivityThread.handleResumeActivity(...) 主要就是获取到当前 Activity 绑定的 ViewManager ，最后调用 ViewManager.addView(...) 方法将 DecorView 设置到 PhoneWindow 上，也即设置到当前 Activity 上。 ViewManager 是一个接口， WindowManager 继承 ViewManager ，而 WindowManagerImpl 实现了接口 WindowManager ，此处的 ViewManager.addView(...) 实际上调用的是 WindowManagerImpl.addView(...) ，源码如下所示：

WindowManagerImpl.addView(...) 内部转发到 WindowManagerGlobal.addView(...) ：

在 WindowManagerGlobal.addView(...) 内部，会创建一个 ViewRootImpl 实例，然后调用 ViewRootImpl.setView(...) 将 ViewRootImpl 与 DecorView 关联到一起：

ViewRootImpl.setView(...) 内部首先关联了传递过来的 DecorView （通过属性 mView 指向 DecorView 即可建立关联），然后最终调用 requestLayout() ，而 requestLayout() 内部又会调用方法 scheleTraversals() ：

ViewRootImpl.scheleTraversals() 内部主要做了两件事：

Choreographer.postCallback(...) 会申请一次 VSYNC 中断信号，当 VSYNC 信号到达时，便会回调 Choreographer.doFrame(...) 方法，内部会触发已经添加的回调任务， Choreographer 的回调任务有以下四种类型：

因此， ViewRootImpl.scheleTraversals(...) 内部通过 mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null) 发送的异步视图渲染消息就会得到回调，即回调 mTra

Ⅱ Android 重学系列 View的绘制流程(六) 硬件渲染(上)

本文开始聊聊Android中的硬件渲染。如果跟着我的文章顺序，从SF进程到App进程的绘制流程一直阅读，我们到这里已经有了一定的基础，可以试着进行横向比对如Chrome浏览器渲染流程，看看软件渲染，硬件渲染，SF合成都做了什么程度的优化。

先让我们回顾一下负责硬件渲染的主体对象ThreadedRenderer在整个绘制流程中做了哪几个步骤。

在硬件渲染的过程中，有一个很核心的对象RenderNode，作为每一个View绘制的节点对象。

当每一次进行准备进行绘制的时候，都会雷打不动执行如下三个步骤：

如果遇到什么问题欢迎来到 https://www.jianshu.com/p/c84bfa909810 下进行讨论

实际上整个硬件渲染的设计还是比较庞大。因此本文先聊聊ThreadedRender整个体系中主要对象的构造以及相关的原理。

首先来认识下面几个重要的对象有一个大体的印象。

在java层中面向Framework中，只有这么多，下面是一一映射的简图。

能看到实际上RenderNode也会跟着View 树的构建同时一起构建整个显示层级。也是因此ThreadedRender也能以RenderNode为线索构建出一套和软件渲染一样的渲染流程。

仅仅这样？如果只是这么简单，知道我习惯的都知道，我喜欢把相关总结写在最后。如果把总揽写在正文开头是因为设计比较繁多。因为我们如果以流水线的形式进行剖析容易造成迷失细节的困境。

让我继续介绍一下，在硬件渲染中native层的核心对象。

如下是一个思维导图：

有这么一个大体印象后，就不容易迷失在源码中。我们先来把这些对象的实例化以及上面列举的ThreadedRenderer在ViewRootImpl中执行行为的顺序和大家来聊聊其原理，先来看看ThreadedRenderer的实例化。

当发现mSurfaceHolder为空的时候会调用如下函数：

而这个方法则调用如下的方法对ThreadedRenderer进行创建：

文件：/ frameworks / base / core / java / android / view / ThreadedRenderer.java

能不能创建的了ThreadedRenderer则决定于全局配置。如果ro.kernel.qemu的配置为0，说明支持OpenGL 则可以直接返回true。如果qemu.gles为-1说明不支持OpenGL es返回false，只能使用软件渲染。如果设置了qemu.gles并大于0，才能打开硬件渲染。

我们能看到ThreadedRenderer在初始化，做了三件事情：

关键是看1-3点中ThreadRenderer都做了什么。

文件：/ frameworks / base / core / jni / android_view_ThreadedRenderer.cpp

能看到这里是直接实例化一个RootRenderNode对象，并把指针的地址直接返回。

能看到RootRenderNode继承了RenderNode对象，并且保存一个JavaVM也就是我们所说的Java虚拟机对象，一个java进程全局只有一个。同时通过getForThread方法，获取ThreadLocal中的Looper对象。这里实际上拿的就是UI线程的Looper。

在这个构造函数有一个mDisplayList十分重要，记住之后会频繁出现。接着来看看RenderNode的头文件：
文件：/ frameworks / base / libs / hwui / RenderNode.h

实际上我把几个重要的对象留下来：

文件：/ frameworks / base / core / java / android / view / RenderNode.java

能看到很简单，就是包裹一个native层的RenderNode返回一个Java层对应的对象开放Java层的操作API。

能看到这个过程生成了两个对象：

这个对象实际上让RenderProxy持有一个创建动画上下文的工厂。RenderProxy可以通过ContextFactoryImpl为每一个RenderNode创建一个动画执行对象的上下文AnimationContextBridge。

文件：/ frameworks / base / libs / hwui / renderthread / RenderProxy.cpp

在这里有几个十分重要的对象被实例化，当然这几个对象在聊TextureView有聊过( SurfaceView和TextureView 源码浅析 )：

我们依次看看他们初始化都做了什么。

文件：/ frameworks / base / libs / hwui / renderthread / RenderThread.cpp

能看到其实就是简单的调用RenderThread的构造函数进行实例化，并且返回对象的指针。

RenderThread是一个线程对象。先来看看其头文件继承的对象：
文件：/ frameworks / base / libs / hwui / renderthread / RenderThread.h

其中RenderThread的中进行排队处理的任务队列实际上是来自ThreadBase的WorkQueue对象。

文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h

ThreadBase则是继承于Thread对象。当调用start方法时候其实就是调用Thread的run方法启动线程。

另一个更加关键的对象，就是实例化一个Looper对象到WorkQueue中。而直接实例化Looper实际上就是新建一个Looper。但是这个Looper并没有获取当先线程的Looper，这个Looper做什么的呢？下文就会揭晓。

WorkQueue把一个Looper的方法指针设置到其中，其作用可能是完成了某一件任务后唤醒Looper继续工作。

而start方法会启动Thread的run方法。而run方法最终会走到threadLoop方法中，至于是怎么走进来的，之后有机会会解剖虚拟机的源码线程篇章进行讲解。

在threadloop中关键的步骤有如下四个：

在这个过程中创建了几个核心对象：

另一个核心的方法就是，这个方法为WorkQueue的Looper注册了监听：

能看到在这个Looper中注册了对DisplayEventReceiver的监听，也就是Vsync信号的监听，回调方法为displayEventReceiverCallback。

我们暂时先对RenderThread的方法探索到这里，我们稍后继续看看回调后的逻辑。

文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h

能看到这里的逻辑很简单实际上就是调用Looper的pollOnce方法，阻塞Looper中的循环，直到Vsync的信号到来才会继续往下执行。详细的可以阅读我写的 Handler与相关系统调用的剖析 系列文章。

文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h

实际上调用的是WorkQueue的process方法。

文件：/ frameworks / base / libs / hwui / thread / WorkQueue.h

能看到这个过程中很简单，几乎和Message的loop的逻辑一致。如果Looper的阻塞打开了，则首先找到预计执行时间比当前时刻都大的WorkItem。并且从mWorkQueue移除，最后添加到toProcess中，并且执行每一个WorkItem的work方法。而每一个WorkItem其实就是通过从某一个压入方法添加到mWorkQueue中。

到这里，我们就明白了RenderThread中是如何消费渲染任务的。那么这些渲染任务又是哪里诞生呢？

上文聊到了在RenderThread中的Looper会监听Vsync信号，当信号回调后将会执行下面的回调。

能看到这个方法的核心实际上就是调用drainDisplayEventQueue方法，对ui渲染任务队列进行处理。

能到在这里mVsyncRequested设置为false，且mFrameCallbackTaskPending将会设置为true，并且调用queue的postAt的方法执行ui渲染方法。

还记得queue实际是是指WorkQueue，而WorkQueue的postAt方法实际实现如下：
/ frameworks / base / libs / hwui / thread / WorkQueue.h

情景带入，当一个Vsync信号达到Looper的监听者，此时就会通过WorkQueue的drainDisplayEventQueue 压入一个任务到队列中。

每一个默认的任务都是执行dispatchFrameCallback方法。这里的判断mWorkQueue中是否存在比当前时间更迟的时刻，并返回这个WorkItem。如果这个对象在头部needsWakeup为true，说明可以进行唤醒了。而mWakeFunc这个方法指针就是上面传下来：

把阻塞的Looper唤醒。当唤醒后就继续执行WorkQueue的process方法。也就是执行dispatchFrameCallbacks方法。

在这里执行了两个事情：

先添加到集合中，在上面提到过的threadLoop中，会执行如下逻辑：

如果大小不为0，则的把中的IFrameCallback全部迁移到mFrameCallbacks中。

而这个方法什么时候调用呢？稍后就会介绍。其实这部分的逻辑在TextureView的解析中提到过。

接下来将会初始化一个重要对象：

这个对象名字叫做画布的上下文，具体是什么上下文呢？我们现在就来看看其实例化方法。
文件：/ frameworks / base / libs / hwui / renderthread / CanvasContext.cpp

文件：/ device / generic / goldfish / init.ranchu.rc

在init.rc中默认是opengl，那么我们就来看看下面的逻辑：

首先实例化一个OpenGLPipeline管道，接着OpenGLPipeline作为参数实例化CanvasContext。

文件：/ frameworks / base / libs / hwui / renderthread / OpenGLPipeline.cpp

能看到在OpenGLPipeline中，实际上就是存储了RenderThread对象，以及RenderThread中的mEglManager。透过OpenGLPipeline来控制mEglManager进而进一步操作OpenGL。

做了如下操作：

文件：/ frameworks / base / libs / hwui / renderstate / RenderState.cpp

文件：/ frameworks / base / libs / hwui / renderthread / DrawFrameTask.cpp

实际上就是保存这三对象RenderThread；CanvasContext；RenderNode。

文件：/ frameworks / base / core / jni / android_view_ThreadedRenderer.cpp

能看到实际上就是调用RenderProxy的setName方法给当前硬件渲染对象设置名字。

文件：/ frameworks / base / libs / hwui / renderthread / RenderProxy.cpp

能看到在setName方法中，实际上就是调用RenderThread的WorkQueue，把一个任务队列设置进去，并且调用runSync执行。

能看到这个方法实际上也是调用post执行排队执行任务，不同的是，这里使用了线程的Future方式，阻塞了执行，等待CanvasContext的setName工作完毕。

Ⅲ Android TV 焦点原理源码解析

相信很多刚接触AndroidTV开发的开发者，都会被各种焦点问题给折磨的不行。不管是学技术还是学习其他知识，都要学习和理解其中原理，碰到问题我们才能得心应手。下面就来探一探Android的焦点分发的过程。

Android焦点事件的分发是从ViewRootImpl的processKeyEvent开始的，源码如下：

源码比较长，下面我就慢慢来讲解一下具体的每一个细节。

dispatchKeyEvent方法返回true代表焦点事件被消费了。

ViewGroup的dispatchKeyEvent()方法的源码如下：

（2）ViewGroup的dispatchKeyEvent执行流程

（3）下面再来瞧瞧view的dispatchKeyEvent方法的具体的执行过程

惊奇的发现执行了onKeyListener中的onKey方法，如果onKey方法返回true，那么dispatchKeyEvent方法也会返回true

可以得出结论：如果想要修改ViewGroup焦点事件的分发，可以这么干：

注意：实际开发中，理论上所有焦点问题都可以通过给dispatchKeyEvent方法增加监听来来拦截来控制。

（1）dispatchKeyEvent方法返回false后，先得到按键的方向direction值，这个值是一个int类型参数。这个direction值是后面来进行焦点查找的。

（2）接着会调用DecorView的findFocus()方法一层一层往下查找已经获取焦点的子View。
ViewGroup的findFocus方法如下：

View的findFocus方法

说明：判断view是否获取焦点的isFocused()方法， (mPrivateFlags & PFLAG_FOCUSED) != 0 和view 的isFocused()方法是一致的。

其中isFocused()方法的作用是判断view是否已经获取焦点，如果viewGroup已经获取到了焦点，那么返回本身即可，否则通过mFocused的findFocus()方法来找焦点。mFocused其实就是ViewGroup中获取焦点的子view，如果mView不是ViewGourp的话，findFocus其实就是判断本身是否已经获取焦点，如果已经获取焦点了，返回本身。

（3）回到processKeyEvent方法中，如果findFocus方法返回的mFocused不为空，说明找到了当前获取焦点的view（mFocused），接着focusSearch会把direction（遥控器按键按下的方向）作为参数，找到特定方向下一个将要获取焦点的view，最后如果该view不为空，那么就让该view获取焦点。

（4）focusSearch方法的具体实现。

focusSearch方法的源码如下：

可以看出focusSearch其实是一层一层地网上调用父View的focusSearch方法，直到当前view是根布局（isRootNamespace()方法），通过注释可以知道focusSearch最终会调用DecorView的focusSearch方法。而DecorView的focusSearch方法找到的焦点view是通过FocusFinder来找到的。

（5）FocusFinder是什么？

它其实是一个实现 根据给定的按键方向，通过当前的获取焦点的View，查找下一个获取焦点的view这样算法的类。焦点没有被拦截的情况下，Android框架焦点的查找最终都是通过FocusFinder类来实现的。

（6）FocusFinder是如何通过findNextFocus方法寻找焦点的。

下面就来看看FocusFinder类是如何通过findNextFocus来找焦点的。一层一层往下看，后面会执行findNextUserSpecifiedFocus()方法，这个方法会执行focused(即当前获取焦点的View)的findUserSetNextFocus方法，如果该方法返回的View不为空，且isFocusable = true && isInTouchMode() = true的话，FocusFinder找到的焦点就是findNextUserSpecifiedFocus()返回的View。

（7）findNextFocus会优先根据XML里设置的下一个将获取焦点的View ID值来寻找将要获取焦点的View。

看看View的findUserSetNextFocus方法内部都干了些什么，OMG不就是通过我们xml布局里设置的nextFocusLeft，nextFocusRight的viewId来找焦点吗，如果按下Left键，那么便会通过nextFocusLeft值里的View Id值去找下一个获取焦点的View。

可以得出以下结论：

1. 如果一个View在XML布局中设置了focusable = true && isInTouchMode = true，那么这个View会优先获取焦点。

2. 通过设置nextFocusLeft，nextFocusRight，nextFocusUp，nextFocusDown值可以控制View的下一个焦点。

Android焦点的原理实现就这些。总结一下：

为了方便同志们学习，我这做了张导图，方便大家理解~

Ⅳ Android源码追踪—android:onClick

之前对源码的阅读，总是用时一通乱七八糟的跳转，以学会使用为目的；过了一段时间，就忘记了，因此打算将一些源码的阅读经历记录下来，也通过敲一遍的过程，加深理解。

最开始，用一个比较简单的例子来小试牛刀吧

对于View（Button、TextView等）的点击事件，常用的写法是通过 findViewById 获取View的实例，然后通过 setOnClickListener 设置监听事件，比如我们有如下Button控件。

设置点击事件（假设在Activity中）

但是还有一种写法是在xml布局中通过android:onClick属性直接指定点击执行的函数。

【思考】

首先我们知道诸如 android:xxx 之类的属性是会在某个attrs文件中定义的，此处的 android:onClick 是View的属性，定义在如下文件中。

在View的构造函数中，会解析出此属性的值。

看这里， 如果变量handlerName不为空，就会为此View设置点击事件了 ，这个handlerName就是onClick属性的值doSubmit，但这个点击事件，并不是我们所熟悉的OnClickListener。

进一步看看这个 DeclaredOnClickListener 类

DeclaredOnClickListener 实现了 OnClickListener ，其中重点是参数 mResolvedMethod 和 mResolvedContext 。

在onClick事件中最终通过反射 mResolvedMethod.invoke(mResolvedContext, v); 执行了doSubmit方法。

doSubmit的访问权限是否可以设置为private呢？

答案：不可以，因为源码中没有调用 mMethod.setAccessible(true); 注入所有修饰符。

其实在onClick属性的注释中就已经说明了。

Ⅳ Android TV开发焦点移动源码分析

点可以理解为选中态，在Android TV上起很重要的作用。一个视图控件只有在获得焦点的状态下，才能响应按键的Click事件。
相对于手机上用手指点击屏幕产生的Click事件， 在TV中通过点击遥控器的方向键来控制焦点的移动。当焦点移动到目标控件上之后，按下遥控器的确定键，才会触发一个Click事件，进而去做下一步的处理
在处理焦点的时候，有一些基础的用法需要知道。
首先，一个控件isFocusable()需要为true才有资格可以获取到焦点。如果想要在触摸模式下获取焦点，需要通过setFocusableInTouchMode(boolean)来设置。也可以直接在xml布局文件中指定：

keyEvent 分发过程：

而当按下遥控器的按键时，会产生一个按键事件，就是KeyEvent，包含“上”，“下”，“左”，“右”，“返回”，“确定”等指令。焦点的处理就在KeyEvent的分发当中完成。
首先，KeyEvent会流转到ViewRootImpl中开始进行处理，具体方法是内部类 ViewPostImeInputStage 中的 processKeyEvent ：

接下来先看一下KeyEvent在view框架中的分发：

这里也是可以做焦点控制，最好是在 event.getAction() == KeyEvent.ACTION_DOWN 进行.
因为android 的 ViewRootlmpl 的 processKeyEvent 焦点搜索与请求的地方 进行了判断if (event.getAction() == KeyEvent.ACTION_DOWN)

• 首先ViewGroup会一层一层往上执行父类的dispatchKeyEvent方法，如果返回true那么父类的dispatchKeyEvent方法就会返回true，也就代表父类消费了该焦点事件，那么焦点事件自然就不会往下进行分发。
• 然后ViewGroup会判断mFocused这个view是否为空，如果为空就会return false，焦点继续往下传递；如果不为空，那就会return mFocused的dispatchKeyEvent方法返回的结果。这个mFocused其实是ViewGroup中当前获取焦点的子View

发现执行了onKeyListener中的onKey方法，如果onKey方法返回true，那么dispatchKeyEvent方法也会返回true
如果想要修改ViewGroup焦点事件的分发
• 重写view的dispatchKeyEvent方法
• 给某个子view设置onKeyListener监听

下面再来看一下如果一个页面第一次进入，系统是如何确定焦点是定位在哪个view上的

由于DecorView继承自FrameLayout，这里调用的是ViewGroup的requestFocus

descendantFocusability:
• FOCUS_AFTER_DESCENDANTS：先分发给Child View进行处理，如果所有的Child View都没有处理，则自己再处理
• FOCUS_BEFORE_DESCENDANTS：ViewGroup先对焦点进行处理，如果没有处理则分发给child View进行处理
• FOCUS_BLOCK_DESCENDANTS：ViewGroup本身进行处理，不管是否处理成功，都不会分发给ChildView进行处理
因为 PhoneWindow 给 DecoreView 初始化时设置 了 setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS)，所以这里默认是FOCUS_AFTER_DESCENDANTS

到此第一次请求焦点的过程基本告一个段落

焦点移动的时候，默认的情况下，会按照一种算法去找在指定移动方向上最近的邻居。在一些情况下，焦点的移动可能跟开发者的意图不符，这时开发者可以在布局文件中使用下面这些XML属性来指定下一个焦点对象：

在KeyEvent分发中已经知道如果分发过程中event没有被消耗，就会根据方向搜索以及请求焦点View

流程一：查找用户指定的下一个焦点

流程二：获取搜索方向上所有可以获取焦点的view，使用算法查找下一个view
addFocusables() 获取搜索方向上可获得焦点的view

descendantFocusability属性决定了ViewGroup和其子view的聚焦优先级
• FOCUS_BLOCK_DESCENDANTS：viewgroup会覆盖子类控件而直接获得焦点
• FOCUS_BEFORE_DESCENDANTS：viewgroup会覆盖子类控件而直接获得焦点
• FOCUS_AFTER_DESCENDANTS：viewgroup只有当其子类控件不需要获取焦点时才获取焦点
addFocusables 的第一个参数views是由root决定的。在ViewGroup的focusSearch方法中传进来的root是DecorView，也可以主动调用FocusFinder的findNextFocus方法，在指定的ViewGroup中查找焦点。
FocusFinder.findNextFocus 查找焦点

Ⅵ Android源码解析Window系列第（一）篇---Window的基本认识和Activity的加载流程

您可能听说过View ,ViewManager,Window,PhoneWindow,WindowManager,WindowManagerService,可是你知道这几个类是什么关系，干嘛用的。概括的来说，View是放在Window中的，Window是一个抽象类，它的具体实现是PhoneWindow，PhoneWindow还有个内部类DecorView，WindowManager是一个interface，继承自ViewManager，它是外界访问Window的入口，，提供了add/remove/updata的方法操作View，WindowManager与WindowManagerSerice是个跨进程的过程，WindowManagerService的职责是对系统中的所有窗口进行管理。如果您不太清楚，建议往下看，否则就不要看了。

Android系统的Window有很多种，大体上来说，Framework定义了三种窗口类型；

这就是Framework定义了三种窗口类型，这三种类型定义在WindowManager的内部类LayoutParams中，WindowManager讲这三种类型 进行了细化，把每一种类型都用一个int常量来表示，这些常量代表窗口所在的层，WindowManagerService在进行窗口叠加的时候，会按照常量的大小分配不同的层，常量值越大，代表位置越靠上面， 所以我们可以猜想一下，应用程序Window的层值常量要小于子Window的层值常量，子Window的层值常量要小于系统Window的层值常量。 Window的层级关系如下所示。

上面说了Window分为三种，用Window的type区分，在搞清楚Window的创建之前，我们需要知道怎么去描述一个Window，我们就把Window当做一个实体类，给我的感觉，它必须要下面几个字段。

实际上WindowManager.LayoutParams对Window有很详细的定义。

提取几个重要的参数

Window是一个是一个抽象的概念，千万不要认为我们所看到的就是Window,我们平时所看到的是视图，每一个Window都对应着一个View，View和Window通过ViewRootImpl来建立联系。有了View，Window的存在意义在哪里呢，因为View不能单独存在，它必须依附着Window，所以有视图的地方就有Window,比如Activity,一个Dialog,一个PopWindow,一个菜单，一个Toast等等。

通过上面我们知道视图和Window的关系，那么有一个问题，是先有视图，还是先有Window。这个答案只有在源码中找了。应用程序的入口类是ActivityThread，在ActivityThread中有performLaunchActivity来启动Activity，这个performLaunchActivity方法内部会创建一个Activity。

如果activity不为null,就会调用attach,在attach方法中通过PolicyManager创建了Window对象，并且给Window设置了回调接口。

PolicyManager的实现类是Policy

这样Window就创建出来了， 所以先有Window，后有视图，视图依赖Window存在 ，再说一说视图（Activity）为Window设置的回调接口。

Activity实现了这个回调接口，当Window的状态发生变化的时候，就会回调Activity中实现的这些接口，有些回调接口我们还是熟悉的，dispatchTouchEvent，onAttachedToWindow，onDetachedFromWindow等。

下面分析view是如何附属到window上的，通过上面可以看到，在attach之后就要执行callActivityOnCreate，在onCreate中我们会调用setContentView方法。

getWindow获取了Window对象，Window的具体实现类是PhoneWindow,所以要看PhoneWindow的setContentView方法。

这里涉及到一个mContentParent变量，他是一个DecorView的一部分，DecorView是PhoneWindow的一个内部类，我先介绍一下关于DecorView的知识。

DecorView是Activity的顶级VIew，DecorView继承自FrameLayout,在DecorView中有上下两个部分，上面是标题栏，下面是内容栏，我们通过PhoneWindow的setContentView所设置的布局文件是加到内容栏（mContentParent）里面的，View层的事件都是先经过DecorView在传递给我们的View的。

OK在回到setContentView的源码分析，我们可以得到Activity的Window创建需要三步。

- 1、 如果没有DecorView，在installDecor中创建DecorView。

- 2、将View添加到decorview中的mContentParent中。

- 3、回调Activity的onContentChanged接口。

先看看第一步，installDecor的源码

installDecor中调用了generateDecor，继续看

直接给new一个DecorView，有了DecorView之后，就可以加载具体的布局文件到DecorView中了，具体的布局文件和系统和主题有关系。

在看第二步，将View添加到decorview中的mContentParent中。

直接将Activity视图加到DecorView的mContentParent中，最后一步，回调Activity的onContentChanged接口。在Activity中寻找onContentChanged方法，它是个空实现，我们可以在子Activity中处理。

到此DecorView被创建完毕，我们一开始从Thread中的handleLaunchActivity方法开始分析，首先加载Activity的字节码文件，利用反射的方式创建一个Activity对象，调用Activity对象的attach方法，在attach方法中，创建系统需要的Window并为设置回调，这个回调定义在Window之中，由Activity实现，当Window的状态发生变化的时候，就会回调Activity实现的这些回调方法。调用attach方法之后，Window被创建完成，这时候需要关联我们的视图，在handleLaunchActivity中的attach执行之后就要执行handleLaunchActivity中的callActivityOnCreate，在onCreate中我们会调用setContentView方法。通过setContentView，创建了Activity的顶级View---DecorView,DecorView的内容栏（mContentParent）用来显示我们的布局。 这个是我们上面分析得到了一个大致流程，走到这里，这只是添加的过程，还要有一个显示的过程，显示的过程就要调用handleLaunchActivity中的handleResumeActivity方法了。最后会调用makeVisible方法。

这里面首先拿到WindowManager对象，用tWindowManager 的父接口ViewManager接收，ViewManager可以
最后调用 mDecor.setVisibility(View.VISIBLE)设置mDecor可见。到此，我们终于明白一个Activity是怎么显示在我们的面前了。
参考链接：
http://blog.csdn.net/feiclear_up/article/details/49201357

Ⅶ Android ViewRootImpl

本文主要分析两个问题：
1、为什么View 的绘制流程是从 ViewRootImpl 的performTraversals()方法开始的？
2、View 的invalidate方法是怎么触发到ViewRootImpl 的performTraversals()方法的。
在阅读本文前，最好先了解window的添加过程，Android消息处理机制 和 View 的绘制流程。推荐先阅读以下文章：
Android Window和WindowManager
Android-消息机制
Android View 的绘制流程

android 源码注释的意思是：ViewRootImpl是视图层次结构的顶部，实现 View 和 WindowManager 之间所需的协议。是 WindowManager Global 的内部实现中重要的组成部分。

View 的绘制流程是从 ViewRootImpl 的performTraversals()方法开始的，那到底是哪里调用了performTraversals()方法呢，下面我们分析一下：

1.私有属性的performTraversals()方法肯定是在内部调用起来的，经过搜索找到是doTraversal()方法调用了。

2.接着找到了，调用了doTraversal() 的TraversalRunnable 类

3.内部只有一个地方实例化了TraversalRunnable 的实例mTraversalRunnable ，查到到两个方法内都调用了mTraversalRunnable ，明显 scheleTraversals 是主动触发这个 Runnable 。这就表明调用了scheleTraversals ()函数的地方都主动触发了view的刷新。

4.接着我们看一下 mChoreographer.postCallback 做了什么

可以看到，最后后走进了scheleVsyncLocked()方法内。

5.mDisplayEventReceiver 的类 是 FrameDisplayEventReceiver，继承自
DisplayEventReceiver 。

最后走到这里就没了，那么这个方法是做了什么呢，这个方法的注释是这个意思：安排在下一个显示帧开始时传送单个垂腔察直同步脉冲。意思就是，调用了这个方法可以收到系统传送过来的垂直同步脉冲信号。Android系统每隔16ms就会发送一个VSYNC信号（VSYNC：vertical synchronization 垂直同步，帧同步），触发对UI进行渲染。这个垂直同步信对于应用来说了，只有了订阅了监听，才能收到。而且是订阅一次，收到一次。

6.既然是在这个类里面订阅垂直同步信号的，那回调也应该在这里。于是找到了以下方法。

native code 调用到 onVsync，这个方法的注释解释如下：当接收到垂直同步脉冲时调用。接收者应该渲染一个帧，然后调用 {@link scheleVsync} 来安排下一个垂直同步脉冲。
这个方法的具体实现在前面分析到的FrameDisplayEventReceiver 类里面。

这里可以看到，其实mHandler就是当前主线程的handler，当接收到onVsync信号的时候，将自己封装到Message中，等到Looper处理，最后Looper处理消息基圆宽的时候就会调用run方法，这里是Handler的机制，不做解释。

7.最后，如下图调用所示，最终从mCallbackQueues取回之前添加的任务再执行run方法，也就是TraservalRunnable的run方法。

总结上面的分析，调用流程如下图所示如下：

上面我们分析到只要调用了ViewRootImpl 的scheleTraversals ()方法，最终就能调用了ViewRootImpl 的performTraversals()来开始绘制。搏亮那肯定是我们常调用的view刷新的接口，经过一系列的方法调用，最终调用了ViewRootImpl 的scheleTraversals ()方法。下面我们分析一下常用的View 的 invalidate()接口是怎么调用到了ViewRootImpl 的scheleTraversals ()方法。

可以看出，invalidate有多个重载方法，但最终都会调用invalidateInternal方法，在这个方法内部，进行了一系列的判断，判断View是否需要重绘，接着为该View设置标记位，然后把需要重绘的区域传递给父容器，即调用父容器的invalidateChild方法。
接着我们看ViewGroup#invalidateChild：

由于不断向上调用父容器的方法，到最后会调用到ViewRootImpl的invalidateChildInParent方法，我们来看看它的源码，ViewRootImpl#invalidateChildInParent:

最后调用了scheleTraversals方法，触发View的工作流程。至此，我们已经完整地分析了一次调用View 的 invalidate()方法到触发ViewRootImpl 的scheleTraversals()方法。

Ⅷ Carson带你学Android：你真的了解view.post()吗

为什么view.post()能保证获取到view的宽高？

View.post()的原理： 以Handler为基础，View.post() 将传入任务添加到 View绘制任务所在的消息队列尾部，从而保证View.post() 任务的执行时机是在View 绘制任务完成之后的。 其中，几个关键点：

所以：

具体源码分析请看： Android：为什么view.post()能保证获取到view的宽高？

为什么onCreate()使用view.post()无法立刻执行任务（如获取宽高），需要在onResume()后才可获取？

在onCreate()时，AttachInfo还没被赋值（为null）（是在view.dispatchAttachedToWindow()才被赋值），所亮物猜以会走下述源码的过程2；通过上面分析，此过程的作用仅是：保存了通过post()添加的任务，并没执行。

若只是创建一个 View & 调用它的post()，那么post的任务会不会被执行？

不会。主要原因是：
每个View中post() 需执行的任务，必须得添加到窗口视图-执行绘制流程 - 任务才会被post到消息队列里去等待执行，即依赖于dispatchAttachedToWindow ()；

若View未添加到窗口视图，那么就不会走绘制流程，post() 添加的任务最终不会被post到消息队列里，即得不到执行。（但会保存到HandlerAction数组里）

上述例子，因为它没有被添加到窗口视图，所以不会走绘制流程，所以该任务最终不会被post到消息队列里 & 执行

此时只需要添加将View添加到窗口，那么post()的任务即可蚂租被执行

view.pos()传入的任务被执行的有效期是多久？

在整个 Activity 的生命周期内都可以正常使用 View.post() 任务

任务被执行是构造AttachInfo，所敬型以任务释放即时释放AttachInfo （置为null）。而AttachInfo 的释放操作（置为null）是在 Activity 生命周期 onDestory 方法之后

下面，我们将分析，什么时候调用上述入口，即DecorView.dispatchDetachedFromWindow()；

此时需从 将DecorView从WindowManager中移除 开始讲起：移除 Window 窗口任务是通过 ActivityThread.handleDestoryActivity()完成。

View.post() 任务被执行的有效期是在 Activity 生命周期 onDestory()后。本质是追踪AttachInfo的释放过程（置为null）

AttachInfo的释放过程是在 将DecorView从WindowManager中移除时：回调DecorView.dispatchDetachedFromWindow()，其具体行为是：

而上述过程是在ActivityThread.handleDestoryActivity()中回调 Activity.onDestory()之后。

至此，关于view.post()的四大常见疑问 （坑）内容讲解完毕。

不定期分享关于 安卓开发 的干货，追求 短、平、快 ，但 却不缺深度 。

Ⅸ Android的View类是怎样定义的源代码是什么

view的定义还真不是一两句话能说清楚的。源码里代码2万多行，最前面的注释有500多行。

如果你用android studio，直接Ctrl 点击View应该就能看到源码。
当然也可以在网页里查看源码
http ://androidxref.com

Ⅹ Android-ViewPager源码解析与性能优化

ViewPager高度设置为wrap_content或者具体的高度值无效，是因为ViewPager的onMeasure方法在度量宽高的时候，在方法体的最开始就直接调用了setMeasuredDimension()方法将自身的宽高度量，但是并没有在其onMeasure()计算完其具体的子View的宽高之后，重新度量一次自身的宽高

从这里我们可以看到，ViewPager的宽高会受其父容器的宽高的限制，但是并不会因为自身子View的宽高而影响ViewPager的宽高。

看setMeasuredDimension的源码调用可以看出，当父容器的高度确定时，ViewPager的宽高其实就是父容器的宽高，ViewPager就是在onMeasure方法一进来的时候就直接填充满整个父容器的剩余空间。在计算孩子节点之前，就已经计算好了ViewPager的宽高，在计算完孩子节点之后，并不会再去重返告新计算ViewPager的宽高。

自定义一个ViewPager，根据子View的宽高重新度量ViewPager的宽高。其实做法就是在自定义onMeasure的super.onMeasure(widthMeasureSpec, heightMeasureSpec);之前重新计算heightMeasureSpec，将原本ViewPager接收的父容器的限定的heightMeasureSpec替换成我们自定义的heightMeasureSpec。

但是这样的做法，会有种问题，即在ViewPager的子View是采用LinearLayout作为根布局的时候，并且给LinearLayout设置了固定的高度值，那么会出现ViewPager动态高度无效的问题
其实具体的做法，就是仿造measureChild的做法，自定义子View的heightMeasureSpec然后度量整个子View，其实子View的宽度也可以这样做。

这里其实是源码层做了限制，在setOffscreenPageLimit中设置了一个默认值，而这个默认值的大小为1

所以从这里可以看出，ViewPager的最小缓存的limit是1，而不能小于1，当小于1的时候就会被强制的设置为1。
而populate()函数就是用来处理ViewPager的缓存的。
populate()的生命周期是与Adapter的生命周期绑定的。
其实在setOffscreenPageLimit()的时候，调用的populate()，而populate()内部调用的

而pupulate(int newCurrentItem)方法在另一处调用的地方就是在setCurrentItem。
其实ViewPager缓存都是基于派世盯ItemInfo这个类来进行的，

看下ViewPager.addNewItem的源码
其实ViewPager.addNewItem就是通过调用Adapter.instantiateItem来创建对应的View，并且将View保存到ItemInfo中的object属性，并且判断ViewPager缓存中是否已经有ItemInfo，如果没有，则添加，如果有则做修改替换

从分析FragmentStatePagerAdapter来看，setUserVisibleHint方法会优先于Fragment的生命周期函数 执行。因为在FragmentStatePagerAdapter中提交事务，是在调用finishUpdate方法中进行的，只有提交事务的时候，才会去执行Fragment的生命周期。
FragmentStatePagerAdapter中的instantiateItem和destroyItem都实现了对fragment的事尘和务的添加和删除，而finishUpdate实现了事务的提交，所以在实现FragmentStatePagerAdapter的时候，并不需要重写instantiateItem和destroyItem