Android 八股文(二)

William C.2024-03-12

Android 八股文(二)

系统篇

类加载机制

Android中的类加载机制与Java的类加载机制类似，但由于Android特有的虚拟机（如Dalvik和ART）以及应用的打包方式（APK），其类加载过程有一些特定的特点和优化。以下是Android类加载机制的主要方面：

类加载的基本过程
类加载过程分为三个主要阶段：
- 加载（Loading）：类加载器（ClassLoader）将字节码文件加载到内存中。
- 连接（Linking）：包括验证（Verification）、准备（Preparation）和解析（Resolution）等过程，确保类的正确性。
- 初始化（Initialization）：执行类的静态块和初始化静态变量。
ClassLoader的层次结构
Android中的类加载器继承自Java的类加载体系，主要有以下几种：
- BootClassLoader：这是Android中的引导类加载器，用来加载系统核心类，如java.*、android.*等基础库。
- PathClassLoader：主要用于加载应用程序的类（即从/data/app/中的APK文件中加载类），它从设备文件系统中指定路径查找类。
- DexClassLoader：用来加载.dex或.apk文件中的类，尤其是在需要动态加载时使用，如在插件化框架中加载外部的.dex文件。
- ApplicationClassLoader：这个是Android应用程序的类加载器，继承自PathClassLoader，负责加载应用自己的类和资源。
Android类加载机制的双亲委派模式
类加载采用的是双亲委派模型，即一个类加载器加载类时，首先会将请求委派给它的父类加载器：
- 如果父类加载器能够加载该类，则直接返回该类。
- 如果父类加载器不能加载，则由当前的类加载器加载。
这样做的好处是防止重复加载类，并且保证系统类优先被加载，避免自定义类覆盖系统类。
Dex文件与OAT文件
Android的应用程序打包成APK后，类文件会编译成.dex（Dalvik Executable）格式，这是一种针对Android虚拟机优化过的字节码格式。

在早期的Dalvik虚拟机中，APK中的.dex文件会被解释执行。而在Android 5.0之后，采用了ART（Android Runtime），APK在安装时会被提前编译（Ahead-Of-Time，AOT）为.oat文件（optimized Android executables），提升了运行时的性能。这意味着大部分类的加载是在安装时就已经完成了编译和优化，而不是在运行时解释执行。
多Dex和动态加载
当APK文件过大时，可能会包含多个.dex文件，这时可以通过MultiDex机制来加载额外的类文件。Android在5.0以下版本中并不支持直接加载多个.dex，但通过MultiDex库，可以动态加载附加的.dex文件。

动态加载的场景下，还可以使用DexClassLoader来加载外部的类，例如从网络下载的插件或热修复补丁。
热修复与插件化
热修复（例如修复bug）和插件化技术常常会用到类加载器。通过DexClassLoader或修改PathClassLoader，可以动态地将补丁文件或插件加载到内存中，而无需重新启动应用。
Android中的优化
Android在类加载过程中，采用了多种优化策略以提高性能：
- 内存优化：通过共享dex文件，多个应用可以共享已经加载的库，减少内存消耗。
- 预编译：通过AOT编译，减少了运行时的类加载时间。
- 缓存机制：加载的类会被缓存起来，避免重复加载。

类加载器

类加载流程中的“加载”阶段被放在了Java虚拟机外部实现，实现这个阶段的工具称为类加载器（Class Loader）。

类与类加载器

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段。对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性。通俗的讲，就是两个类是否”相等“的一个大前提是这两个类是由同一类加载器加载而来，不同类加载器加载出的Class对象一定不是同一个对象。

这里所指的“相等”，包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括了使用instanceof关键字做对象所属关系判定等各种情况。

双亲委派模型

站在Java虚拟机的角度来看，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另外一种就是其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader。

站在Java开发人员的角度来看，类加载器就应当划分得更细致一些。自JDK 1.2以来，Java一直保持着三层类加载器、双亲委派的类加载架构。这三层类加载器如下：

启动类加载器（Bootstrap Class Loader）：这个类加载器负责加载存放在\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt .jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。
扩展类加载器（Extension Class Loader）：这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责加载\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。
应用程序类加载器（Application Class Loader）：这个类加载器由sun.misc.Launcher$AppClassLoader来实现。由于应用程序类加载器是ClassLoader类中的getSystemClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

