❶ 从零开始仿写一个抖音App——android绘制机制以及Surface家族源码全解析
本篇文章分为以下章节，读者可以按需阅读
阅读须知
图1就是 Android 屏幕显示的抽象示意图，这里我来解释一下：
Android 的两种常用绘图机制：
其实源码的主要流程都在图3中，我下面讲的东西算是对图3的补充和说明。另外强烈建议结合 Android 源码阅读本章节。
**这里我们以 View 的创建流程为例，讲述一下 Surface 在这个过程中的创建流程，Surface 的创建流程如图5所示。 **
我们都知道 Surface 可以通过 lockCanvas 和 unlockCanvasAndPost 这两个 api 来再通过 Canvas 来绘制图像，这一节我就通过这两个 api 来讲讲 Surface 的绘制流程，整个流程如图6所示。
图7是 ST 与 Surface、SV、TV 等等组件结合的概览图，我这里简单解释一下：
我将根据图8的流程来讲解 ST 的创建与使用
和前面一样，本小节接下来的分析也都是顺着图9来的
❷ Android源码解析RPC系列(一)---Binder原理
看了几天的Binder，决定有必要写一篇博客，记录一下学习成果，Binder是Android中比较综合的一块知识了，目前的理解只限于java层。首先Binder是干嘛用的？不用说，跨进程通信全靠它，操作系统的不同进程之间，数据不共享，对于每个进程来说，它都天真地以为自己独享了整个系统，完全不知道其他进程的存在，进程之间需要通信需要某种系统机制才能完成，在Android整个系统架构中，采用了大量的C/S架构的思想，所以Binder的作用就显得非常重要了，但是这种机制为什么是Binder呢？在Linux中的RPC方式有管道，消息队列，共享内存等，消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，这样就有两次拷贝过程。共享内存不需要拷贝，但控制复杂，难以使用。Binder是个折中的方案，只需要拷贝一次就行了。其次Binder的安全性比较好，好在哪里，在下还不是很清楚，基于安全性和传输的效率考虑，选择了Binder。Binder的英文意思是粘结剂，Binder对象是一个可以跨进程引用的对象，它的实体位于一个进程中，这个进程一般是Server端，该对象提供了一套方法用以实现对服务的请求，而它的引用却遍布于系统的各个进程（Client端）之中，这样Client通过Binder的引用访问Server，所以说，Binder就像胶水一样，把系统各个进程粘结在一起了，废话确实有点多。
为了从而保障了系统的安全和稳定，整个系统被划分成内核空间和用户空间
内核空间：独立于普通的应用程序，可以访问受保护的内存空间，有访问底层硬件设备的所有权限。
用户空间：相对与内核空间，上层运用程序所运行的空间就是用户空间，用户空间访问内核空间的唯一方式就是系统调用。一个4G的虚拟地址空间，其中3G是用户空间，剩余的1G是内核空间。如果一个用户空间想与另外一个用户空间进行通信，就需要内核模块支持，这个运行在内核空间的，负责各个用户进程通过Binder通信的内核模块叫做Binder驱动，虽然叫做Binder驱动，但是和硬件并没有什么关系，只是实现方式和设备驱动程序是一样的，提供了一些标准文件操作。
在写AIDL的时候，一般情况下，我们有两个进程，一个作为Server端提供某种服务，然后另外一个进程作为Client端,连接Server端之后，就 可以使用Server里面定义的服务。这种思想是一种典型的C/S的思想。值得注意的是Android系统中的Binder自身也是C/S的架构，也有Server端与Client端。一个大的C/S架构中，也有一个小的C/S架构。
先笼统的说一下，在整个Binder框架中，由系列组件组成，分别是Client、Server、ServiceManager和Binder驱动程序，其中Client、Server和ServiceManager运行在用户空间，Binder驱动程序运行内核空间。运行在用户空间中的Client、Server和ServiceManager，是在三个不同进程中的，Server进程中中定义了服务提供给Client进程使用，并且Server中有一个Binder实体，但是Server中定义的服务并不能直接被Client使用，它需要向ServiceManager注册，然后Client要用服务的时候，直接向ServiceManager要，ServiceManager返回一个Binder的替身（引用）给Client，这样Client就可以调用Server中的服务了。
场景 ：进程A要调用进程B里面的一个draw方法处理图片。
分析 ：在这种场景下，进程A作为Client端，进程B做为Server端，但是A/B不在同一个进程中，怎么来调用B进程的draw方法呢，首先进程B作为Server端创建了Binder实体，为其取一个字符形式，可读易记的名字，并将这个Binder连同名字以数据包的形式通过Binder驱动发送给ServiceManager，也就是向ServiceManager注册的过程，告诉ServiceManager，我是进程B，拥有图像处理的功能，ServiceManager从数据包中取出名字和引用以一个注册表的形式保留了Server进程的注册信息。为什么是以数据包的形式呢，因为这是两个进程，直接传递对象是不行滴，只能是一些描述信息。现在Client端进程A联系ServiceManager，说现在我需要进程B中图像处理的功能，ServiceManager从注册表中查到了这个Binder实体，但是呢，它并不是直接把这个Binder实体直接给Client,而是给了一个Binder实体的代理，或者说是引用，Client通过Binder的引用访问Server。分析到现在，有个关键的问题需要说一下，ServiceManager是一个进程，Server是另一个进程，Server向ServiceManager注册Binder必然会涉及进程间通信。当前实现的是进程间通信却又要用到进程间通信，这就好象蛋可以孵出鸡前提却是要找只鸡来孵蛋，确实是这样的，ServiceManager中预先有了一个自己的Binder对象（实体），就是那只鸡，然后Server有个Binder对象的引用，就是那个蛋，Server需要通过这个Binder的引用来实现Binder的注册。鸡就一只，蛋有很多，ServiceManager进程的Binder对象（实体）仅有一个，其他进程所拥有的全部都是它的代理。同样一个Server端Binder实体也应该只有一个，对应所有Client端全部都是它的代理。
我们再次理解一下Binder是什么？在Binder通信模型的四个角色里面；他们的代表都是“Binder”，一个Binder对象就代表了所有，包括了Server，Client,ServiceManager,这样，对于Binder通信的使用者而言，不用关心实现的细节。对Server来说，Binder指的是Binder实体，或者说是本地对象，对于Client来说，Binder指的是Binder代理对象，也就是Binder的引用。对于Binder驱动而言，在Binder对象进行跨进程传递的时候，Binder驱动会自动完成这两种类型的转换。
简单的总结一下，通过上面一大段的分析，一个Server在使用的时候需要经历三个阶段
1、定义一个AIDL文件
Game.aidl
GameManager .aidl
2、定义远端服务Service
在远程服务中的onBind方法，实现AIDL接口的具体方法，并且返回Binder对象
3、本地创建连接对象
以上就是一个远端服务的一般套路，如果是在两个进程中，就可以进程通信了，现在我们分析一下，这个通信的流程。重点是GameManager这个编译生成的类。
从类的关系来看，首先接口GameManager 继承 IInterface ，IInterface是一个接口，在GameManager内部有一个内部类Stub，Stub继承了Binder，（Binder实现了IBinder），并且实现了GameManager接口，在Stub中还有一个内部类Proxy，Proxy也实现了GameManager接口，一个整体的结构是这样的
现在的问题是，Stub是什么？Proxy又是什么？在上面说了在Binder通信模型的四个角色里面；他们的代表都是“Binder”，一个Binder对象就代表了所有，包括了Server，Clinet，ServiceManager，为了两个进程的通信，系统给予的内核支持是Binder,在抽象一点的说,Binder是系统开辟的一块内存空间，两个进程往这块空间里面读写数据就行了，Stub从Binder中读数据，Proxy向Binder中写数据,达到进程间通信的目的。首先我们分析Stub。
Stub 类继承了Binder ，说明了Stub有了跨进程传输的能力，实现了GameManager接口，说明它有了根据游戏ID查询一个游戏的能力。我们在bind一个Service之后，在onServiceConnecttion的回调里面，就是通过asInterface方法拿到一个远程的service的。
asInterface调用queryLocalInterface。
mDescriptor，mOwner其实是Binder的成员变量，Stub继承了Binder，在构造函数的时候，对着两个变量赋的值。
如果客户端和服务端是在一个进程中，那么其实queryLocalInterface获取的就是Stub对象，如果不在一个进程queryLocalInterface查询的对象肯定为null，因为不同进程有不同虚拟机，肯定查不到mOwner对象的，所以这时候其实是返回的Proxy对象了。拿到Stub对象后，通常在onServiceConnected中，就把这个对象转换成我们多定义AIDL接口。
比如我们这里会转换成GameManager，有了GameManager对象，就可以调用后querryGameById方法了。如果是一个进程，那直接调用的是自己的querryGameById方法，如果不是一个进程，那调用了就是代理的querryGameById方法了。
看到其中关键的一行是
mRemote就是一个IBinder对象，相对于Stub，Proxy 是组合关系（HAS-A），内部有一个IBinder对象mRemote，Stub是继承关系(IS-A)，直接实现了IBinder接口。
transact是个native方法，最终还会回掉JAVA层的onTransact方法。
onTransact根据调用号（每个AIDL函数都有一个编号，在跨进程的时候，不会传递函数，而是传递编号指明调用哪个函数）调用相关函数；在这个例子里面，调用了Binder本地对象的querryGameById方法；这个方法将结果返回给驱动，驱动唤醒挂起的Client进程里面的线程并将结果返回。于是一次跨进程调用就完成了。
***Please accept mybest wishes for your happiness and success ! ***
❸ Android Handler源码分析
Handler相信安卓开发者都很熟悉了，平常在开发的时候应用场景很多，但是Handler到底是如何发送消息和接收消息的呢，它内部到底做了些什么工作呢，本篇文章就Handler来分析它的源码流程
在Handler中有多个发送消息的方法，以下为几个例子：
第一个不用多说直接发送消息的，延迟时间是0
第二个发送带有延迟的消息，如果delayMillis 是负数则设置为0
第三个发送消息排在消息队列的头部，等待处理
从源码可以看出来第一个和第二个方法都是调用sendMessageAtTime方法，而sendMessageAtTime方法调用的是enqueueMessage方法，所以它们调用的都是enqueueMessage方法
走到这里我们看到这个msg.target 就是当前Handler，这里之所以这样写是为了后面用于消息分发的，这里的queue不会为空，我们来看queue到底在哪里实例的
在这里看到不仅MessageQueue在这里实例化并且Looper也是在这里实例化的，在这里有个疑问就是mQueue这样写会不会为空呢，带着这个疑问我们后面解答，我们先看Looper中的myLooper方法
发现是从ThreadLocal静态对象里面获取的Looper对象，再看下在哪里设置的呢
在这里我们看下ThreadLocal是怎么设置和获取的，找到set方法和get方法
在这里说明一下一个线程对应一个ThreadLocalMap 一个ThreadLocalMap 对应一个key和value值，key对应的是sThreadLocal，value对应的存储的Looper对象。接着在这里发现MessageQueue是在这里实例化的，这里有个prepare方法里面设置的，那到底在哪里调用的呢。熟悉Activity启动流程源码的童鞋都知道，最终Activity启动流程操作主要是在ActivityThread里面的，并且Android程序刚开始的入口是ActivityThread的main方法，所以我们查看main方法
我们看到在入口调用了Looper.prepareMainLooper方法，我们直接进入方法
在这里惊奇的发现调用了prepare方法，在下面判断中保证一个线程中只能有一个Looper对象，否则抛出异常。
走到这里做个总结：
从上面可以看出几乎所有的发送消息方法都会调用enqueueMessage方法，我们查看MessageQueue中的enqueueMessage方法
这个方法主要是用来存储消息队列的，并且通过时间进行有序排序，有了消息之后就通过nativeWake方法这个方法是底层实现的，这个方法是用通过JNI实现的，即在底层通过C实现的，底层在这里就不多说了，不是本篇主要内容。在上面我们在ActivityThread中main方法中调用了Looper.loop()方法，这样这个方法就被唤醒，接着我们查看此方法到底干了啥
这个方法是个无限循环方法等待获取可以处理分发msg消息的，我们重点来看MessageQueue.next()方法
这个方法很重要在这里主要是取出Message返回给Looper.loop()用做消息分发，现在来看Looper.loop()方法中调用的Handler dispatchMessage方法
在这里如果Message 设置了callback 的话，则直接调用 message.callback.run()方法，如果有设置Handler的callback，则也进行分发，如果都没有的话，那就直接调用handleMessage(Message msg)方法。
做个总结：
最后：
在这里多说几句为什么用链表结构的方式进行存储消息，而不用数组的方式呢，熟悉ArrayList源码的开发者都知道它里面其实就是以数组的方式进行存储数据的，而LinkedList是以节点的方式存储的，相当于二叉树结构的和链表结构类似，所以最终我们知道链接结构主要是增加删除效率高，而数组的方式则是查询的效率高
❹ 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 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应用程序的源码
一般工程的AndroidManifest.xml里包含下面代码的是主界面
<intent-filter>
<actionandroid:name="android.intent.action.MAIN"/>
<categoryandroid:name="android.intent.category.LAUNCHER"/>
</intent-filter>
找到主界面后就根据主界面的函数找其他界面的入口，一点一点的分析就好了
❼ ValueAnimator源码解析-基于Android API30
先上个时序图，整个调用链都在图里了。
ValueAnimator.java
初始化动画，并将监听添加到AnimationHandler
AnimationHandler.java
将Frame监听添加到Choreographer
Choreographer.java
请求下一个信号，不明白信号的可看 《Android 底层渲染 - 屏幕刷新机制源码分析》
FrameDisplayEventReceiver.java
当来了信号量后，执行onvsync，发送Handler同步消息，Message的Callback就是FrameDisplayEventReceiver，最终通过Handler执行了FrameDisplayEventReceiver.run()方法
DisplayEventReceiver.java
请求信号量，并分发处理
FrameDisplayEventReceiver.java
处理回调
Choreographer.CallbackRecord.java
执行Frame回调
AnimationHandler.java
帧回调到动画回调
ValueAnimator.java
整个流程就分析完了。动画的核心驱动是，利用屏幕的刷新机制，请求信号，然后在通过Handler的同步消息，执行Frame回调。Frame回调中在执行动画回调。动画回调中根据时间和动画插值。计算出最新的动画值，回调给用户。ValueAnimation中animateBasedOnTime方法会返回当前动画是否结束，如果已经结束就移除动画回调，如果未结束FrameCallback的doFrame中处理完这一帧后，会继续请求下一个信号量。
❽ [Android源码分析] － 异步通信Handler机制
一、问题：在Android启动后会在新进程里创建一个主线程，也叫UI线程（ 非线程安全 ）这个线程主要负责监听屏幕点击事件与界面绘制。当Application需要进行耗时操作如网络请求等，如直接在主线程进行容易发生ANR错误。所以会创建子线程来执行耗时任务，当子线程执行完毕需要通知UI线程并修改界面时，不可以直接在子线程修改UI，怎么办？
解决方法：Message Queue机制可以实现子线程与UI线程的通信。
该机制包括Handler、Message Queue、Looper。Handler可以把消息/ Runnable对象 发给Looper，由它把消息放入所属线程的消息队列中，然后Looper又会自动把消息队列里的消息/Runnable对象 广播 到所属线程里的Handler，由Handler处理接收到的消息或Runnable对象。
1、Handler
每次创建Handler对象时，它会自动绑定到创建它的线程上。如果是主线程则默认包含一个Message Queue，否则需要自己创建一个消息队列来存储。
Handler是多个线程通信的信使。比如在线程A中创建AHandler，给它绑定一个ALooper，同时创建属于A的消息队列AMessageQueue。然后在线程B中使用AHandler发送消息给ALooper，ALooper会把消息存入到AMessageQueue，然后再把AMessageQueue广播给A线程里的AHandler，它接收到消息会进行处理。从而实现通信。
2、Message Queue
在主线程里默认包含了一个消息队列不需要手动创建。在子线程里，使用Looper.prepare()方法后，会先检查子线程是否已有一个looper对象，如果有则无法创建，因为每个线程只能拥有一个消息队列。没有的话就为子线程创建一个消息队列。
Handler类包含Looper指针和MessageQueue指针，而Looper里包含实际MessageQueue与当前线程指针。
下面分别就UI线程和worker线程讲解handler创建过程：
首先，创建handler时，会自动检查当前线程是否包含looper对象，如果包含，则将handler内的消息队列指向looper内部的消息队列，否则，抛出异常请求执行looper.prepare()方法。
－ 在 UI线程 中，系统自动创建了Looper 对象，所以，直接new一个handler即可使用该机制；
－ 在 worker线程 中，如果直接创建handler会抛出运行时异常－即通过查‘线程－value’映射表发现当前线程无looper对象。所以需要先调用Looper.prepare()方法。在prepare方法里，利用ThreadLocal<Looper>对象为当前线程创建一个Looper（利用了一个Values类，即一个Map映射表，专为thread存储value，此处为当前thread存储一个looper对象）。然后继续创建handler， 让handler内部的消息队列指向该looper的消息队列（这个很重要，让handler指向looper里的消息队列，即二者共享同一个消息队列，然后handler向这个消息队列发送消息，looper从这个消息队列获取消息） 。然后looper循环消息队列即可。当获取到message消息，会找出message对象里的target，即原始发送handler，从而回调handler的handleMessage() 方法进行处理。
－ handler与looper共享消息队列 ，所以handler发送消息只要入列，looper直接取消息即可。
－ 线程与looper映射表 ：一个线程最多可以映射一个looper对象。通过查表可知当前线程是否包含looper，如果已经包含则不再创建新looper。
5、基于这样的机制是怎样实现线程隔离的，即在线程中通信呢。
核心在于 每一个线程拥有自己的handler、message queue、looper体系 。而 每个线程的Handler是公开 的。B线程可以调用A线程的handler发送消息到A的共享消息队列去，然后A的looper会自动从共享消息队列取出消息进行处理。反之一样。
二、上面是基于子线程中利用主线程提供的Handler发送消息出去，然后主线程的Looper从消息队列中获取并处理。那么还有另外两种情况：
1、主线程发送消息到子线程中；
采用的方法和前面类似。要在子线程中实例化AHandler并设定处理消息的方法，同时由于子线程没有消息队列和Looper的轮询，所以要加上Looper.prepare(),Looper.loop()分别创建消息队列和开启轮询。然后在主线程中使用该AHandler去发送消息即可。
2、子线程A与子线程B之间的通信。
1、 Handler为什么能够实现不同线程的通信？核心点在哪？
不同线程之间，每个线程拥有自己的Handler、消息队列和Looper。Handler是公共的，线程可以通过使用目标线程的Handler对象来发送消息，这个消息会自动发送到所属线程的消息队列中去，线程自带的Looper对象会不断循环从里面取出消息并把消息发送给Handler，回调自身Handler的handlerMessage方法，从而实现了消息的线程间传递。
2、 Handler的核心是一种事件激活式（类似传递一个中断）的还是主要是用于传递大量数据的？重点在Message的内容，偏向于数据传输还是事件传输。
目前的理解，它所依赖的是消息队列，发送的自然是消息，即类似事件中断。
0、 Android消息处理机制(Handler、Looper、MessageQueue与Message)
1、 Handler、Looper源码阅读
2、 Android异步消息处理机制完全解析，带你从源码的角度彻底理解
谢谢！
wingjay
❾ 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 socket源码解析(三)socket的connect源码解析
上一篇文章着重的聊了socket服务端的bind，listen，accpet的逻辑。本文来着重聊聊connect都做了什么？
如果遇到什么问题，可以来本文 https://www.jianshu.com/p/da6089fdcfe1 下讨论
当服务端一切都准备好了。客户端就会尝试的通过 connect 系统调用，尝试的和服务端建立远程连接。
首先校验当前socket中是否有正确的目标地址。然后获取IP地址和端口调用 connectToAddress 。
在这个方法中，能看到有一个 NetHooks 跟踪socket的调用，也能看到 BlockGuard 跟踪了socket的connect调用。因此可以hook这两个地方跟踪socket，不过很少用就是了。
核心方法是 socketConnect 方法，这个方法就是调用 IoBridge.connect 方法。同理也会调用到jni中。
能看到也是调用了 connect 系统调用。
文件：/ net / ipv4 / af_inet.c
在这个方法中做的事情如下：
注意 sk_prot 所指向的方法是， tcp_prot 中 connect 所指向的方法，也就是指 tcp_v4_connect .
文件：/ net / ipv4 / tcp_ipv4.c
本质上核心任务有三件:
想要能够理解下文内容，先要明白什么是路由表。
路由表分为两大类：
每个路由器都有一个路由表(RIB)和转发表 (fib表)，路由表用于决策路由，转发表决策转发分组。下文会接触到这两种表。
这两个表有什么区别呢？
网上虽然给了如下的定义：
但实际上在Linux 3.8.1中并没有明确的区分。整个路由相关的逻辑都是使用了fib转发表承担的。
先来看看几个和FIB转发表相关的核心结构体：
熟悉Linux命令朋友一定就能认出这里面大部分的字段都可以通过route命令查找到。
命令执行结果如下：
在这route命令结果的字段实际上都对应上了结构体中的字段含义：
知道路由表的的内容后。再来FIB转发表的内容。实际上从下面的源码其实可以得知，路由表的获取，实际上是先从fib转发表的路由字典树获取到后在同感加工获得路由表对象。
转发表的内容就更加简单
还记得在之前总结的ip地址的结构吗？
需要进行一次tcp的通信，意味着需要把ip报文准备好。因此需要决定源ip地址和目标IP地址。目标ip地址在之前通过netd查询到了，此时需要得到本地发送的源ip地址。
然而在实际情况下，往往是面对如下这么情况：公网一个对外的ip地址，而内网会被映射成多个不同内网的ip地址。而这个过程就是通过DDNS动态的在内存中进行更新。
因此 ip_route_connect 实际上就是选择一个缓存好的，通过DDNS设置好的内网ip地址并找到作为结果返回，将会在之后发送包的时候填入这些存在结果信息。而查询内网ip地址的过程，可以成为RTNetLink。
在Linux中有一个常用的命令 ifconfig 也可以实现类似增加一个内网ip地址的功能：
比如说为网卡eth0增加一个IPV6的地址。而这个过程实际上就是调用了devinet内核模块设定好的添加新ip地址方式，并在回调中把该ip地址刷新到内存中。
注意 devinet 和 RTNetLink 严格来说不是一个存在同一个模块。虽然都是使用 rtnl_register 注册方法到rtnl模块中：
文件：/ net / ipv4 / devinet.c
文件：/ net / ipv4 / route.c
实际上整个route模块，是跟着ipv4 内核模块一起初始化好的。能看到其中就根据不同的rtnl操作符号注册了对应不同的方法。
整个DDNS的工作流程大体如下：
当然，在tcp三次握手执行之前，需要得到当前的源地址，那么就需要通过rtnl进行查询内存中分配的ip。
文件：/ include / net / route.h
这个方法核心就是 __ip_route_output_key .当目的地址或者源地址有其一为空，则会调用 __ip_route_output_key 填充ip地址。目的地址为空说明可能是在回环链路中通信，如果源地址为空，那个说明可能往目的地址通信需要填充本地被DDNS分配好的内网地址。
在这个方法中核心还是调用了 flowi4_init_output 进行flowi4结构体的初始化。
文件：/ include / net / flow.h
能看到这个过程把数据中的源地址，目的地址，源地址端口和目的地址端口，协议类型等数据给记录下来，之后内网ip地址的查询与更新就会频繁的和这个结构体进行交互。
能看到实际上 flowi4 是一个用于承载数据的临时结构体，包含了本次路由操作需要的数据。
执行的事务如下：
想要弄清楚ip路由表的核心逻辑，必须明白路由表的几个核心的数据结构。当然网上搜索到的和本文很可能大为不同。本文是基于LInux 内核3.1.8.之后的设计几乎都沿用这一套。
而内核将路由表进行大规模的重新设计，很大一部分的原因是网络环境日益庞大且复杂。需要全新的方式进行优化管理系统中的路由表。
下面是fib_table 路由表所涉及的数据结构：
依次从最外层的结构体介绍：
能看到路由表的存储实际上通过字典树的数据结构压缩实现的。但是和常见的字典树有点区别，这种特殊的字典树称为LC-trie 快速路由查找算法。
这一篇文章对于快速路由查找算法的理解写的很不错: https://blog.csdn.net/dog250/article/details/6596046
首先理解字典树：字典树简单的来说，就是把一串数据化为二进制格式，根据左0，右1的方式构成的。
如图下所示：
这个过程用图来展示，就是沿着字典树路径不断向下读，比如依次读取abd节点就能得到00这个数字。依次读取abeh就能得到010这个数字。
说到底这种方式只是存储数据的一种方式。而使用数的好处就能很轻易的找到公共前缀，在字典树中找到公共最大子树，也就找到了公共前缀。
而LC-trie 则是在这之上做了压缩优化处理，想要理解这个算法，必须要明白在 tnode 中存在两个十分核心的数据：
这负责什么事情呢？下面就简单说说整个lc-trie的算法就能明白了。
当然先来看看方法 __ip_dev_find 是如何查找
文件：/ net / ipv4 / fib_trie.c
整个方法就是通过 tkey_extract_bits 生成tnode中对应的叶子节点所在index，从而通过 tnode_get_child_rcu 拿到tnode节点中index所对应的数组中获取叶下一级别的tnode或者叶子结点。
其中查找index最为核心方法如上，这个过程，先通过key左移动pos个位，再向右边移动（32 - bits）算法找到对应index。
在这里能对路由压缩算法有一定的理解即可，本文重点不在这里。当从路由树中找到了结果就返回 fib_result 结构体。
查询的结果最为核心的就是 fib_table 路由表，存储了真正的路由转发信息
文件：/ net / ipv4 / route.c
这个方法做的事情很简单，本质上就是想要找到这个路由的下一跳是哪里？
在这里面有一个核心的结构体名为 fib_nh_exception 。这个是指fib表中去往目的地址情况下最理想的下一跳的地址。
而这个结构体在上一个方法通过 find_exception 获得.遍历从 fib_result 获取到 fib_nh 结构体中的 nh_exceptions 链表。从这链表中找到一模一样的目的地址并返回得到的。
文件：/ net / ipv4 / tcp_output.c