android源码分析工具

‘壹’ Android-trace分析工具

1.TraceView

官方说明文档:

https://developer.android.google.cn/studio/profile/cpu-profiler

android CPU profiler

CPU profiler可以实时检查应用的CPU使用率和线程activity,并记录函数跟踪，以便于您可以优化和调试您的应用程序.

Flame Chart如果出现问题 颜色也会加深

2.systrace

简介:

systrace是Android4.1版本之后推出的，对系统Performance分析的工具。systrace的功能包括跟踪系统I/O操作,内核工作队列,CPU负载以及Android各个子系统的运行状况等。

主要由三部分构成:

1.内核部分

systrace采用了linux Kernel的ftrace功能，所以如果要使用systrace的话，必须开启Kernel和ftrace相关的模块.

2.数据采集部分

Android中定义了一个trace类,应用程序可以使用该类把统计信息输出给trace,同时，android有一个atrace程序，它可以从ftrace中读取统计信息然后交给数据分析工具来处理.

3.数据分析工具

Android提供一个systrace.py用来配置数据采集的方法(如采集数据的标签，输出文件名等)和收集ftrace统计数据并生成一个结果网页文件供用户查看。

简单的说,当机器以60帧/秒显示，用户会感知机器流畅。如果出现显示时丢帧的情况，就需要知道系统在做什么?Systrace是用来收集系统和应用的数据信息和一些中间生成数据的细节，在Android4.1和4.2系统之后出现。Systrace在分析一些显示问题上特别有用，如应用画图慢，显示动作或者动画时变形。

抓取systrace

进入本地Android/Sdk/platform-tools/systrace目录下,执行python systrace.py view --time = 10

python脚本的option