这些类加载器之间的协作关系通常情况下如下图所示：

这个模型被称为”双亲委派模型（Parents Delegation Model）“。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的，而是通常使用组合（Composition）关系来复用父加载器的代码。

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

以类java.lang.Object为例，它存放在rt .jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。

双亲委派模型对于保证Java程序的稳定运作极为重要，但它的实现却异常简单，用以实现双亲委派的代码只有短短十余行，全部集中在java.lang.ClassLoader的loadClass()方法之中，如下所示。

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // 首先，检查请求的类是否已经被加载过了
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                   // 委派父类加载器加载
                    c = parent.loadClass(name, false);
                } else {
                   // 如果父类加载器为空
                   // 使用启动类加载器加载
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // 如果父类加载器抛出ClassNotFoundException 
                // 说明父类加载器无法完成加载请求
            }

            if (c == null) {
                // 在父类加载器无法加载时
                // 再调用本身的findClass方法来进行类加载
                long t1 = System.nanoTime();
                c = findClass(name);

                // 统计
                PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

Android中的类加载器

Android 和传统的 JVM 是一样的，也需要通过 ClassLoader 将目标类加载到内存，类加载器之间也符合双亲委派模型。但是在 Android 中，ClassLoader 的加载细节有略微的差别。

在 Android 虚拟机里是无法直接运行 .class 文件的，Android 会将所有的 .class 文件转换成一个 .dex 文件，并且 Android 将加载 .dex 文件的实现封装在 BaseDexClassLoader 中，而我们一般只使用它的两个子类：PathClassLoader 和 DexClassLoader。

PathClassLoader

PathClassLoader 的源码中只有两个构造函数，如下：

/**
 * @param dexPath  包含.dex文件的jar/apk文件路径
 */
public PathClassLoader(String dexPath, ClassLoader parent) {
    super(dexPath, null, null, parent);
}
/**
 * @param dexPath  包含.dex文件的jar/apk文件路径
 * @param librarySearchPath C/C++ native库的路径
 */
public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
    super(dexPath, null, librarySearchPath, parent);
}

PathClassLoader继承自BaseDexClassLoader，BaseDexClassLoader中dexPath受到限制，一般只能是已经安装应用的apk路径。不过PathClassLoader情况比较特殊：

在Android 4.4以下版本时，PathClassLoader只能加载已安装到系统中的apk/dex文件。
Android 5.0~Android 8.0，PathClassLoader没有限制必须已安装的apk，并且PathClassLoader中optimizedDirectory固定为null，所以无法进行dex2oat操作，最后会直接加载原始dex，达到了禁用dex2oat以实现加载加速的效果。
Android 8.1或更高，此时DexClassLoader中optimizedDirectory同样固定传递null，oat输出目录在dex目录/oat/下，此时DexClassLoader与PathClassLoader相同。

当一个 App 被安装到手机后，apk 里面的 class.dex 中的 class 均是通过 PathClassLoader 来加载的，可以通过如下代码验证：

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        val loader = MainActivity::class.java.classLoader
        println(loader.toString())
    }
}

打印结果如下：

DexClassLoader

对比 PathClassLoader 在Android 4.4以下只能加载已经安装应用的 dex 或 apk 文件，DexClassLoader 则没有此限制，可以从 SD 卡上加载包含 class.dex 的 .jar 和 .apk 文件，这也是插件化和热修复的基础，在不需要安装应用的情况下，完成需要使用的 dex 的加载。

DexClassLoader 的源码里面只有一个构造方法，代码如下：

/**
 * @param dexPath 包含 class.dex 的 apk、jar 文件路径 ，多个路径用文件分隔符（默认是“:”）分隔
 * @param optimizedDirectory 用来缓存优化的 dex 文件的路径，即从 apk 或 jar 文件中提取出来的 dex 文件。该路径不可以为空，且应该是应用私有的，有读写权限的路径。
 */
public DexClassLoader(String dexPath, String optimizedDirectory,
        String librarySearchPath, ClassLoader parent) {
    super(dexPath, null, librarySearchPath, parent);
}

接下来我们尝试使用DexClassLoader来自定义一个类加载器实现热修复。

类加载器实践案例

自定义类加载器

我们尝试使用自己的类加载器来加载本地磁盘上的类文件。

首先创建一个测试类，并将其复制到磁盘的某一处，这里我创建了一个Test类，编译后将其复制到”~/Downloads”目录下。

class Test {
    fun testPrint() {
        println("This class is load from custom class loader.")
    }
}

接下来，创建一个DiskClassLoader继承自ClassLoader，重写其findClass方法，如下所示。

/**
 * 加载本地磁盘中的class文件
 */
class DiskClassLoader(private val filePath: String) : ClassLoader() {

    override fun findClass(name: String?): Class<*> {
        val newPath = "$filePath$name.class"
        var classBytes: ByteArray? = null
        val path: Path
        try {
            path = Paths.get(URI(newPath))
            classBytes = Files.readAllBytes(path)
        } catch (e: URISyntaxException) {
            e.printStackTrace()
        } catch (e: IOException) {
            e.printStackTrace()
        }
        // 创建Class对象
        return defineClass(name, classBytes, 0, classBytes?.size ?: 0)
    }
}

接下来尝试使用这个类加载器：

val loader = DiskClassLoader("file:///User/sukaidev/Downloads/")
try {
    val c = loader.loadClass("Test")
    if (c != null) {
        // 反射创建对象
        val obj = c.newInstance()
        // 反射调用testPrint()方法
        c.getDeclaredMethod("testPrint").invoke(obj)
    }
} catch (e: Exception) {
    e.printStackTrace()
}

类加载器成功加载了路径为”User/sukaidev/Downloads/Test.class”的文件。

热修复实践

创建项目

先来创建一个创建 Android 项目，名字随意，项目结构如下：

ISay.java 是一个接口，内部只定义了一个方法 saySomething。

package com.sukaidev.dexclassloaderhotfix

interface ISay {
    fun saySomething(): String
}

SayException.java 实现了 ISay 接口，但是在 saySomething 方法中，打印“Oops! Something went wrong.”来模拟一个线上的 bug。

package com.sukaidev.dexclassloaderhotfix

class SayException : ISay {
    override fun saySomething(): String {
        return "Oops! Something went wrong."
    }
}

最后在 MainActivity.kt 中，当点击 Button 的时候，将 saySomething 返回的内容通过 Toast 显示在屏幕上。

package com.sukaidev.dexclassloaderhotfix

class MainActivity : AppCompatActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
    val say: ISay = SayException()
    findViewById<AppCompatButton>(R.id.btn).setOnClickListener {
      Toast.makeText(this, say.saySomething(), Toast.LENGTH_SHORT).show()
    }
  }
}

点击按钮模拟线上报错，效果如下。

接下来尝试对其进行热修复。

创建热修复补丁

新建一个Java module用于制作热修复补丁，新建ISay和SayHotFix两个类，注意包名必须保持与上面一致。

package com.sukaidev.dexclassloaderhotfix

interface ISay {
    fun saySomething(): String
}

SayHotFix 实现 ISay 接口，并在 saySomething 中返回了新的结果，用来模拟 bug 修复后的结果。

package com.sukaidev.dexclassloaderhotfix

class SayHotFix : ISay {
    override fun saySomething(): String {
        return "Everything is OK."
    }
}

接下来只需要build一下项目，就会在模块的build/libs目录下生成jar包。

这个hotfix.jar就是我们需要的补丁包了，但是光有jar包是不行的，DexClassLoader只能加载.dex类型的包，因此接下来通过dx工具将生成的hotfix.jar优化为dex文件。

dx工具可以在Android Sdk目录下的build-tools目录中找到各版本的dx程序，例如我的电脑可以在版本号为30.0.3的build-tools中找到：

使用命令优化jar包：

1	dx –dex –output=hotfix_dex.jar hotfix.jar

这样我们就拿到了最终需要的补丁包hotfix_dex.jar。

加载补丁包

正常来讲我们的补丁包是通过后端下发，然后客户端使用DexClassLoader来加载的，这里为了方便模拟，直接通过adb命令push到sdk卡中：

1	adb push hotfix_dex.jar /storage/emulated/0/

接着修改 MainActivity 中的逻辑，使用DexClassLoader加载HotFix patch中的 SayHotFix类，如下：