‘贰’ [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 RecyclerView的布局管理器 GridLayoutManager源码分析<三>

Android RecyclerView绘制页面的源码分析<一>

Android RecyclerView布局管理器LinearLayoutManager源码分析<二>

以上两篇讲述了RecycerView LinearLayoutManager 页面绘制以及子条目的布局,LinearLayoutManager 是一个线性的管理器即是控制垂直以及水平展示 一个条目表示一行,然而显示生活中有很多需求是一行展示多个子条目这个时候就用到了 GridLayoutManager 表格布局管理器 来实现这种需求
GridLayoutManager :继承于LinearLayoutManager的网格状布局管理器 默认一行展示一个

GridLayoutManager网格布局管理器 实现一行展示多个条目,本章解释了GridLayoutManager的简单源码实现表格布局的大概调用,下一章展示复杂的表格布局即展示不顾地条目数的表格布局

‘肆’ Android 分析OOM工具介绍

如图1所示, 步骤
** 1, 2, 3** 为打开Android Monitor并切换标签到monitor的过程

4, 5, 6 对应的图标和文字含义分别是

MAT 工具识别，并解析hprof文件,
有两种方式可以获得hprof文件

MAT并不能直接打开这两个hprof, 必须通过hprof-conv来转换一次

如图3所示，选中(过滤出MainActivity), 然后通过Objects可以看出它有8个实例

接着选中 com.example.wowo.MainActivity 然后右键选择
Merge shortest paths to GC Roots -> exclude week references

因为弱引用是会被回收的，所以排除掉更加容易发现OOM.

什么是OOM out-of-memory？

Android下的APP运行在VM中(Dalvik or ART), 一个APP需要的内存是有限，这个值在不同的平台, 不同的手机上是不同的，当APP需要的内存超过了内存上限，就会引起OOM.

下面给出一个最基本的Android APP显示HelloWorld的例子.

这时如果不停的旋转屏幕, 这时通过观察Android Monitor里的Free和allocated的memory会发现 allocated 的memory会不断增加，而Free的memory会不断减小

这时通过图1中步聚5 mp java heap, 然后filter到MainActivity, 会发现MainActivity有多个实例

接着再通过MAT来分析， 图4所示

发现有很多FinalizerReference， 应该是与GC有关，由于旋转屏幕会导致MainActivity销毁并重新创建实例，而JVM在创建MainActivity实例时还有free的memory, 所以并没有触发GC，即原来的MainActivity的实例并没有被回收，所以多次旋转后，在free memory还有的情况下就会保存多个MainActivity的实例造成内存泄露的假象。当free memory 不够时，这时会触发GC, 会回收之前销毁的MainActivity的实例。

所以在查看OOM问题时，当allocated内存不断增大时，应该人为先触发GC(点击图1的4)。
如果allocated的内存没有下降，说明当前并没有可回收的实例占据内存了。

而在该例中，如果点击了initiate GC后，allocated的内存立即减少了。
Android Monitor看到MainActivity也就只有一个实例了。

‘伍’ 如何对Android的本地代码进行profiling

现在用Android native code写程序库的人越来越多。对于那些需要写的库实时性要求特别强的应用，通过profiling来进行优化是一个非常有用的特性，因为它能帮你理解程序编译后的本质，比如多少instruction，哪些method调用多少次，多长时间，等等。
Android开发环境提供了Traceview这样一个工具，可以点到这个链接里面去看官方对他的介绍。总的来说，就是它提供给程序开发者目标程序的执行日志，以此帮助你调试程序和优化性能。有两种方法能够声称traceview所需的log，一种是利用DDMS的profiling特性，通过控制什么时候开始和结束logging来获得log。这个方法在你没有程序源代码的时候有用，因为只需要Run程序就能获得log信息，但是没有精准的起始中止控制。另一种是通过将Android自带的Debug类加到code中，然后调用里面的method来开始和中止trace信息的纪录。这个方法能让开发者非常精准地控制什么时候开始纪录，什么时候结束纪录，因为开始和技术都是在code中执行的。

对于Java程序来说，官方网页介绍了一个标准流程，就是在程序中引入Debug类，然后在你想要开始纪录profiling信息的时候调用startMethodTracing()，然后在准备结束的时候调用stopMethodTracing()方法。纪录的log文件默认放在sdcard中。
然而对于本地native代码，该方法就无效了。原因是这个方式只能trace你的java层的方法和其对Android API的调用，却无法trace Android API背后的那些方法，也无法trace你自己写的native code。如果你希望trace这些更底层的代码，就需要用Debug类提供的Debug.startNativeTracing()和 Debug.stopNativeTracing()。而且，这个配对只能工作的虚拟机emulator中，因为只有trace qemu emulator，才能去trace每一个进程的每一条cpu指令，甚至包括内核的代码，我们也才能获得更多的信息比如context switch，cache misses。
下面就来看看，利用该方法对来profile native code是怎样一个流程：
1. 新建一个Android Virtual Device，给一个名字，比如Profile。可以在AVD manager中创建。
2. 在命令行中通过命令”emulator -avd -trace
” 来运行该AVD。比如emulator -avd Profile -trace myTrace。
3. 将startNativeTracing()和stopNativeTracing()添加到你想profile的代码中。
4. 在Eclipse中build代码，确保没有错误。安装到正在运行的AVD中。
5. 去AVD中运行代码，确保你希望trace的代码段正常运行了。如果你观察运行AVD的那个terminal的窗口，应该会有比如“–start tracing–” 和 “–stop tracing–”这样的消息出现，这就说明代码正常运行了。
6. App运行完毕后，退出emulator。
7. 去你的用户目录找trace文件。这个目录是存储你AVD settings的目录，默认一般都在/Home/User/.android/avd/下。这个User是你自己的用户名，如果你是用的Mac或者Linux，这个路径也就是~/.android/avd。
8. 找到和你AVD名字对应的文件夹，里面有另一个子文件夹，命名就是你的trace名字，比如这里就是myTrace。里面的文件包括：
qtrace.bb
qtrace.exc
qtrace.insn
qtrace.method
qtrace.pid
qtrace.static
9.你需要用tracedmmp这个工具来将这些文件转化为符合Traceview格式的文件。问题在于，坑爹的Android SDK/NDK环境不原生提供这个工具。所以……..请看下一步
10. 好吧，这个工具来自于Android的源代码环境。那我们需要做的，就是下载整个Android源代码，编译。这个过程通常会持续……一个小时以上。请参考官方手册来进行编译。如果你使用的是Linux，恭喜你，什么别的资料都不用找，就一步一步按照手册来就行了。如果你是Mac用户……哥们，还是按照官方手册来吧，但过程就听天由命了。
11. Okay，假设到这里，你已经完成了整个Android源代码的编译。接下来，在源代码的根目录下运行“source build/envsetup.sh”，然后将根目录下的/out/host/xxxx/bin加到PARH路径中。xxx表示你的编译平台。这下你就可以run tracedmmp了。开一个终端，执行“tracedmmp ~/.android/avd/Profile/myTrace/”，tracedmmp去分析刚才那些五花八门的二进制文件，挖掘里面的symbolic信息，然后将其和trace数据对应。等一小会，就可以得到instruction的信息，并会生成一个更详细的包括所有profiling信息的html文档，这个文档和Traceview兼容的，可以直接打开，也可以用Traceview工具分析。
这样，整个profiling过程就结束了。
需要注意一点的是，这个方法和method tracing比有一个局限，就是因为工作在真实设备上，所以emulator不能模拟所有的真实设备效果，比如memory contention和bus contention，同时也无法模拟真实的cache效果，因为emulator中的cache设计是大大简化了的。

‘陆’ android framework层用什么工具开发代码

framework的开发比应用层就要烦的多啦。做应用在eclipse中就足够了，用android系统中的控件等工具，或者是自己写个类来实现特定的功能。而framework层的开发，需要往源码中添加代码、xml、图片、id等等数据，这个id可是费了我好大的劲才搞定的。在项目开始的一个半月里，我探索、尝试了很多，现在把我的经验分享出来。网上关于framework层的开发信息很少，多是靠自己。
最有效的方式就是分析android的源码，看google是怎样实现一个类的，以及类的层次。我现在看的主要是widget和app中的代码，其他的还没涉及。像View，ViewGroup，Activity，ActivityThread都是非常重要的类，也是代码量很大的类，我只是大概地过了下，还没有仔细分析过。

我花大力气的地方是资源文件夹下values中几个文件的作用。

‘柒’ 谁有android4.4 Email源码分析文档

Google提供的Android包含了原始Android的目标机代码，主机编译工具、仿真环境，下载的代码包经过解压后(这里是Android2.2的源码包)，源代码的第一层目录结构如下：
|-- Makefile
|-- bionic （bionic C库）
|-- bootable （启动引导相关代码）
|-- build （存放系统编译规则及generic等基础开发包配置）

|-- cts （Android兼容性测试套件标准）
|-- dalvik （dalvik JAVA虚拟机）
|-- development （应用程序开发相关）
|-- external （android使用的一些开源的模组）
|-- frameworks （核心框架——java及C++语言）
|-- hardware （主要保护硬解适配层HAL代码）
|-- libcore
|-- ndk
|-- device
|-- out （编译完成后的代码输出与此目录）
|-- packages （应用程序包）
|-- prebuilt （x86和arm架构下预编译的一些资源）
|-- sdk （sdk及模拟器）
|-- system （文件系统库、应用及组件——C语言）
`-- vendor （厂商定制代码）

bionic 目录

|-- libc （C库）
| |-- arch-arm （ARM架构，包含系统调用汇编实现）
| |-- arch-x86 （x86架构，包含系统调用汇编实现）
| |-- bionic （由C实现的功能，架构无关）
| |-- docs （文档）
| |-- include （头文件）
| |-- inet
| |-- kernel （Linux内核中的一些头文件）
| |-- netbsd （？netbsd系统相关，具体作用不明）
| |-- private （？一些私有的头文件）
| |-- stdio （stdio实现）
| |-- stdlib （stdlib实现）
| |-- string （string函数实现）
| |-- tools （几个工具）
| |-- tzcode （时区相关代码）
| |-- unistd （unistd实现）
| `-- zoneinfo （时区信息）
|-- libdl （libdl实现，dl是动态链接，提供访问动态链接库的功能）
|-- libm （libm数学库的实现，）
| |-- alpha （apaha架构）
| |-- amd64 （amd64架构）
| |-- arm （arm架构）
| |-- bsdsrc （？bsd的源码）
| |-- i386 （i386架构）
| |-- i387 （i387架构？）
| |-- ia64 （ia64架构）
| |-- include （头文件）
| |-- man （数学函数，后缀名为.3，一些为freeBSD的库文件）
| |-- powerpc （powerpc架构）
| |-- sparc64 （sparc64架构）
| `-- src （源代码）
|-- libstdc++ （libstdc++ C++实现库）
| |-- include （头文件）
| `-- src （源码）
|-- libthread_db （多线程程序的调试器库）
| `-- include （头文件）
`-- linker （动态链接器）
`-- arch （支持arm和x86两种架构）

bootable 目录

|-- bootloader （适合各种bootloader的通用代码）
| `-- legacy （估计不能直接使用，可以参考）
| |-- arch_armv6 （V6架构，几个简单的汇编文件）
| |-- arch_msm7k （高通7k处理器架构的几个基本驱动）
| |-- include （通用头文件和高通7k架构头文件）
| |-- libboot （启动库，都写得很简单）
| |-- libc （一些常用的c函数）
| |-- nandwrite （nandwirte函数实现）
| `-- usbloader （usbloader实现）
|-- diskinstaller （android镜像打包器，x86可生产iso）
`-- recovery （系统恢复相关）
|-- edify （升级脚本使用的edify脚本语言）
|-- etc （init.rc恢复脚本）
|-- minui （一个简单的UI）
|-- minzip （一个简单的压缩工具）
|-- mttils （mtd工具）
|-- res （资源）
| `-- images （一些图片）
|-- tools （工具）
| `-- ota （OTA Over The Air Updates升级工具）
`-- updater （升级器）

build目录

|-- core （核心编译规则）
|-- history （历史记录）
|-- libs
| `-- host （主机端库，有android “cp”功能替换）
|-- target （目标机编译对象）
| |-- board （开发平台）
| | |-- emulator （模拟器）
| | |-- generic （通用）
| | |-- idea6410 （自己添加的）
| | `-- sim （最简单）
| `-- proct （开发平台对应的编译规则）
| `-- security （密钥相关）
`-- tools （编译中主机使用的工具及脚本）
|-- acp （Android "acp" Command）
|-- apicheck （api检查工具）
|-- applypatch （补丁工具）
|-- apriori （预链接工具）
|-- atree （tree工具）
|-- bin2asm （bin转换为asm工具）
|-- check_prereq （检查编译时间戳工具）
|-- dexpreopt （模拟器相关工具，具体功能不明）
|-- droiddoc （？作用不明，java语言，网上有人说和JDK5有关）
|-- fs_config （This program takes a list of files and directories）
|-- fs_get_stats （获取文件系统状态）
|-- iself （判断是否ELF格式）
|-- isprelinked （判断是否prelinked）
|-- kcm （按键相关）
|-- lsd （List symbol dependencies）
|-- releasetools （生成镜像的工具及脚本）
|-- rgb2565 （rgb转换为565）
|-- signapk （apk签名工具）
|-- soslim （strip工具）
`-- zipalign （zip archive alignment tool）

‘捌’ 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 ! ***