class MainActivity : AppCompatActivity() {

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
    var say: ISay
    findViewById<AppCompatButton>(R.id.btn).setOnClickListener {
      val jarFile =
        File(Environment.getExternalStorageDirectory().path + File.separator + "hotfix_dex.jar")

      if (!jarFile.exists()) {
        say = SayException()
        Toast.makeText(this, say.saySomething(), Toast.LENGTH_SHORT).show()
        return@setOnClickListener
      }

      val dexClassLoader =
        DexClassLoader(jarFile.absolutePath, filesDir.absolutePath, null, classLoader)
      try {
        val clazz = dexClassLoader.loadClass("com.sukaidev.dexclassloaderhotfix.SayHotFix")
        val iSay: ISay = clazz.newInstance() as ISay
        Toast.makeText(this, iSay.saySomething(), Toast.LENGTH_SHORT).show()
      } catch (e: Exception) {
        e.printStackTrace()
      }
    }
  }
}

注意这里需求读取SD卡上的补丁包，API 23以上需要动态申请权限。运行后效果如下：

Binder机制

1.Binder到底是什么？

中文即粘合剂，意思为粘合了两个不同的进程

网上有很多对Binder的定义，但都说不清楚：Binder是跨进程通信方式、它实现了IBinder接口，是连接 ServiceManager的桥梁blabla，估计大家都看晕了，没法很好的理解

我认为：对于Binder的定义，在不同场景下其定义不同

2. 知识储备

在讲解Binder前，我们先了解一些Linux的基础知识

进程空间划分

一个进程空间分为用户空间 & 内核空间（Kernel），即把进程内用户 & 内核隔离开来
二者区别：
进程间，用户空间的数据不可共享，所以用户空间 = 不可共享空间
进程间，内核空间的数据可共享，所以内核空间 = 可共享空间

所有进程共用1个内核空间

进程内用户空间 & 内核空间进行交互需通过系统调用，主要通过函数：

copy_from_user（）：将用户空间的数据拷贝到内核空间
copy_to_user（）：将内核空间的数据拷贝到用户空间

进程隔离 & 跨进程通信（ IPC ）

进程隔离
为了保证安全性 & 独立性，一个进程不能直接操作或者访问另一个进程，即Android的进程是相互独立、隔离的
跨进程通信（ IPC ）
即进程间需进行数据交互、通信
跨进程通信的基本原理

a. 而Binder的作用则是：连接两个进程，实现了mmap()系统调用，主要负责创建数据接收的缓存空间 & 管理数据接收缓存
b. 注：传统的跨进程通信需拷贝数据2次，但Binder机制只需1次，主要是使用到了内存映射，具体下面会详细说明

3. Binder 跨进程通信机制模型

模型原理图

Binder 跨进程通信机制模型基于 Client - Server 模式

模型组成角色说明

此处重点讲解 Binder驱动的作用 & 原理：

简介

跨进程通信的核心原理

模型原理步骤说明

额外说明

说明1：Client进程、Server进程 & Service Manager 进程之间的交互都必须通过Binder驱动（使用 open 和 ioctl文件操作函数），而非直接交互
原因：

Client进程、Server进程 & Service Manager进程属于进程空间的用户空间，不可进行进程间交互
Binder驱动属于进程空间的内核空间，可进行进程间 & 进程内交互
所以，原理图可表示为以下：

虚线表示并非直接交互

说明2： Binder驱动 & Service Manager进程属于 Android基础架构（即系统已经实现好了）；而Client 进程和 Server 进程属于Android应用层（需要开发者自己实现）
所以，在进行跨进程通信时，开发者只需自定义Client & Server 进程并显式使用上述3个步骤，最终借助 Android的基本架构功能就可完成进程间通信

说明3：Binder请求的线程管理

Server进程会创建很多线程来处理Binder请求
Binder模型的线程管理采用Binder驱动的线程池，并由Binder驱动自身进行管理
而不是由Server进程来管理的
一个进程的Binder线程数默认最大是16，超过的请求会被阻塞等待空闲的Binder线程。
所以，在进程间通信时处理并发问题时，如使用ContentProvider时，它的CRUD（创建、检索、更新和删除）方法只能同时有16个线程同时工作
至此，我相信大家对Binder 跨进程通信机制模型已经有了一个非常清晰的定性认识
下面，我将通过一个实例，分析Binder跨进程通信机制模型在 Android中的具体代码实现方式
即分析上述步骤在Android中具体是用代码如何实现的

4. Binder机制在Android中的具体实现原理

Binder机制在 Android中的实现主要依靠 Binder类，其实现了IBinder 接口

实例说明：Client进程需要调用 Server进程的加法函数（将整数a和b相加）

即：

Client进程需要传两个整数给 Server进程
Server进程需要把相加后的结果返回给Client进程
具体步骤
下面，我会根据Binder 跨进程通信机制模型的步骤进行分析

步骤1：注册服务

过程描述
Server进程通过Binder驱动向 Service Manager进程注册服务
代码实现
Server进程创建一个 Binder 对象

Binder 实体是 Server进程在 Binder 驱动中的存在形式
该对象保存 Server 和 ServiceManager 的信息（保存在内核空间中）
Binder 驱动通过内核空间的Binder 实体找到用户空间的Server对象

    
    Binder binder = new Stub();
    // 步骤1：创建Binder对象 ->>分析1

    // 步骤2：创建 IInterface 接口类 的匿名类
    // 创建前，需要预先定义 继承了IInterface 接口的接口 -->分析3
    IInterface plus = new IPlus(){

          // 确定Client进程需要调用的方法
          public int add(int a,int b) {
               return a+b;
         }

          // 实现IInterface接口中唯一的方法
          public IBinder asBinder（）{ 
                return null ;
           }
};
          // 步骤3
          binder.attachInterface(plus，"add two int");
         // 1. 将（add two int，plus）作为（key,value）对存入到Binder对象中的一个Map<String,IInterface>对象中
         // 2. 之后，Binder对象 可根据add two int通过queryLocalIInterface（）获得对应IInterface对象（即plus）的引用，可依靠该引用完成对请求方法的调用
        // 分析完毕，跳出


<-- 分析1：Stub类 -->
    public class Stub extends Binder {
    // 继承自Binder类 ->>分析2

          // 复写onTransact（）
          @Override
          boolean onTransact(int code, Parcel data, Parcel reply, int flags){
          // 具体逻辑等到步骤3再具体讲解，此处先跳过
          switch (code) { 
                case Stub.add： { 

                       data.enforceInterface("add two int"); 

                       int  arg0  = data.readInt();
                       int  arg1  = data.readInt();

                       int  result = this.queryLocalIInterface("add two int") .add( arg0,  arg1); 

                        reply.writeInt(result); 

                        return true; 
                  }
           } 
      return super.onTransact(code, data, reply, flags); 

}
// 回到上面的步骤1，继续看步骤2

<-- 分析2：Binder 类 -->
 public class Binder implement IBinder{
    // Binder机制在Android中的实现主要依靠的是Binder类，其实现了IBinder接口
    // IBinder接口：定义了远程操作对象的基本接口，代表了一种跨进程传输的能力
    // 系统会为每个实现了IBinder接口的对象提供跨进程传输能力
    // 即Binder类对象具备了跨进程传输的能力

        void attachInterface(IInterface plus, String descriptor)；
        // 作用：
          // 1. 将（descriptor，plus）作为（key,value）对存入到Binder对象中的一个Map<String,IInterface>对象中
          // 2. 之后，Binder对象 可根据descriptor通过queryLocalIInterface（）获得对应IInterface对象（即plus）的引用，可依靠该引用完成对请求方法的调用

        IInterface queryLocalInterface(Stringdescriptor) ；
        // 作用：根据 参数 descriptor 查找相应的IInterface对象（即plus引用）

        boolean onTransact(int code, Parcel data, Parcel reply, int flags)；
        // 定义：继承自IBinder接口的
        // 作用：执行Client进程所请求的目标方法（子类需要复写）
        // 参数说明：
        // code：Client进程请求方法标识符。即Server进程根据该标识确定所请求的目标方法
        // data：目标方法的参数。（Client进程传进来的，此处就是整数a和b）
        // reply：目标方法执行后的结果（返回给Client进程）
         // 注：运行在Server进程的Binder线程池中；当Client进程发起远程请求时，远程请求会要求系统底层执行回调该方法

        final class BinderProxy implements IBinder {
         // 即Server进程创建的Binder对象的代理对象类
         // 该类属于Binder的内部类
        }
        // 回到分析1原处
}

<-- 分析3：IInterface接口实现类 -->

 public interface IPlus extends IInterface {
          // 继承自IInterface接口->>分析4
          // 定义需要实现的接口方法，即Client进程需要调用的方法
         public int add(int a,int b);
// 返回步骤2
}

<-- 分析4：IInterface接口类 -->
// 进程间通信定义的通用接口
// 通过定义接口，然后再服务端实现接口、客户端调用接口，就可实现跨进程通信。
public interface IInterface
{
    // 只有一个方法：返回当前接口关联的 Binder 对象。
    public IBinder asBinder();
}
  // 回到分析3原处

注册服务后，Binder驱动持有 Server进程创建的Binder实体

步骤2：获取服务

Client进程使用某个 service前（此处是相加函数），须通过Binder驱动向 ServiceManager进程获取相应的Service信息
具体代码实现过程如下：

此时，Client进程与 Server进程已经建立了连接

步骤3：使用服务

Client进程根据获取到的 Service信息（Binder代理对象），通过Binder驱动建立与该Service所在Server进程通信的链路，并开始使用服务

过程描述

Client进程将参数（整数a和b）发送到Server进程
Server进程根据Client进程要求调用目标方法（即加法函数）
Server进程将目标方法的结果（即加法后的结果）返回给Client进程

代码实现过程

① Client进程将参数（整数a和b）发送到Server进程

// 1. Client进程 将需要传送的数据写入到Parcel对象中
// data = 数据 = 目标方法的参数（Client进程传进来的，此处就是整数a和b） + IInterface接口对象的标识符descriptor
  android.os.Parcel data = android.os.Parcel.obtain();
  data.writeInt(a); 
  data.writeInt(b); 

  data.writeInterfaceToken("add two int");；
  // 方法对象标识符让Server进程在Binder对象中根据"add two int"通过queryLocalIInterface（）查找相应的IInterface对象（即Server创建的plus），Client进程需要调用的相加方法就在该对象中

  android.os.Parcel reply = android.os.Parcel.obtain();
  // reply：目标方法执行后的结果（此处是相加后的结果）

// 2. 通过 调用代理对象的transact（） 将 上述数据发送到Binder驱动
  binderproxy.transact(Stub.add, data, reply, 0)
  // 参数说明：
    // 1. Stub.add：目标方法的标识符（Client进程 和 Server进程 自身约定，可为任意）
    // 2. data ：上述的Parcel对象
    // 3. reply：返回结果
    // 0：可不管

// 注：在发送数据后，Client进程的该线程会暂时被挂起
// 所以，若Server进程执行的耗时操作，请不要使用主线程，以防止ANR


// 3. Binder驱动根据 代理对象 找到对应的真身Binder对象所在的Server 进程（系统自动执行）
// 4. Binder驱动把 数据 发送到Server 进程中，并通知Server 进程执行解包（系统自动执行）

② Server进程根据Client进要求调用目标方法（即加法函数）

// 1. 收到Binder驱动通知后，Server 进程通过回调Binder对象onTransact（）进行数据解包 & 调用目标方法
  public class Stub extends Binder {

          // 复写onTransact（）
          @Override
          boolean onTransact(int code, Parcel data, Parcel reply, int flags){
          // code即在transact（）中约定的目标方法的标识符

          switch (code) { 
                case Stub.add： { 
                  // a. 解包Parcel中的数据
                       data.enforceInterface("add two int"); 
                        // a1. 解析目标方法对象的标识符

                       int  arg0  = data.readInt();
                       int  arg1  = data.readInt();
                       // a2. 获得目标方法的参数
                      
                       // b. 根据"add two int"通过queryLocalIInterface（）获取相应的IInterface对象（即Server创建的plus）的引用，通过该对象引用调用方法
                       int  result = this.queryLocalIInterface("add two int") .add( arg0,  arg1); 
                      
                        // c. 将计算结果写入到reply
                        reply.writeInt(result); 
                        
                        return true; 
                  }
           } 
      return super.onTransact(code, data, reply, flags); 
      // 2. 将结算结果返回 到Binder驱动

③ Server进程将目标方法的结果（即加法后的结果）返回给Client进程

  // 1. Binder驱动根据 代理对象 沿原路 将结果返回 并通知Client进程获取返回结果
  // 2. 通过代理对象 接收结果（之前被挂起的线程被唤醒）

    binderproxy.transact(Stub.ADD, data, reply, 0)；
    reply.readException();；
    result = reply.readInt()；
          }
}