并发编程领域可以抽象成三个核心问题：分工、同步和互斥。

1. 分工

所谓分工，即拆分任务，例如不同的线程做不同的事情。

Java SDK 并发包里的 Executor、Fork/Join、Future 本质上都是一种分工方法。除此之外，并发编程领域还总结了一些设计模式，基本上都是和分工方法相关的，例如生产者 - 消费者、Thread-Per-Message、Worker Thread 模式等都是用来指导你如何分工的。

2. 同步

一个线程执行完了一个任务，如何通知执行后续任务的线程开工而已。

协作一般是和分工相关的。Java SDK 并发包里的 Executor、Fork/Join、Future 本质上都是分工方法，但同时也能解决线程协作的问题。除此之外，Java SDK 里提供的 CountDownLatch、CyclicBarrier、Phaser、Exchanger 也都是用来解决线程协作问题的。

当某个条件不满足时，线程需要等待，当某个条件满足时，线程需要被唤醒执行。

在 Java 并发编程领域，解决协作问题的核心技术是管程。管程是解决并发问题的万能钥匙。

3. 互斥

分工、同步主要强调的是性能，但并发程序里还有一部分是关于正确性的，用专业术语叫“线程安全”。并发程序里，当多个线程同时访问同一个共享变量的时候，结果是不确定的。不确定，则意味着可能正确，也可能错误，事先是不知道的。而导致不确定的主要源头是可见性问题、有序性问题和原子性问题，为了解决这三个问题，Java 语言引入了内存模型，内存模型提供了一系列的规则，利用这些规则，我们可以避免可见性问题、有序性问题，但是还不足以完全解决线程安全问题。解决线程安全问题的核心方案还是互斥。

所谓互斥，指的是同一时刻，只允许一个线程访问共享变量。

实现互斥的核心技术就是锁，Java 语言里 synchronized、SDK 里的各种 Lock 都能解决互斥问题。虽说锁解决了安全性问题，但同时也带来了性能问题，那如何保证安全性的同时又尽量提高性能呢？可以分场景优化，Java SDK 里提供的 ReadWriteLock、StampedLock 就可以优化读多写少场景下锁的性能。还可以使用无锁的数据结构，例如 Java SDK 里提供的原子类都是基于无锁技术实现的。

除此之外，还有一些其他的方案，原理是不共享变量或者变量只允许读。这方面，Java 提供了 Thread Local 和 final 关键字，还有一种 Copy-on-write 的模式。

使用锁除了要注意性能问题外，还需要注意死锁问题。

开篇词 (1讲)

开篇词 | 为什么我们要学习Java虚拟机？

模块一：Java虚拟机基本原理 (12讲)

01 | Java代码是怎么运行的？

02 | Java的基本类型

03 | Java虚拟机是如何加载Java类的?

04 | JVM是如何执行方法调用的？（上）

05 | JVM是如何执行方法调用的？（下）

06 | JVM是如何处理异常的？

07 | JVM是如何实现反射的？

08 | JVM是怎么实现invokedynamic的？（上）

09 | JVM是怎么实现invokedynamic的？（下）

10 | Java对象的内存布局

11 | 垃圾回收（上）

12 | 垃圾回收（下）

模块二：高效编译 (12讲)

【工具篇】 常用工具介绍

13 | Java内存模型

14 | Java虚拟机是怎么实现synchronized的？

15 | Java语法糖与Java编译器

16 | 即时编译（上）

17 | 即时编译（下）

18 | 即时编译器的中间表达形式

19 | Java字节码（基础篇）

20 | 方法内联（上）

21 | 方法内联（下）

22 | HotSpot虚拟机的intrinsic

23 | 逃逸分析

模块三：代码优化 (10讲)

24 | 字段访问相关优化

25 | 循环优化

26 | 向量化

27 | 注解处理器

28 | 基准测试框架JMH（上）

29 | 基准测试框架JMH（下）

30 | Java虚拟机的监控及诊断工具（命令行篇）

31 | Java虚拟机的监控及诊断工具（GUI篇）

32 | JNI的运行机制

33 | Java Agent与字节码注入

模块四：黑科技 (3讲)

34 | Graal：用Java编译Java

35 | Truffle：语言实现框架

36 | SubstrateVM：AOT编译框架

尾声 (1讲)

尾声 | 道阻且长，努力加餐

1. 典型情况：在有用户参与的情况下，Activity所经过的生命周期的改变
2. 异常情况：Activity被系统回收或者由于当前设备的Configuration发生改变从而导致Activity被销毁重建。

1.1 Activity的生命周期全面分析 / 1

1.1.1 典型情况下的生命周期分析 / 2

• onStart和onResume，onPause和onStop的区别？
  • onStart和onStop是从Activity是否可见来回调的
  • onResume和onPause是从Activity是否位于前台这个角度来回调的。
• 当前Activity为A，打开ActivityB，A的onPause会先于B的onResume执行。所以不能在onPause中执行重量级的操作，因为onPause方法执行完新的Activity的onResume才可以执行。

1.1.2 异常情况下的生命周期分析 / 8

情况1：资源相关的系统配置发生改变导致Activity被杀死并重新创建

1. Activity异常状态终止时，系统会调用onSaveInstanceState来保存Activity的状态
2. 当Activity被重新创建时，系统会调用onRestoreInstanceState，同时把被销毁时保存的Bundle对象传递给方法。
3. 系统默认恢复的：文本框的输入、ListView的滚动位置
4. 保存和恢复View的层次结构：委托上层保存数据 Activity > Window > ViewGroup(DecorView) 委托思想 上层委托下层，父容器委托子元素处理事情。

情况2：内存资源不足导致低优先级的Activity被杀死

1. Activity按优先级从高到低：
   1. 前台Activity：正在和用户交互的Activity
   2. 可见但非前台Activity：有弹窗的Activity
   3. 后台Activity：已经被暂停的Activity
2. 系统配置发生改变时不重建Activity的方法：
   1. android:configChange="orientation"

1.2 Activity的启动模式 / 16

1.2.1 Activity的LaunchMode / 16

四种启动模式

1. standard：标准模式
2. singtop：栈顶复用模式，位于栈顶时不会重复创建
3. singleTask：栈内复用模式，实例以上Activity全部出栈，把实例调到栈顶。
4. singleInstance：单实例模式，创建实例时会创建新的任务栈

TaskAffinity 任务相关性

1. taskAffinity：标识一个Activity所需要的任务栈的名字
2. 默认Activity的栈名为包名
3. 主要和singTask或allowTaskReparenting属性配对使用
   1. taskAffinity+singleTask，待启动的Activity会运行在名字和TaskAffinity相同的任务栈中
   2. taskAffinity+allowTaskReparenting，应用A启动应用B的某个Activity后，此Activity的allowTaskReparenting为true时，此Activity会直接从应用A的任务栈转移到B的任务栈中。

1.2.2 Activity的Flags / 27

Flags影响启动模式、运行状态等

1. FLAG_ACTIVITY_NEW_TASK
2. FLAG_ACTIVITY_SINGLE_TOP
3. FLAG_ACTIVITY_CLEAR_TOP
4. FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS

1.3 IntentFilter的匹配规则 / 28

Activity的隐式调用需要Intent能够匹配目标组件的IntentFilter中的过滤信息，如果不匹配将无法启动目标Activity。

匹配规则：

1. 一个intent-filter中可以有多个cation、category、data
2. 一个Intent同时匹配action、category、data 才算完全匹配，只有完全匹配才能成功启动目标Activity。

3. 一个Activity 中可以有多个intent-filter，只要能匹配任何一组intent-filter即可成功启动对应的Activity。

• action的匹配规则
  • 要求Intent中的action存在，且必须和过滤规则中的其中一个action相同。
• category的匹配规则
  • 要求Intent 中如果含有category,那么所有的category都必须和过滤规则中的其中一个category相同。
• data的匹配规则
  • 如果过滤规则中定义了data, 那么Intent 中必须也要定义可匹配的data。
  • data由两部分组成，mineType和URI。
    • mimeType指媒体类型，比如image/jpeg、audio/mpeg4-generic和video/*等，可以表示图片、文本、视频等不同的媒体格式。
    • URI包含的数据就比较多了，URI结构：scheme://host:port/path|pathPrefix|pathPattern
    • Scheme、Host、Port、Path等
• 隐式启动一个Activity时，可能出现错误，判断是否有Activity符合匹配规则：
  • PackageManager.resolveActivity或Intent.resolveActivity，返回最佳匹配的Activity信息
  • queryIntentActivities，返回所有成功的Activity信息

1.1 Android系统架构

1.2 Android系统源码目录

1.2.1 整体结构

1.2.2 应用层部分

1.2.3 应用框架层部分

1.2.4 C/C++程序库部分

1.3 源码阅读

1.3.1 在线阅读

1.3.2 使用Source Insight

1.4 本章小结

• 为什么 Java 要在虚拟机里运行？
• Java 虚拟机具体是怎样运行 Java 字节码的？
• Java 虚拟机的运行效率究竟是怎么样的？

为什么 Java 要在虚拟机里运行？

1. Java是一种高级语言，不能直接运行在硬件，需要转换
2. 设计一个面向Java语言的虚拟机，通过编译器将 Java 程序转换成该虚拟机所能识别的指令序列。
3. 在现有平台(Windows Linux)上实现Java虚拟机，Java程序便可以在不同平台上的虚拟机实现里运行。

Java 虚拟机具体是怎样运行 Java 字节码的？

• 从虚拟机视角来看
  1. 执行 Java 代码首先需要将它编译而成的 class 文件加载到 Java 虚拟机中。加载后的 Java 类会被存放于方法区（Method Area）中。实际运行时，虚拟机会执行方法区内的代码。
  2. 在运行过程中，每当调用进入一个 Java 方法，Java 虚拟机会在当前线程的 Java 方法栈中生成一个栈帧，用以存放局部变量以及字节码的操作数。这个栈帧的大小是提前计算好的，而且 Java 虚拟机不要求栈帧在内存空间里连续分布。
  3. 当退出当前执行的方法时，不管是正常返回还是异常返回，Java 虚拟机均会弹出当前线程的当前栈帧，并将之舍弃。
• 从硬件视角来看，Java 字节码无法直接执行。因此，Java 虚拟机需要将字节码翻译成机器码。
  1. 第一种是解释执行，即逐条将字节码翻译成机器码并执行；
  2. 第二种是即时编译（Just-In-Time compilation，JIT），即将一个方法中包含的所有字节码编译成机器码后再执行。

Java 虚拟机的运行效率究竟是怎么样的？

1. 即时编译建立在程序符合二八定律的假设上，也就是百分之二十的代码占据了百分之八十的计算资源。
2. 即时编译，对于占据大部分的不常用的代码，我们无需耗费时间将其编译成机器码，而是采取解释执行的方式运行；
3. 另一方面，对于仅占据小部分的热点代码，我们则可以将其编译成机器码，以达到理想的运行速度。

为了满足不同用户场景的需要，HotSpot 内置了多个即时编译器：

1. C1 又叫做 Client 编译器，面向的是对启动性能有要求的客户端 GUI 程序，采用的优化手段相对简单，因此编译时间较短。
2. C2 又叫做 Server 编译器，面向的是对峰值性能有要求的服务器端程序，采用的优化手段相对复杂，因此编译时间较长，但同时生成代码的执行效率较高。
3. Graal 是 Java 10 正式引入的实验性即时编译器。

从 Java 7 开始，HotSpot 默认采用分层编译的方式：热点方法首先会被 C1 编译，而后热点方法中的热点会进一步被 C2 编译。

总结与实践

今天我简单介绍了 Java 代码为何在虚拟机中运行，以及如何在虚拟机中运行。

之所以要在虚拟机中运行，是因为它提供了可移植性。一旦 Java 代码被编译为 Java 字节码，便可以在不同平台上的 Java 虚拟机实现上运行。此外，虚拟机还提供了一个代码托管的环境，代替我们处理部分冗长而且容易出错的事务，例如内存管理。

Java 虚拟机将运行时内存区域划分为五个部分，分别为方法区、堆、PC 寄存器、Java 方法栈和本地方法栈。Java 程序编译而成的 class 文件，需要先加载至方法区中，方能在 Java 虚拟机中运行。

为了提高运行效率，标准 JDK 中的 HotSpot 虚拟机采用的是一种混合执行的策略。它会解释执行 Java 字节码，然后会将其中反复执行的热点代码，以方法为单位进行即时编译，翻译成机器码后直接运行在底层硬件之上。

HotSpot 装载了多个不同的即时编译器，以便在编译时间和生成代码的执行效率之间做取舍。

• 并发程序幕后的故事
• 源头之一：缓存导致的可见性问题
• 源头之二：线程切换带来的原子性问题
• 源头之三：编译优化带来的有序性问题

并发程序幕后的故事

CPU、内存、I/O 设备都在不断迭代，但有一个核心矛盾一直存在，就是这三者的速度差异。

为了合理利用 CPU 的高性能，平衡这三者的速度差异，计算机体系结构、操作系统、编译程序都做出了贡献，主要体现为：

1. CPU 增加了缓存，以均衡与内存的速度差异；
2. 操作系统增加了进程、线程，以分时复用 CPU，进而均衡 CPU 与 I/O 设备的速度差异；
3. 编译程序优化指令执行次序，使得缓存能够得到更加合理地利用。

现在我们几乎所有的程序都默默地享受着这些成果，但是天下没有免费的午餐，并发程序很多诡异问题的根源也在这里。

源头之一：缓存导致的可见性问题

在单核时代，所有的线程都是在一颗 CPU 上执行，CPU 缓存与内存的数据一致性容易解决。因为所有线程都是操作同一个 CPU 的缓存，一个线程对缓存的写，对另外一个线程来说一定是可见的。

一个线程对共享变量的修改，另外一个线程能够立刻看到，我们称为可见性。

多核时代，每颗 CPU 都有自己的缓存，这时 CPU 缓存与内存的数据一致性就没那么容易解决了，当多个线程在不同的 CPU 上执行时，这些线程操作的是不同的 CPU 缓存。

源头之二：线程切换带来的原子性问题

由于 IO 太慢，早期的操作系统就发明了多进程，即便在单核的 CPU 上我们也可以一边听着歌，一边写 Bug，这个就是多进程的功劳。

高级语言里一条语句往往需要多条 CPU 指令完成，例如count += 1，至少需要三条 CPU 指令：

• 指令 1：首先，需要把变量 count 从内存加载到 CPU 的寄存器；
• 指令 2：之后，在寄存器中执行 +1 操作；
• 指令 3：最后，将结果写入内存（缓存机制导致可能写入的是 CPU 缓存而不是内存）。

操作系统做任务切换，可以发生在任何一条 CPU 指令执行完。

我们把一个或者多个操作在 CPU 执行的过程中不被中断的特性称为原子性。CPU 能保证的原子操作是 CPU 指令级别的，而不是高级语言的操作符。因此，很多时候我们需要在高级语言层面保证操作的原子性。

源头之三：编译优化带来的有序性问题

编译器为了优化性能，有时候会改变程序中语句的先后顺序，例如程序中：“a=6；b=7；”编译器优化后可能变成“b=7；a=6；”

在 Java 领域一个经典的案例就是利用双重检查创建单例对象，例如下面的代码：

public class Singleton {
  static Singleton instance;
  static Singleton getInstance(){
    if (instance == null) {
      synchronized(Singleton.class) {
        if (instance == null)
          instance = new Singleton();
        }
    }
    return instance;
  }
}

这看上去一切都很完美，无懈可击，但实际上这个 getInstance() 方法并不完美。问题出在哪里呢？出在 new 操作上，我们以为的 new 操作应该是：

1. 分配一块内存 M；
2. 在内存 M 上初始化 Singleton 对象；
3. 然后 M 的地址赋值给 instance 变量。

但是实际上优化后的执行路径却是这样的：

1. 分配一块内存 M；
2. 将 M 的地址赋值给 instance 变量；
3. 最后在内存 M 上初始化 Singleton 对象。

优化后会导致什么问题呢？我们假设线程 A 先执行 getInstance() 方法，当执行完指令 2 时恰好发生了线程切换，切换到了线程 B 上；如果此时线程 B 也执行 getInstance() 方法，那么线程 B 在执行第一个判断时会发现 instance != null ，所以直接返回 instance，而此时的 instance 是没有初始化过的，如果我们这个时候访问 instance 的成员变量就可能触发空指针异常。

总结

只要我们能够深刻理解可见性、原子性、有序性在并发场景下的原理，很多并发 Bug 都是可以理解、可以诊断的。

在介绍可见性、原子性、有序性的时候，特意提到缓存导致的可见性问题，线程切换带来的原子性问题，编译优化带来的有序性问题，其实缓存、线程、编译优化的目的和我们写并发程序的目的是相同的，都是提高程序性能。但是技术在解决一个问题的同时，必然会带来另外一个问题，所以在采用一项技术的同时，一定要清楚它带来的问题是什么，以及如何规避。

课后思考

常听人说，在 32 位的机器上对 long 型变量进行加减操作存在并发隐患，到底是不是这样呢？

答：long类型64位，所以在32位的机器上，对long类型的数据操作通常需要多条指令组合出来，无法保证原子性，所以并发的时候会出问题。

SOLID

开闭原则是目标，里氏代换原则是基础，依赖倒转原则是
手段。

23种设计模式

Java程序设计平台

Java“白皮书”的关键术语

Java applet与Internet

Java发展简史

关于Java的常见误解

2.1 init进程启动过程

2.1.1 引入init进程

Android系统启动流程的前几步：

1. 启动电源以及系统启动
2. 引导程序Bootloader
3. linux内核启动
4. init进程启动

2.1.2 init进程的入口函数

2.1.3 解析init.rc

2.1.4 解析Service类型语句

2.1.5 init启动Zygote

2.1.6 属性服务

2.1.7 init进程启动总结

init进程主要做了三件事：

1. 创建一些文件夹并挂载设备
2. 初始化和启动属性服务
3. 解析init.rc配置文件并启动zygote进程

2.2 Zygote进程启动过程

2.2.1 Zygote概述

在Android系统中，DVM(Dalvik虚拟机)、应用程序进程以及运行系统的关键服务的SystemServer进程都是由Zygote进程来创建的，我们也将它称为孵化器。它通过fock(复制进程)的形式来创建应用程序进程和SystemServer进程，由于Zygote进程在启动时会创建DVM，因此通过fock而创建的应用程序进程和SystemServer进程可以在内部获取一个DVM的实例拷贝。

2.2.2 Zygote启动脚本

2.2.3 Zygote进程启动过程介绍

2.2.4 Zygote进程启动总结

Zygote进程共做了如下几件事：

1. 创建AppRuntime并调用其start方法，启动Zygote进程。
2. 创建JVM并为JVM注册JNI方法。
3. 通过JNI调用ZygoteInit的main函数进入Zygote的Java框架层。
4. 通过registerZygoteSocket函数创建服务端Socket，并通过runSelectLoop函数等待ActivityManagerService的请求来创建新的应用程序进程。
5. 启动SystemServer进程。

2.3 SystemServer处理过程

2.3.1 Zygote处理SystemServer进程

2.3.2 解析SystemServer进程

2.3.3 SystemServer进程总结

SystemServer进程被创建后，主要做了如下工作:

1. 启动Binder线程池，这样就可以与其他进程进行通信。
2. 创建SystemServiceManager,其用于对系统的服务进行创建、启动和生命周期管理。
3. 启动各种系统服务。

2.4 Launcher启动过程

2.4.1 Launcher概述

系统启动的最后一步是启动一个应用程序用来显示系统中已经安装的应用程序，这个应用程序就叫作Launcher。Launcher在启动过程中会请求PackageManagerService返回系统中已经安装的应用程序的信息，并将这些信息封装成一一个快捷图标列表显示在系统屏幕上，这样用户可以通过点击这些快捷图标来启动相应的应用程序。
通俗来讲Launcher就是Android系统的桌面，它的作用主要有以下两点:

1. 作为Android系统的启动器，用于启动应用程序。
2. 作为Android系统的桌面，用于显示和管理应用程序的快捷图标或者其他桌面组件。

2.4.2 Launcher启动过程介绍

2.4.3 Launcher中应用图标显示过程

2.5 Android系统启动流程

1. 启动电源以及系统启动
   当电源按下时引导芯片代码开始从预定义的地方（固化在ROM）开始执行。加载引导程序Bootloader到RAM，然后执行。
2. 引导程序BootLoader
   引导程序BootLoader是在Android操作系统开始运行前的一个小程序，它的主要作用是把系统OS拉起来并运行。
3. Linux内核启动
   内核启动时，设置缓存、被保护存储器、计划列表、加载驱动。当内核完成系统设置，它首先在系统文件中寻找init.rc文件，并启动init进程。
4. init进程启动
   初始化和启动属性服务，并且启动Zygote进程。
5. Zygote进程启动
   创建JavaVM并为JavaVM注册JNI，创建服务端Socket，启动SystemServer进程。
6. SystemServer进程启动
   启动Binder线程池和SystemServiceManager，并且启动各种系统服务。
7. Launcher启动

2.6 本章小结

2.1 Android IPC简介

1. IPC Inter-Process Communication，含义为进程间通信或者跨进程通信，是指两个进程之间进行数据交换的过程。
   • 进程：一个执行单元，PC和移动设备上指一个程序或应用
   • 线程：CPU调度的最小单元，一种有限的系统资源
2. 为什么需要多进程？
   1. 一个应用因为某些原因需要采用多进程模式来实现。比如某些模块运行在单独进程中，或者为了更多的内存空间
   2. 向其他应用获取数据

2.2 Android中的多进程模式

2.2.1 开启多进程模式

指定android:process属性开启多进程模式：

• ":"：当前应用的私有进程，其他应用的组件不可以和它跑在一个进程中；
• "."：全局进程，其他应用通过ShareUID方式可以和他跑在同一个进程中。

Android系统会为每个应用分配一个唯一的UID，具有相同UID的应用才能共享数据。两个应用通过ShareUID跑在同一个进程，需要这两个应用有相同的ShareUID并且签名相同才可以。在这种情况下，它们可以互相访问对方的私有数据，比如data目录，组件信息等，不管他们是否跑在同一个进程中。如果在同一个进程中，还可以共享内存数据。

2.2.2 多进程模式的运行机制

Android为每一个应用分配了独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间。

使用多进程会导致的问题：

1. 静态成员和单例模式完全失效
2. 线程同步机制完全失效
3. SharedPreferences的可靠性下降
4. Application会创建多次

2.3 IPC基础概念介绍

序列化：将对象的状态信息转换为可以存储或传输的形式的过程。

2.3.1 Serializable接口

• serialVersionUID：
  • 辅助序列化和反序列化
  • serialVersionUID相同才能反序列化成功
• 两种变量不参与序列化：
  • 静态成员属于类，不属于对象
  • transient关键字标记的成员变量
• 使用ObjectOutputStream和ObjectInputStream进行对象的序列化和反序列化。
• 重写writeObject()和readObject()方法可以重写序列化和反序列化过程。
• 反序列化失败的几种情况：未指定serialVersionUID；成员变量的数量、类型结构等变化时；非常规性改版：类名变化。

2.3.2 Parcelable接口

Parcelable主页方法：

• writeToParcel：序列化
• CREATOR：read方法，反序列化
• describeContents：内容描述

Serializable和Parcelable：

• 两者都可以实现序列化并可用于intent间的数据传递
• Serializable使用简单，但是开销很大，推荐使用在存储设备或者网络传输；
• Parcelable效率很高，主要用在内存序列化上。

2.3.3 Binder

Binder的理解：

• 直观来说，Binder 是Android中的一个类，它实现了IBinder接口。
• 从IPC角度来说，Binder是Android中的一种跨进程通信方式：
  • 从Android Framework角度来说，Binder是ServiceManager连接各种Manager (ActivityManager、WindowManager， 等等)和相应ManagerService的桥梁;
  • 从Android应用层来说，Binder 是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的Binder 对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据，这里的服务包括普通服务和基于AIDL的服务。

Android开发中， Binder主要用在Service中，包括AIDL和Messenger。其中普通的Service的Binder不涉及进程间通讯；而Messenger的底层其实就是AIDL。

1. 新建一个AIDL示例，SDK会自动为我们生产AIDL所对应的Binder类。创建Book.java、Book.aidl、IBookManager.aidl，Build后生成IBookManager.java。

• Book.java

  public class Book implements Parcelable {
      public int bookId;
  
      public String bookName;
  
      //...
  
  }
  

• Book.aidl

  package com.wz.testaidl;
  import com.wz.testaidl.Book;
  
  parcelable Book ;
  

• IBookManager.aidl

  package com.wz.testaidl;
  import com.wz.testaidl.Book;
  
  interface IBookManager{
  
      List<Book> getBookList();
  
      void addBook(in Book book);
  
  }
  

AIDL自动生成的java文件方法说明：

• DESCRIPTOR：Binder的唯一标识，一般用当前Binder的类名表示。
• asInterface：将服务端的Binder对象转换成客户端所需要的AIDL接口类型的对象；
  • 客户端和服务端位于相同进程，那么此方法返回的就是服务端Stub对象本身；
  • 否则返回系统封装后的Stub.proxy对象。
• asBinder：用于返回当前的Binder对象
• onTransact：运行在服务端的Binder线程池中，当客户端发起跨进程通讯时，远程请求会通过系统底层封装交由此方法处理。
• Proxy#[Method]：代理类中的接口方法。内部实现：
  1. 首先创建该方法所需要的输入型参数Parcel对象_data和输出型参数Parcel对象_reply；
  2. 然后把参数写入_data中（如果有参数的话）；
  3. 接着调用transact方法来发起RPC（远程过程调用）请求，同时当前线程挂起；
  4. 然后服务端的onTransace方法会被调用直到RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果；
  5. 最后返回_reply中的数据。

首先，当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以如果一个远程方法是很耗时的，那么不能在UI线程中发起此远程请求；其它，由于服务端的Binder方法运行在Binder的线程池中，所以Binder方法不管是否耗时都应该采用同步的方式去实现，因为它已经运行在一个线程中了。

Binder死亡通知
Binder的两个重要方法linkToDeath和unlinkToDeath。

• 通过linkToDeath可以给Binder设置一个死亡代理，当Binder死亡时，我们就会收到通知，然后就可以重新发起连接请求。

• 声明一个DeathRecipient对象，DeathRecipient是一个接口，其内部只有一个方法binderDied，实现这个方法后就可以在Binder死亡的时候收到通知了。

  private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient(){
      @override
  
      public void binderDied(){
  
          if(mBookManager==null){
  
              return;
  
          }
  
          mBookManager.asBinder().unlinkToDeath(mDeathRecipient，0);
  
          mBookManager=null;
  
          //TODO:重新绑定远程Service
  
      }
  
  }
  

• 在客户端绑定远程服务成功后，给binder设置死亡代理:

  mService = IMessageBoxManager.Stub.asInterface(binder);
  binder.linkToDeath(mDeathRecipient，0);
  

• 另外，通过Binder的isBinderAlive方法，也可以判断Binder是否死亡。

• binderDied和onServiceDisconnected区别：

  • binderDied在客户端的Binder线程池中被回调
  • onServiceDisconnected在UI线程中被回调

2.4 Android中的IPC方式

2.4.1 使用Bundle

我们知道，四大组件中的三大组件( Activity、Service、 Receiver) 都是支持在Intent中传递Bundle数据的，由于Bundle实现了Parcelable 接口，所以它可以方便地在不同的进程间传输。基于这一点，当我们在一个进程中启动了另一个进程的Activity、 Service 和Receiver，我们就可以在Bundle 中附加我们需要传输给远程进程的信息并通过Intent 发送出去。当然，我们传输的数据必须能够被序列化，比如基本类型、实现了Parcellable 接口的对象、实现了Serializable 接口的对象以及一些Android支持的特殊对象，具体内容可以看Bundle这个类，就可以看到所有它支持的类型。Bundle不支持的类型我们无法通过它在进程间传递数据。

除了直接传递数据这种典型的使用场景，它还有一种特殊的使用场景。比如A进程正在进行一个计算，计算完成后它要启动B进程的一个组件并把计算结果传递给B进程，可是遗憾的是这个计算结果不支持放入Bundle中，因此无法通过Intent来传输，这个时候如果我们用其他IPC方式就会略显复杂。可以考虑如下方式：我们通过Intent启动进程B的一个Service组件(比如IntentService)， 让Service在后台进行计算，计算完毕后再启动B进程中真正要启动的目标组件，由于Service也运行在B进程中，所以目标组件就可以直接获取计算结果，这样一来就轻松解决了跨进程的问题。这种方式的核心思想在于将原本需要在A进程的计算任务转移到B进程的后台Service中去执行，这样就成功地避免了进程间通信问题，而且只用了很小的代价。

2.4.2 使用文件共享

通过文件共享这种方式来共享数据对文件格式是没有具体要求的，比如可以是文本文件，也可以是XML文件，只要读/写双方约定数据格式即可。通过文件共享的方式也是有局限性的，比如并发读/写的问题，如果并发读/写，那么我们读出的内容就有可能不是最新的，如果是并发写的话那就更严重了。因此我们要尽量避免并发写这种情况的发生或者考虑使用线程同步来限制多个线程的写操作。文件共享方式适合在对数据同步要求不高的进程之间进行通信，并且要妥善处理并发读/写的问题。

当然，SharedPreferences 是个特例，SharedPreferences 是Android中提供的轻量级存储方案，它通过键值对的方式来存储数据，在底层实现上它采用XML文件来存储键值对，每个应用的SharedPreferences文件都可以在当前包所在的data目录下查看到。一般来说， 它的目录位于/data/data/package name/shared_ prefs 目录下，其中package name表示的是当前应用的包名。从本质上来说，SharedPreferences 也属于文件的一种，但是由于系统对它的读/写有一定的缓存策略，即在内存中会有一份SharedPreferences文件的缓存，因此在多进程模式下，系统对它的读/写就变得不可靠，当面对高并发的读/写访问，Sharedpreferences有很大几率会丢失数据，因此，不建议在进程间通信中使用SharedPreferences。

2.4.3 使用Messenger

1. 构建服务端Service，运行在独立进程中：

   public class MessengerService extends Service {
       private static final String TAG = "MessengerService";
   
       @Override
   
       public IBinder onBind(Intent intent) {
   
           return mMessenger.getBinder();
   
       }
   
       private final Messenger mMessenger = new Messenger(new MessengerHandler());
   
       private static class MessengerHandler extends Handler {
   
           @Override
   
           public void handleMessage(@NonNull Message msg) {
   
               Log.e(TAG， "server receive msg: " + msg.what);
   
               final Messenger replyTo = msg.replyTo;
   
               final Message replyMsg = Message.obtain();
   
               replyMsg.what = 999;
   
               try {
   
                   replyTo.send(replyMsg);
   
               } catch (RemoteException e) {
   
                   e.printStackTrace();
   
               }
   
           }
   
       }
   
   }
   

   // AndroidManifext.xml
   <service android:name=".MessengerService"
   
       android:process=":remote"/>
   

2. 客户端：

   1. 通过绑定服务端返回的binder创建Messenger对象，并通过这个Messenger对象向服务端发送消息。
   2. 服务端给客户端回复消息：使用Message的replyTo参数。

   public class MainActivity extends AppCompatActivity {
       private static final String TAG = "MainActivity";
   
       @Override
   
       protected void onCreate(Bundle savedInstanceState) {
   
           super.onCreate(savedInstanceState);
   
           setContentView(R.layout.activity_main);
   
           final Intent intent = new Intent(this， MessengerService.class);
   
           bindService(intent， serviceConnection， Context.BIND_AUTO_CREATE);
   
       }
   
       private ServiceConnection serviceConnection = new ServiceConnection() {
   
           @Override
   
           public void onServiceConnected(ComponentName componentName， IBinder iBinder) {
   
               Log.e(TAG， "onServiceConnected: ");
   
               Messenger mServerMessenger = new Messenger(iBinder);
   
               final Message msg = Message.obtain();
   
               msg.what = 666;
   
               //赋值replyTo，服务端才可以回复消息
   
               msg.replyTo = mClientMessenger;
   
               try {
   
                   mServerMessenger.send(msg);
   
               } catch (RemoteException e) {
   
                   e.printStackTrace();
   
               }
   
           }
   
           @Override
   
           public void onServiceDisconnected(ComponentName componentName) {
   
           }
   
       };
   
       private Messenger mClientMessenger = new Messenger(new MessengerHandler());
   
       private static class MessengerHandler extends Handler {
   
           @Override
   
           public void handleMessage(@NonNull Message msg) {
   
               Log.e(TAG， "client receive msg: " + msg.what);
   
           }
   
       }
   
       @Override
   
       protected void onDestroy() {
   
           unbindService(serviceConnection);
   
           super.onDestroy();
   
       }
   
   }
   

   流程图如下：
   

总结：

• Messenger 是以串行的方式处理客户端发来的消息，如果大量的消息同时发送到服务端，服务端仍然只能一个个处理，如果有大量的并发请求，那么用Messenger就不太合适了。
• Messenger的作用主要是为了传递消息，很多时候我们可能需要跨进程调用服务端的方法，这种情形用Messenger就无法做到了，但是我们可以使用AIDL来实现跨进程的方法调用。

2.4.4 使用AIDL

使用AIDL来进行进程间通信的流程，分为服务端和客户端两个方面。

1. 服务端：

   1. 创建一个AIDL文件，将暴露给客户端的接口在这个AIDL文件中声明(见2.3.3)
   2. 创建一个Service用来监听客户端的连接请求，在Service中实现AIDL接口。

   public class BookMangerService extends Service {
       private CopyOnWriteArrayList<Book> mBookList = new CopyOnWriteArrayList<>();
   
       @Override
   
       public IBinder onBind(Intent intent) {
   
           return mBinder;
   
       }
   
       private IBinder mBinder = new IBookManager.Stub(){
   
           @Override
   
           public List<Book> getBookList() {
   
               return mBookList;
   
           }
   
           @Override
   
           public void addBook(Book book) {
   
               mBookList.add(book);
   
           }
   
       };
   
   }
   

   <service android:name=".BookMangerService"
       android:process=":remote"/>
   

2. 客户端

   1. 首先需要绑定服务端的Service
   2. 绑定成功后，将服务端返回的Binder对象转成AIDL接口所属的类型，接着就可以调用AIDL中的方法了。

   public class MainActivity extends AppCompatActivity {
       private static final String TAG = "MainActivity";
   
       @Override
   
       protected void onCreate(Bundle savedInstanceState) {
   
           super.onCreate(savedInstanceState);
   
           setContentView(R.layout.activity_main);
   
           final Intent intent = new Intent(this， BookMangerService.class);
   
           bindService(intent， serviceConnection， Context.BIND_AUTO_CREATE);
   
       }
   
       private ServiceConnection serviceConnection = new ServiceConnection() {
   
           @Override
   
           public void onServiceConnected(ComponentName componentName， IBinder iBinder) {
   
               final IBookManager bookManager = IBookManager.Stub.asInterface(iBinder);
   
               try {
   
                   Log.e(TAG， "bookList.size()： " + bookManager.getBookList().size());
   
                   bookManager.addBook(new Book());
   
                   bookManager.addBook(new Book());
   
                   Log.e(TAG， "bookList.size()： " + bookManager.getBookList().size());
   
               } catch (RemoteException e) {
   
                   e.printStackTrace();
   
               }
   
           }
   
           @Override
   
           public void onServiceDisconnected(ComponentName componentName) {
   
           }
   
       };
   
       @Override
   
       protected void onDestroy() {
   
           unbindService(serviceConnection);
   
           super.onDestroy();
   
       }
   
   }
   

RemoteCallbackList

在解注册的过程中，服务端无法找到之前注册的那个listener，因为Binder会把客户端传递过来的对象重新转化并生成一个新的对象。

RemoteCallbackList是系统专门提供的用于删除跨进程listener的接口。Remote一CallbackList是一个泛型，支持管理任意的AIDL接口。内部有一个Map结构专门用来保存所有的AIDL回调，这个Map的key是IBinder类型，value 是Callback类型，如下所示。

public class RemoteCallbackList<E extends IInterface>{
    ArrayMap<IBinder， Callback> mCallbacks = new ArrayMap<IBinder， Callback>() ;
}

其中Callback中封装了真正的远程listener。 当客户端注册listener 的时候，它会把这个listener的信息存入mCallbacks中，其中key和value分别通过下面的方式获得：

IBinder key = listener.asBinder();
Callback value = new Callback(listener，cookie);

当客户端解注册的时候，只要遍历服务端所有的listener，找出那个和解注册listener具有相同Binder对象的服务端listener并把它删除就可以了。当客户端进程终止后，RemoteCallbackList能够自动移除客户端所注册的listener。RemoteCallbackList内部自动实现了线程同步的功能，所以使用它来注册和解注册时，不需要做额外的线程同步工作。

使用RemoteCallbackList，有一点需要注意。我们无法像操作List一样去操作它，尽管它的名字中也带个List，但是它并不是一个List。遍历RemoteCallbackList，必须要按照下面的方式进行，其中beginBroadcast和finishBroadcast必须配对使用，哪怕我们仅仅是想要获取RemoteCallbackList的元素个数。

final int N = mListenerList.beginBroadcast();
for(int i=0;i<N;i++){   
    IOnNewBookArrivedListener l = mListenerList.getBroadcastItem(i);
    if(l!=null){
        //TODO
    }
}
mListenerList.finishBroadcast();

如何在AIDL中使用权限验证功能？

1. 第一种方法：可以在onBind中进行验证，验证不通过就直接返回null。然后在AndroidMenifest中声明所需的权限。

   public IBinder onBind(Intent intent){
       int check = checkCallingOrSelfPermission("xx.xx.xx");
   
       if(check==PackageManager.PERMISSION_DENIED){
   
           return null;
   
       }
   
       return mBinder;
   
   }
   

   <uses-permission android:name="xx.xx.xx"/>
   

2. 第二种方法：可以在服务端的onTransact中进行权限验证，如果验证失败，就直接返回false，这样服务端就不会终止执行AIDL中的方法从而达到保护服务端的效果。可以验证permission，也可以验证Uid和Pid。

   public boolean onTransact(int code,Parcel data,Parcel reply,int flags) throws RemoteException{
       int check = checkCallingOrSelfPermission("xx.xx.xx");
   
       if(check==PackageManager.PERMISSION_DENIED){
   
           return false;
   
       }
   
       String packageName = null;
   
       String[] packages = getPackageManager().getPackgesForUid(getCallingUid());
   
       if(packages!=null&&packages.length>0){
   
           packageName = packages[0];
   
       }
   
       if(!packageName.startWith("xx.xx")){
   
           return false;
   
       }
   
       return super.onTransact(code,data,reply,flags);
   
   }
   

3. 还可以为Service指定android:permission属性等。

2.4.5 使用ContentProvider

2.4.6 使用Socket

2.5 Binder连接池

随着AIDL数量的增加，我们不能无限制地增加Service，Service 是四大组件之一一，本身就是一种系统资源。针对上述问题，我们需要减少Service的数量，将所有的AIDL放在同一个Service中去管理。

每个业务模块创建自己的AIDL接口并实现此接口，这个时候不同业务模块之间是不能有耦合的，所有实现细节我们要单独开来，然后向服务端提供自己的唯一标识和其对应的 Binder 对象；对于服务端来说，只需要一个 Service就可以了，服务端提供一个queryBinder 接口，这个接口能够根据业务模块的特征来返回相应的Binder对象给它们，不同的业务模块拿到所需的Binder对象后就可以进行远程方法调用了。由此可见，Binder连接池的主要作用就是将每个业务模块的Binder请求统一转发到远程Service中去执行，从而避免了重复创建Service的过程。

2.6 选用合适的IPC方式

2.1 概述

本章主要介绍Java虚拟机内存的各个区域，及其作用、服务对象以及可能产生的问题。

2.2 运行时数据区域

2.2.1 程序计数器

程序计数器 （Program Counter Register）

• 线程私有，当前线程所执行的字节码的行号指示器。
• PC寄存器，保证程序能够连续地执行下去，可以确定下一条指令的地址。

2.2.2 Java虚拟机栈

Java虚拟机栈（Java Virtual Machine Stacks）

• 线程私有。
• 每个方法在执行的同时都会创建一个栈帧，栈帧存储局部变量表、操作数栈、动态链接、方法出口等信息。调用Java方法时栈帧入栈，方法执行完成栈帧出栈。
  • 栈内存就是虚拟机栈。
  • 局部变量表存放编译期可知的基本数据类型、引用类型和returnAddress类型。
• 栈容量超出，StackOverflowError；内存不够，OOM。

2.2.3 本地方法栈

本地方法栈（Native Method Stack）

• Java虚拟机实现可能用到C Stacks支持Native语言。

2.2.4 Java堆

Java堆（Java Heap）

• 所有线程共享的内存区域。
• 存放对象实例。
• Java堆是垃圾收集器管理的主要区域，也被称为GC堆。
• 按分代收集算法，分为新生代和老年代。
• 堆中没有内存或无法扩展时，抛出OOM。

2.2.5 方法区

方法区（Method Area）

• 各个线程共享的内存区域。
• 存储被Java虚拟机加载的类信息、常量、静态变量、即时编译期编译后的代码等数据。

2.2.6 运行时常量池

运行时常量池（Runtime Constant Pool）

• 是方法区的一部分。
• 存放编译期生成的字面量和符号引用。

2.2.7 直接内存

直接内存（Direct Memory）

• 并不是虚拟机运行时数据区的一部分，会被频繁使用，导致OOM。
• JDK 1.4引入的NIO，可以使用Native函数库直接分配堆外内存。不受Java堆大小限制，容易被忽略，导致OOM。

2.3 HotSpot虚拟机对象探秘

对象如何创建、如何布局以及如何访问。

2.3.1 对象的创建

1. 检查类是否被加载、解析、初始化过。
2. 为新生对象分配内存
   1. Java堆内存绝对规整：指针碰撞。用过的内存在一边，空闲在另一边，中间用指针作为分界点指示器。分配空间就需要把指针移动与对象大小相等的距离。
   2. Java堆内存不规整：虚拟机维护一个表记录内存是否可用。分配空间时从列表中查询、分配，并更新列表。
3. 处理并发安全问题
   1. 对分配内存的动作进行同步处理，比如在虚拟机采用CAS算法并配上失败重试的方式，保证更新操作的原子性。
   2. 预先分配本地线程分配缓存（Thread Local Allocation Buffer，TLAB），在TLAB上分配内存。当TLAB用完并且被分配到新的TLAB时，才需要同步锁定。
4. 初始化分配到的内存空间
   1. 除了对象头外都初始化为零。
5. 设置对象的对象头
   1. 将对象的所属类、HashCode和GC分代年龄等存储在对象头中。
6. 执行init方法进行初始化
   1. 执行init方法，初始化对象的成员变量、调用类的构造方法，这样一个对象就被创建出来了。

2.3.2 对象的内存布局

• 对象头（Header）
  • Mark World：存储对象自身的运行时数据，比如HashCode、GC分代年龄、锁状态标志、线程持有的锁等。
  • 元数据指针：用于指向方法区中的目标类的元数据，通过元数据可以确定对象的具体类型。
• 实例数据（Instance Data）
  • 用于存储对象中的各个类型的字段信息（包括从父类继承来的）
• 对齐填充（Padding）
  • 不一定存在，起到了占位符的作用。

2.3.3 对象的访问定位

• 句柄访问
  • Java堆中划出内存作为句柄池，reference中存储对象的句柄地址。句柄中包含对象实例数据与类型数据各自的具体地址信息。
  • 好处：对象被移动时只改变句柄中的实例数据指针，reference不需要修改。
• 直接指针访问
  • Java堆对象的布局中放置访问类型数据的相关信息，reference中存储对象地址。
  • 好处：速度更快，节省指针定位的实际开销，HotSpot虚拟机中更常使用。

2.4 实战：OutOfMemoryError异常

2.4.1 Java堆溢出

2.4.2 虚拟机栈和本地方法栈溢出

2.4.3 方法区和运行时常量池溢出

2.4.4 本机直接内存溢出

2.5 本章 小结

• 什么是Java内存模型？
• 使用volatile的困惑
• Happen-Before规则
  1. 程序的顺序性规则
  2. volatile 变量规则
  3. 传递性
  4. 管程中锁的规则
  5. 线程 start() 规则
  6. 线程 join() 规则
• 被我们忽视的final
• 总结

什么是Java内存模型？

导致可见性的原因是缓存，导致有序性的原因是编译优化，那解决可见性、有序性最合理的方案应该是按需禁用缓存以及编译优化。

Java 内存模型规范了 JVM 如何提供按需禁用缓存和编译优化的方法。具体来说，这些方法包括 volatile、synchronized 和 final 三个关键字，以及六项 Happens-Before 规则。

使用volatile的困惑

volatile 关键字并不是 Java 语言的特产，古老的 C 语言里也有，它最原始的意义就是禁用 CPU 缓存。

Java 内存模型在 1.5 版本对 volatile 语义进行了增强。怎么增强的呢？答案是一项 Happens-Before 规则。

Happen-Before规则

如何理解 Happens-Before 呢？
前面一个操作的结果对后续操作是可见的。Happens-Before 约束了编译器的优化行为，虽允许编译器优化，但是要求编译器优化后一定遵守 Happens-Before 规则。

1. 程序的顺序性规则

在一个线程中，按照程序顺序，前面的操作 Happens-Before 于后续的任意操作。

2. volatile 变量规则

对一个 volatile 变量的写操作， Happens-Before 于后续对这个 volatile 变量的读操作。

3. 传递性

如果 A Happens-Before B，且 B Happens-Before C，那么 A Happens-Before C。

4. 管程中锁的规则

对一个锁的解锁 Happens-Before 于后续对这个锁的加锁。

“管程指的是什么”。管程是一种通用的同步原语，在 Java 中指的就是 synchronized，synchronized 是 Java 里对管程的实现。
管程中的锁在 Java 里是隐式实现的，在进入同步块之前，会自动加锁，而在代码块执行完会自动释放锁，加锁以及释放锁都是编译器帮我们实现的。

5. 线程 start() 规则

这条是关于线程启动的。它是指主线程 A 启动子线程 B 后，子线程 B 能够看到主线程在启动子线程 B 前的操作。

6. 线程 join() 规则

这条是关于线程等待的。它是指主线程 A 等待子线程 B 完成（主线程 A 通过调用子线程 B 的 join() 方法实现），当子线程 B 完成后（主线程 A 中 join() 方法返回），主线程能够看到子线程的操作。当然所谓的“看到”，指的是对共享变量的操作。

被我们忽视的final

有没有办法告诉编译器优化得更好一点呢？这个可以有，就是final关键字。final 修饰变量时，初衷是告诉编译器：这个变量生而不变，可以可劲儿优化。

总结

在 Java 语言里面，Happens-Before 的语义本质上是一种可见性，A Happens-Before B 意味着 A 事件对 B 事件来说是可见的，无论 A 事件和 B 事件是否发生在同一个线程里。例如 A 事件发生在线程 1 上，B 事件发生在线程 2 上，Happens-Before 规则保证线程 2 上也能看到 A 事件的发生。

课后思考

有一个共享变量 abc，在一个线程里设置了 abc 的值 abc=3，你思考一下，有哪些办法可以让其他线程能够看到abc==3？

答：

1. 声明共享变量abc，并使用volatile关键字修饰abc
2. 声明共享变量abc，在synchronized关键字对abc的赋值代码块加锁，由于Happen-before管程锁的规则，可以使得后续的线程可以看到abc的值。
3. A线程启动后，使用A.JOIN()方法来完成运行，后续线程再启动，则一定可以看到abc==3

• Java 虚拟机的 boolean 类型
• Java 的基本类型
• Java 基本类型的大小

Java 虚拟机的 boolean 类型

在 Java 虚拟机规范中，boolean 类型则被映射成 int 类型。具体来说，“true”被映射为整数 1，而“false”被映射为整数 0。

Java 的基本类型

除了上面提到的 boolean 类型外，Java 的基本类型还包括整数类型 byte、short、char、int 和 long，以及浮点类型 float 和 double。

Java 的基本类型都有对应的值域和默认值。可以看到，byte、short、int、long、float 以及 double 的值域依次扩大，而且前面的值域被后面的值域所包含。因此，从前面的基本类型转换至后面的基本类型，无需强制转换。另外一点值得注意的是，尽管他们的默认值看起来不一样，但在内存中都是 0。

Java 基本类型的大小

在第一篇中我曾经提到，Java 虚拟机每调用一个 Java 方法，便会创建一个栈帧。为了方便理解，这里我只讨论供解释器使用的解释栈帧（interpreted frame）。

这种栈帧有两个主要的组成部分，分别是局部变量区，以及字节码的操作数栈。这里的局部变量是广义的，除了普遍意义下的局部变量之外，它还包含实例方法的“this 指针”以及方法所接收的参数。

1.存储

在 Java 虚拟机规范中，局部变量区等价于一个数组，并且可以用正整数来索引。除了 long、double 值需要用两个数组单元来存储之外，其他基本类型以及引用类型的值均占用一个数组单元。

也就是说，boolean、byte、char、short 这四种类型，在栈上占用的空间和 int 是一样的，和引用类型也是一样的。因此，在 32 位的 HotSpot 中，这些类型在栈上将占用 4 个字节；而在 64 位的 HotSpot 中，他们将占 8 个字节。

当然，这种情况仅存在于局部变量，而并不会出现在存储于堆中的字段或者数组元素上。对于 byte、char 以及 short 这三种类型的字段或者数组单元，它们在堆上占用的空间分别为一字节、两字节，以及两字节，也就是说，跟这些类型的值域相吻合。

1.加载
讲完了存储，现在我来讲讲加载。Java 虚拟机的算数运算几乎全部依赖于操作数栈。也就是说，我们需要将堆中的 boolean、byte、char 以及 short 加载到操作数栈上，而后将栈上的值当成 int 类型来运算。

对于 boolean、char 这两个无符号类型来说，加载伴随着零扩展。举个例子，char 的大小为两个字节。在加载时 char 的值会被复制到 int 类型的低二字节，而高二字节则会用 0 来填充。

对于 byte、short 这两个类型来说，加载伴随着符号扩展。举个例子，short 的大小为两个字节。在加载时 short 的值同样会被复制到 int 类型的低二字节。如果该 short 值为非负数，即最高位为 0，那么该 int 类型的值的高二字节会用 0 来填充，否则用 1 来填充。

总结与实践

今天我介绍了 Java 里的基本类型。

其中，boolean 类型在 Java 虚拟机中被映射为整数类型：“true”被映射为 1，而“false”被映射为 0。Java 代码中的逻辑运算以及条件跳转，都是用整数相关的字节码来实现的。

除 boolean 类型之外，Java 还有另外 7 个基本类型。它们拥有不同的值域，但默认值在内存中均为 0。这些基本类型之中，浮点类型比较特殊。基于它的运算或比较，需要考虑 +0.0F、-0.0F 以及 NaN 的情况。

除 long 和 double 外，其他基本类型与引用类型在解释执行的方法栈帧中占用的大小是一致的，但它们在堆中占用的大小确不同。在将 boolean、byte、char 以及 short 的值存入字段或者数组单元时，Java 虚拟机会进行掩码操作。在读取时，Java 虚拟机则会将其扩展为 int 类型。

确保对象的唯一性——单例模式

单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。
注意：
1、单例类只能有一个实例。
2、单例类必须自己创建自己的唯一实例。
3、单例类必须给所有其他对象提供这一实例。

介绍

意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
主要解决：一个全局使用的类频繁地创建与销毁。
何时使用：当您想控制实例数目，节省系统资源的时候。
如何解决：判断系统是否已经有这个单例，如果有则返回，如果没有则创建。
关键代码：构造函数是私有的。

懒汉式，线程安全

优点：第一次调用才初始化，避免内存浪费。
缺点：必须加锁 synchronized 才能保证单例，但加锁会影响效率。

public class Singleton {  
    private static Singleton instance;  
    private Singleton (){}  
    public static synchronized Singleton getInstance() {  
    if (instance == null) {  
        instance = new Singleton();  
    }  
    return instance;  
    }  
}

饿汉式

优点：没有加锁，执行效率会提高。
缺点：类加载时就初始化，浪费内存。

public class Singleton {  
    private static Singleton instance = new Singleton();  
    private Singleton (){}  
    public static Singleton getInstance() {  
    return instance;  
    }  
}

双检锁/双重校验锁（DCL，即 double-checked locking）

描述：这种方式采用双锁机制，安全且在多线程情况下能保持高性能。
缺点：synchronized性能效率问题

public class Singleton {  
    private volatile static Singleton singleton;  
    private Singleton (){}  
    public static Singleton getSingleton() {  
    if (singleton == null) {  
        synchronized (Singleton.class) {  
        if (singleton == null) {  
            singleton = new Singleton();  
        }  
        }  
    }  
    return singleton;  
    }  
}

静态内部类

public class Singleton {  
    private static class SingletonHolder {  
    private static final Singleton INSTANCE = new Singleton();  
    }  
    private Singleton (){}  
    public static final Singleton getInstance() {  
    return SingletonHolder.INSTANCE;  
    }  
}

枚举

public enum Singleton {  
    INSTANCE;  
    public void whateverMethod() {  
    }  
}

什么是数据结构？什么是算法？

从广义上讲，数据结构就是指一组数据的存储结构。算法就是操作数据的一组方法。

从狭义上讲，是指某些著名的数据结构和算法，比如队列、栈、堆、二分查找、动态规划等。

我们要讲的这些经典数据结构和算法，都是前人从很多实际操作场景中抽象出来的，可以高效地帮助我们解决很多实际的开发问题。

那数据结构和算法有什么关系呢？

数据结构和算法是相辅相成的。数据结构是为算法服务的，算法要作用在特定的数据结构之上。
比如，因为数组具有随机访问的特点，常用的二分查找算法需要用数组来存储数据。但如果我们选择链表这种数据结构，二分查找算法就无法工作了，因为链表并不支持随机访问。

学习的重点在什么地方？

想要学习数据结构与算法，首先要掌握一个数据结构与算法中最重要的概念——复杂度分析。

数据结构和算法解决的是如何更省、更快地存储和处理数据的问题，因此，我们就需要一个考量效率和资源消耗的方法，这就是复杂度分析方法。

搞定复杂度分析，下面就要进入数据结构与算法的正文内容了。

其中包括20个最常用的、最基础数据结构与算法：

• 数据结构：数组、链表、栈、队列、散列表、二叉树、堆、跳表、图、Trie 树；
• 算法：递归、排序、二分查找、搜索、哈希算法、贪心算法、分治算法、回溯算法、动态规划、字符串匹配算法。

在学习数据结构和算法的过程中，要注意学习它的“来历”“自身的特点”“适合解决的问题”以及“实际的应用场景”。

多辩证地思考，多问为什么。

学习技巧

1. 边学边练，适度刷题
2. 多问、多思考、多互动
3. 给自己设立一个切实可行的目标
4. 知识需要沉淀，不要想试图一下子掌握所有

复杂对象的组装与创建——建造者模式

建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。

介绍

意图：将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
主要解决：主要解决在软件系统中，有时候面临着"一个复杂对象"的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。
何时使用：一些基本部件不会变，而其组合经常变化的时候。
如何解决：将变与不变分离开。
关键代码：建造者：创建和提供实例，导演：管理建造出来的实例的依赖关系。
应用实例： 1、去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的"套餐"。 2、JAVA 中的 StringBuilder。
优点： 1、建造者独立，易扩展。 2、便于控制细节风险。
缺点： 1、产品必须有共同点，范围有限制。 2、如内部变化复杂，会有很多的建造类。
使用场景： 1、需要生成的对象具有复杂的内部结构。 2、需要生成的对象内部属性本身相互依赖。
注意事项：与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。

3.1　View与ViewGroup

3.2　坐标系

3.2.1　Android坐标系

3.2.2　View坐标系

3.3　View的滑动

3.3.1　layout()方法

3.3.2　offsetLeftAndRight()与offsetTopAndBottom()

3.3.3　LayoutParams（改变布局参数）

3.3.4　动画

3.3.5　scrollTo与scollBy

3.3.6　Scroller

3.4　属性动画

3.5　解析Scroller

3.6　View的事件分发机制

3.6.1　源码解析Activity的构成

3.6.2　源码解析View的事件分发机制

3.7　View的工作流程

3.7.1　View的工作流程入口

3.7.2　理解MeasureSpec

3.7.3　View的measure流程

3.7.4　View的layout流程

3.7.5　View的draw流程

3.8　自定义View

3.8.1　继承系统控件的自定义View

3.8.2　继承View的自定义View

3.8.3　自定义组合控件

3.8.4　自定义ViewGroup

3.9　本章小结

3.1 View基础知识

3.1.1 什么是View

• View是Android中所有控件的基类，是界面层的控件的一种抽象
• ViewGroup，继承View，内部包含了许多控件
• 通过View和ViewGroup构成View树的结构，类似于Web中的Dom树

3.1.2 View的位置参数

• 坐标：X轴和Y轴，正方向为右和下
• View的属性：
  • x/y：View左上角的位置
  • top/left/right/bottom：上下左右
  • translationX/translationY：平移量

3.1.3 MotionEvent和TouchSlop

1.MotionEvent
手指接触屏幕后产生的事件。

ACTION_CANCEL：从当前控件转移到外层控件时会触发

获得点击事件发生时的X Y坐标：

• getX()/getY()：相对控件的位置
• getRawX()/getRawY()：相对整个屏幕的位置

2.TouchSlop

系统能识别的滑动最小距离，和设备相关。
获取方法：

ViewConfiguration.get(getContext()).getScaledTouchSlop()

3.1.4 VelocityTracker、GestureDetector和Scroller

1.VelocityTracker

速度追踪

使用：
首先在view的onTouchEvent方法中追踪当前单击事件的速度:

VelocityTracker velocityTracker = VelocityTracker.obtain();//实例化一个VelocityTracker 对象
velocityTracker.addMovement(event);//添加追踪事件

接着在ACTION_UP事件中获取当前的速度:

velocityTracker .computeCurrentVelocity(1000);//指定时间
float xVelocity = velocityTracker .getXVelocity();//水平方向
float yVelocity = velocityTracker .getYVelocity();//垂直方向

最后，当不需要使用它的时候，释放、回收：

/*清除释放*/
velocityTracker.clear();
velocityTracker.recycle()

速度 = (终点位置-起点位置)/时间

2.GestureDetector

手势检测，辅助检测用户单击、滑动、长按、双击等行为

使用：

创建一个GestureDetecor对象并实现OnGestureListener接口：

GestureDetector mGestureDetector = new GestureDetector(this);//实例化一个GestureDetector对象
mGestureDetector.setIsLongpressEnabled(false);// 解决长按屏幕后无法拖动的现象

然后，在待监听view的onTouchEvent方法中添加如下实现：

//目标view的onTouchEvent方法中修改返回值
boolean consume = mGestureDetector.onTouchEvent(event);
return consume;

建议：

监听滑动，使用onTouchEvent
监听双击，使用GestureDetector

3.Scroller

使用Scroller的实现滑动的步骤：

1. 初始化一个Scroller对象
2. 重写View.computeScroll()方法
3. 调用startScroll()开始滑动，invalidate()重绘

Scroller scroller = new Scroller(mContext); //实例化一个Scroller对象

@Override
public void computeScroll() {
    super.computeScroll();
    if(mScroller.computeScrollOffset()){
        ((View) getParent()).scrollTo(mScroller.getCurrX(),mScroller.getCurrY());
         //通过不断的重绘不断的调用computeScroll方法
         invalidate();
    }  
}

public void smoothScrollTo(int destX,int destY){
      int scrollX=getScrollX();
      int delta=destX-scrollX;
      //1000秒内滑向destX
      mScroller.startScroll(scrollX,0,delta,0,2000);
      invalidate();
  }

3.2 View的滑动

3.2.1 使用scrollTo/scrollBy

• scrollTo：基于所传参数的绝对滑动
• scrollBy：基于当前位置的相对滑动，调用的也是scrollTo方法。

3.2.2 使用动画

1.视图动画：

//translate.xml
<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android">
    <translate android:fromXDelta="0" android:toXDelta="300" android:duration="1000"/>
</set>

//Java代码
mCustomView.setAnimation(AnimationUtils.loadAnimation(this, R.anim.translate));

2.属性动画：

ObjectAnimator.ofFloat(mCustomView,"translationX",0,300).setDuration(1000).start();

3.2.3 改变布局参数

通过改变View的布局参数，实现View的滑动。

LinearLayout.LayoutParams layoutParams= (LinearLayout.LayoutParams) getLayoutParams();
layoutParams.leftMargin = getLeft() + offsetX;
layoutParams.topMargin = getTop() + offsetY;
setLayoutParams(layoutParams);

3.2.4 各种滑动方式的对比

针对上面的分析做一下总结,如下所示:

• scrollTo/scrollBy:操作简单,适合对 View 内容的滑动;
• 动画:操作简单,主要适用于没有交互的View 和实现复杂的动画效果;
• 改变布局参数:操作稍微复杂,适用于有交互的View。

3.3 弹性滑动

弹性滑动思想:将一次大的滑动分成若干次小的滑动
并在一个时间段內完成,弹性滑动的具体实现方式有很多,比如通过 Scroller、Handler#postDelayed以及Thread#sleep等。

3.3.1 使用Scroller

Scroller scroller = new Scroller(mContext); //实例化一个Scroller对象

@Override
public void computeScroll() {
    super.computeScroll();
    if(mScroller.computeScrollOffset()){
        ((View) getParent()).scrollTo(mScroller.getCurrX(),mScroller.getCurrY());
         //通过不断的重绘不断的调用computeScroll方法
         invalidate();
    }  
}

public void smoothScrollTo(int destX,int destY){
      int scrollX=getScrollX();
      int delta=destX-scrollX;
      //1000秒内滑向destX
      mScroller.startScroll(scrollX,0,delta,0,2000);
      invalidate();
  }

分析：
Scroller.invalidate方法导致View重绘，View.draw方法被执行，然后在重写的View.computeScroll方法中，会判断computeScrollOffset，true则调用scrollTo/scrollBy滚动、invalidate/postInvalidate再次重绘，如此反复，直到computeScrollOffset为false。

3.3.2 通过动画

动画本身就是一种渐近的过程,因此通过它来实现的滑动天然就具有弹性效果,比如以下代码可以让一个 View 的内容在 100ms 内向左移动 100 像素。

ObjectAnimator.ofFloat (targetView, “translationX”, 0, 100).setDuration
(100).start () ;

我们还可以利用动画的特性来实现一些动画不能实现的效果，例如：

final int startX = 0;
final int deltaX = 100;

ValueAnimator animator = ValueAnimator.ofInt (0, 1).setDuration (1000);
animator.addUpdateListener (new AnimatorUpdateListener () {
    @Override
    public void onAnimationUpdate (ValueAnimator animator) {
        float fraction =  animator.getAnimatedFraction ();
        mButton1.scrollTo (startX + (int) (deltaX * fraction), 0);
    }
});
animator.start ();

利用onAnimationUpdate,我们就可以在动画的每一帧到来时获取动画完成的比例,然后再根据这个比例计算出当前View 所要滑动的距离。

3.3.3 使用延时策略

3.4 View的事件分发机制

3.4.1 点击事件的传递规则

所谓点击事件的事件分发,其实就是对 MotionEvent事件的分发过程,即当一个MotionEvent 产生了以后,系统需要把这个事件传递给一个具体的View,而这个传递的过程就是分发过程。

事件分发的三个方法：

• dispatchTouchEvent
  • 用来进行事件的分发。如果事件能够传递给当前 View,那么此方法一定会被调用,返回结果受当前View 的 onTouchEvent 和下级 View的dispatchTouchEvent 方法的影响,表示是否消耗当前事件。
• onInterceptTouchEvent
  • 在 dispatchTouchEvent 方法中调用,用来判断是否拦截某个事件,如果当前 View 拦截了某个事件,那么在同一个事件序列当中,此方法不会被再次调用,返回结果表示是否拦截当前事件。
• onTouchEvent
  • 在 dispatchTouchEvent 方法中调用,用来处理点击事件,返回结果表示是否消耗当前事件,如果不消耗,则在同一个事件序列中,当前 View 无法再次接收到事件。

//伪代码
public boolean dispatchTouchEvent(MotionEvent ev) {
    boolean result = false;
    if(onInterceptTouchEvent(ev)) { //是否拦截
        result = onTouchEvent(ev);  //拦截，处理事件
    } else {    //不拦截，分发事件
        result = child.dispatchTouchEvent(ev);
    }
    return result;
}

点击事件和监听优先级：
onTouchListener > onTouchEvent > onClickListener

当一个点击事件产生后,它的传递过程遵循如下顺序: Activity-> Window-> View,即事件总是先传递给 Activity, Activity 再传递给 Window,最后后Window 再传递给顶级 View。顶级 View 接收到事件后,就会按照事件分发机制去分发事件。
考虑一种情况,如果一个View 的 onTouchEvent 返回false,那么它的父容器的 onTouchEvent 将会被调用,依此类推。如果所有的元素都不处理这个事件,那么这个事件将会最终传递给 Activity 处理,即Activity的onTouchEvent 方法会被调用。

3.4.2 事件分发的源码解析

1.Activity对点击事件的分发过程

1. Activity#dispatchTouchEvent

   public boolean dispatchTouchEvent (MotionEvent ev) {
       if (ev.getAction () == MotionEvent.ACTION DOWN) {
   
           onUserInteraction ();
   
       }
   
       if (getWindow ().superDispatchTouchEvent (ev)) {
   
           return true;
   
       }
   
       return onTouchEvent (ev) ;
   
   }
   

2. Window#superDispatchTouchEvent

   Window 类可以控制顶级 View 的外观和行为策略,它的唯一实现位于 android.policy.PhoneWindow 。

   public abstract boolean superDispatchTouchEvent(MotionEvent event);
   

3. PhoneWindow#superDispatchTouchEvent

   @Override
   public boolean superDispatchTouchEvent(MotionEvent event) {
   
       return mDecor.superDispatchTouchEvent(event);
   
   }
   

4. DecorView#getDecorView

   顶层View，是一个FrameLayout。

2.顶级View对点击事件的分发过程

• 如果顶级 ViewGroup 拦截事件即onInterceptTouchEvent 返回 true,则事件由 ViewGroup 处理,这时如果 ViewGroup 的mOnTouchListener 被设置,则 onTouch 会被调用,否则 onTouchEvent会被调用。也就是说,如果都提供的话,onTouch 会屏蔽掉 onTouchEvent。在onTouchEvent中,如果设置了mOnClickListener,则 onClick 会被调用。
• 如果顶级ViewGroup 不拦截事件,则事件会传递给它所在的点击事件链上的子 View,这时子 View 的 dispatchTouchEvent 会被调用。到此为止,事件已经从顶级 View 传递给了下一层 View,接下来的传递过程和顶级 View 是一致的,如此循环,完成整个事件的分发。

ViewGroup#dispatchTouchEvent

1. 判断当前View是否拦截点击事件

   // Check for interception.
   final boolean intercepted;
   
   if (actionMasked == MotionEvent.ACTION_DOWN
   
           || mFirstTouchTarget != null) {
   
       final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
   
       if (!disallowIntercept) {
   
           intercepted = onInterceptTouchEvent(ev);
   
           ev.setAction(action); // restore action in case it was changed
   
       } else {
   
           intercepted = false;
   
       }
   
   } else {
   
       // There are no touch targets and this action is not an initial down
   
       // so this view group continues to intercept touches.
   
       intercepted = true;
   
   }
   

   • 判断拦截：
     
     1. MotionEvent.ACTION_DOWN
     2. mFirstTouchTarget != null
     3. 判断mGroupFlags，可通过子View的requestDisallowInterceptTouchEvent()设置

2. ViewGroup遍历子所有View

   1. 判断子元素是否能接受这个点击事件。主要是通过两点：
      1. 子元素是否在播放动画
      2. 点击事件的着落点是否在子元素的区域内。
   2. dispatchTransformedTouchEvent()
      1. 实际就是调用子元素的dispatchTouchEvent()方法。
      2. 返回值为true，那么mFirstTouchTarget将会赋值并且跳出循环
      3. 返回值为false，将事件分发给下一个子View。

   final View[] children = mChildren;
   for (int i = childrenCount - 1; i >= 0; i--){
   
       ...
   
       //2. 通过dispatchTransformedTouchEvent()将事件传递给子View
   
       if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
   
           // Child wants to receive touch within its bounds.
   
           mLastTouchDownTime = ev.getDownTime();
   
           if (preorderedList != null) {
   
               // childIndex points into presorted list, find original index
   
               for (int j = 0; j < childrenCount; j++) {
   
                   if (children[childIndex] == mChildren[j]) {
   
                       mLastTouchDownIndex = j;
   
                       break;
   
                   }
   
               }
   
           } else {
   
               mLastTouchDownIndex = childIndex;
   
           }
   
           mLastTouchDownX = ev.getX();
   
           mLastTouchDownY = ev.getY();
   
           //3.对mFirstTouchTarget赋值
   
           newTouchTarget = addTouchTarget(child, idBitsToAssign);
   
           alreadyDispatchedToNewTouchTarget = true;
   
           break;
   
       }
   
       ev.setTargetAccessibilityFocus(false);
   
   }
   

   private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
           View child, int desiredPointerIdBits) {
   
       final boolean handled;
   
       if (child == null) {
   
           handled = super.dispatchTouchEvent(transformedEvent);
   
       } else {
   
           handled = child.dispatchTouchEvent(transformedEvent);
   
       }
   
       return handled;
   
   }
   

   private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) {
       final TouchTarget target = TouchTarget.obtain(child, pointerIdBits);
   
       target.next = mFirstTouchTarget;
   
       //mFirstTouchTarget为链表结构
   
       mFirstTouchTarget = target;
   
       return target;
   
   }
   

   mFirstTouchTarget是否赋值，将会影响ViewGroup的拦截策略。如果mFirstTouchTarget为null，那么ViewGroup将会拦截下来同一序列的所有事件，自己处理并不再向子元素传递。那mFirstTouchTarget在什么情况下才为null呢？一般在两种情况下，

   • 要么是ViewGroup遍历了所有的子元素事件没有被处理；
   • 要么是子元素处理了ACTION_DOWN但是dispatchTouchEvent返回为false。

   if (mFirstTouchTarget == null) {
       // 此处的第三个参数为null，代表事件交给ViewGroup自己处理
   
       handled = dispatchTransformedTouchEvent(ev, canceled, null,
   
               TouchTarget.ALL_POINTER_IDS);
   
   }
   

3.View对点击事件的处理过程

1. 是否设置了onTouchListener()
2. 是：调用onTouch()
3. 否：调用onTouchEvent()

onTouch()的优先级要高于onTouchEvent()。

public boolean dispatchTouchEvent(MotionEvent event) {
    //...
    //首先判断是否设置了onTouchListener()
    ListenerInfo li = mListenerInfo;
    if (li != null && li.mOnTouchListener != null
            && (mViewFlags & ENABLED_MASK) == ENABLED
            && li.mOnTouchListener.onTouch(this, event)) {
        result = true;
    }
    //调用onTouchEvent(event)
    if (!result && onTouchEvent(event)) {
        result = true;
    }
    //...
    return result;
}

View的点击事件是在ACTION_UP事件中调用了performClick()方法处理,长按事件是在ACTION_DOWN事件中调用了checkForLongClick()方法处理。

public boolean onTouchEvent(MotionEvent event) {
    ...
    //如果View设有代理，将会执行TouchDelegate.onTouchEvent(event)
    if (mTouchDelegate != null) {
        if (mTouchDelegate.onTouchEvent(event)) {
            return true;
        }
    }
    //只要View的CLICKABLE和LONG_CLICKABLE有一个返回true，他就会被消耗这个事件。
    if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) {
        switch (action) {
            case MotionEvent.ACTION_UP:
                  ...
                        if (!focusTaken) {
                            if (mPerformClick == null) {
                                mPerformClick = new PerformClick();
                            }
                            //点击事件
                            if (!post(mPerformClick)) {
                                performClick();
                            }
                        }
                    ...
                mIgnoreNextUpEvent = false;
                break;

            case MotionEvent.ACTION_DOWN:
                ...
                //长按事件
                if (!clickable) {
                    checkForLongClick(0, x, y);
                    break;
                }
                ...
                break;
                ...
        }
        return true;
    }
    return false;
}

3.5 View的滑动冲突

3.5.1 常见的滑动冲突场景

1. 外部滑动方向和内部滑动方向不一致；
2. 外部滑动方向和内部滑动方向一致；
3. 上面两种情况的嵌套。

3.5.2 滑动冲突的处理规则

1. 场景1，当用户左右滑动时，让外部的View拦截点击事件；当用户上下滑动时，让内部View拦截点击事件。
2. 场景2，根据业务不同进行判断，让外部或内部View拦截处理。
3. 场景3，相对复杂，根据业务进行处理。

如何判断是左右滑动还是上下滑动？
根据水平或垂直方向的距离差、夹角或速度差进行判断。

3.5.3 滑动冲突的解决方式

1）外部拦截法

父容器如果需要此事件就拦截，重写父容器的onInterceptTouchEvent方法。

public boolean onInterceptTouchEvent(MotionEvent event) {
    boolean intercepted = false;
    int x = (int) event.getX();
    int y = (int) event.getY();
    switch (event.getAction()) {
    case MotionEvent.ACTION_DOWN: {
        intercepted = false;    //!!!
        break;
    }
    case MotionEvent.ACTION_MOVE: {
        if (满足父容器的拦截要求) {
            intercepted = true;
        } else {
            intercepted = false;
        }
        break;
    }
    case MotionEvent.ACTION_UP: {
        intercepted = false;
        break;
    }
    default:
        break;
    }
    mLastXIntercept = x;
    mLastYIntercept = y;
    return intercepted;
}

2）内部拦截法

父容器不拦截任何事件，所有事件传递给子元素，如果子元素需要就直接消耗，否则就交给父容器处理。父容器需要的话，调用parent.requestDisallowInterceptTouchEvent方法。

public boolean dispatchTouchEvent(MotionEvent event) {
    int x = (int) event.getX();
    int y = (int) event.getY();

    switch (event.getAction()) {
    case MotionEvent.ACTION_DOWN: {
        parent.requestDisallowInterceptTouchEvent(true);
        break;
    }
    case MotionEvent.ACTION_MOVE: {
        int deltaX = x - mLastX;
        int deltaY = y - mLastY;
        if (父容器需要此类点击事件) {
            parent.requestDisallowInterceptTouchEvent(false);
        }
        break;
    }
    case MotionEvent.ACTION_UP: {
        break;
    }
    default:
        break;
    }

    mLastX = x;
    mLastY = y;
    return super.dispatchTouchEvent(event);
}

重写父容器的onInterceptTouchEvent方法。

public boolean onInterceptTouchEvent(MotionEvent event) {
    int action = event.getAction();
    if (action == MotionEvent.ACTION_DOWN) {
        return false;
    } else {
        return true;
    }
}

Java 语言的类型可以分为两大类：基本类型（primitive types）和引用类型（reference types）。

• Java 的基本类型，它们是由 Java 虚拟机预先定义好的。
• 引用类型，Java 将其细分为四种：类、接口、数组类和泛型参数。由于泛型参数会在编译过程中被擦除（我会在专栏的第二部分详细介绍），因此 Java 虚拟机实际上只有前三种。在类、接口和数组类中，数组类是由 Java 虚拟机直接生成的，其他两种则有对应的字节流。

说到字节流，最常见的形式要属由 Java 编译器生成的 class 文件。除此之外，我们也可以在程序内部直接生成，或者从网络中获取（例如网页中内嵌的小程序 Java applet）字节流。这些不同形式的字节流，都会被加载到 Java 虚拟机中，成为类或接口。

无论是直接生成的数组类，还是加载的类，Java 虚拟机都需要对其进行链接和初始化。

加载

加载，是指查找字节流，并且据此创建类的过程。对于数组类来说，它并没有对应的字节流，而是由 Java 虚拟机直接生成的。对于其他的类来说，Java 虚拟机则需要借助类加载器来完成查找字节流的过程。

启动类加载器是由 C++ 实现的，没有对应的 Java 对象，因此在 Java 中只能用 null 来指代。除了启动类加载器之外，其他的类加载器都是 java.lang.ClassLoader 的子类，因此有对应的 Java 对象。这些类加载器需要先由另一个类加载器，比如说启动类加载器，加载至 Java 虚拟机中，方能执行类加载。

双亲委派模型：每当一个类加载器接收到加载请求时，它会先将请求转发给父类加载器。在父类加载器没有找到所请求的类的情况下，该类加载器才会尝试去加载。

在 Java 9 之前，启动类加载器负责加载最为基础、最为重要的类，比如存放在 JRE 的 lib 目录下 jar 包中的类（以及由虚拟机参数 -Xbootclasspath 指定的类）。除了启动类加载器之外，另外两个重要的类加载器是扩展类加载器（extension class loader）和应用类加载器（application class loader），均由 Java 核心类库提供。

Java 9 引入了模块系统，并且略微更改了上述的类加载器。扩展类加载器被改名为平台类加载器（platform class loader）。Java SE 中除了少数几个关键模块，比如说 java.base 是由启动类加载器加载之外，其他的模块均由平台类加载器所加载。

在 Java 虚拟机中，类的唯一性是由类加载器实例以及类的全名一同确定的。即便是同一串字节流，经由不同的类加载器加载，也会得到两个不同的类。

链接

链接，是指将创建成的类合并至 Java 虚拟机中，使之能够执行的过程。它可分为验证、准备以及解析三个阶段。

验证阶段的目的，在于确保被加载类能够满足 Java 虚拟机的约束条件。

准备阶段的目的，则是为被加载类的静态字段分配内存。除了分配内存外，部分 Java 虚拟机还会在此阶段构造其他跟类层次相关的数据结构，比如说用来实现虚方法的动态绑定的方法表。

在 class 文件被加载至 Java 虚拟机之前，这个类无法知道其他类及其方法、字段所对应的具体地址，甚至不知道自己方法、字段的地址。因此，每当需要引用这些成员时，Java 编译器会生成一个符号引用。在运行阶段，这个符号引用一般都能够无歧义地定位到具体目标上。
解析阶段的目的，正是将这些符号引用解析成为实际引用。如果符号引用指向一个未被加载的类，或者未被加载类的字段或方法，那么解析将触发这个类的加载（但未必触发这个类的链接以及初始化。）

Java 虚拟机规范并没有要求在链接过程中完成解析。它仅规定了：如果某些字节码使用了符号引用，那么在执行这些字节码之前，需要完成对这些符号引用的解析。

初始化

在 Java 代码中，如果要初始化一个静态字段，我们可以在声明时直接赋值，也可以在静态代码块中对其赋值。

如果直接赋值的静态字段被 final 所修饰，并且它的类型是基本类型或字符串时，那么该字段便会被 Java 编译器标记成常量值（ConstantValue），其初始化直接由 Java 虚拟机完成。除此之外的直接赋值操作，以及所有静态代码块中的代码，则会被 Java 编译器置于同一方法中，并把它命名为 < clinit >。

类加载的最后一步是初始化，便是为标记为常量值的字段赋值，以及执行 < clinit > 方法的过程。Java 虚拟机会通过加锁来确保类的 < clinit > 方法仅被执行一次。

那么，类的初始化何时会被触发呢？JVM 规范枚举了下述多种触发情况：

1. 当虚拟机启动时，初始化用户指定的主类；
2. 当遇到用以新建目标类实例的 new 指令时，初始化 new 指令的目标类；
3. 当遇到调用静态方法的指令时，初始化该静态方法所在的类；
4. 当遇到访问静态字段的指令时，初始化该静态字段所在的类；
5. 子类的初始化会触发父类的初始化；
6. 如果一个接口定义了 default 方法，那么直接实现或者间接实现该接口的类的初始化，会触发该接口的初始化；
7. 使用反射 API 对某个类进行反射调用时，初始化这个类；
8. 当初次调用 MethodHandle 实例时，初始化该 MethodHandle 指向的方法所在的类。

总结与实践

今天我介绍了 Java 虚拟机将字节流转化为 Java 类的过程。这个过程可分为加载、链接以及初始化三大步骤。

加载是指查找字节流，并且据此创建类的过程。加载需要借助类加载器，在 Java 虚拟机中，类加载器使用了双亲委派模型，即接收到加载请求时，会先将请求转发给父类加载器。

链接，是指将创建成的类合并至 Java 虚拟机中，使之能够执行的过程。链接还分验证、准备和解析三个阶段。其中，解析阶段为非必须的。

初始化，则是为标记为常量值的字段赋值，以及执行 < clinit > 方法的过程。类的初始化仅会被执行一次，这个特性被用来实现单例的延迟初始化。

• 简易锁模型
• 改进后的锁模型
• Java 语言提供的锁技术：synchronized
• 用 synchronized 解决 count+=1 问题
• 锁和受保护资源的关系

那原子性问题到底该如何解决呢？

“同一时刻只有一个线程执行”这个条件非常重要，我们称之为互斥。如果我们能够保证对共享变量的修改是互斥的，那么，无论是单核 CPU 还是多核 CPU，就都能保证原子性了。

简易锁模型

我们把一段需要互斥执行的代码称为临界区。线程在进入临界区之前，首先尝试加锁 lock()，如果成功，则进入临界区，此时我们称这个线程持有锁；否则呢就等待，直到持有锁的线程解锁；持有锁的线程执行完临界区的代码后，执行解锁 unlock()。

改进后的锁模型

锁和锁要保护的资源是有对应关系的，在并发编程世界里，锁和资源也应该有这个关系，但这个关系在我们上面的模型中是没有体现的，所以我们需要完善一下我们的模型。

1. 首先，我们要把临界区要保护的资源标注出来，如图中临界区里增加了一个元素：受保护的资源 R；
2. 其次，我们要保护资源 R 就得为它创建一把锁 LR；
3. 最后，针对这把锁 LR，我们还需在进出临界区时添上加锁操作和解锁操作。
4. 另外，在锁 LR 和受保护资源之间，我特地用一条线做了关联，这个关联关系非常重要。很多并发 Bug 的出现都是因为把它忽略了，然后就出现了类似锁自家门来保护他家资产的事情。

Java 语言提供的锁技术：synchronized

锁是一种通用的技术方案，Java 语言提供的 synchronized 关键字，就是锁的一种实现。synchronized 关键字可以用来修饰方法，也可以用来修饰代码块，它的使用示例基本上都是下面这个样子：

class X {
  // 修饰非静态方法
  synchronized void foo() {
    // 临界区
  }
  // 修饰静态方法
  synchronized static void bar() {
    // 临界区
  }
  // 修饰代码块
  Object obj = new Object()；
  void baz() {
    synchronized(obj) {
      // 临界区
    }
  }
}  

• Java 编译器会在 synchronized 修饰的方法或代码块前后自动加上加锁 lock() 和解锁 unlock()。
• 当修饰静态方法的时候，锁定的是当前类的 Class 对象，在上面的例子中就是 Class X；当修饰非静态方法的时候，锁定的是当前实例对象 this。

class X {
  // 修饰静态方法
  synchronized(X.class) static void bar() {
    // 临界区
  }
}
class X {
  // 修饰非静态方法
  synchronized(this) void foo() {
    // 临界区
  }
}

用 synchronized 解决 count+=1 问题

锁和受保护资源的关系

受保护资源和锁之间的关联关系是 N:1 的关系。

class SafeCalc {
  static long value = 0L;
  synchronized long get() {
    return value;
  }
  synchronized static void addOne() {
    value += 1;
  }
}

如果你仔细观察，就会发现改动后的代码是用两个锁保护一个资源。这个受保护的资源就是静态变量 value，两个锁分别是 this 和 SafeCalc.class。我们可以用下面这幅图来形象描述这个关系。由于临界区 get() 和 addOne() 是用两个锁保护的，因此这两个临界区没有互斥关系，临界区 addOne() 对 value 的修改对临界区 get() 也没有可见性保证，这就导致并发问题了。

总结

互斥锁，在并发领域的知名度极高，只要有了并发问题，大家首先容易想到的就是加锁，因为大家都知道，加锁能够保证执行临界区代码的互斥性。临界区的代码是操作受保护资源的路径，不是随便一把锁都能有效。所以必须深入分析锁定的对象和受保护资源的关系，综合考虑受保护资源的访问路径，多方面考量才能用好互斥锁。

课后思考

下面的代码用 synchronized 修饰代码块来尝试解决并发问题，你觉得这个使用方式正确吗？有哪些问题呢？能解决可见性和原子性问题吗？

class SafeCalc {
  long value = 0L;
  long get() {
    synchronized (new Object()) {
      return value;
    }
  }
  void addOne() {
    synchronized (new Object()) {
      value += 1;
    }
  }
}

答：加锁本质就是在锁对象的对象头中写入当前线程id，但是new object每次在内存中都是新对象，所以加锁无效。
老师：一个合理的受保护资源与锁之间的关联关系应该是 N:1。只有共享一把锁才能起到互斥的作用。

3.1 概述

GC需要完成的3件事情：

1. 哪些内存需要回收？
2. 什么时候回收？
3. 如何回收？

3.2 对象已死吗

垃圾收集器在堆进行回收前，要确定对象是否仍被使用。

3.2.1 引用计数算法

3.2.2 可达性分析算法

3.2.3 再谈引用

3.2.4 生存还是死亡

3.2.5 回收方法区

3.3 垃圾收集算法

3.3.1 标记—清除算法

3.3.2 复制算法

3.3.3 标记—整理算法

3.3.4 分代收集算法

3.4 HotSpot的算法实现

3.4.1 枚举根节点

3.4.2 安全点

3.4.3 安全区域

3.5 垃圾收集器

3.5.1 Serial收集器

3.5.2 ParNew收集器

3.5.3 ParallelScavenge收集器

3.5.4 SerialOld收集器

3.5.5 ParallelOld收集器

3.5.6 CMS收集器

3.5.7 G1收集器

3.5.8 理解GC日志

3.5.9 垃圾收集器参数总结

3.6 内存分配与回收策略

3.6.1 对象优先在Eden分配

3.6.2 大对象直接进入老年代

3.6.3 长期存活的对象将进入老年代

3.6.4 动态对象年龄判定

3.6.5 空间分配担保

3.7 本章 小结

为什么需要复杂度分析？

事后统计法的局限性：

1. 测试结果非常依赖测试环境
2. 测试结果受数据规模的影响很大

我们需要一个不用具体的测试数据来测试，就可以粗略地估计算法的执行效率的方法。这就是我们今天要讲的时间、空间复杂度分析方法。

大 O 复杂度表示法

所有代码的执行时间 T(n) 与每行代码的执行次数 n 成正比。

大 O 时间复杂度表示法，表示代码执行时间随数据规模增长的变化趋势，也叫作渐进时间复杂度，简称时间复杂度。

时间复杂度分析

1. 只关注循环执行次数最多的一段代码
2. 加法法则：总复杂度等于量级最大的那段代码的复杂度
3. 乘法法则：嵌套代码的复杂度等于嵌套内外代码复杂度的乘积

几种常见时间复杂度实例分析

粗略地分为两类，多项式量级和非多项式量级。其中，非多项式量级只有两个：O(2n) 和 O(n!)。

下面是几种常见的多项式时间复杂度：

1. O(1)
   1. 一般情况下，只要算法中不存在循环语句、递归语句，即使有成千上万行的代码，其时间复杂度也是Ο(1)。
2. O(logn)、O(nlogn)
   1. 在采用大 O 标记复杂度的时候，可以忽略系数，即 O(Cf(n)) = O(f(n))。
3. O(m+n)、O(m*n)
   1. 代码的复杂度由两个数据的规模来决定。

空间复杂度分析

空间复杂度全称就是渐进空间复杂度，表示算法的存储空间与数据规模之间的增长关系。

我们常见的空间复杂度就是 O(1)、O(n)、O(n2 )，像 O(logn)、O(nlogn) 这样的对数阶复杂度平时都用不到。而且，空间复杂度分析比时间复杂度分析要简单很多。所以，对于空间复杂度，掌握刚我说的这些内容已经足够了。

3.1 应用程序进程简介

要想启动一个应用程序，首先要保证这个应用程序所需要的应用程序进程已经启动。AMS在启动应用程序时会检查这个应用程序需要的应用程序进程是否存在，不存在就会请求Zygote进程启动需要的应用程序进程。在2.2节中，我们知道在Zygote的Java框架层中会创建一个Server端的Socket,这个Socket用来等待AMS请求Zygote来创建新的应用程序进程。Zygote进程通过fock自身创建应用程序进程，这样应用程序进程就会获得Zygote进程在启动时创建的虚拟机实例。当然，在应用程序进程创建过程中除了获取虚拟机实例外，还创建了Binder 线程池和消息循环，这样运行在应用进程中的应用程序就可以方便地使用Binder进行进程间通信以及处理消息了。

3.2 应用程序进程启动过程介绍

3.2.1 AMS发送启动应用程序进程请求

3.2.2 Zygote接收请求并创建应用程序进程

3.3 Binder线程池启动过程

3.4 消息循环创建过程

3.5 本章小结

4.1 初识ViewRoot和DecorView

1. ActivityThread#handleResumeActivity
   1. 当 Activity 对象被创建完毕后，会将 DecorView 通过 WindowManager 添加到 Window 中。
2. WindowManagerGlobal#addView
   1. 创建 ViewRootImpl 对象，并将 ViewRootImpl 对象和 DecorView 建立关联。
3. ViewRootImpl#setView
   1. ViewRootImpl#requestLayout
   2. ViewRootImpl#scheduleTraversals
   3. ViewRootImpl.TraversalRunnable#performTraversals
      1. ViewRootImpl#performMeasure
      2. ViewRootImpl#performLayout
      3. ViewRootImpl#performDraw

4.2 理解MeasureSpec

4.2.1 MeasureSpec

• 测量规格，决定View的大小。
• 是一个32位int值，高2位代表SpecMode(测量模式)，低30位代表SpecSize(规格大小)。
• 三种模式：
  • UNSPECIFIED 父容器不对View有任何限制，要多大就给多大。常用于系统内部。
  • EXACTLY 父容器已经检测出View所需要的精确大小即SpecSize。对应LyaoutParams中的match_parent或具体数值。
  • AT_MOST 父容器为子视图指定一个最大尺寸SpecSize。对应LayoutParams中的wrap_content。
• View的MeasureSpec由LayoutParams和父容器的LayoutParams共同决定。

4.2.2 MeasureSpec和LayoutParams的对应关系

4.3 View的工作流程

1. 先将DecorView加载到Window中
2. 然后开始View的绘制，调用ViewRootImpl的PerformTraversals方法
3. performTraversals()中依次调用performMeasure()、performLayout()和performDraw()三个方法，分别完成顶级 View的绘制
4. performMeasure() > measure() > onMeasure()，其中会实现子View的measure过程，layout和draw同理。

4.3.1 measure过程

测量View的宽高

protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
    setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec),
                         getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));
}

• View的Measure
  • measure() > onMeasure() > setMeasuredDimension() > getDefaultSize()
• ViewGroup的Measure
  • measureChildren() > measureChild() > getChildMeasureSpec() > child.measure()

直接继承View的自定义View，需要重写onMeasure()并设置wrap_content时的自身大小，否则效果相当于macth_parent。

如何保证某个View已经测量完毕？

1. Activity/View#onWindowFocusChanged
2. view.post(runnable)
3. ViewTreeObserver
4. view.measure(int widthMeasureSpec , int heightMeasureSpec)

4.3.2 layout过程

确定元素的位置

1. View的layout()，通过setFrame()来设定自己的四个顶点，确定自己的位置
2. onLayout()确定子元素的位置，空方法，不同的ViewGroup实现不同。

4.3.3 draw过程

将View绘制到屏幕上

1. 绘制背景（drawBackground）
2. 绘制自己（onDraw）
3. 绘制children（dispatchDraw）
4. 绘制装饰（onDrawScrollBars）

4.4 自定义View

4.4.1 自定义View的分类

1. 继承View
   • 重写onDraw
   • 支持wrap_content、处理padding
2. 继承ViewGroup
   • 处理自身和子元素的测量和布局
3. 继承特定的View(如TextView)
4. 继承ViewGroup(如LinearLayout)

4.4.2 自定义View须知

1. 尽量不要在View中使用Handler，使用post
2. 及时停止线程和动画
3. 滑动嵌套时，处理滑动冲突
4. 自定义属性
   1. values下创建自定义属性的xml
   2. View的构造方法中解析自定义属性并处理
   3. 在布局中使用自定义属性

4.4.3 自定义View示例

4.4.4 自定义View的思想

• 保护没有关联关系的多个资源
• 保护有关联关系的多个资源
• 使用锁的正确姿势

当我们要保护多个资源时，首先要区分这些资源是否存在关联关系。

保护没有关联关系的多个资源

银行业务中有针对账户余额（余额是一种资源）的取款操作，也有针对账户密码（密码也是一种资源）的更改操作，我们可以为账户余额和账户密码分配不同的锁来解决并发问题，这个还是很简单的。

用不同的锁对受保护资源进行精细化管理，能够提升性能。这种锁还有个名字，叫细粒度锁。

保护有关联关系的多个资源

使用锁的正确姿势

用同一把锁来保护多个资源，要求锁能覆盖所有受保护资源。
如何让 A 对象和 B 对象共享一把锁呢？
答：用 Account.class 作为共享的锁。Account.class 是所有 Account 对象共享的，而且这个对象是 Java 虚拟机在加载 Account 类的时候创建的，所以我们不用担心它的唯一性。使用 Account.class 作为共享的锁，我们就无需在创建 Account 对象时传入了，代码更简单。

总结

相信你看完这篇文章后，对如何保护多个资源已经很有心得了，关键是要分析多个资源之间的关系。

• 如果资源之间没有关系，很好处理，每个资源一把锁就可以了。
• 如果资源之间有关联关系，就要选择一个粒度更大的锁，这个锁应该能够覆盖所有相关的资源。
• 除此之外，还要梳理出有哪些访问路径，所有的访问路径都要设置合适的锁，这个过程可以类比一下门票管理。

关联关系如果用更具体、更专业的语言来描述的话，其实是一种“原子性”特征。“原子性”的本质是什么？其实不是不可分割，不可分割只是外在表现，其本质是多个资源间有一致性的要求，操作的中间状态对外不可见。所以解决原子性问题，是要保证中间状态对外不可见。

课后思考

在第一个示例程序里，我们用了两把不同的锁来分别保护账户余额、账户密码，创建锁的时候，我们用的是：private final Object xxxLock = new Object();，如果账户余额用 this.balance 作为互斥锁，账户密码用 this.password 作为互斥锁，你觉得是否可以呢？

答：用this.balance 和this.password 都不行。不能用可变对象做锁。
老师：一个是锁有可能会变化，另一个是 Integer 和 String 类型的对象不适合做锁。如果锁发生变化，就意味着失去了互斥功能。 Integer和String 类型的对象在 JVM 里面是可能被重用的，除此之外，JVM 里可能被重用的对象还有 Boolean，那重用意味着什么呢？意味着你的锁可能被其他代码使用，如果其他代码 synchronized(你的锁)，而且不释放，那你的程序就永远拿不到锁，这是隐藏的风险。
锁，应是私有的、不可变的、不可重用的。

锁的最佳实践：

// 普通对象锁
private final Object 
  lock = new Object();
// 静态对象锁
private static final Object
  lock = new Object(); 

对象的克隆——原型模式

原型模式（Prototype Pattern）是用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。

介绍

意图：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
主要解决：在运行期建立和删除原型。
何时使用： 1、当一个系统应该独立于它的产品创建，构成和表示时。 2、当要实例化的类是在运行时刻指定时，例如，通过动态装载。 3、为了避免创建一个与产品类层次平行的工厂类层次时。 4、当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。
如何解决：利用已有的一个原型对象，快速地生成和原型对象一样的实例。
关键代码： 1、实现克隆操作，在 JAVA 继承 Cloneable，重写 clone()，在 .NET 中可以使用 Object 类的 MemberwiseClone() 方法来实现对象的浅拷贝或通过序列化的方式来实现深拷贝。 2、原型模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些"易变类"拥有稳定的接口。
应用实例： 1、细胞分裂。 2、JAVA 中的 Object clone() 方法。
优点： 1、性能提高。 2、逃避构造函数的约束。
缺点： 1、配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。 2、必须实现 Cloneable 接口。
使用场景： 1、资源优化场景。 2、类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。 3、性能和安全要求的场景。 4、通过 new 产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。 5、一个对象多个修改者的场景。 6、一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。 7、在实际项目中，原型模式很少单独出现，一般是和工厂方法模式一起出现，通过 clone 的方法创建一个对象，然后由工厂方法提供给调用者。原型模式已经与 Java 融为浑然一体，大家可以随手拿来使用。
注意事项：与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过拷贝一个现有对象生成新对象的。浅拷贝实现 Cloneable，重写，深拷贝是通过实现 Serializable 读取二进制流。
注意：拷贝所创建的是全新的对象，它们在内存中拥有新的地址，新对象的修改不会对原型对象造成任何影响，每一个克隆对象都是相互独立的。通过不同的方式对拷贝对象进行修改后，可以得到一系列相似但不完全相同的对象。

4.1 根Activity的启动过程

1. Launcher请求AMS过程
2. AMS到ApplicationThread的调用过程
3. ActivityThread启动Activity的过程

4.1.1 Launcher请求AMS过程

4.1.2 AMS到ApplicationThread的调用过程

4.1.3 ActivityThread启动Activity的过程

4.1.4 根Activity启动过程中涉及的进程

4.2 Service的启动过程

1. ContextImpl到AMS的调用过程
2. ActivityThread启动Service

4.2.1 ContextImpl到AMS的调用过程

4.2.2 ActivityThread启动Service

4.3 Service的绑定过程

1. ContextImpl到AMS的调用过程
2. Service的绑定过程

4.3.1 ContextImpl到AMS的调用过程

4.3.2 Service的绑定过程

4.4 广播的注册、发送和接收过程

4.4.1 广播的注册过程

4.4.2 广播的发送和接收过程

1. ContextImpl到AMS的调用过程
2. AMS到BroadcastReceiver的调用过程。

4.5 Content Provider的启动过程

1. query方法到AMS的调用过程
2. AMS启动Content Provider的过程

4.5.1 query方法到AMS的调用过程

4.5.2 AMS启动Content Provider的过程

4.6 本章小结

• 最好情况时间复杂度（best case time complexity）
• 最坏情况时间复杂度（worst case time complexity）
• 平均情况时间复杂度（average case time complexity）
• 均摊时间复杂度（amortized time complexity）

最好情况时间复杂度就是，在最理想的情况下，执行这段代码的时间复杂度。
最坏情况时间复杂度就是，在最糟糕的情况下，执行这段代码的时间复杂度。

平均时间复杂度的全称应该叫加权平均时间复杂度或者期望时间复杂度，这个值是概率论中的加权平均值，也叫作期望值。

均摊时间复杂度就是一种特殊的平均时间复杂度。

大部分情况下，我们并不需要区分最好、最坏、平均三种复杂度。平均复杂度只在某些特殊情况下才会用到，而均摊时间复杂度应用的场景比它更加特殊、更加有限。

4.1　线程基础

4.1.1　进程与线程

1.什么是进程
进程是操作系统结构的基础，是程序在一个数据集合上运行的过程，是系统进行资源分配和调度的基本单位。进程可以被看作程序的实体，同样，它也是线程的容器。进程就是程序的实体，是受操作系统管理的基本运行单元。
2.什么是线程
线程是操作系统调度的最小单元，也叫作轻量级进程。在一个进程中可以创建多个线程，这些线程都拥有各自的计数器、堆栈和局部变量等属性，并且能够访问共享的内存变量。
3.为何要使用多线程
在操作系统级别上来看主要有以下几个方面：

• 使用多线程可以减少程序的响应时间，使程序具备了更好的交互性。
• 与进程相比，线程创建和切换开销更小，同时多线程在数据共享方面效率非常高。
• 避免多CPU或者多核计算机的资源浪费，提高CPU的利用率。
• 使用多线程能简化程序的结构，使程序便于理解和维护。

4.1.2　线程的状态

Java线程在运行的声明周期中可能会处于6种不同的状态，这6种线程状态分别为如下所示。

• New：新创建状态。线程被创建，还没有调用 start 方法，在线程运行之前还有一些基础工作要做。
• Runnable：可运行状态。一旦调用start方法，线程就处于Runnable状态。一个可运行的线程可能正在 运行也可能没有运行，这取决于操作系统给线程提供运行的时间。
• Blocked：阻塞状态。表示线程被锁阻塞，它暂时不活动。
• Waiting：等待状态。线程暂时不活动，并且不运行任何代码，这消耗最少的资源，直到线程调度器重新激活它。
• Timed waiting：超时等待状态。和等待状态不同的是，它是可以在指定的时间自行返回的。
• Terminated：终止状态。表示当前线程已经执行完毕。导致线程终止有两种情况：第一种就是run方法执行完毕正常退出；第二种就是因为一个没有捕获的异常而终止了run方法，导致线程进入终止状态。

4.1.3　创建线程

多线程的实现一般有以下3种方法，其中前两种为最常用的方法。

1. 继承Thread类，重写run()方法
2. 实现Runnable接口，并实现该接口的run()方法
3. 实现Callable接口，重写call()方法

Callable接口实际是属于Executor框架中的功能类，Callable接口与Runnable接口的功能类似，但提供了比Runnable更强大的功能，主要表现为以下3点：

1. Callable可以在任务接受后提供一个返回值；
2. Callable中的call()方法可以抛出异常；
3. 运行Callable可以拿到一个Future对象，Future对象表示异步计算的结果，它提供了检查计算是否完成的方法。由于线程属于异步计算模型，因此无法从别的线程中得到函数的返回值，在这种情况下就可 以使用 Future 来监视目标线程调用 call()方法的情况。但调用 Future的get()方法以获取结果时，当前线程就会阻塞，直到call()方法返回结果。

4.1.4　理解中断

当线程的run方法执行完毕，或者在方法中出现没有捕获的异常时，线程将终止。

• interrupt()方法可以用来请求中断线程。当一个线程调用 interrupt 方法时，线程的中断标识位将被置位(中断标识位为true)，线程会不时地检测这个中断标识位，以判断线程是否应该被中断。
• Thread.currentThread().isInterrupted() 判断线程是否被置位
• Thread.interrupted()，对中断标识位进行复位。

但是如果一个线程被阻塞，就无法检测中断状态。如果一个线程处于阻塞状态，线程在检查中断标识位时如果发现中断标识位为true，则会在阻塞方法调用处抛出InterruptedException异常，并且在抛出异常前将线程的中断标识位复位，即重新设置为false。需要注意的是被中断的线程不一定会终止，中断线程是为了引起线程的注意，被中断的线程可以决定如何 去响应中断。如果是比较重要的线程则不会理会中断，而大部分情况则是线程会将中断作为一个终止的请求。

抛出InterruptedException异常后合理的处理方式：

1. 在catch子句中，调用Thread.currentThread.interrupt()来设置中断状态(因为抛出异常后中断标识位会复位)，让外界通过判断Thread.currentThread().isInterrupted()来决定是否终止线程还是继续下去。

   void my Task() {
       try {
   
           sleep(50)
   
       } catch(InterruptedException) {
   
           Thread.currentThread().interrupted();
   
           //...
   
       }
   
   }
   

2. 更好的做法就是，不使用try来捕获这样的异常，让方法直接抛出，这样调用者可以捕获这个异常。

   void myTask() throw InterruptedException {
       sleep(50)
   
   }
   

4.1.5　安全地终止线程

4.2　同步

在多线程应用中，两个或者两个以上的线程需要共享对同一个数据的存取。如果两个线程存取相同的对象，并且每一个线程都调用了修改该对象的方法， 这种情况通常被称为竞争条件。比如很多人同时买火车票，如果不使用同步保证其原子性，有可能出现两个人买同一张票的情况。解决方法如下：当一个线程要使用火车票这个资源时，我们就交给它一把锁，等它把事情做完后再把锁给另一个要用这个资源的线程。这样就不会出现上述情况了。

4.2.1　重入锁与条件对象

synchronized 关键字自动提供了锁以及相关的条件。重入锁ReentrantLock是 Java SE 5.0引入的，就是支持重进入的锁，它表示该锁能够支持一个线程对资源的重复加锁。用 ReentrantLock保护代码块的结构如下所示：

Lock mLock = new ReentrantLock();
mLock.lock() ;
try {
//...
} finally {
mLock.unlock() ;
}

这一结构确保任何时刻只有一个线程进入临界区，临界区就是在同一时刻只能有一个任务访问的代码区。一旦一个线程封锁了锁对象，其他任何线程都无法进入Lock语句。把解锁的操作放在finally中是十分必 要的。如果在临界区发生了异常，锁是必须要释放的，否则其他线程将会永远被阻塞。进入临界区时，却 发现在某一个条件满足之后，它才能执行。这时可以使用一个条件对象来管理那些已经获得了一个锁但是 却不能做有用工作的线程，条件对象又被称作条件变量。

一个锁对象拥有多个相关的条件对象，可以用newCondition方法获得一个条件对象Condition，我们得到条件对象后调用await方法，当前线程就被阻塞了并放弃了锁。一旦一个线程调用 await 方法，它就会进入该条件的等待集并处于阻塞状态，直到另一个线程调用了同 一个条件的signalAll方法时为止。调用signalAll方法时并不是立即激活一个等待线程，它仅仅解除了等待线程的阻塞，以便这些线程能 够在当前线程退出同步方法后，通过竞争实现对对象的访问。还有一个方法是signal，它则是随机解除某个线程的阻塞。如果该线程仍然不能运行，则再次被阻塞。如果没有其他线程再次调用signal，那么系统就死锁了。

4.2.2　同步方法

如果一个方法用 synchronized 关键字声明，那么对象的锁将保护整个方法。

public synchronized void method() {
}

等价于：

Lock mLock = new ReentrantLock();
public void method() {
    mLock.lock();
    try {
    } finally {
        mLock.unlock();
    }
}

4.2.3　同步代码块

其获得了obj的锁，obj指的是一个对象。

synchronized(obj) {
}

同步代码块是非常脆弱的， 通常不推荐使用。一般实现同步最好用java.util.concurrent包下提供的类，比如阻塞队列。

4.2.4　volatile

有时仅仅为了读写一个或者两个实例域就使用同步的话，显得开销过大;而volatile关键字为实例域的同步访问提供了免锁的机制。如果声明一个域为volatile，那么编译器和虚拟机就知道该域是可能被另一个 线程并发更新的。再讲到volatile关键字之前，我们需要了解一下内存模型的相关概念以及并发编程中的3个 特性：原子性、可见性和有序性。

1.Java内存模型

Java中的堆内存用来存储对象实例，堆内存是被所有线程共享的运行时内存区域，因此，它存在内存可见性的问题。而局部变量、方法定义的参数则不会在线程之间共享，它们不会有内存可见性问题，也不受内存模型的影响。Java 内存模型定义了线程和主存之间的抽象关系：线程之间的共享变量存储在主存中， 每个线程都有一个私有的本地内存，本地内存中存储了该线程共享变量的副本。需要注意的是本地内存是 Java内存模型的一个抽象概念，其并不真实存在，它涵盖了缓存、写缓冲区、寄存器等区域。Java内存模型控制线程之间的通信，它决定一个线程对主存共享变量的写入何时对另一个线程可见。

线程A与线程B之间若要通信的话，必须要经历下面两个步骤：

1. 线程A把线程A本地内存中更新过的共享变量刷新到主存中去。
2. 线程B到主存中去读取线程A之前已更新过的共享变量。

2.原子性、可见性和有序性

• 原子性
  • 对基本数据类型变量的读取和赋值操作是原子性操作，即这些操作是不可被中断的，要么执行完毕， 要么就不执行。一个语句含有多个操作时，就不是原子性操作。
  • java.util.concurrent.atomic 包中有 很多类使用了很高效的机器级指令(而不是使用锁)来保证其他操作的原子性。例如 AtomicInteger 类提供 了方法incrementAndGet和decrementAndGet，它们分别以原子方式将一个整数自增和自减。可以安全地使用 AtomicInteger类作为共享计数器而无须同步。另外这个包还包含AtomicBoolean、AtomicLong和 AtomicReference这些原子类，这仅供开发并发工具的系统程序员使用，应用程序员不应该使用这些类。
• 可见性
  • 可见性，是指线程之间的可见性，一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果，另一个线程马上就能看到。
  • 当一个共享变量被volatile修饰时，它会保证修改的值立即被更新到主存，所以对其他线程是可见的。当有其他线程需要读取该值时，其他线程会去主存中读取新值。
  • 普通的共享变量不能保证可见性，因为普通共享变量被修改之后，并不会立即被写入主存，何时被写入主存也是不确定的。当其他线程去读取该值时，此时主存中可能还是原来的旧值，这样就无法保证可见性。
• 有序性
  • Java内存模型中允许编译器和处理器对指令进行重排序，虽然重排序过程不会影响到单线程执行的正确性，但是会影响到多线程并发执行的正确性。
  • 可以通过volatile来保证有序性；
  • 还可以通 过synchronized和Lock来保证有序性。我们知道，synchronized和Lock保证每个时刻只有一个线程执行同步代码，这相当于是让线程顺序执行同步代码，从而保证了有序性。

3.volatile关键字

当一个共享变量被volatile修饰之后，其就具备了两个含义，一个是线程修改了变量的值时，变量的新值对其他线程是立即可见的，即不同线程对这个变量进行操作时具有可见性。另一个含义是禁止使用指令重排序。

什么是重排序呢?重排序通常是编译器或运行时环境为了优化程序性能而采取的对指令进行重新排序执行的一种手段。重排序分为两类：编译期重排序和运行期重排序，分别对应编译时和运行时环境。

volatile不保证操作原子性
volatile保证有序性

4.正确使用volatile关键字

synchronized关键字可防止多个线程同时执行一段代码，那么这就会很影响程序执行效率。而volatile关键字在某些情况下的性能要优于synchronized。但是要注意volatile关键字是无法替代synchronized关键字的， 因为volatile关键字无法保证操作的原子性。通常来说，使用volatile必须具备以下两个条件：

1. 对变量的写操作不会依赖于当前值。
2. 该变量没有包含在具有其他变量的不变式中。

使用volatile有很多种场景，这里介绍其中的两种。

1. 状态标志

   volatile boolean shutdownRequested;
   public void shutdown () {
   
       shutdownRequested = true;
   
   }
   
   public void doWork() {
   
       while (!shutdownRequested) {
   
       }
   
   }
   

2. 双重检查模式(DCL)

4.3　阻塞队列

4.3.1　阻塞队列简介

阻塞队列常用于生产者和消费者的场景，生产者是往队列里添加元素的线程，消费者是从队列里拿元 素的线程。阻塞队列就是生产者存放元素的容器，而消费者也只从容器里拿元素。

1.常见阻塞场景

阻塞队列有两个常见的阻塞场景，它们分别是：

1. 当队列中没有数据的情况下，消费者端的所有线程都会被自动阻塞(挂起)，直到有数据放入队列。队列空，消费者堵塞。
2. 当队列中填满数据的情况下，生产者端的所有线程都会被自动阻塞(挂起)，直到队列中有空的位置，线程被自动唤醒。队列满，生产者堵塞。

支持以上两种阻塞场景的队列被称为阻塞队列。

2.BlockingQueue的核心方法

• 放入数据
  • offer(anObject)：表示如果可能的话，将anObject加到BlockingQueue里。即如果BlockingQueue可以容纳，则返回true，否则返回false。(本方法不阻塞当前执行方法的线程。)
  • offer(E o，long timeout，TimeUnit unit)：可以设定等待的时间。如果在指定的时间内还不能往队列中加入BlockingQueue，则返回失败。
  • put(anObject)：将anObject加到BlockingQueue里。如果BlockQueue没有空间，则调用此方法的线程被阻断，直到BlockingQueue里面有空间再继续。
• 获取数据：
  • poll(time)：取走BlockingQueue 里排在首位的对象。若不能立即取出，则可以等 time参数规定的时间。取不到时返回null。
  • poll(long timeout，TimeUnit unit)：从BlockingQueue中取出一个队首的对象。如果在指定时间内，队列一旦有数据可取，则立即返回队列中的数据;否则直到时间超时还没有数据可取，返回失败。
  • take()：取走BlockingQueue里排在首位的对象。若BlockingQueue为空，则阻断进入等待状态，直到 BlockingQueue有新的数据被加入。
  • drainTo()：一次性从BlockingQueue获取所有可用的数据对象(还可以指定获取数据的个数)。通过该方法，可以提升获取数据的效率;无须多次分批加锁或释放锁。

4.3.2　Java中的阻塞队列

在Java中提供了7个阻塞队列，它们分别如下所示。

• ArrayBlockingQueue：由数组结构组成的有界阻塞队列。
• LinkedBlockingQueue：由链表结构组成的有界阻塞队列。
• PriorityBlockingQueue：支持优先级排序的无界阻塞队列。
• DelayQueue：使用优先级队列实现的无界阻塞队列。
• SynchronousQueue：不存储元素的阻塞队列。
• LinkedTransferQueue：由链表结构组成的无界阻塞队列。
• LinkedBlockingDeque：由链表结构组成的双向阻塞队列。

4.3.3　阻塞队列的实现原理

4.3.4　阻塞队列的使用场景

4.4　线程池

在编程中经常会使用线程来异步处理任务，但是每个线程的创建和销毁都需要一定的开销。如果每次 执行一个任务都需要开一个新线程去执行，则这些线程的创建和销毁将消耗大量的资源;并且线程都是“各 自为政”的，很难对其进行控制，更何况有一堆的线程在执行。这时就需要线程池来对线程进行管理。在 Java 1.5中提供了Executor框架用于把任务的提交和执行解耦，任务的提交交给Runnable或者Callable，而 Executor框架用来处理任务。Executor框架中最核心的成员就是 ThreadPoolExecutor，它是线程池的核心实现 类。

4.4.1　ThreadPoolExecutor

ThreadPoolExecutor构造方法：

public ThreadPoolExecutor(
    int corePoolSize,   //核心线程数
    int maximumPoolSize,//最大线程数
    long keepAliveTime,//非核心线程超时时间
    TimeUnit unit,//keepAliveTime参数的时间单位
    BlockingQueue<Runnable> workQueue,//任务队列
    ThreadFactory threadFactory,//线程工厂，可创建新线程
    RejectedExecutionHandler handler//饱和策略
)

4.4.2　线程池的处理流程和原理

4.4.3　线程池的种类

通过直接或者间接地配置ThreadPoolExecutor的参数可以创建不同类型的ThreadPoolExecutor，其中有 4 种线程池比较常用，它们分别是 FixedThreadPool、CachedThreadPool、SingleThreadExecutor和 ScheduledThreadPool。下面分别介绍这4种线程池。

1.FixedThreadPool

FixedThreadPool 是可重用固定线程数的线程池。

FixedThreadPool就是一个有固定数量核心线程的线程池，并且这些核心线程不会被回收。当线程数超过 corePoolSize 时，就将任务存储在任务队列中;当线程池有空闲线程时，则从任务队列中去取任务执行。

2.CachedThreadPool

CachedThreadPool是一个根据需要创建线程的线程池。CachedThreadPool 比较适于大量的需要立即处理并且耗时较少的任务。

3.SingleThreadExecutor

SingleThreadExecutor是使用单个工作线程的线程池。能确保所有的任务在一个线程中按照顺序逐一执行。

4.ScheduledThreadPool

ScheduledThreadPool是一个能实现定时和周期性任务的线程池。

4.5　AsyncTask的原理

4.6　本章小结

• 向现实世界要答案
• 没有免费的午餐
• 如何预防死锁
  1. 破坏占用且等待条件
  2. 破坏不可抢占条件
  3. 破坏循环等待条件

在上一篇文章中，我们用 Account.class 作为互斥锁，来解决银行业务里面的转账问题，虽然这个方案不存在并发问题，但是所有账户的转账操作都是串行的，性能太差。

向现实世界要答案

其实用两把锁就实现了，转出账本一把，转入账本另一把。在 transfer() 方法内部，我们首先尝试锁定转出账户 this（先把转出账本拿到手），然后尝试锁定转入账户 target（再把转入账本拿到手），只有当两者都成功时，才执行转账操作。这个逻辑可以图形化为下图这个样子。

class Account {
  private int balance;
  // 转账
  void transfer(Account target, int amt){
    // 锁定转出账户
    synchronized(this) {              
      // 锁定转入账户
      synchronized(target) {           
        if (this.balance > amt) {
          this.balance -= amt;
          target.balance += amt;
        }
      }
    }
  } 
}

没有免费的午餐

相对于用 Account.class 作为互斥锁，锁定的范围太大，我们锁定两个账户范围就小多了，这样的锁，上一章我们介绍过，叫细粒度锁。使用细粒度锁可以提高并行度，是性能优化的一个重要手段。

使用细粒度锁是有代价的，这个代价就是可能会导致死锁。

死锁的一个比较专业的定义是：一组互相竞争资源的线程因互相等待，导致“永久”阻塞的现象。

如何预防死锁

要避免死锁就需要分析死锁发生的条件，只有以下这四个条件都发生时才会出现死锁：

1. 互斥，共享资源 X 和 Y 只能被一个线程占用；
2. 占有且等待，线程 T1 已经取得共享资源 X，在等待共享资源 Y 的时候，不释放共享资源 X；
3. 不可抢占，其他线程不能强行抢占线程 T1 占有的资源；
4. 循环等待，线程 T1 等待线程 T2 占有的资源，线程 T2 等待线程 T1 占有的资源，就是循环等待。

也就是说只要我们破坏其中一个，就可以成功避免死锁的发生。其中，互斥这个条件我们没有办法破坏，因为我们用锁为的就是互斥，不过其他三个条件都是有办法破坏掉的。

1. 对于“占用且等待”这个条件，我们可以一次性申请所有的资源，这样就不存在等待了。
2. 对于“不可抢占”这个条件，占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了。
3. 对于“循环等待”这个条件，可以靠按序申请资源来预防。所谓按序申请，是指资源是有线性顺序的，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样线性化后自然就不存在循环了。

1. 破坏占用且等待条件

对于“占用且等待”这个条件，我们可以一次性申请所有的资源，这样就不存在等待了。

可以增加一个账本管理员，然后只允许账本管理员从文件架上拿账本，只有账本 A 和 B 都在的时候才会给账本申请者。

对应到编程领域，“同时申请”这个操作是一个临界区，我们也需要一个角色（Java 里面的类）来管理这个临界区，我们就把这个角色定为 Allocator。它有两个重要功能，分别是：同时申请资源 apply() 和同时释放资源 free()。

账户 Account 类里面持有一个 Allocator 的单例（必须是单例，只能由一个人来分配资源）。

当账户 Account 在执行转账操作的时候：

1. 首先向 Allocator 同时申请转出账户和转入账户这两个资源，成功后再锁定这两个资源；
2. 当转账操作执行完，释放锁之后，我们需通知 Allocator 同时释放转出账户和转入账户这两个资源。

具体的代码实现如下：

class Allocator {
  private List<Object> als =
    new ArrayList<>();
  // 一次性申请所有资源
  synchronized boolean apply(
    Object from, Object to){
    if(als.contains(from) ||
         als.contains(to)){
      return false;  
    } else {
      als.add(from);
      als.add(to);  
    }
    return true;
  }
  // 归还资源
  synchronized void free(
    Object from, Object to){
    als.remove(from);
    als.remove(to);
  }
}

class Account {
  // actr应该为单例
  private Allocator actr;
  private int balance;
  // 转账
  void transfer(Account target, int amt){
    // 一次性申请转出账户和转入账户，直到成功
    while(!actr.apply(this, target))
      ；
    try{
      // 锁定转出账户
      synchronized(this){              
        // 锁定转入账户
        synchronized(target){           
          if (this.balance > amt){
            this.balance -= amt;
            target.balance += amt;
          }
        }
      }
    } finally {
      actr.free(this, target)
    }
  } 
}

2. 破坏不可抢占条件

对于“不可抢占”这个条件，占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了。

破坏不可抢占条件看上去很简单，核心是要能够主动释放它占有的资源，这一点 synchronized 是做不到的。原因是 synchronized 申请资源的时候，如果申请不到，线程直接进入阻塞状态了，而线程进入阻塞状态，啥都干不了，也释放不了线程已经占有的资源。

后续 java.util.concurrent 这个包下面提供的 Lock 是可以解决这个问题的。

3. 破坏循环等待条件

对于“循环等待”这个条件，可以靠按序申请资源来预防。所谓按序申请，是指资源是有线性顺序的，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样线性化后自然就不存在循环了。

这个实现非常简单，我们假设每个账户都有不同的属性 id，这个 id 可以作为排序字段，申请的时候，我们可以按照从小到大的顺序来申请。比如下面代码中，①~⑥处的代码对转出账户（this）和转入账户（target）排序，然后按照序号从小到大的顺序锁定账户。

class Account {
  private int id;
  private int balance;
  // 转账
  void transfer(Account target, int amt){
    Account left = this        ①
    Account right = target;    ②
    if (this.id > target.id) { ③
      left = target;           ④
      right = this;            ⑤
    }                          ⑥
    // 锁定序号小的账户
    synchronized(left){
      // 锁定序号大的账户
      synchronized(right){ 
        if (this.balance > amt){
          this.balance -= amt;
          target.balance += amt;
        }
      }
    }
  } 
}

总结

我们今天这一篇文章主要讲了用细粒度锁来锁定多个资源时，要注意死锁的问题。这个就需要你能把它强化为一个思维定势，遇到这种场景，马上想到可能存在死锁问题。当你知道风险之后，才有机会谈如何预防和避免，因此，识别出风险很重要。

预防死锁主要是破坏三个条件中的一个，有了这个思路后，实现就简单了。但仍需注意的是，有时候预防死锁成本也是很高的。例如上面转账那个例子，我们破坏占用且等待条件的成本就比破坏循环等待条件的成本高，破坏占用且等待条件，我们也是锁了所有的账户，而且还是用了死循环 while(!actr.apply(this, target));方法，不过好在 apply() 这个方法基本不耗时。 在转账这个例子中，破坏循环等待条件就是成本最低的一个方案。

所以我们在选择具体方案的时候，还需要评估一下操作成本，从中选择一个成本最低的方案。

课后思考

我们上面提到：破坏占用且等待条件，我们也是锁了所有的账户，而且还是用了死循环 while(!actr.apply(this, target));这个方法，那它比 synchronized(Account.class) 有没有性能优势呢？

synchronized(Account.class) 锁了Account类相关的所有操作。while死循环的方式只锁定了当前操作的两个相关的对象。两种影响到的范围不同。
while循环可以加个timeout，避免一直阻塞下去。

工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。

介绍

意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
主要解决：主要解决接口选择的问题。
何时使用：我们明确地计划不同条件下创建不同实例时。
如何解决：让其子类实现工厂接口，返回的也是一个抽象的产品。
关键代码：创建过程在其子类执行。
应用实例： 1、您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。 2、Hibernate 换数据库只需换方言和驱动就可以。
优点： 1、一个调用者想创建一个对象，只要知道其名称就可以了。 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现，调用者只关心产品的接口。
缺点：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。
使用场景： 1、日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。 2、数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。 3、设计一个连接服务器的框架，需要三个协议，"POP3"、"IMAP"、"HTTP"，可以把这三个作为产品类，共同实现一个接口。
注意事项：作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。

如何实现随机访问？

什么是数组？数组（Array）是一种线性表数据结构。它用一组连续的内存空间，来存储一组具有相同类型的数据。

线性表

线性表（Linear List），顾名思义，线性表就是数据排成像一条线一样的结构。每个线性表上的数据最多只有前和后两个方向。其实除了数组，链表、队列、栈等也是线性表结构。

而与它相对立的概念是非线性表，比如二叉树、堆、图等。之所以叫非线性，是因为，在非线性表中，数据之间并不是简单的前后关系。

连续的内存空间和相同类型的数据

数组支持随机访问，根据下标随机访问的时间复杂度为 O(1)。

低效的“插入”和“删除”

插入操作：

数组有序：

• 如果在数组的末尾插入元素，需要移动数据，时间复杂度为 O(1)。
• 如果在数组的开头插入元素，所有的数据都需要依次往后移动一位，最坏时间复杂度是 O(n)。

数组无序：

• 直接将第k位的数据搬移到数组元素的最后；
• 把新的元素直接放入第k个位置。

删除操作：

跟插入数据类似，如果我们要删除第 k 个位置的数据，为了内存的连续性，也需要搬移数据。

• 如果删除数组末尾的数据，则最好情况时间复杂度为 O(1)；
• 如果删除开头的数据，则最坏情况时间复杂度为 O(n)；
• 平均情况时间复杂度也为 O(n)。

实际上，在某些特殊场景下，我们并不一定非得追求数组中数据的连续性。如果我们将多次删除操作集中在一起执行，删除的效率是不是会提高很多呢？

我们继续来看例子。数组 a[10] 中存储了 8 个元素：a，b，c，d，e，f，g，h。现在，我们要依次删除 a，b，c 三个元素。

为了避免 d，e，f，g，h 这几个数据会被搬移三次，我们可以先记录下已经删除的数据。每次的删除操作并不是真正地搬移数据，只是记录数据已经被删除。当数组没有更多空间存储数据时，我们再触发执行一次真正的删除操作，这样就大大减少了删除操作导致的数据搬移。

如果你了解 JVM，你会发现，这不就是 JVM 标记清除垃圾回收算法的核心思想吗？没错，数据结构和算法的魅力就在于此，很多时候我们并不是要去死记硬背某个数据结构或者算法，而是要学习它背后的思想和处理技巧，这些东西才是最有价值的。

警惕数组的访问越界问题

在 C 语言中，只要不是访问受限的内存，所有的内存空间都是可以自由访问的。

访问数组的本质就是访问一段连续内存，只要数组通过偏移计算得到的内存地址是可用的，那么程序就可能不会报任何错误。这种情况下，一般都会出现莫名其妙的逻辑错误。

Java会做越界检查，抛出 java.lang.ArrayIndexOutOfBoundsException。

容器能否完全替代数组？

ArrayList的优势：

1. 就是可以将很多数组操作的细节封装起来，如数组插入、删除数据时的数据搬移操作。
2. 支持动态扩容
   1. 存储空间不够的时候，空间自动扩容为 1.5 倍大小。
   2. 扩容操作涉及内存申请和数据搬移，比较耗时，如果能事先确定数据大小，最好创建时指定。

以下情况用数组会更合适些：

1. 存储基本类型。比如 int、long，需要封装为 Integer、Long 类；而拆箱、装箱有一定的性能消耗，所以如果特别关注性能，就可以选用数组。
2. 数据大小事先已知，数据操作非常简单，用不到ArrayList提供的大部分方法，也可以直接使用数组。
3. 多维数组。

总结一下，对于业务开发，直接使用容器就足够了，省时省力。毕竟损耗一丢丢性能，完全不会影响到系统整体的性能。但如果你是做一些非常底层的开发，比如开发网络框架，性能的优化需要做到极致，这个时候数组就会优于容器，成为首选。

解答开篇

为什么大多数编程语言中，数组要从 0 开始编号，而不是从 1 开始呢？

答：

1. 减少内存寻址运算。

   1. “下标”最确切的定义应该是“偏移”

   2. 如果下标为0，a[k]的内存地址计算公式为：

      a[k]_address = base_address + k * type_size

   3. 如果下标为1，a[k]的内存地址计算公式为：

      a[k]_address = base_address +(k-1)*type_size

   4. 如果从1开始编号，每次随机访问数组元素都多了一次减法运算。

2. 历史原因。

   1. C 语言设计者用 0 开始计数数组下标，之后的 Java、JavaScript 等高级语言都效仿了 C 语言。
   2. 在一定程度上减少 C 语言程序员学习 Java 的学习成本。

5.1 Context的关联类

从图中我们可以看出，ContextImpl和ContextWrapper继承自Context，ContextWrapper内部包含有Context类型的mBase对象，mBase具体指向的是ContextImpl。ContextImpl提供了很多功能，但是外界需要使用并拓展ContextImpl的功能，因此设计上使用了装饰模式，ContextWrapper是装饰类，它对ContextImpl进行包装，ContextWrapper主要是起了方法传递作用，ContextWrapper中几乎所有的方法实现都是调用ContextImpl的相应方法来实现的。ContextThemeWrapper、Service和Application都继承自ContextWrapper，这样他们都可以通过mBase来使用Context的方法，同时它们也是装饰类，在ContextWrapper的基础上又添加了不同的功能。ContextThemeWrapper中包含和主题相关的方法（比如： getTheme方法），因此，需要主题的Activity继承ContextThemeWrapper，而不需要主题的Service则继承ContextWrapper。

Context的关联类采用了装饰模式，主要有以下的优点:

• 使用者(比如Service) 能够更方便地使用Context。
• 如果ContextImpl发生了变化，它的装饰类ContextWrapper不需要做任何修改。
• ContextImpl 的实现不会暴露给使用者，使用者也不必关心ContextImpl的实现。●通过组合而非继承的方式，拓展ContextImpl的功能，在运行时选择不同的装饰类，实现不同的功能。

5.2 Application Context的创建过程

5.3 Application Context的获取过程

5.4 Activity的Context创建过程

5.5 Service的Context创建过程

5.6 本章小结

• 完美的就医流程
• 用 synchronized 实现等待 - 通知机制
• 小试牛刀：一个更好地资源分配器
• 尽量使用 notifyAll()

完美的就医流程

一个完整的等待 - 通知机制：

1. 线程首先获取互斥锁，当线程要求的条件不满足时，释放互斥锁，进入等待状态；
2. 当要求的条件满足时，通知等待的线程，重新获取互斥锁。

用 synchronized 实现等待 - 通知机制

在 Java 语言里，等待 - 通知机制可以有多种实现方式，比如 Java 语言内置的 synchronized 配合 wait()、notify()、notifyAll() 这三个方法就能轻松实现。

在下面这个图里，左边有一个等待队列，同一时刻，只允许一个线程进入 synchronized 保护的临界区（这个临界区可以看作大夫的诊室），当有一个线程进入临界区后，其他线程就只能进入图中左边的等待队列里等待（相当于患者分诊等待）。这个等待队列和互斥锁是一对一的关系，每个互斥锁都有自己独立的等待队列。

在并发程序中，当一个线程进入临界区后，由于某些条件不满足，需要进入等待状态，Java 对象的 wait() 方法就能够满足这种需求。如上图所示，当调用 wait() 方法后，当前线程就会被阻塞，并且进入到右边的等待队列中，这个等待队列也是互斥锁的等待队列。 线程在进入等待队列的同时，会释放持有的互斥锁，线程释放锁后，其他线程就有机会获得锁，并进入临界区了。

那线程要求的条件满足时，该怎么通知这个等待的线程呢？很简单，就是 Java 对象的 notify() 和 notifyAll() 方法。当条件满足时调用 notify()，会通知等待队列（互斥锁的等待队列）中的线程，告诉它条件曾经满足过。

为什么说是曾经满足过呢？因为 notify() 只能保证在通知时间点，条件是满足的。而被通知线程的执行时间点和通知的时间点基本上不会重合，所以当线程执行的时候，很可能条件已经不满足了（保不齐有其他线程插队）。

小试牛刀：一个更好地资源分配器

等待 - 通知机制的基本原理搞清楚后，我们就来看看它如何解决一次性申请转出账户和转入账户的问题吧。在这个等待 - 通知机制中，我们需要考虑以下四个要素。

1. 互斥锁：上一篇文章我们提到 Allocator 需要是单例的，所以我们可以用 this 作为互斥锁。
2. 线程要求的条件：转出账户和转入账户都没有被分配过。
3. 何时等待：线程要求的条件不满足就等待。
4. 何时通知：当有线程释放账户时就通知。

class Allocator {
  private List<Object> als;
  // 一次性申请所有资源
  synchronized void apply(
    Object from, Object to){
    // 经典写法
    while(als.contains(from) ||
         als.contains(to)){
      try{
        wait();
      }catch(Exception e){
      }   
    } 
    als.add(from);
    als.add(to);  
  }
  // 归还资源
  synchronized void free(
    Object from, Object to){
    als.remove(from);
    als.remove(to);
    notifyAll();
  }
}

尽量使用 notifyAll()

notify() 是会随机地通知等待队列中的一个线程，而 notifyAll() 会通知等待队列中的所有线程。使用 notify() 有风险，它的风险在于可能导致某些线程永远不会被通知到。

总结

等待 - 通知机制是一种非常普遍的线程间协作的方式。工作中经常看到有同学使用轮询的方式来等待某个状态，其实很多情况下都可以用今天我们介绍的等待 - 通知机制来优化。Java 语言内置的 synchronized 配合 wait()、notify()、notifyAll() 这三个方法可以快速实现这种机制，但是它们的使用看上去还是有点复杂，所以你需要认真理解等待队列和 wait()、notify()、notifyAll() 的关系。

课后思考

很多面试都会问到，wait() 方法和 sleep() 方法都能让当前线程挂起一段时间，那它们的区别是什么？

wait与sleep区别在于：
1. wait会释放所有锁而sleep不会释放锁资源；
2. wait只能在同步方法和同步块中使用，而sleep任何地方都可以；
3. wait无需捕捉异常，而sleep需要。
两者相同点：都会让渡CPU执行时间，等待再次调度！

抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。

介绍

意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
主要解决：主要解决接口选择的问题。
何时使用：系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。
如何解决：在一个产品族里面，定义多个产品。
关键代码：在一个工厂里聚合多个同类产品。
应用实例：工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。假设一种情况（现实中是不存在的，要不然，没法进入共产主义了，但有利于说明抽象工厂模式），在您的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用 OOP 的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。
优点：当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。
缺点：产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。
使用场景：1、QQ 换皮肤，一整套一起换。 2、生成不同操作系统的程序。
注意事项：产品族难扩展，产品等级易扩展。

6.1 AMS家族

6.1.1 Android 7.0的AMS家族

6.1.2 Android 8.0的AMS家族

6.2 AMS的启动过程

6.3 AMS与应用程序进程

AMS与应用程序进程的关系主要有以下两点:

• 启动应用程序时AMS会检查这个应用程序需要的应用程序进程是否存在。
• 如果需要的应用程序进程不存在，AMS就会请求Zygote进程创建需要的应用程序进程。

6.4 AMS重要的数据结构

6.4.1 解析ActivityRecord

ActivityRecord内部记录了Activity 的所有信息，因此它用来描述一个Activity， 它是在启动Activity 时被创建的，具体是在ActivityStarter 的startActivity方法中被创建的，具体可以查看4.1.2节。ActivityRecord 的部分重要成员变量如表6一1所示。

从表中可以看出ActivityRecord的作用，其内部存储了Activity 的所有信息，包括AMS的引用、AndroidManifest 节点信息、Activity 状态、Activity 资源信息和Activity 进程相关信息等，需要注意的是其中含有该ActivityRecord 所在的TaskRecord， 这就将ActivityRecord和TaskRecord关联在一起，它们是Activity 任务栈模型的重要成员，我们接着来查看TaskRecord。

6.4.2 解析TaskRecord

从表中可以发现TaskRecord的作用，其内部存储了任务栈的所有信息，包括任务栈的唯一标识符、任务栈的倾向性、任务栈中的Activity记录和AMS的引用等，需要注意的是其中含有ActivityStack,也就是当前Activity 任务栈所归属的ActivityStack,我们接着来查看ActivityStack。

6.4.3 解析ActivityStack

ActivityStack是一个管理类，用来管理系统所有Activity的各种状态，其内部维护了TaskRecord的列表，因此从Activity任务栈这一角度来说，ActivityStack也可以理解为Activity堆栈。它由ActivityStackSupervisor来进行管理的，而ActivityStackSupervisor在AMS中的构造方法中被创建。

ActivityStack的实例类型

```
public final class ActivityStackSupervisor implements DisplayListener {
   ...
    //用来存储Launcher App的所有Activity
    ActivityStack mHomeStack;

    //表示当前正在接收输入或启动下一个Activity的所有Activity
    ActivityStack mFocusedStack; 

    //表示此前接收输入的所有Activity。
    private ActivityStack mLastFocusedStack;
    ...
}
```

ActivityState

• ActivityStack中通过枚举存储了Activity的所有的状态：

  enum ActivityState {
         INITIALIZING,
  
         RESUMED,
  
         PAUSING,
  
         PAUSED,
  
         STOPPING,
  
         STOPPED,
  
         FINISHING,
  
         DESTROYING,
  
         DESTROYED
  
  }
  

特殊状态的Activity

• 这些特殊的状态都是ActivityRecord类型的，ActivityRecord用来记录一个Activity的所有信息。

  ActivityRecord mPausingActivity = null;//正在暂停的Activity
  ActivityRecord mLastPausedActivity = null;//上一个已经暂停的Activity
  
  ActivityRecord mLastNoHistoryActivity = null;//最近一次没有历史记录的Activity
  
  ActivityRecord mResumedActivity = null;//已经Resume的Activity
  
  ActivityRecord mLastStartedActivity = null;//最近一次启动的Activity
  
  ActivityRecord mTranslucentActivityWaiting = null;//传递给convertToTranslucent方法的最上层的Activity
  

维护的ArrayList

• ActivityStack中维护了很多ArrayList，这些ArrayList中的元素类型主要有ActivityRecord和TaskRecord，其中TaskRecord用来记录Activity的Task。

6.5 Activity栈管理

Activity栈：存储和管理Activity。

6.5.1 Activity任务栈模型

• ActivityRecord用来记录一个Activity 的所有信息
• TaskRecord 中包含了一个或多个ActivityRecord, TaskRecord 用来表示Activity 的任务栈，用来管理栈中的ActivityRecord
• ActivityStack又包含了一个或多个TaskRecord,它是TaskRecord的管理者。Activity 栈管理就是建立在Activity 任务栈模型之上的

有了栈管理，我们可以对应用程序进行操作，应用可以复用自身应用中以及其他应用的Activity, 节省了资源。

6.5.2 Launch Mode

• standerd：默认模式，每次启动Activity都会创建一个新的Activity实例。
• singleTop：如果要启动的Activity已经在栈顶，则不会重新创建Activity，同时该Activity的onNewIntent方法会被调用。如果要启动的Activity不在栈顶，则会重新创建该Activity的实例。
• singleTask：如果要启动的Activity已经存在于它想要归属的栈中，那么不会创建该Activity实例，将栈中位于该Activity上的所有的Activity出栈，同时该Activity的onNewIntent方法会被调用。如果要启动的Activity不存在于它想要归属的栈中，并且该栈存在，则会重新创建该Activity的实例。如果要启动的Activity想要归属的栈不存在，则首先要创建一个新栈，然后创建该Activity实例并压入到新栈中。
• singleInstance：和singleTask基本类似，不同的是启动Activity时，首先要创建在一个新栈，然后创建该Activity实例并压入新栈中，新栈中只会存在这一个Activity实例。

6.5.3 Intent的FLAG

• FLAG_ACTIVITY_NO_HISTORY：Activity一旦退出，就不会存在于栈中。同样的，也可以在AndroidManifest.xml中设置“android:noHistory”。
• FLAG_ACTIVITY_MULTIPLE_TASK：需要和FLAG_ACTIVITY_NEW_TASK一同使用才有效果，系统会启动一个新的栈来容纳新启动的Activity.
• FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS：Activity不会被放入到“最近启动的Activity”列表中。
• FLAG_ACTIVITY_BROUGHT_TO_FRONT：这个标志位通常不是由应用程序中的代码设置的，而是Launch Mode为singleTask时，由系统自动加上的。
• FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY：这个标志位通常不是由应用程序中的代码设置的，而是从历史记录中启动的（长按Home键调出）。
• FLAG_ACTIVITY_CLEAR_TASK：需要和FLAG_ACTIVITY_NEW_TASK一同使用才有效果，用于清除与启动的Activity相关栈的所有其他Activity。

6.5.4 taskAffinity

我们可以在AndroidManifest.xml设置android:taskAffinity，用来指定Activity希望归属的栈， 默认情况下，同一个应用程序的所有的Activity都有着相同的taskAffinity。taskAffinity在下面两种情况时会产生效果：

• askAffinity与FLAG_ACTIVITY_NEW_TASK或者singleTask配合。如果新启动Activity的taskAffinity和栈的taskAffinity相同（栈的taskAffinity取决于根Activity的taskAffinity）则加入到该栈中。如果不同，就会创建新栈。
• taskAffinity与allowTaskReparenting配合。如果allowTaskReparenting为true，说明Activity具有转移的能力。

6.6 本章小结

6.1　设计模式六大原则

设计模式的六大原则，它们分别是单一职责原则、开放封闭原
则、里氏替换原则、依赖倒置原则、迪米特原则和接口隔离原则。

• S 单一职责原则定义：就一个类而言，应该仅有一个引起它变化的原因。
• O 开放封闭原则定义：类、模块、函数等应该是对于拓展是开放，对于修改是封闭。
• L 里氏替换原则定义：所有引用基类(父类)的地方必须能透明地使用其子类的对象。
• I 接口隔离原则定义：一个类对另一个类的依赖应该建立在最小的接口上。
• D 依赖倒置原则定义：高层模块不应该依赖低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
• 迪米特原则定义：一个软件实体应当尽可能少地与其他实体发生相互作用。

6.2　设计模式分类

GoF提出的设计模式总共有23种，根据目的准则分类，分为三大类。

• 创建型设计模式，共5种:单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。
• 结构型设计模式，共7种:适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享 元模式。
• 行为型设计模式，共11种:策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令 模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

6.3　创建型设计模式

6.3.1　单例模式

6.3.2　简单工厂模式

6.3.3　工厂方法模式

6.3.4　建造者模式

6.4　结构型设计模式

6.4.1　代理模式

6.4.2　装饰模式

6.4.3　外观模式

6.4.4　享元模式

6.5　行为型设计模式

6.5.1　策略模式

6.5.2　模板方法模式

6.5.3　观察者模式

6.6　本章小结

数组和链表的区别

从底层的存储结构上看一下数组和链表的区别：

数组需要一块连续的内存空间来存储，对内存的要求比较高。
链表并不需要一块连续的内存空间，它通过“指针”将一组零散的内存块串联起来使用。

常见的链表结构：单链表、双向链表和循环链表。

单链表

链表通过指针将一组零散的内存块串联在一起。其中，我们把内存块称为链表的“结点”。为了将所有的结点串起来，每个链表的结点除了存储数据之外，还需要记录链上的下一个结点的地址。如图所示，我们把这个记录下个结点地址的指针叫作后继指针next。

我们习惯性地把第一个结点叫作头结点，把最后一个结点叫作尾结点。其中，头结点用来记录链表的基地址，尾结点指针指向一个空地址NULL。

链表的插入和删除操作，只需要考虑相邻结点的指针改变，所以对应的时间复杂度是O(1)。

链表要想随机访问第k个元素，需要根据指针一个结点一个结点地依次遍历，直到找到相应的结点，需要O(n)的时间复杂度。

循环链表

循环链表是一种特殊的单链表，它的尾结点指针是指向链表的头结点。

和单链表相比，循环链表的优点是从链尾到链头比较方便。当要处理的数据具有环型结构特点时，就特别适合采用循环链表。

双向链表

双向链表，它支持两个方向，每个结点不止有一个后继指针next指向后面的结点，还有一个前驱指针prev指向前面的结点。

双向链表需要额外的两个空间来存储后继结点和前驱结点的地址。

双向链表适合解决哪种问题呢？

• 从结构上来看，双向链表可以支持O(1)时间复杂度的情况下找到前驱结点，正是这样的特点，也使双向链表在某些情况下的插入、删除等操作都要比单链表简单、高效。

在实际的软件开发中，从链表中删除一个数据无外乎这两种情况：

• 删除结点中“值等于某个给定值”的结点；
• 删除给定指针指向的结点。

对于第一种情况，不管是单链表还是双向链表，都需要从头结点开始一个一个依次遍历对比，直到找到值等于给定值的结点，然后再通过指针操作将其删除。删除操作时间复杂度是O(1)，但遍历查找的时间复杂度为O(n)，所以总时间复杂度为O(n)。

对于第二种情况，因为双向链表中的结点已经保存了前驱结点的指针，不需要像单链表那样遍历。所以，针对第二种情况，单链表删除操作需要O(n)的时间复杂度，而双向链表只需要在O(1)的时间复杂度内！

插入同理。双向链表的按值查询的效率也要比单链表高一些。

LinkedHashMap其中就用到了双向链表。

链表VS数组性能大比拼

数组简单易用，在实现上使用的是连续的内存空间，可以借助CPU的缓存机制，预读数组中的数据，所以访问效率更高。而链表在内存中并不是连续存储，所以对CPU缓存不友好，没办法有效预读。

链表与数组最大的区别：

• 数组的缺点是大小固定
• 链表本身没有大小的限制，天然地支持动态扩容。

解答开篇
如何基于链表实现LRU缓存淘汰算法？

思路：
维护一个有序单链表，越靠近链表尾部的结点是越早之前访问的。当有一个新的数据被访问时，我们从链表头开始顺序遍历链表。

1. 如果此数据已经被缓存在链表中，遍历、删除这个数据对应的结点，然后再插入到链表头部。
2. 如果此数据没有在缓存链表中，又可以分为两种情况：
   1. 缓存未满，插入到链表头部；
   2. 缓存已满，删除链表尾结点，将新数据结点插入链表头部。

因为需要遍历链表，所以时间复杂度为O(n)。

• 安全性问题
• 活跃性问题
• 性能问题

并发编程中我们需要注意的问题有很多，主要有三个方面，分别是：安全性问题、活跃性问题和性能问题。

安全性问题

什么是线程安全？其实本质上就是正确性，而正确性的含义就是程序按照我们期望的执行。

那如何才能写出线程安全的程序呢？理论上线程安全的程序，就要避免出现原子性问题、可见性问题和有序性问题。

那是不是所有的代码都需要认真分析一遍是否存在这三个问题呢？当然不是，其实只有一种情况需要：存在共享数据并且该数据会发生变化，通俗地讲就是有多个线程会同时读写同一数据。

当多个线程同时访问同一数据，并且至少有一个线程会写这个数据的时候，如果我们不采取防护措施，那么就会导致并发 Bug，对此还有一个专业的术语，叫做数据竞争（Data Race）。

竞态条件（Race Condition），指的是程序的执行结果依赖线程执行的顺序。

在并发场景中，程序的执行依赖于某个状态变量，当某个线程发现状态变量满足执行条件后，开始执行操作；可是就在这个线程执行操作的时候，其他线程同时修改了状态变量，导致状态变量不满足执行条件了。

那面对数据竞争和竞态条件问题，又该如何保证线程的安全性呢？其实这两类问题，都可以用互斥这个技术方案，而实现互斥的方案有很多，CPU 提供了相关的互斥指令，操作系统、编程语言也会提供相关的 API。从逻辑上来看，我们可以统一归为：锁。

活跃性问题

所谓活跃性问题，指的是某个操作无法执行下去。我们常见的“死锁”就是一种典型的活跃性问题，当然除了死锁外，还有两种情况，分别是“活锁”和“饥饿”。

有时线程虽然没有发生阻塞，但仍然会存在执行不下去的情况，这就是所谓的“活锁”。可以类比现实世界里的例子，路人甲从左手边出门，路人乙从右手边进门，两人为了不相撞，互相谦让，路人甲让路走右手边，路人乙也让路走左手边，结果是两人又相撞了。这种情况，基本上谦让几次就解决了，因为人会交流啊。

解决“活锁”的方案很简单，谦让时，尝试等待一个随机的时间就可以了。

那“饥饿”该怎么去理解呢？所谓“饥饿”指的是线程因无法访问所需资源而无法执行下去的情况。如果线程优先级“不均”，在 CPU 繁忙的情况下，优先级低的线程得到执行的机会很小，就可能发生线程“饥饿”；持有锁的线程，如果执行的时间过长，也可能导致“饥饿”问题。

解决“饥饿”问题的方案很简单，有三种方案：一是保证资源充足，二是公平地分配资源，三就是避免持有锁的线程长时间执行。这三个方案中，方案一和方案三的适用场景比较有限，因为很多场景下，资源的稀缺性是没办法解决的，持有锁的线程执行的时间也很难缩短。倒是方案二的适用场景相对来说更多一些。

那如何公平地分配资源呢？在并发编程里，主要是使用公平锁。所谓公平锁，是一种先来后到的方案，线程的等待是有顺序的，排在等待队列前面的线程会优先获得资源。

性能问题

使用“锁”要非常小心，但是如果小心过度，也可能出“性能问题”。“锁”的过度使用可能导致串行化的范围过大，这样就不能够发挥多线程的优势了，而我们之所以使用多线程搞并发程序，为的就是提升性能。

使用锁的时候一定要关注对性能的影响。 那怎么才能避免锁带来的性能问题呢？这个问题很复杂，Java SDK 并发包里之所以有那么多东西，有很大一部分原因就是要提升在某个特定领域的性能。

不过从方案层面，我们可以这样来解决这个问题：

第一，既然使用锁会带来性能问题，那最好的方案自然就是使用无锁的算法和数据结构了。在这方面有很多相关的技术，例如线程本地存储 (Thread Local Storage, TLS)、写入时复制 (Copy-on-write)、乐观锁等；Java 并发包里面的原子类也是一种无锁的数据结构；Disruptor 则是一个无锁的内存队列，性能都非常好……

第二，减少锁持有的时间。互斥锁本质上是将并行的程序串行化，所以要增加并行度，一定要减少持有锁的时间。这个方案具体的实现技术也有很多，例如使用细粒度的锁，一个典型的例子就是 Java 并发包里的 ConcurrentHashMap，它使用了所谓分段锁的技术（这个技术后面我们会详细介绍）；还可以使用读写锁，也就是读是无锁的，只有写的时候才会互斥。

性能方面的度量指标有很多，我觉得有三个指标非常重要，就是：吞吐量、延迟和并发量。

• 吞吐量：指的是单位时间内能处理的请求数量。吞吐量越高，说明性能越好。
• 延迟：指的是从发出请求到收到响应的时间。延迟越小，说明性能越好。
• 并发量：指的是能同时处理的请求数量，一般来说随着并发量的增加、延迟也会增加。所以延迟这个指标，一般都会是基于并发量来说的。例如并发量是 1000 的时候，延迟是 50 毫秒。

总结

并发编程是一个复杂的技术领域，微观上涉及到原子性问题、可见性问题和有序性问题，宏观则表现为安全性、活跃性以及性能问题。

我们在设计并发程序的时候，主要是从宏观出发，也就是要重点关注它的安全性、活跃性以及性能。安全性方面要注意数据竞争和竞态条件，活跃性方面需要注意死锁、活锁、饥饿等问题，性能方面我们虽然介绍了两个方案，但是遇到具体问题，你还是要具体分析，根据特定的场景选择合适的数据结构和算法。

课后思考

Java 语言提供的 Vector 是一个线程安全的容器，有同学写了下面的代码，你看看是否存在并发问题呢？

void addIfNotExist(Vector v, 
    Object o){
  if(!v.contains(o)) {
    v.add(o);
  }
}

答：vector是线程安全，指的是它方法单独执行的时候没有并发正确性问题，并不代表把它的操作组合在一起没有问题，而这个程序显然有老师讲的竞态条件问题。
老师：你需要将共享变量 v 封装在对象的内部，而后控制并发访问的路径，这样就能有效防止对 Vector v 变量的滥用，从而导致并发问题。

class SafeVector{
  private Vector v; 
  // 所有公共方法增加同步控制
  synchronized 
  void addIfNotExist(Object o){
    if(!v.contains(o)) {
      v.add(o);
    }
  }
}

为了简化并且更加高质量地在Activity、Fragment、Thread和Service等之间的通信，同时解决组件之间 高耦合的同时仍能继续高效地通信，事件总线设计出现了。

7.1　解析EventBus

EventBus是一款针对Android优化的发布-订阅事件总线。它简化了应用程序内各组件间、组件与后台线 程间的通信。其优点是开销小，代码更优雅，以及将发送者和接收者解耦。

7.1.1　使用EventBus

EventBus的三要素如下。

• Event：事件。
  • 可以是任意类型的对象。
• Subscriber：事件订阅者。
  • 在 EventBus 3.0 之前消息处理的方法只能限定于 onEvent、 onEventMainThread、onEventBackgroundThread和onEventAsync，它们分别代表4种线程模型。
  • 而在EventBus 3.0之后，事件处理的方法可以随便取名，但是需要添加一个注解@Subscribe，并且要指定线程模型(默认 为POSTING)。4种线程模型下面会讲到。
• Publisher：事件发布者。
  • 可以在任意线程任意位置发送事件， 直接调用 EventBus 的post(Object)方法。可以自己实例化EventBus对象，但一般使用 EventBus.getDefault()就可以。根据post函数参数的类型，会自动调用订阅相应类型事件的函数。

EventBus的4种ThreadMode(线程模型)如下。

• POSTING(默认)：
  • 如果使用事件处理函数指定了线程模型为POSTING，那么该事件是在哪个线程 发布出来的，事件处理函数就会在哪个线程中运行，也就是说发布事件和接收事件在同一个线程中。在线 程模型为POSTING的事件处理函数中尽量避免执行耗时操作，因为它会阻塞事件的传递，甚至有可能会引 起ANR。
• MAIN：
  • 事件的处理会在UI线程中执行。事件处理的时间不能太长，长了会导致ANR。
• BACKGROUND：
  • 如果事件是在UI线程中发布出来的，那么该事件处理函数就会在新的线程中运行; 如果事件本来就是在子线程中发布出来的，那么该事件处理函数直接在发布事件的线程中执行。在此事件 处理函数中禁止进行UI更新操作。
• ASYNC：
  • 无论事件在哪个线程中发布，该事件处理函数都会在新建的子线程中执行;同样，此事件 处理函数中禁止进行UI更新操作。

EventBus基本用法
(1)自定义一个事件类
(2)在需要订阅事件的地方注册事件
EventBus.getDefault().register(this);
(3)发送事件
EventBus.getDefault().post(messageEvent);
(4)处理事件
(5)取消事件订阅
EventBus.getDefault().unregister(this);

EventBus的黏性事件
除了上面讲的普通事件外，EventBus还支持发送黏性事件，就是在发送事件之后再订阅该事件也能收到该事件，这跟黏性广播类似。
(1)订阅者处理黏性事件 sticky = true
(2)发送黏性事件
EventBus.getDefault().postSticky(new MessageEvent ("黏性事件")) ;

7.1.2　源码解析EventBus

7.2　解析otto

7.2.1　使用otto

7.2.2　源码解析otto

7.1 Window、WindowManager和WMS

• Window是一个抽象类，具体的实现类为PhoneWindow,它对View进行管理。
• WindowManager 是一个接口类，继承自接口ViewManager，它是用来管理Window的，它的实现类为WindowManagerImpl。如果我们]想要对Window (View)进行添加、更新和删除操作就可以使用WindowManager,。
• WindowManager 会将具体的工作交由WMS来处理，WindowManager 和WMS通过Binder来进行跨进程通信，WMS作为系统服务有很多API是不会暴露给WindowManager的，这一点与ActivityManager和AMS的关系有些类似。

Window包含了View并对View进行管理，Window用虚线来表示是因为Window是一个抽象概念，用来描述一个窗口，并不是真实存在的，Window 的实体其实也是View。WindowManager用来管理Window,而WindowManager所提供的功能最终会由WMS进行处理。

7.2 WindowManager的关联类

7.3 Window的属性

7.3.1 Window的类型和显示次序

Window的类型总体来说分为三大类：

• Application Window（应用程序窗口）
• Sub Window（子窗口）
• System Window（系统窗口）

应用程序窗口

public static final int FIRST_APPLICATION_WINDOW = 1;//1
public static final int TYPE_BASE_APPLICATION   = 1;//窗口的基础值，其他的窗口值要大于这个值
public static final int TYPE_APPLICATION        = 2;//普通的应用程序窗口类型
public static final int TYPE_APPLICATION_STARTING = 3;//应用程序启动窗口类型，用于系统在应用程序窗口启动前显示的窗口。
public static final int TYPE_DRAWN_APPLICATION = 4;
public static final int LAST_APPLICATION_WINDOW = 99;//2

应用程序窗口的Type值范围为1到99。

子窗口

子窗口，不能独立的存在，需要附着在其他窗口才可以，PopupWindow就属于子窗口。子窗口的Type值范围为1000到1999。

系统窗口
Toast、输入法窗口、系统音量条窗口、系统错误窗口都属于系统窗口。系统窗口的类型定义如下所示：系统窗口的类型值有接近40个，这里只列出了一小部分， 系统窗口的Type值范围为2000到2999。

窗口显示次序

当一个进程向WMS申请一个窗口时，WMS会为窗口确定显示次序。为了方便窗口显示次序的管理，手机屏幕可以虚拟的用X、Y、Z轴来表示，其中Z轴垂直于屏幕，从屏幕内指向屏幕外，这样确定窗口显示次序也就是确定窗口在Z轴上的次序，这个次序称为Z-Oder。Type值是Z-Oder排序的依据，我们知道应用程序窗口的Type值范围为1到99，子窗口1000到1999 ，系统窗口 2000到2999，，一般情况下，Type值越大则Z-Oder排序越靠前，就越靠近用户。

7.3.2 Window的标志

Window的标志也就是Flag，用于控制Window的显示，同样被定义在WindowManager的内部类LayoutParams中。

设置Window的Flag有三种方法：

• 第一种是通过Window的addFlags方法；
• 第二种通过Window的setFlags方法；
• 第三种则是给LayoutParams设置Flag，并通过WindowManager的addView方法进行添加。

7.3.3 软键盘相关模式

为了使得软键盘窗口能够按照期望来显示，WindowManager的静态内部类LayoutParams中定义了软键盘相关模式：

设置SoftInputMode：

• AndroidManifest中Activity的属性android:windowSoftInputMode；
• Java代码getWindow().setSoftInputMode。

7.4 Window的操作

对于Window的操作，最终都是交由WMS来进行处理。窗口的操作分为两大部分，一部分是WindowManager处理部分，另一部分是WMS处理部分。

7.4.1 系统窗口的添加过程

7.4.2 Activity的添加过程

1. Activity 在启动过程中，如果Activity所在的进程不存在则会创建新的进程，创建新的进程之后就会运行代表主线程的实例ActivityThread；
2. 当界面要与用户进行交互时，会调用ActivityThread 的handleResumeActivity方法；
3. performResumeActivity方法最终会调用Activity 的onResume方法；
4. 得到ViewManager类型的对象后，调用了ViewManager 的addView方法，而addView方法则是在WindowManagerImpl中实现的，addView方法的第一个参数为DecorView。

7.4.3 Window的更新过程

Window的更新过程和Window的添加过程是类似的。

1. 调用ViewManager的updateViewLayout方法，updateViewLayout 方法在WindowManagerImpl 中实现，WindowManagerImpl的updateViewLayout方法会调用WindowManagerGlobal的updateViewI ayout方法
2. 更新的参数设置到View中，得到要更新的窗口在View列表中的索引在ViewRootImpl列表中根据索引得到窗口的ViewRootlmpl，更新布局参数列表，调用ViewRootImpl的setLayoutParams方法将更新的参数设置到ViewRootImpl 中，ViewRootImpl的setLayoutParams 方法在最后会调用ViewRootImpl的scheduleTraversals方法。
3. 在TraversalRunnable的run方法中调用了doTraversal方法，在doTraversal方法中又调用了performTraversals 方法，performTraversals 方法使得ViewTree开始View的工作流程：
   1. relayoutWindow方法内部会调用IWindowSession 的relayout方法来更新Window视图，最终会调用WMS的relayoutWindow方法。
   2. performTraversals 方法分别调用performMeasure、performLayout和performDraw方法,它们的内部又会调用View的measure、layout和draw方法，这样就完成了View 的工作流程。
4. 在performTraversals方法中更新了Window视图，又执行Window中的View的工作流程，这样就完成了Window 的更新。

7.5 本章小结

算法的封装与切换——策略模式

在策略模式（Strategy Pattern）中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。
在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。

介绍

意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
主要解决：在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。
何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。
如何解决：将这些算法封装成一个一个的类，任意地替换。
关键代码：实现同一个接口。
应用实例： 1、诸葛亮的锦囊妙计，每一个锦囊就是一个策略。 2、旅行的出游方式，选择骑自行车、坐汽车，每一种旅行方式都是一个策略。 3、JAVA AWT 中的 LayoutManager。
优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。
缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。
使用场景： 1、如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。 2、一个系统需要动态地在几种算法中选择一种。 3、如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。
注意事项：如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。

7.1 概述

虚拟机如何加载Class文件？Class文件中的信息进入虚拟机中会发生什么变化？

虚拟机把描述类的数据从Class文件加载到内存，并对内存进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的java类型，这就是虚拟机的类加载机制。

Java语言中，类型的加载、连接和初始化过程都是在程序运行期间完成的。Java可以动态扩展语言特性就是依赖运行期动态加载和动态连接实现的。

7.2 类加载的时机

类的生命周期：加载、验证、准备、解析、初始化、使用、卸载。
验证、准备、解析三个阶段称为连接。
其中，加载、验证、准备、初始化和卸载5个阶段是确定的，解析阶段则不一定：这是为了支持Java语言的运行时绑定。

对于初始化节点，虚拟机规范严格规定了有且只有5种情况必须对类进行“初始化”（加载、验证、准备自然在此之前开始）：

1. 遇到new，getstatic，putstatic或invokestatic这4条字节码指令
2. 使用java.lang.reflect包的方法对类进行反射调用
3. 当初始化一个类的时候，发现其父类还没有进行过初始化，则需要先出发父类的初始化。
4. 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
5. 当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic,REF_putStatic,REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先出发初始化。

以上5种触发类初始化的行为成为主动引用，除此之外，所有引用类的方式都不会触发初始化，称为被动引用。

7.3 类加载的过程

7.3.1 加载

1. 通过一个类的全限定名来获取定义此类的二进制字节流
2. 将这个字节流所代表的静态存储结构转换为方法区内的运行时数据结构
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

7.3.2 验证

验证是连接阶段的第一步，目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

1. 文件格式验证
   • 验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。
2. 元数据验证
   • 对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范要求。例如是否有父类、是否继承了不允许继承的类、是否实现了父类或接口中要求实现的所有方法等。
3. 字节码验证
   • 最复杂，通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。上个阶段校验数据类型，这个分析类的方法体，确保方法运行时不会危害虚拟机。例如操作栈放置int使用时却按long加载入本地变量表中等 。
4. 符号引用验证
   • 发生在虚拟机将符号引用转换为直接引用的时候，这个转换动作将在连接的第三个阶段——解析阶段中发生。

7.3.3 准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段。这些变量所使用的内存都将在方法区中分配。注意：内存分配仅包括类变量（static修饰）。
如果类字段的字段属性表中存在ConstantValue属性，那么在准备阶段变量的值就会被初始化为ConstantValue属性所指定的值。

7.3.4 解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

• 符号引用：以一组符号来描述所引用的目标,可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。
• 直接引用：可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。

虚拟机规范并未规定解析阶段发生的具体时间，所以虚拟机可以根据需要来判断到底是在类被加载器加载时就对常量池中的符号进行解决，还是等到一个符号引用被使用前才解析它。

invokedynamic指令用于支持动态语言支持，即程序运行到这条指令时，解析动作才能进行。

解析动作主要针对接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。

7.3.5 初始化

初始化阶段，才真正开始执行类中定义的Java程序代码。
初始化阶段，根据程序员通过程序制定的主观计划，去初始化变量和其他资源。初始化阶段是执行类构造器<clinit>()方法的过程：

• <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的。
• <clinit>()与类的构造函数不同，它不需要显示地调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。
• 由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优于子类的变量赋值操作。
• <clinit>()方法对于类或接口并不是必须的。
• 虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步。

7.4 类加载器

类加载器：通过一个类的全限定名来获取描述此类的二进制字节流。

7.4.1 类与类加载器

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确定其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。即比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义。类加载器不同，类必定不相等。

7.4.2 双亲委派模型

• 系统类加载器
  • Bootstrap ClassLoader
  • Extensions ClassLoader
  • Application ClassLoader
• 自定义类加载器

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

双亲委派模型的好处：Java类随着它的类加载器一起具备了一种带有优先级的层次关系。
双亲委派模型的实现：java.lang.ClassLoader的loadClass()方法。

7.4.3 破坏双亲委派模型

1. JDK1.2之前使用loadClass()，之后使用findClass()
2. 基础类调用用户的代码。如JDBC。解决：线程上下文类加载器（Thread Context ClassLoader）。
3. 用户追求动态性，如代码热替换，模块热部署等。

7.5 本章小结

几个写链表代码技巧：

1. 技巧一：理解指针或引用的含义
2. 技巧二：警惕指针丢失和内存泄漏
3. 技巧三：利用哨兵简化实现难度
4. 技巧四：重点留意边界条件处理
5. 技巧五：举例画图，辅助思考
6. 技巧六：多写多练，没有捷径

技巧一：理解指针或引用的含义

指针：将某个变量赋值给指针，实际上就是将这个变量的地址赋值给指针，或者反过来说，指针中存储了这个变量的内存地址，指向了这个变量，通过指针就能找到这个变量。

技巧二：警惕指针丢失和内存泄漏

C语言中，插入结点时，一定要注意操作的顺序；删除链表结点时，一定要记得手动释放内存空间。

技巧三：利用哨兵简化实现难度

针对链表的插入、删除操作，需要对插入第一个结点和删除最后一个结点的情况进行特殊处理。

技巧四：重点留意边界条件处理

常用来检查链表代码是否正确的边界条件有这样几个：

• 如果链表为空时，代码是否能正常工作？
• 如果链表只包含一个结点时，代码是否能正常工作？
• 如果链表只包含两个结点时，代码是否能正常工作？
• 代码逻辑在处理头结点和尾结点的时候，是否能正常工作？

技巧五：举例画图，辅助思考

技巧六：多写多练，没有捷径

常见的链表操作：

• 单链表反转
• 链表中环的检测
• 两个有序的链表合并
• 删除链表倒数第n个结点
• 求链表的中间结点

• 什么是管程
• MESA 模型
• wait() 的正确姿势
• notify() 何时可以使用

什么是管程

管程和信号量是等价的，所谓等价指的是用管程能够实现信号量，也能用信号量实现管程。

管程，指的是管理共享变量以及对共享变量的操作过程，让他们支持并发。

MESA 模型

在管程的发展史上，先后出现过三种不同的管程模型，分别是：Hasen 模型、Hoare 模型和 MESA 模型。其中，现在广泛应用的是 MESA 模型，并且 Java 管程的实现参考的也是 MESA 模型。所以今天我们重点介绍一下 MESA 模型。

在并发编程领域，有两大核心问题：一个是互斥，即同一时刻只允许一个线程访问共享资源；另一个是同步，即线程之间如何通信、协作。这两大问题，管程都是能够解决的。

管程是如何解决互斥问题的

管程解决互斥问题的思路很简单，就是将共享变量及其对共享变量的操作统一封装起来。在下图中，管程 X 将共享变量 queue 这个队列和相关的操作入队 enq()、出队 deq() 都封装起来了；线程 A 和线程 B 如果想访问共享变量 queue，只能通过调用管程提供的 enq()、deq() 方法来实现；enq()、deq() 保证互斥性，只允许一个线程进入管程。

管程如何解决线程间的同步问题?

在管程模型里，共享变量和对共享变量的操作是被封装起来的，图中最外层的框就代表封装的意思。框的上面只有一个入口，并且在入口旁边还有一个入口等待队列。当多个线程同时试图进入管程内部时，只允许一个线程进入，其他线程则在入口等待队列中等待。这个过程类似就医流程的分诊，只允许一个患者就诊，其他患者都在门口等待。管程里还引入了条件变量的概念，而且每个条件变量都对应有一个等待队列，如下图，条件变量 A 和条件变量 B 分别都有自己的等待队列。

那条件变量和等待队列的作用是什么呢？其实就是解决线程同步问题。

public class BlockedQueue<T>{
  final Lock lock =
    new ReentrantLock();
  // 条件变量：队列不满  
  final Condition notFull =
    lock.newCondition();
  // 条件变量：队列不空  
  final Condition notEmpty =
    lock.newCondition();

  // 入队
  void enq(T x) {
    lock.lock();
    try {
      while (队列已满){
        // 等待队列不满 
        notFull.await();
      }  
      // 省略入队操作...
      //入队后,通知可出队
      notEmpty.signal();
    }finally {
      lock.unlock();
    }
  }
  // 出队
  void deq(){
    lock.lock();
    try {
      while (队列已空){
        // 等待队列不空
        notEmpty.await();
      }
      // 省略出队操作...
      //出队后，通知可入队
      notFull.signal();
    }finally {
      lock.unlock();
    }  
  }
}

wait() 的正确姿势

但是有一点，需要再次提醒，对于 MESA 管程来说，有一个编程范式，就是需要在一个 while 循环里面调用 wait()。这个是 MESA 管程特有的。

while(条件不满足) {
  wait();
}

notify() 何时可以使用

还有一个需要注意的地方，就是 notify() 和 notifyAll() 的使用，前面章节，我曾经介绍过，除非经过深思熟虑，否则尽量使用 notifyAll()。那什么时候可以使用 notify() 呢？需要满足以下三个条件：

1. 所有等待线程拥有相同的等待条件；
2. 所有等待线程被唤醒后，执行相同的操作；
3. 只需要唤醒一个线程。

总结

Java 参考了 MESA 模型，语言内置的管程（synchronized）对 MESA 模型进行了精简。MESA 模型中，条件变量可以有多个，Java 语言内置的管程里只有一个条件变量。具体如下图所示。

Java 内置的管程方案（synchronized）使用简单，synchronized 关键字修饰的代码块，在编译期会自动生成相关加锁和解锁的代码，但是仅支持一个条件变量；而 Java SDK 并发包实现的管程支持多个条件变量，不过并发包里的锁，需要开发人员自己进行加锁和解锁操作。

并发编程里两大核心问题——互斥和同步，都可以由管程来帮你解决。学好管程，理论上所有的并发问题你都可以解决，并且很多并发工具类底层都是管程实现的，所以学好管程，就是相当于掌握了一把并发编程的万能钥匙。

课后思考

wait() 方法，在 Hasen 模型和 Hoare 模型里面，都是没有参数的，而在 MESA 模型里面，增加了超时参数，你觉得这个参数有必要吗？

有hasen 是执行完，再去唤醒另外一个线程。能够保证线程的执行。hoare，是中断当前线程，唤醒另外一个线程，执行玩再去唤醒，也能够保证完成。而mesa是进入等待队列，不一定有机会能够执行。

函数式编程是一种编程范式。我们常见的编程范式有命令式编程、函数式编程和逻辑式编程。我们常见的面向对象编程是一种命令式编程。命令式编程是面向计算机硬件的抽象，有变量、赋值语句、表达式和控制语句。而函数式编程是面向数学的抽象，将计算描述为一种表达式求值，函数可以在任何地方定 义，并且可以对函数进行组合。
响应式编程是一种面向数据流和变化传播的编程范式，数据更新是相关联的。把函数式编程里的一套思路和响应式编程合起来就是函数响应式编程。
函数响应式编程可以极大地简化项目，特别是处理嵌套回调的异步事件、复杂的列表过滤和变换或者 时间相关问题。在 Android 开发中使用函数响应式编程的主要有两大框架:一个是RxJava，另一个是Goodle 推出的Agera。

8.1　RxJava基本用法

8.1.1　RxJava概述

1.ReactiveX与RxJava

RxJava是ReactiveX的一种Java实现。 Rx是一个函数库，让开发者可以利用可观察序列和LINQ风格查询操作符来编写异步和基于事件的程序。开发者可以用Observables表示异步数据流，用LINQ操作符查询异步数据流，用Schedulers参数化异步数据流的并发处理。

2.为何要用RxJava

RxJava的原理就是创建一个Observable对象，然后使用各种操作符建立起来的链式操作，就如同流水线一样，把你想要处理的数据一步一步地加工成你想要的成品，然后发射给Subscriber处理。

3.RxJava与观察者模式

RxJava的异步操作是通过扩展的观察者模式来实现的。RxJava有4个角色Observable、Observer、Subscriber和Suject。Observable和 Observer 通过subscribe方法实现订阅关系，Observable就可以在需要的时候通知Observer。

8.1.2　RxJava基本实现

RxJava的基本用法分为如下3个步骤。

1. 创建Observer(观察者) onCompleted onError onNext
2. 创建 Observable(被观察者) create just from
3. Subscribe(订阅)

8.1.3　RxJava的不完整定义回调

8.2　RxJava的Subject

Subject 既可以是一个 Observer 也可以是一个 Observerable，它是连接 Observer 和Observerable的桥梁。

1. PublishSubject
2. BehaviorSubject
3. ReplaySubject
4. AsyncSubject

8.3　RxJava操作符入门

8.3.1　创建操作符

1. interval 按固定时间间隔发射整数序列
2. range 发射指定范围的整数序列
3. repeat 重复发射特定数据

8.3.2　变换操作符

变换操作符的作用是对Observable发射的数据按照一定规则做一些变换操作，然后将变换后的数据发射出去。

1. map 变换
2. flatMap 集合变换
3. cast 转换
4. concatMap 连续变换
5. flatMapIterable
6. buffer 缓存x个
7. groupBy 分组

8.3.3　过滤操作符

过滤操作符用于过滤和选择Observable发射的数据序列，让Observable只返回满足我们条件的数据。

1. filter 过滤
2. elementAt 第x个
3. distinct 去重
4. skip 跳过
5. take 只取x个
6. ignoreElements 忽略
7. throttleFirst 发射第一个
8. throttleWithTimeOut 超时限流

8.3.4　组合操作符

组合操作符可以同时处理多个Observable来创建我们所需要的Observable。

1. startWith 插入数据
2. merge 合并
3. concat 顺序合并
4. zip 合并
5. combineLastest

8.3.5　辅助操作符

1. delay 延迟
2. Do 添加回调
   • doOnEach
   • doOnNext
   • doOnSubscribe
   • doOnUnsubscribe
   • doOnCompleted
   • doOnError
   • doOnTerminate
   • finallyDo
3. subscribeOn observeOn 指定线程
4. timeout 超时

8.3.6　错误处理操作符

RxJava在错误出现的时候就会调用Subscriber的onError方法将错误分发出去，由Subscriber自己来处理错 误。

1. catch
   • onErrorReturn
   • onErrorResumeNext
   • onExceptionResumeNext
2. retry

8.3.7　条件操作符和布尔操作符

条件操作符和布尔操作符可用于根据条件发射或变换Observable，或者对它们做布尔运算。

• 条件操作符有amb、defaultIfEmpty、skipUntil、skipWhile、takeUntil和takeWhile等；
• 布尔操作符有all、contains、isEmpty、exists和sequenceEqual。

8.3.8　转换操作符

转换操作符用来将 Observable 转换为另一个对象或数据结构。转换操作符有 toList、toSortedList、toMap、toMultiMap、getIterator和nest等。

8.4　RxJava的线程控制

1.内置的Scheduler
如果我们不指定线程，默认是在调用subscribe方法的线程上进行回调的。如果我们想切换线程，就需要使用Scheduler。RxJava 已经内置了如下5个Scheduler。

• Schedulers.immediate()：直接在当前线程运行，它是timeout、timeInterval和timestamp操作符的默认调度器。
• Schedulers.newThread()：总是启用新线程，并在新线程执行操作。
• Schedulers.io()：I/O操作(读写文件、读写数据库、网络信息交互等)所使用的 Scheduler。
• Schedulers.computation()：计算所使用的 Scheduler，例如图形的计算。
• Schedulers.trampoline()：当我们想在当前线程执行一个任务时，并不是立即时，可以用trampoline()将它入队。
• AndroidSchedulers.mainThread()：RxAndroid库中提供的Scheduler，它指定的操作在主线程中运行。

2.控制线程
在RxJava中用subscribeOn和observeOn操作符来控制线程。

8.5　RxJava的使用场景

8.5.1　RxJava结合OkHttp访问网络

8.5.2　RxJava结合Retrofit访问网络

8.5.3　用RxJava实现RxBus

8.6　RxJava源码解析

8.6.1 RxJava的订阅过程

8.6.2　RxJava的变换过程

8.6.3　RxJava的线程切换过程

8.7　本章小结

如何理解“栈”？

• 后进者先出，先进者后出，这就是典型的“栈”结构。
• 从栈的操作特性上来看，栈是一种“操作受限”的线性表，只允许在一端插入和删除数据。

为什么还要用这个“操作受限”的“栈”呢？

• 特定的数据结构是对特定场景的抽象，而且，数组或链表暴露了太多的操作接口，操作上的确灵活自由，但使用时就比较不可控，自然也就更容易出错。

如何实现一个“栈”？

栈既可以用数组来实现，也可以用链表来实现。用数组实现的栈，我们叫作顺序栈，用链表实现的栈，我们叫作链式栈。

顺序栈和链式栈，时间、空间复杂度都是 O(1)。

支持动态扩容的顺序栈

1. 底层依赖一个支持动态扩容的数组
2. 当栈满了之后，申请一个更大的数组，将原来的数据搬移到新数组中。

• 出栈的时间复杂度仍然是 O(1)。
• 入栈操作：当栈中有空闲空间，入栈操作的时间复杂度为 O(1)；空间不够时，需要重新申请内存和数据搬移，时间复杂度为O(n)。
• 平均情况下的耗时接近O(1)

栈在函数调用中的应用

函数调用栈操作系统给每个线程分配了一块独立的内存空间，这块内存被组织成“栈”这种结构, 用来存储函数调用时的临时变量。每进入一个函数，就会将临时变量作为一个栈帧入栈，当被调用函数执行完成，返回之后，将这个函数对应的栈帧出栈。

栈在表达式求值中的应用

1. 编译器就是通过两个栈来实现的。其中一个保存操作数的栈，另一个是保存运算符的栈。我们从左向右遍历表达式，当遇到数字，我们就直接压入操作数栈；当遇到运算符，就与运算符栈的栈顶元素进行比较。
2. 如果比运算符栈顶元素的优先级高，就将当前运算符压入栈；如果比运算符栈顶元素的优先级低或者相同，从运算符栈中取栈顶运算符，从操作数栈的栈顶取2个操作数，然后进行计算，再把计算完的结果压入操作数栈，继续比较。

栈在括号匹配中的应用

借助栈来检查表达式中的括号是否匹配：

用栈来保存未匹配的左括号，从左到右依次扫描字符串。当扫描到左括号时，则将其压入栈中；当扫描到右括号时，从栈顶取出一个左括号。如果能够匹配，比如“(”跟“)”匹配，“[”跟“]”匹配，“{”跟“}”匹配，则继续扫描剩下的字符串。如果扫描的过程中，遇到不能配对的右括号，或者栈中没有数据，则说明为非法格式。

解答开篇

如何实现浏览器的前进、后退功能？

我们使用两个栈，X和Y，我们把首次浏览的页面依次压入栈X，当点击后退按钮时，再依次从栈X中出栈，并将出栈的数据依次放入栈Y。当我们点击前进按钮时，我们依次从栈Y中取出数据，放入栈X中。当栈X中没有数据时，那就说明没有页面可以继续后退浏览了。当栈Y中没有数据，那就说明没有页面可以点击前进按钮浏览了。

使用泛型机制编写的程序代码要比哪些杂乱地使用Object变量，然后在进行强制类型转换的代码具有更好的安全性和可读性。泛型对于集合类尤其有用，例如，ArrayList就是一个无处不在的集合类。

1 为什么要使用泛型程序设计

泛型程序设计（Generic programming）意味着编写的代码可以被很多不同类型的对象所重用。

1.1 类型参数的好处

不使用泛型的问题：

1. 当获取一个值时必须进行强制类型转换。
2. 操作时没有错误检查。

泛型提供的解决方案类型参数（type parameters），使得程序具有更好的可读性和安全性。

如ArrayList，声明时即可知道数据类型，并且添加数据时有检查，可以避免插入错误类型的数据。

1.2 谁想成为泛型程序员

泛型程序员的任务就是预测出所用类的未来可能有的所有用途。
通配符类型（wildcard type），可以帮助库的构建者编写出尽可能灵活的方法。

2 定义简单泛型类

一个泛型类（generic class）就是一个或多个类型变量的类。

public class Pair<T> {
    
    private T first;
    private T second;

    public Pair() { first = null;second = null; }

    public Pair(T first, T second) { this.first = first;this.second = second; }

    public T getFirst() { return first; }

    public void setFirst(T first) { this.first = first; }

    public T getSecond() { return second; }

    public void setSecond(T second) { this.second = second; }
}

Pair类引入了一个类型变量T，用<>括起来，并放在类型后面。泛型类可以有多个类型变量。
类定义中的 类型变量 指定 方法的返回类型 以及 域和局部变量的类型。

3 泛型方法

定义一个带有类型参数的简单方法：

class ArrayAlg {

    public static <T> T getMiddle(T... a) {
        return a[a.length / 2];
    }
}

4 类型变量的限定

有时，类或者方法需要对类型变量加以约束。解决方案是将T限制为实现某个接口。

public static <T extends Comparable> T min(T[] a)...

一个类型变量或通配符可以有多个限定：

T extends Comparable & Serializable

5 泛型代码和虚拟机

虚拟机没有泛型类型对象--所有对象都属于普通类。

5.1 类型擦除

无论何时定义一个泛型类型，都自动提供了一个相应的原始类型（raw type）。原始类型的名字就是删去类型参数后的泛型类型名。擦除（erased）类型变量，并替换为限定类型（无限定的变量用Object）。

5.2 翻译泛型表达式

当程序调用泛型方法时，如果擦除返回类型，编译器插入强制类型转换。

5.3 翻译泛型方法

类型擦除也会出现在泛型方法中。

类型擦除与多态发生冲突。解决这个问题，编译器会生成一个桥方法（bridge method）。

Java泛型转换的事实：

• 虚拟机中没有泛型，只有普通的类和方法。
• 所有的类型参数都用它们的限定类型替换。
• 桥方法被合成来保存多态。
• 为保持类型安全性，必要时插入强制类型转换。

5.4 调用遗留代码

设计Java泛型类型时，主要目标是运行泛型代码和遗留代码之间能够互操作。

6 约束与局限性

Java泛型使用时要考虑一些限制，大多数限制都是由类型擦除引起的。
(todo暂时只有介绍，没有原因说明)

6.1 不能用基本类型实例化类型参数

没有Pair<double>，只有Pair<Double>。

原因是类型擦除之后，Pair类含有Object类型的域，而Object不能存储double值。

6.2 运行时类型查询只适用于原始类型

虚拟机中的对象总有一个特定的非泛型类型。因此，所有的类型查询只产生原始类型。

if (a instanceof Pair<String>) //error
Pair<String> p = (Pair<String>) a;//Warning

Pair<T>的gatClass将返回Pair.class

6.3 不能创建参数化类型的数组

Pair<String>[] table = new Pair<String>[10];//error

如果需要收集参数化类型对象，使用ArrayList<Pair<String>>。

6.4 Varargs警告

@SuppressWarnings("unchecked")和@SafeVarargs抑制警告。

6.5 不能实例化类型变量

不能使用像new T(...)，new T[...]或T.class这样的表达式中的类型变量。

6.6 不能构造泛型数组

public static <T extends Comparable> T[] minmax(T[] a) { T[] mm = new T[2]; ...}//error

6.7 泛型类的静态上下文中类型变量无效

public class Singleton<T>{
    private static T instance;  //error
    public static T getInstance(){...}  //error
}

6.8 不能抛出或捕获泛型类的实例

public class Problem<T> extends Exception {/**...**/}//error

6.9 可以消除对受查异常的检查

6.10 注意擦除后的冲突

public boolean equals(T value){...}//error

方法擦除equals(T)就是equals(Object)，与Object.equals方法冲突。

7 泛型类型的继承规则

无论S与T有什么关系，通常Pair<S>与Pair<T>没有什么联系。

8 通配符类型

8.1 通配符的概念

通配符类型中，运行类型参数变化。如Pair<? extends Employee>，表示任何泛型Pair类型。

8.2 通配符的超类型限定

通配符还可以指定一个超类型限定,? super Manager。
带有超类型限定的通配符可以向泛型对象写入，带有子类型限定的通配符可以从泛型对象读取。

public static <T extends Comparable<? super T>> T min(T[] a)

有可能被声明为使用类型T的对象，也有可能使用T的超类型。

8.3 无限定通配符

还可以使用无限定的通配符，如Pair<?>。

Pair<?>和Pair本质的不同在于：可以用任意Object对象调用原始Pair类的方法。它对于许多简单操作非常有用，比如hasNulls(Pair<?> p)。

8.4 通配符捕获

9 反射和泛型

9.1 泛型Class类

9.2 使用Class参数进行类型匹配

9.3 虚拟机中的泛型类型信息

处理对象的多种状态及其相互转换——状态模式

在状态模式（State Pattern）中，类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。
在状态模式中，我们创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。

介绍

意图：允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。
主要解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。
何时使用：代码中包含大量与对象状态有关的条件语句。
如何解决：将各种具体的状态类抽象出来。
关键代码：通常命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。而且，状态模式的实现类的方法，一般返回值，或者是改变实例变量的值。也就是说，状态模式一般和对象的状态有关。实现类的方法有不同的功能，覆盖接口中的方法。状态模式和命令模式一样，也可以用于消除 if...else 等条件选择语句。
应用实例： 1、打篮球的时候运动员可以有正常状态、不正常状态和超常状态。 2、曾侯乙编钟中，'钟是抽象接口','钟A'等是具体状态，'曾侯乙编钟'是具体环境（Context）。
优点： 1、封装了转换规则。 2、枚举可能的状态，在枚举状态之前需要确定状态种类。 3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 4、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。 5、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
缺点： 1、状态模式的使用必然会增加系统类和对象的个数。 2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。 3、状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。
使用场景： 1、行为随状态改变而改变的场景。 2、条件、分支语句的代替者。
注意事项：在行为受状态约束的时候使用状态模式，而且状态不超过 5 个。

8.1 WMS的职责

窗口管理
窗口动画
输入系统的中转站
Surface管理

8.2 WMS的创建过程

8.3 WMS的重要成员

8.4 Window的添加过程（WMS处理部分）

addWindow方法分了3个部分来进行讲解，主要就是做了下面4件事：

1. 对所要添加的窗口进行检查，如果窗口不满足一些条件，就不会再执行下面的代码逻辑。
2. WindowToken相关的处理，比如有的窗口类型需要提供WindowToken，没有提供的话就不会执行下面的代码逻辑，有的窗口类型则需要由WMS隐式创建WindowToken。
3. WindowState的创建和相关处理，将WindowToken和WindowState相关联。
4. 创建和配置DisplayContent，完成窗口添加到系统前的准备工作。

8.5 Window的删除过程

Window的删除过程：

1. 检查删除线程的正确性，如果不正确就抛出异常。
2. 从ViewRootImpl列表、布局参数列表和View列表中删除与V对应的元素。
3. 判断是否可以直接执行删除操作，如果不能就推迟删除操作。
4. 执行删除操作，清理和释放与V相关的一切资源。

8.6 本章小结

8.1 Window和WindowManager

Window表示的是一个窗口的概念，它的具体实现是PhoneWindow,创建一个Window很简单，只需要WindowManager去实现，WindowManager是外界访问Window的入口，Window的具体实现是在WindowManagerService中，他们两个的交互是一个IPC的过程，Android中的所有视图都是通过Window来实现的。

Flag参数

• FLAG_NOT_FOCUSABLE
  • 表示窗口不需要获取焦点，也不需要接收各种事件，最终的事件会传递给下层的具体焦点的window
• FLAG_NOT_TOUCH_MODAL
  • 在此模式下，系统会将当前window区域以外的单击事件传递给底层的Window，此前的Window区域以内的单机事件自己处理，
• FLAG_SHOW_WHEN_LOCKED
  • 开启这个属性可以让window显示在锁屏上

Type参数表示window的类型，window有三种类型，分别是应用，子，系统，应用window对应一个Activity,子Window不能单独存在，需要依赖一个父Window。

Window是分层的，每个Window对应着z-ordered,层级大的会覆盖在层级小的Window上面，这和HTML中的z-index的概念是一致的，在这三类中，应用是层级范围是1-99，子window的层级是1000-1999，系统的层级是2000-2999。这些范围对应着type参数，如果想要window在最顶层，那么层级范围设置大一点就好了，很显然系统的值要大一些，系统的值很多，我们一般会选择TYPE_SYSTEM_OVERLAY和TYPE_SYSTEM_ERROR，还需要声明权限。

WindowManager所提供的功能很简单，常用的有三个方法，添加View,更新View,删除View,这三个方法定义在ViewManager中，而WindowManager继承自ViewManager。

    public interface ViewManager {
        public void addView(View view, ViewGroup.LayoutParams params);
        public void updateViewLayout(View view, ViewGroup.LayoutParams params);
        public void removeView(View view);
    }

我们常见的可以拖动的View，其实也很好实现，就是不断的更改他xy的位置：

    btn.setOnTouchListener(new View.OnTouchListener() {
            @Override
            public boolean onTouch(View v, MotionEvent event) {
                int rawX = (int) event.getRawX();
                int rawY = (int) event.getRawY();
                switch (event.getAction()) {
                    case MotionEvent.ACTION_MOVE:
                        layout.x = rawX;
                        layout.y = rawY;
                        wm.updateViewLayout(btn,layout);
                        break;
                }
                return false;
            }
        });

8.2 Window的内部机制

Window是一个抽象的概念,每一个Window都对应着一个View和一个ViewRootlmpl,Window和View通过ViewRootImpl 来建立联系，因此Window并不是实际存在的，它是以View的形式存在。这点从WindowManager的定义也可以看出，它提供的三个接口方法addView、updateViewLayout以及removeView都是针对View的，这说明View才是Window存在的实体。在实际使用中无法直接访问Window, 对Window 的访问必须通过WindowManager。为了分析Window的内部机制，这里从Window的添加、删除以及更新说起。

8.2.1 Window的添加过程

WindowManagerImpl并没有直接去实现一个Window的三大操作，而是全部交给了WindowManagerGlobal来处理，WindowManagerGlobal是一个工厂的性质提供自己的实现。WindowManagerImpl这种工作模式就是典型的桥接模式，将所有的操作全部委托给WindowManagerGlobal去实现，WindowManagerGlobal的addView方法主要分如下几步：

1. 检查参数是否合法，如果是子Window还需要调整一下参数
2. 创建ViewRootImpl并将View添加到列表中
3. 通过ViewRootImpl来更新界面并完成Window的添加

8.2.2 Window的删除过程

8.2.3 Window的更新过程

8.3 Window的创建过程

8.3.1 Activity的Window创建过程

8.3.2 Dialog的Window创建过程

8.3.3 Toast的Window创建过程

• 通用的线程生命周期
• Java 中线程的生命周期
  1. RUNNABLE 与 BLOCKED 的状态转换
  2. RUNNABLE 与 WAITING 的状态转换
  3. RUNNABLE 与 TIMED_WAITING 的状态转换
  4. 从 NEW 到 RUNNABLE 状态
  5. 从 RUNNABLE 到 TERMINATED 状态

通用的线程生命周期

通用的线程生命周期基本上可以用下图这个“五态模型”来描述。这五态分别是：初始状态、可运行状态、运行状态、休眠状态和终止状态。

这“五态模型”的详细情况如下所示：

1. 初始状态，指的是线程已经被创建，但是还不允许分配 CPU 执行。这个状态属于编程语言特有的，不过这里所谓的被创建，仅仅是在编程语言层面被创建，而在操作系统层面，真正的线程还没有创建。
2. 可运行状态，指的是线程可以分配 CPU 执行。在这种状态下，真正的操作系统线程已经被成功创建了，所以可以分配 CPU 执行。
3. 当有空闲的 CPU 时，操作系统会将其分配给一个处于可运行状态的线程，被分配到 CPU 的线程的状态就转换成了运行状态。
4. 运行状态的线程如果调用一个阻塞的 API（例如以阻塞方式读文件）或者等待某个事件（例如条件变量），那么线程的状态就会转换到休眠状态，同时释放 CPU 使用权，休眠状态的线程永远没有机会获得 CPU 使用权。当等待的事件出现了，线程就会从休眠状态转换到可运行状态。
5. 线程执行完或者出现异常就会进入终止状态，终止状态的线程不会切换到其他任何状态，进入终止状态也就意味着线程的生命周期结束了。

Java 中线程的生命周期

Java 语言中线程共有六种状态，分别是：

1. NEW（初始化状态）
2. RUNNABLE（可运行 / 运行状态）
3. BLOCKED（阻塞状态）
4. WAITING（无时限等待）
5. TIMED_WAITING（有时限等待）
6. TERMINATED（终止状态）

在操作系统层面，Java 线程中的 BLOCKED、WAITING、TIMED_WAITING 是一种状态，即前面我们提到的休眠状态。也就是说只要 Java 线程处于这三种状态之一，那么这个线程就永远没有 CPU 的使用权。

1. RUNNABLE 与 BLOCKED 的状态转换

只有一种场景会触发这种转换，就是线程等待 synchronized 的隐式锁。

2. RUNNABLE 与 WAITING 的状态转换

总体来说，有三种场景会触发这种转换。

• 第一种场景，获得 synchronized 隐式锁的线程，调用无参数的 Object.wait() 方法。
• 第二种场景，调用无参数的 Thread.join() 方法。其中的 join() 是一种线程同步方法，例如有一个线程对象 thread A，当调用 A.join() 的时候，执行这条语句的线程会等待 thread A 执行完，而等待中的这个线程，其状态会从 RUNNABLE 转换到 WAITING。当线程 thread A 执行完，原来等待它的线程又会从 WAITING 状态转换到 RUNNABLE。
• 第三种场景，调用 LockSupport.park() 方法。调用 LockSupport.park() 方法，当前线程会阻塞，线程的状态会从 RUNNABLE 转换到 WAITING。调用 LockSupport.unpark(Thread thread) 可唤醒目标线程，目标线程的状态又会从 WAITING 状态转换到 RUNNABLE。

3. RUNNABLE 与 TIMED_WAITING 的状态转换

有五种场景会触发这种转换：

1. 调用带超时参数的 Thread.sleep(long millis) 方法；
2. 获得 synchronized 隐式锁的线程，调用带超时参数的 Object.wait(long timeout) 方法；
3. 调用带超时参数的 Thread.join(long millis) 方法；
4. 调用带超时参数的 LockSupport.parkNanos(Object blocker, long deadline) 方法；
5. 调用带超时参数的 LockSupport.parkUntil(long deadline) 方法。

这里你会发现 TIMED_WAITING 和 WAITING 状态的区别，仅仅是触发条件多了超时参数。

4. 从 NEW 到 RUNNABLE 状态

Java 刚创建出来的 Thread 对象就是 NEW 状态，而创建 Thread 对象主要有两种方法。一种是继承 Thread 对象，重写 run() 方法。

5. 从 RUNNABLE 到 TERMINATED 状态

线程执行完 run() 方法后，会自动转换到 TERMINATED 状态，当然如果执行 run() 方法的时候异常抛出，也会导致线程终止。有时候我们需要强制中断 run() 方法的执行，Java 的 Thread 类里面有个 stop() 方法，不过已经标记为 @Deprecated，所以不建议使用了。正确的姿势其实是调用 interrupt() 方法。

那 stop() 和 interrupt() 方法的主要区别是什么呢？

stop() 方法会真的杀死线程，不给线程喘息的机会，如果线程持有 ReentrantLock 锁，被 stop() 的线程并不会自动调用 ReentrantLock 的 unlock() 去释放锁，那其他线程就再也没机会获得 ReentrantLock 锁，这实在是太危险了。所以该方法就不建议使用了，类似的方法还有 suspend() 和 resume() 方法，这两个方法同样也都不建议使用了，所以这里也就不多介绍了。

而 interrupt() 方法就温柔多了，interrupt() 方法仅仅是通知线程，线程有机会执行一些后续操作，同时也可以无视这个通知。被 interrupt 的线程，是怎么收到通知的呢？一种是异常，另一种是主动检测。

总结

理解 Java 线程的各种状态以及生命周期对于诊断多线程 Bug 非常有帮助，多线程程序很难调试，出了 Bug 基本上都是靠日志，靠线程 dump 来跟踪问题，分析线程 dump 的一个基本功就是分析线程状态，大部分的死锁、饥饿、活锁问题都需要跟踪分析线程的状态。

你可以通过 jstack 命令或者Java VisualVM这个可视化工具将 JVM 所有的线程栈信息导出来，完整的线程栈信息不仅包括线程的当前状态、调用栈，还包括了锁的信息。

课后思考

下面代码的本意是当前线程被中断之后，退出while(true)，你觉得这段代码是否正确呢？

Thread th = Thread.currentThread();
while(true) {
  if(th.isInterrupted()) {
    break;
  }
  // 省略业务代码无数
  try {
    Thread.sleep(100);
  }catch (InterruptedException e){
    e.printStackTrace();
  }
}

答：可能出现无限循环，线程在sleep期间被打断了，抛出一个InterruptedException异常，try catch捕捉此异常，应该重置一下中断标示，因为抛出异常后，中断标示会自动清除掉！

Thread th = Thread.currentThread();
while(true) {
  if(th.isInterrupted()) {
    break;
  }
  // 省略业务代码无数
  try {
    Thread.sleep(100);
  }catch (InterruptedException e)｛
    Thread.currentThread().interrupt();
    e.printStackTrace();
  }
}

9.1 四大组件的运行状态 / 316

1、Activity（展示型组件）

Activity的主要作用是展示一个界面并和用户交互，它扮演的是一种前台界面的角色。

• 需要借助Intent启动。有显示Intent和隐式Intent。隐式Intent指向一个或多个目标Activity组件，当然也可能没有任何一个Activity组件可以处理这个隐式Intent。
• 可以具有特定的启动模式，比如singleTop、singleTask等。
• 通过Activity的finish方法来结束一个Activity组件的运行。

2、Service（计算型组件）

Service用于在后台执行一系列计算任务。

• 启动状态：做后台计算，不需要和外界有直接的交互。
• 绑定状态：这个时候Service内部同样可以进行后台计算，但是处于这种状态时外界可以很方便的和Service组件进行通信。
• 尽管Service组件用于执行后台计算，但它本身是运行在主线程中的，因此耗时的后台计算仍然需要在单独的线程中去完成。
• 灵活采用stopService和unBindService这两个方法才能完全停止一个Service组件。

3、BroadcastReceiver（消息型组件）

BroadcastReceiver用于在不同的组件乃至不同的应用之间传递消息。

• 可以在AndroidManifest中静态注册
• 动态注册，Context.registerReceiver（）和 Context.unRegisterReceiver（）
• 通过Context的一系列send方法来发送广播，发送和接收过程的匹配是通过广播接收者的来描述的。
• 不适合用来执行耗时操作。
• BroadcastReceiver组件一般来说不需要停止，它也没有停止的概念。

4、ContentProvider（数据共享型组件）

ContentProvider用于向其他组件乃至其他应用共享数据。

• 它的内部需要实现增删查改这四种操作，在它的内部维持着一份数据集合，这个数据集合既可以通过数据库来实现，也可以采用其他任何类型来实现，比如List和Map，ContentProvider对数据集合的具体实现并没有任何要求。
• ContentProvider内部的insert、deleted、update和query方法需要处理好线程同步，因为这几个方法是在Binder线程池中被调用的。
• ContentProvider无需手动停止。

9.2 Activity的工作过程 / 318

performLaunchActivity主要完成：

1. 从ActivityClientRecord中获取待启动的Activity的组件信息
2. 通过Instrumentation的newActivity方法使用类加载器创建Activity对象
3. 通过LoadedApk的makeApplication方法来尝试创建新的Application对象
4. 创建ContextImpl对象并通过Activity的attach方法来完成一些重要数据的初始化
5. 调用Activity的onCreate()方法

9.3 Service的工作过程 / 336

9.3.1 Service的启动过程 / 336

handleCreateService主要完成

1. 通过类加载器创建Service的实例
2. 创建Application对象并调用onCreate()
3. 创建ContextImpl并通过Service的attach方法建立联系
4. 调用Service的onCreate方法并将Service对象存储到ActivityThread的一个列表中

9.3.2 Service的绑定过程 / 344

9.4 BroadcastReceiver的工作过程 / 352

9.4.1 广播的注册过程 / 353

9.4.2 广播的发送和接收过程 / 356

9.5 ContentProvider的工作过程 / 362

9.1　注解

从JDK 5开始，Java增加了注解，注解是代码里的特殊标记，这些标记可以在编译、类加载、运行时被读取，并执行相应的处理。通过 使用注解，开发人员可以在不改变原有逻辑的情况下，在源文件中嵌入一些补充的信息。代码分析工具、 开发工具和部署工具可以通过这些补充信息进行验证、处理或者进行部署。

9.1.1　注解分类

注解分为标准注解和元注解。

1.标准注解

标准注解有以下4种：

• @Override:
  • 对覆盖超类中的方法进行标记，如果被标记的方法并没有实际覆盖超类中的方法，则编 译器会发出错误警告。
• @Deprecated:
  • 对不鼓励使用或者已过时的方法添加注解，当编程人员使用这些方法时，将会在编译 时显示提示信息。
• @SuppressWarnings:
  • 选择性地取消特定代码段中的警告。
• @SafeVarargs:J
  • DK 7新增，用来声明使用了可变长度参数的方法，其在与泛型类一起使用时不会出现类型安全问题。

2.元注解

元注解，它用来注解其他注解，从而创建新的注解。元注解有以下几种。

• @Targe:
  • 注解所修饰的对象范围。
• @Inherited:
  • 表示注解可以被继承。
• @Documented:
  • 表示这个注解应该被JavaDoc工具记录。 * @Retention:用来声明注解的保留策略。
• @Repeatable:
  • JDK 8 新增，允许一个注解在同一声明类型(类、属性或方法)上多次使用。

其中@Targe注解取值是一个ElementType类型的数组，其中有以下几种取值，对应不同的对象范围。

• ElementType.TYPE:能修饰类、接口或枚举类型。
• ElementType.FIELD:能修饰成员变量。
• ElementType.METHOD:能修饰方法。
• ElementType.PARAMETER:能修饰参数。
• ElementType.CONSTRUCTOR:能修饰构造方法。
• ElementType.LOCAL_VARIABLE:能修饰局部变量。
• ElementType.ANNOTATION_TYPE:能修饰注解。
• ElementType.PACKAGE:能修饰包。
• ElementType.TYPE_PARAMETER:类型参数声明。
• ElementType.TYPE_USE:使用类型。

其中@Retention注解有3种类型，分别表示不同级别的保留策略。

• RetentionPolicy.SOURCE:源码级注解。
  • 注解信息只会保留在.java源码中，源码在编译后，注解信息被丢弃，不会保留在.class中。
• RetentionPolicy.CLASS:编译时注解。
  • 注解信息会保留在.java 源码以及.class 中。当运行Java程序时， JVM会丢弃该注解信息，不会保留在JVM中。
• RetentionPolicy.RUNTIME:运行时注解。
  • 当运行Java程序时，JVM也会保留该注解信息，可以通过反射获取该注解信息。

9.1.2　定义注解

1）基本定义

定义新的注解类型使用@interface关键字

//定义
public @interface Swordsman{}

//使用
@Swordsman
public class AnnotationTest{}

2）定义成员变量

注解只有成员变量，没有方法。注解的成员变量在注解定义中以“无形参的方法”形式来声明，其“方法名”定义了该成员变量的名字，其返回值定义了该成员变量的类型。还可以使用default关键字为其指定默认值。

//定义注解和成员变量
public @interface Swordsman{
    String name();
    int age();
}
//使用
public class AnnotationTest{
    @Swordsman(name="张无忌",age=23)
    public void fighting(){ }
}
//default指定默认值
public @interface Swordsman{
    String name() default "张无忌";
    int age() default 23;
}

3）定义运行时/编译时注解

可以用@Retention来设定注解的保留策略，这 3个策略的生命周期长度为 SOURCE <CLASS< RUNTIME。生命周期短的能起作用的地方，生命周期长的一定也能起作用。

• 一般如果需要在运行时去动态获取注解信息，那只能用RetentionPolicy.RUNTIME;
• 如果要在编译时进行一些预处理操作，比如生成一些辅助代码，就用 RetentionPolicy.CLASS;
• 如果只是做一些检查性的操作，比如@Override 和 @SuppressWarnings，则可选用RetentionPolicy.SOURCE。当设定为RetentionPolicy.RUNTIME时，这个注解就是运行时注解。

9.1.3　注解处理器

对于不同的注解有不同的注解处理器。 虽然注解处理器的编写会千变万化，但是其也有处理标准，比如:针对运行时注解会采用反射机制处理， 针对编译时注解会采用 AbstractProcessor 来处理。

1.运行时注解处理器

处理运行时注解需要用到反射机制。通过反射获得Field、Method等信息，调用getAnnotation()方法即可获得注解信息。

2.编译时注解处理器

1. 定义注解
2. 编写注解处理器
   1. 注解处理器ClassProcessor，它继承AbstractProcessor
   2. 方法有init、process、getSupportedAnnotationTypes、getSupportedSourceVersion等。
3. 注册注解处理器
   1. 使用Google 开源的AutoService
   2. 在ClassProcessor中添加@AutoService(Processor.class)
4. 应用注解
5. 使用android-apt插件
   1. 仅仅在编译时期去依赖注解处理器所在的函数库并进行工作，但不会打包到APK中。
   2. 为注解处理器生成的代码设置好路径，以便Android Studio能够找到它。

9.2　依赖注入的原理

9.2.1　控制反转与依赖注入

1.控制反转

IoC是Inversion of Control的缩写，即控制反转，借助于“第三方”实现具有依赖关系的对象之间的解耦。

1. 引入IoC容器之前：对象A依赖于对象B，那么对象A在初始化的时候，自己必须主动去创建对象B或者使用已经创建的对象B。无论是创建对象B还是使用对象B，控制权都在自己手上。
2. 引入IoC容器之后：由于IoC容器的加入，对象A与对象B之间失去了直接联系，所以，当对象A运行到需要对象B的时候，IoC容器会主动创建一个对象B注入到对象A需要的地方。
3. 通过引入Ioc容器前后的对比，可以看出：对象A获得依赖对象B的过程，由主动行为变为被动行为，控制权颠倒过来了，这就是控制反转这个名称的由来。

2.依赖注入

Martin Fowler提问：
控制反转是“哪些方面的控制被反转了呢?”
答:“获得依赖对象的过程被反转了”。

控制被反转之后，获得依赖对象的过程由自身管理变为由IoC容器主动注入。于是，他给控制反转取了一个更合适的名字，叫作依赖注入(Dependency Injection)，简称DI。所谓依赖注入，是指由IoC容器在运行期间，动态地将某种依赖关系注入到对象中。

9.2.2　依赖注入的实现方式

这里举一个汽车的例子，汽车类Car包含了引擎Engine等组件：

public class Car{
    private Engine mEngine;
    public Car(){
        mEngine = new PetrolEngine();
    }
}

1. 构造方法注入

   public class Car{
       private Engine mEngine;
   
       public Car(Engine mEngine){
   
           this.mEngine = mEngine;
   
       }
   
   }
   

2. Setter方法注入

   public class Car{
       private Engine mEngine;
   
       public void set(Engine mEngine){
   
           this.mEngine = mEngine;
   
       }
   
   }
   

3. 接口注入

   public interface ICar{
       public void setEngine(Engine engine);
   
   }
   
   public class Car implements ICar{
   
       private Engine mEngine;
   
       @Override
   
       public void setEngine(Engine engine){
   
           this.mEngine = engine;
   
       }
   
   }
   

9.3　依赖注入框架

9.3.1　为何使用依赖注入框架

9.3.2　解析ButterKnife

1.ButterKnife的注解使用方法

1. 添加依赖库
2. 绑定控件
   • @BindView
3. 绑定资源
   • @BindString、@BindArray、@BindBool、@BindColor、@BindDimen、@BindDrawable和@BindBitmap
4. 绑定监听
   • @OnClick、@OnLongClick、@OnTextChanged、@OnTouch、@OnItemClick
5. 可选绑定
   • @Nullable防止找不到资源

2. ButterKnife原理解析

1. ButterKnifeProcessor源码分析
   1. ButterKnifeProcessor#process#findAndParseTargets：查找所有注解并解析
   2. brewJava：方法将使用注解的类生成一个JavaFile
2. ButterKnife的bind方法
   1. 得到Activity的 DecorView，findBindingConstructorForClass方法获得构造器并生成实例
3. 生成的辅助类分析
   1. DecorView传入这个类中，通过findViewById将View返回。

9.3.3　解析Dagger2

Dagger2是一个基于JSR-330(Java依赖注入)标准的依赖注入框架，在编译期间自动生成代码，负责依赖对象的创建。

1.注解使用方法

1. 添加依赖库

2. @Inject和@Component

   1. @Inject：用于标记需要注入的依赖
   2. @Component：注入器，可以编译生成类，调用注入方法

   @Component
   public interface MainActivityComponent {
   
       void inject (MainActivity activity) ;
   
   }
   
   public class MainActivity extends AppCompatActivity {
   
       @Inject
   
       Watch watch;
   
       @Override
   
       protected void onCreate (Bundle savedInstanceState) {
   
           super.onCreate(savedInstanceState);
   
           setContentView(R.layout.activity_main);
   
           Dagger MainActivityComponent.create().inject(this);
   
           watch.work();
   
       }
   
   }
   

3. @Module和@Provides

   1. 如果项目中使用了第三方的类库，或需要注入的类是抽象类，可以采用@Module和@Provides提供注入器。

   @Module
   public class GsonModule {
   
       @Provides
   
       public Gson provideGson() {
   
           return new Gson();
   
       }
   
   }
   
   @Component (modules = GsonModule.class)
   
   public interface MainActivityComponent {
   
       void inject (MainActivity activity);
   
   }
   

4. @Named和@Qualifier

   1. @Qualifier 是限定符，@Named 则是@Qualifier 的一种实现。
   2. 当有两个相同的依赖时，它们都继承同一个父类或者均实现同一个接口。当它们被提供给高层时，Component 就不知道我们到底要提供哪一个依赖 对象了，因为它找到了两个。
   3. 或者通过自定义注解来实现。

   @Module
   public class Eng ineModule {
   
       @Provides
   
       @Named("Gasoline")
   
       public Engine provideGasoline() {
   
           return new GasolineEngine() ;
   
       }
   
       @Provides
   
       @Named("Diesel")
   
       public Engine provideDiesel() {
   
           return new DieselEngine() ;
   
       }
   
   }
   
   public class Car {
   
       private Engine engine;
   
       @Inject
   
       public Car(@Named("Diesel") Engine engine) {
   
           this.engine = engine;
   
       }
   
   }
   

   @Qualifier
   @Retention(RUNTIME)
   
   public dinterface Gasoline {}
   
   @Qualifier
   
   @Retention(RUNTIME)
   
   public dinterface Diesel {}
   
   @Module
   
   public class EngineModule {
   
       @Provides
   
       @Gasoline
   
       public Engine provideGasoline() {
   
           return new Gasol ineEngine();
   
       }
   
       @Provides
   
       @Diesel
   
       public Engine provideDiesel() {
   
           return new DieselEngine();
   
       }
   
   }
   
   public class Car {
   
       private Engine engine;
   
       @Inject
   
       public Car(@Gasoline Engine engine) {
   
           this.engine = engine;
   
       }
   
       public String run() {
   
           return engine.work();
   
       }
   
   }
   

5. @Singleton和@Scope

   1. @Scope是用来自定义注解的，而@Singleton则是用来配合实现局部单例和全局单例的。@Singleton本身不具备创建单例的能力。
   2. 如果想实现全局单例，我们可以用@Scope结合Application来实现。

6. @Component的dependencies

   1. @Component也可以用dependencies依赖于其他Component。

2.懒加载
Dagger2提供了懒加载模式，在@Inject的时候不初始化，而是使用的时候，调用get方法来获取实例。
3.Dagger2原理解析

1. WatchModule_ProvideWatchFactory 用来生成 Watch 实例；
2. Dagger2Activity_MemberInject 将 Watch 实例赋值 给 MainActivity 的成员变量 Watch；
3. DaggerActivityComponent则作为程序入口和桥梁，负责初始化 WatchModule_ProvideWatchFactory和Dagger2Activity_MemberInject，并将它们串联起来。

9.4　本章小结

请求的链式处理——职责链模式

顾名思义，责任链模式（Chain of Responsibility Pattern）为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。
在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。

介绍

意图：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
主要解决：职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递，所以职责链将请求的发送者和请求的处理者解耦了。
何时使用：在处理消息的时候以过滤很多道。
如何解决：拦截的类都实现统一接口。
关键代码：Handler 里面聚合它自己，在 HandlerRequest 里判断是否合适，如果没达到条件则向下传递，向谁传递之前 set 进去。
应用实例： 1、红楼梦中的"击鼓传花"。 2、JS 中的事件冒泡。 3、JAVA WEB 中 Apache Tomcat 对 Encoding 的处理，Struts2 的拦截器，jsp servlet 的 Filter。
优点： 1、降低耦合度。它将请求的发送者和接收者解耦。 2、简化了对象。使得对象不需要知道链的结构。 3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。 4、增加新的请求处理类很方便。
缺点： 1、不能保证请求一定被接收。 2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。 3、可能不容易观察运行时的特征，有碍于除错。
使用场景： 1、有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。 2、在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 3、可动态指定一组对象处理请求。
注意事项：在 JAVA WEB 中遇到很多应用。

CPU资源是有限的，任务的处理速度与线程个数并不是线性正相关。相反，过多的线程反而会导致CPU频繁切换，处理性能下降。所以，线程池的大小一般都是综合考虑要处理任务的特点和硬件环境，来事先设置的。

当我们向固定大小的线程池中请求一个线程时，如果线程池中没有空闲资源了，这个时候线程池如何处理这个请求？是拒绝请求还是排队请求？各种处理策略又是怎么实现的呢？

如何理解“队列”？

你可以把它想象成排队买票，先来的先买，后来的人只能站末尾，不允许插队。先进者先出，这就是典型的“队列”。

栈只支持两个基本操作：入栈push()和出栈pop()。

队列跟栈非常相似，支持的操作也很有限，最基本的操作也是两个：

• 入队enqueue()，放一个数据到队列尾部；
• 出队dequeue()，从队列头部取一个元素。

队列跟栈一样，也是一种操作受限的线性表数据结构。

队列的应用也非常广泛，特别是一些具有某些额外特性的队列，比如循环队列、阻塞队列、并发队列。比如高性能队列Disruptor、Linux环形缓存，都用到了循环并发队列；Javaconcurrent并发包利用ArrayBlockingQueue来实现公平锁等。

顺序队列和链式队列

跟栈一样，队列可以用数组来实现，也可以用链表来实现。用数组实现的队列叫作顺序队列，用链表实现的队列叫作链式队列。

对于栈来说，我们只需要一个栈顶指针就可以了。但是队列需要两个指针：一个是head指针，指向队头；一个是tail指针，指向队尾。

a b c d 入队：

a b 出队：

随着不停地进行入队、出队操作，head和tail都会持续往后移动。当tail移动到最右边，即使数组中还有空闲空间，也无法继续往队列中添加数据了。这个问题该如何解决呢？

答：数据搬移

基于链表的队列实现方法

循环队列

循环队列的代码实现难度要比前面讲的非循环队列难多了，最关键的是，确定好队空和队满的判定条件。

• 队空时：head==tail；
• 队满时：(tail+1)%n=head。

当队列满时，图中的tail指向的位置实际上是没有存储数据的。所以，循环队列会浪费一个数组的存储空间。

阻塞队列和并发队列

阻塞队列其实就是在队列基础上增加了阻塞操作。简单来说，就是在队列为空的时候，从队头取数据会被阻塞。因为此时还没有数据可取，直到队列中有了数据才能返回；如果队列已经满了，那么插入数据的操作就会被阻塞，直到队列中有空闲位置后再插入数据，然后再返回。

这种基于阻塞队列实现的“生产者-消费者模型”，可以有效地协调生产和消费的速度。当“生产者”生产数据的速度过快，“消费者”来不及消费时，存储数据的队列很快就会满了。这个时候，生产者就阻塞等待，直到“消费者”消费了数据，“生产者”才会被唤醒继续“生产”。

而且不仅如此，基于阻塞队列，我们还可以通过协调“生产者”和“消费者”的个数，来提高数据的处理效率。比如前面的例子，我们可以多配置几个“消费者”，来应对一个“生产者”。

在多线程情况下，会有多个线程同时操作队列，这个时候就会存在线程安全问题，那如何实现一个线程安全的队列呢？

线程安全的队列我们叫作并发队列。最简单直接的实现方式是直接在enqueue()、dequeue()方法上加锁，但是锁粒度大并发度会比较低，同一时刻仅允许一个存或者取操作。实际上，基于数组的循环队列，利用CAS原子操作，可以实现非常高效的并发队列。这也是循环队列比链式队列应用更加广泛的原因。在实战篇讲Disruptor的时候，我会再详细讲并发队列的应用。

解答开篇

线程池没有空闲线程时，新的任务请求线程资源时，线程池该如何处理？各种处理策略又是如何实现的呢？

我们一般有两种处理策略。第一种是非阻塞的处理方式，直接拒绝任务请求；另一种是阻塞的处理方式，将请求排队，等到有空闲线程时，取出排队的请求继续处理。

那如何存储排队的请求呢？

我们希望公平地处理每个排队的请求，先进者先服务，所以队列这种数据结构很适合来存储排队请求。

我们前面说过，队列有基于链表和基于数组这两种实现方式。这两种实现方式对于排队请求又有什么区别呢？

基于链表的实现方式，可以实现一个支持无限排队的无界队列（unboundedqueue），但是可能会导致过多的请求排队等待，请求处理的响应时间过长。所以，针对响应时间比较敏感的系统，基于链表实现的无限排队的线程池是不合适的。

而基于数组实现的有界队列（boundedqueue），队列的大小有限，所以线程池中排队的请求超过队列大小时，接下来的请求就会被拒绝，这种方式对响应时间敏感的系统来说，就相对更加合理。不过，设置一个合理的队列大小，也是非常有讲究的。队列太大导致等待的请求太多，队列太小会导致无法充分利用系统资源、发挥最大性能。

除了前面讲到队列应用在线程池请求排队的场景之外，队列可以应用在任何有限资源池中，用于排队请求，比如数据库连接池等。实际上，对于大部分资源有限的场景，当没有空闲资源时，基本上都可以通过“队列”这种数据结构来实现请求排队。

10.1 Android的消息机制概述

Android的消息机制主要是指Handler的运行机制，从开发的角度来说，Handler 是Android消息机制的上层接口，通过它可以轻松地将一个任务切换到Handler所在的线程中去执行。Handler 的运行需要底层的MessageQueue和Looper的支撑。

• MessageQueue 消息队列，内部存储了一组消息，以队列的形式对外提供插入和删除的工作，采用单链表的数据结构来存储消息列表。
• Looper 消息循环。由于MessageQueue只是一个消息的存储单元，它不能去处理消息，而Looper就填补了这个功能，Looper 会以无限循环的形式去查找是否有新消息，如果有的话就处理消息，否则就一直等待着 。
• ThreadLocal 并不是线程，它的作用是可以在每个线程中存储数据。我们知道，Handler 创建的时候会采用当前线程的Looper来构造消息循环系统，那么Handler内部如何获取到当前线程的Looper呢?这就要使用ThreadLocal了，ThreadLocal可以在不同的线程中互不干扰地存储并提供数据，通过ThreadLocal可以轻松获取每个线程的Looper。
• 当然需要注意的是，线程是默认没有Looper的，如果需要使用Handler就必须为线程创建Looper。我们经常提到的主线程，也叫UI线程，它就是ActivityThread， ActivityThread 被创建时就会初始化Looper，这也是在主线程中默认可以使用Handler的原因。

10.2 Android的消息机制分析

子线程中无法访问UI

• 如何解决子线程中无法访问UI？
  • 答：使用Handler，将访问UI的工作切换到主线程。
• 为什么子线程中无法访问UI？
  • 答：这是因为Android的UI控件不是线程安全的，如果在多线程中并发访问可能会导致UI控件处于不可预期的状态。那为什么系统不对UI控件的访问加上锁机制呢?缺点有两个：首先加上锁机制会让UI访问的逻辑变得复杂;其次锁机制会降低UI访问的效率，因为锁机制会阻塞某些线程的执行。鉴于这两个缺点，最简单且高效的方法就是采用单线程模型来处理UI操作，对于开发者来说也不是很麻烦，只是需要通过Handler切换一下UI访问的执行线程即可。

Handler工作原理

1. 创建Handler和Looper。
   1. Handler创建时会采用当前线程的Looper来构建内部的消息循环系统，如果当前线程没有Looper，那么就会报错，需要手动创建Looper。
2. 发送消息。
   1. 通过Handler的post方法将一个Runnable投递到Handler内部的Looper中去处理，
   2. 也可以通过Handler的send方法发送一个消息，这个消息同样会在Looper中去处理。其实post方法最终也是通过send方法来完成的，接下来主要来看一下send方法的工作过程。
   3. 当Handler的send方法被调用时，它会调用MessageQueue的enqueueMesssagge方法将这个消息放入消息队列中。
3. 处理消息。
   1. Looper发现有新消息到来时，就会处理这个消息，最终消息中的Runnable或者Handler的handleMessage方法就会被调用。
   2. 注意Looper是运行在创建Handler所在的线程中的，这样一来Handler中的业务逻辑就被切换到创建Handler所在的线程中去执行了。

10.2.1 ThreadLocal的工作原理

ThreadLocal是一个线程内部的数据存储类，通过它可以在指定的线程中存储数据，数据存储以后，只有在指定线程中可以获取到存储的数据，对于其他线程来说则无法获取到数据。

在日常开发中用到ThreadLocal的地方较少，但是在某些特殊的场景下，通过ThreadLocal可以轻松地实现一些看起来很复杂的功能，这一点在Android的源码中也有所体现，比如Looper、 ActivityThread以及AMS中都用到了ThreadLocal。

ThreadLocal的使用场景：

1. 当某些数据是以线程为作用域并且不同线程具有不同的数据副本的时候，就可以考虑采用ThreadLocal。比如对于Handler来说，它需要获取当前线程的Looper， 很显然Looper的作用域就是线程并且不同线程具有不同的Looper，这个时候通过ThreadLocal就可以轻松实现Looper在线程中的存取。
2. ThreadLocal另一个使用场景是复杂逻辑下的对象传递，比如监听器的传递，有些时候一个线程中的任务过于复杂，这可能表现为函数调用栈比较深以及代码入口的多样性，在这种情况下，我们又需要监听器能够贯穿整个线程的执行过程，这个时候可以怎么做呢?其实这时就可以采用ThreadLocal，采用ThreadLocal可以让监听器作为线程内的全局对象而存在，在线程内部只要通过get方法就可以获取到监听器。

10.2.2 消息队列的工作原理

消息队列在Android中指的是MessageQueue, MessageQueue主要包含两个操作：插入和读取。数据结构是单链表，单链表在插入和删除上比较有优势。

• enqueueMessage 插入消息
• next 读取并移除一条消息。

next方法是一个无限循环的方法，如果消息队列中没有消息，那么next方法会一直阻塞在这里。 当有新消息到来时，next 方法会返回这条消息并将其从单链表中移除。

10.2.3 Looper的工作原理

Looper在Android的消息机制中扮演着消息循环的角色，具体来说就是它会不停地从MessageQueue中查看是否有新消息,如果有新消息就会立刻处理,否则就一直阻塞在那里。

Looper的工作原理

1. Looper.prepare()创建Looper
   • Looper的构造方法中会创建一个MessageQueue
2. Looper.loop()开启消息轮询
3. msg.target.dispatchMessage(msg)消息的发送者Handler分发消息然后处理

Looper的其他方法：

• prepareMainLooper方法，这个方法主要是给主线程也就是ActivityThread创建Looper使用的，其本质也是通过prepare方法来实现的。由于主线程的Looper比较特殊，所以Looper提供了一个getMainLooper方法，通过它可以在任何地方获取到主线程的Looper。
• 退出Looper，Looper提供了quit和quitSafely来退出一个Looper，二者的区别是: quit 会直接退出Looper，而quitSafely 只是设定一个退出标记，然后把消息队列中的已有消息处理完毕后才安全地退出。Looper 退出后，通过Handler发送的消息会失败，这个时候Handler的send方法会返回false。在子线程中，如果手动为其创建了Looper，那么在所有的事情完成以后应该调用quit方法来终止消息循环，否则这个子线程就会一直处于等待的状态，而如果退出Looper以后，这个线程就会立刻终

10.2.4 Handler的工作原理

Handler的工作主要包含消息的发送和接收过程。消息的发送可以通过post 的一系列方法以及send的一 系列方法来实现, post的一系列方法最终 是通过send的一系列方法来实现的。发送一条消息的典型过程如下所示。

1. 发送消息
   • Handler.sendMessageDelayed -> Handler.sendMessageAtTime() -> MessageQueue.enqueueMessage()
2. 分发消息 (Handler#dispatchMessage)
   1. 使用Message的callback处理消息
   2. 创建Handler的实例handleCallback处理消息
   3. 调用Handler的handleMessage来处理消息

10.3 主线程的消息循环

主线程ActivityThread的main方法中：

1. 创建主线程的Looper：Looper.prepareMainLooper();
2. 开启主线程的消息循环：Looper.loop();

ActivityThread.H
负责ActivityThread中的消息队列进行，它内部定义了一组消息类型，主要包含了四大组件的启动和停止等过程，如下所示。

Activity和四大组件通信间通信：

1. ActivityThread通过ApplicationThread和AMS发送请求
2. AMS完成请求后回调ApplicationThread中的Binder方法，然后ApplicationThread会向H发送消息
3. H收到消息后将ApplicationThread的逻辑切换到Activity中去执行

10.1 概述

10.1.1 Java虚拟机家族

1. HotSpot VM
2. J9 VM
3. Zing VM

10.1.2 Java虚拟机执行流程

10.2 Java虚拟机结构

10.2.1 Class文件格式

10.2.2 类的生命周期

类的生命周期：
一个Java文件，从被加载到Java虚拟机内存中到从内存中卸载的过程。

1. 加载：查找并加载Class文件。
2. 链接
   1. 验证：确保被导入类型的正确性。
   2. 准备：为类的静态字段分配字段，并用默认值初始化这些字段。
   3. 解析：虚拟机将常量池内的符号引用替换为直接引用。
3. 初始化：将类变量初始化为正确的初始值。
4. 使用
5. 卸载

10.2.3 类加载子系统

类加载子系统通过多种类加载器来查找和加载Class文件到Java虚拟机中。Java虚拟机有两种你那个类加载器：系统加载器和自定义加载器。

系统加载器：

1. Bootstrap ClassLoader（引导类加载器）
2. Extensions ClassLoader（拓展类加载器）
3. Application ClassLoader（应用程序类加载器）

10.2.4 运行时数据区域

1. 程序计数器
2. Java虚拟机栈
3. 本地方法栈
4. Java堆
5. 方法区
6. 运行时常量池
7. 直接内存

10.3 对象的创建

1. 判断对象对应的类是否加载、链接和初始化
2. 为对象分配内存
   1. 指针碰撞
   2. 空闲列表
3. 处理并发安全问题
   1. 分配内存进行同步处理
   2. 本地线程分配缓冲
4. 初始化分配到的内存空间
5. 设置对象的对象头
6. 执行init方法进行初始化

10.4 对象的堆内存布局

以HotSpot虚拟机为例，对象在堆内存的布局分为三个区域，分别是对象头（Header）、实例数据（Instance Data）、对齐填充（Padding）。

10.5 oop-klass模型

oop-klass模型模型是用来描述Java对象实例的一种模型，它分为两个部分，OOP（Ordinary Object Pointer）指普通对象指针，用来表示对象的实例信息。klass用来描述元数据。

10.6 垃圾标记算法

10.6.1 Java中的引用

1. 强引用：新建对象时引用，不会回收。
2. 软引用：SoftReference，内存不足时回收。
3. 弱引用：WeakReference，GC时回收。
4. 虚引用：PhantomReference，和对象生命周期没有关系；被回收时会收到一个系统通知。

10.6.2 引用计数算法

基本思想：背个对象都有一个引用计数器，当对象在某处类引用的时候，它的引用计数器加1，引用失效时减1。当引用计数器中的值为0，则该对象就不能被使用，变成了垃圾。

目前主流Java虚拟机并没有选择使用引用计数算法，因为它没有解决对象之间互相循环引用的问题。

10.6.3 根搜索算法

思想：选定一些对象作为GC Roots，并组成根对象集合，然后以这些GC Roots的对象作为起始点，向下搜索，如果目标对象到GC Roots是连接着的，我们则称为该对象是可达的，如果不可达则说说明目标对象是可以被回收的对象。如图：

在Java中，可以作为GC Roots的对象主要有以下几种：

• Java栈中引用的对象。
• 本地方法栈中JNI引用的对象。
• 方法区中运行时常量池引用的对象。
• 方法区中静态属性引用的对象。
• 运行中的线程。
• 由引导类加载器加载的对象。
• GC控制的对象。

10.7 Java对象在虚拟机中的生命周期

1. 创建阶段（Created）
   1. 为对象分配存储空间
   2. 构造对象
   3. 从超类到子类对static成员进行初始化
   4. 递归调用超类的构造方法
   5. 调用子类的构造方法
2. 应用阶段（In Use）
3. 不可见阶段（Invisible）
4. 不可达阶段（Unreachable）
5. 收集阶段（Collected）
6. 终结阶段（Finalized）
7. 对象空间重新分配阶段（Deallocated）

10.8 垃圾收集算法

10.8.1 标记—清除算法

• 标记阶段：标记处可以回收的对象
• 清除阶段：回收被标记的对象所占的空间。

缺点：

• 标记和清除的效率不高。
• 容易产生大量不连续的内存碎片，碎片太多可能导致没有足够的连续内存分配给较大对象，从而触发新的一次垃圾收集动作。

10.8.2 复制算法

为了解决标记—清除算法效率不高的问题。

1. 它把内存空间划分为两个相等的区域，每次只使用其中一个区域；
2. 在垃圾收集时，遍历当前使用的区域，把存活的对象复制到另一个区域中，最后将当前使用的区域的可回收对象进行回收。

• 这种算法每次对整个半区进行内存回收，不需要考虑内存碎片问题，代价就是使用内存为原来的一般。
• 复制算法的效率与存活对象数目有很大关系，如果存活对象很少，复制算法的效率就会很高。所以复制算法广泛应用于新生代中。

10.8.3 标记-压缩算法

老年代不适用复制算法，因为老年代对象存活率高，会有很多复制操作，导致效率变低。

标记-压缩算法在标记可回收的对象后，将所有存活的对象压缩到内存的另一端，使他们紧凑地排列在一起，然后对边界以外的内存进行回收。

10.8.4 分代收集算法

对不同生命周期的对象采取不同的收集算法，这就是分代的概念。

• 新生代
  • Eden空间
  • From Survivor空间
  • To Survivor空间
• 老年代

Eden空间中大多数对象生命周期很短，Eden空间和两个Survivor空间所占比例为8:1。

根据Java堆区的空间划分，垃圾收集的类型分为两种：

• Minor Collection：新生代垃圾收集
• Full Collection ：老年代收集。又称Major Collection。

Full Collection通常情况下伴随至少一次的Minor Collection，收集频率较低，耗时较长。

10.9 本章小结

• 为什么要使用多线程？
• 多线程的应用场景
• 创建多少线程合适？

要解决这个问题，首先要分析以下两个问题：

1. 为什么要使用多线程？
2. 多线程的应用场景有哪些？

为什么要使用多线程？

使用多线程，本质上就是提升程序性能。

在提升性能之前，首要问题是：如何度量性能。

度量性能的指标有很多，但是有两个指标是最核心的，它们就是延迟和吞吐量。

• 延迟指的是发出请求到收到响应这个过程的时间；延迟越短，意味着程序执行得越快，性能也就越好。
• 吞吐量指的是在单位时间内能处理请求的数量；吞吐量越大，意味着程序能处理的请求越多，性能也就越好。

这两个指标内部有一定的联系（同等条件下，延迟越短，吞吐量越大），但是由于它们隶属不同的维度（一个是时间维度，一个是空间维度），并不能互相转换。

我们所谓提升性能，从度量的角度，主要是降低延迟，提高吞吐量。

多线程的应用场景

要想“降低延迟，提高吞吐量”，对应的方法呢，基本上有两个方向，一个方向是优化算法，另一个方向是将硬件的性能发挥到极致。前者属于算法范畴，后者则是和并发编程息息相关了。那计算机主要有哪些硬件呢？主要是两类：一个是 I/O，一个是 CPU。简言之，在并发编程领域，提升性能本质上就是提升硬件的利用率，再具体点来说，就是提升 I/O 的利用率和 CPU 的利用率。

操作系统解决硬件利用率问题的对象往往是单一的硬件设备，而我们的并发程序，往往需要 CPU 和 I/O 设备相互配合工作，也就是说，我们需要解决 CPU 和 I/O 设备综合利用率的问题。关于这个综合利用率的问题，操作系统虽然没有办法完美解决，但是却给我们提供了方案，那就是：多线程。

如下图所示，如果只有一个线程，执行 CPU 计算的时候，I/O 设备空闲；执行 I/O 操作的时候，CPU 空闲，所以 CPU 的利用率和 I/O 设备的利用率都是 50%。

如果有两个线程，如下图所示，当线程 A 执行 CPU 计算的时候，线程 B 执行 I/O 操作；当线程 A 执行 I/O 操作的时候，线程 B 执行 CPU 计算，这样 CPU 的利用率和 I/O 设备的利用率就都达到了 100%。

我们将 CPU 的利用率和 I/O 设备的利用率都提升到了 100%，会对性能产生了哪些影响呢？通过上面的图示，很容易看出：单位时间处理的请求数量翻了一番，也就是说吞吐量提高了 1 倍。此时可以逆向思维一下，如果 CPU 和 I/O 设备的利用率都很低，那么可以尝试通过增加线程来提高吞吐量。

在单核时代，多线程主要就是用来平衡 CPU 和 I/O 设备的。如果程序只有 CPU 计算，而没有 I/O 操作的话，多线程不但不会提升性能，还会使性能变得更差，原因是增加了线程切换的成本。但是在多核时代，这种纯计算型的程序也可以利用多线程来提升性能。为什么呢？因为利用多核可以降低响应时间。

为便于你理解，这里我举个简单的例子说明一下：计算 1+2+… … +100 亿的值，如果在 4 核的 CPU 上利用 4 个线程执行，线程 A 计算 [1，25 亿)，线程 B 计算 [25 亿，50 亿)，线程 C 计算 [50，75 亿)，线程 D 计算 [75 亿，100 亿]，之后汇总，那么理论上应该比一个线程计算 [1，100 亿] 快将近 4 倍，响应时间能够降到 25%。一个线程，对于 4 核的 CPU，CPU 的利用率只有 25%，而 4 个线程，则能够将 CPU 的利用率提高到 100%。

创建多少线程合适？

创建多少线程合适，要看多线程具体的应用场景。我们的程序一般都是 CPU 计算和 I/O 操作交叉执行的，由于 I/O 设备的速度相对于 CPU 来说都很慢，所以大部分情况下，I/O 操作执行的时间相对于 CPU 计算来说都非常长，这种场景我们一般都称为 I/O 密集型计算；和 I/O 密集型计算相对的就是 CPU 密集型计算了，CPU 密集型计算大部分场景下都是纯 CPU 计算。I/O 密集型程序和 CPU 密集型程序，计算最佳线程数的方法是不同的。

对于 CPU 密集型计算，多线程本质上是提升多核 CPU 的利用率，所以对于一个 4 核的 CPU，每个核一个线程，理论上创建 4 个线程就可以了，再多创建线程也只是增加线程切换的成本。所以，对于 CPU 密集型的计算场景，理论上“线程的数量 =CPU 核数”就是最合适的。不过在工程上，线程的数量一般会设置为“CPU 核数 +1”，这样的话，当线程因为偶尔的内存页失效或其他原因导致阻塞时，这个额外的线程可以顶上，从而保证 CPU 的利用率。

对于 I/O 密集型的计算场景，比如前面我们的例子中，如果 CPU 计算和 I/O 操作的耗时是 1:1，那么 2 个线程是最合适的。如果 CPU 计算和 I/O 操作的耗时是 1:2，那多少个线程合适呢？是 3 个线程，如下图所示：CPU 在 A、B、C 三个线程之间切换，对于线程 A，当 CPU 从 B、C 切换回来时，线程 A 正好执行完 I/O 操作。这样 CPU 和 I/O 设备的利用率都达到了 100%。

通过上面这个例子，我们会发现，对于 I/O 密集型计算场景，最佳的线程数是与程序中 CPU 计算和 I/O 操作的耗时比相关的，我们可以总结出这样一个公式：

最佳线程数 =1 +（I/O 耗时 / CPU 耗时）

我们令 R=I/O 耗时 / CPU 耗时，综合上图，可以这样理解：当线程 A 执行 IO 操作时，另外 R 个线程正好执行完各自的 CPU 计算。这样 CPU 的利用率就达到了 100%。

不过上面这个公式是针对单核 CPU 的，至于多核 CPU，也很简单，只需要等比扩大就可以了，计算公式如下：

最佳线程数 =CPU 核数 * [ 1 +（I/O 耗时 / CPU 耗时）]

总结

很多人都知道线程数不是越多越好，但是设置多少是合适的，却又拿不定主意。其实只要把握住一条原则就可以了，这条原则就是将硬件的性能发挥到极致。上面我们针对 CPU 密集型和 I/O 密集型计算场景都给出了理论上的最佳公式，这些公式背后的目标其实就是将硬件的性能发挥到极致。

对于 I/O 密集型计算场景，I/O 耗时和 CPU 耗时的比值是一个关键参数，不幸的是这个参数是未知的，而且是动态变化的，所以工程上，我们要估算这个参数，然后做各种不同场景下的压测来验证我们的估计。不过工程上，原则还是将硬件的性能发挥到极致，所以压测时，我们需要重点关注 CPU、I/O 设备的利用率和性能指标（响应时间、吞吐量）之间的关系。

课后思考

有些同学对于最佳线程数的设置积累了一些经验值，认为对于 I/O 密集型应用，最佳线程数应该为：2 * CPU 的核数 + 1，你觉得这个经验值合理吗？

不合理，应该根据是IO密集型或者是CPU密集型，具体问题具体分析。
老师：我们曾讲到最佳线程数最终还是靠压测来确定的，实际工作中大家面临的系统，“I/O 耗时 / CPU 耗时”往往都大于 1，所以基本上都是在这个初始值的基础上增加。增加的过程中，应关注线程数是如何影响吞吐量和延迟的。一般来讲，随着线程数的增加，吞吐量会增加，延迟也会缓慢增加；但是当线程数增加到一定程度，吞吐量就会开始下降，延迟会迅速增加。这个时候基本上就是线程能够设置的最大值了。

10.1概述302

10.2Javac编译器303

10.2.1Javac的源码与调试303

10.2.2解析与填充符号表305

10.2.3注解处理器307

10.2.4语义分析与字节码生成307

10.3Java语法糖的味道311

10.3.1泛型与类型擦除311

10.3.2自动装箱、拆箱与遍历循环315

10.3.3条件编译317

10.4实战：插入式注解处理器318

10.4.1实战目标318

10.4.2代码实现319

10.4.3运行与测试326

10.4.4其他应用案例327

10.5本章 小结328

自定义语言的实现——解释器模式

解释器模式（Interpreter Pattern）提供了评估语言的语法或表达式的方式，它属于行为型模式。这种模式实现了一个表达式接口，该接口解释一个特定的上下文。这种模式被用在 SQL 解析、符号处理引擎等。

介绍

意图：给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。
主要解决：对于一些固定文法构建一个解释句子的解释器。
何时使用：如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
如何解决：构建语法树，定义终结符与非终结符。
关键代码：构建环境类，包含解释器之外的一些全局信息，一般是 HashMap。
应用实例：编译器、运算表达式计算。
优点： 1、可扩展性比较好，灵活。 2、增加了新的解释表达式的方式。 3、易于实现简单文法。
缺点： 1、可利用场景比较少。 2、对于复杂的文法比较难维护。 3、解释器模式会引起类膨胀。 4、解释器模式采用递归调用方法。
使用场景： 1、可以将一个需要解释执行的语言中的句子表示为一个抽象语法树。 2、一些重复出现的问题可以用一种简单的语言来进行表达。 3、一个简单语法需要解释的场景。
注意事项：可利用场景比较少，JAVA 中如果碰到可以用 expression4J 代替。

如何理解递归？

递归是一种应用非常广泛的算法（或者编程技巧），数据结构和算法的编码实现都要用到递归，比如DFS深度优先搜索、前中后序二叉树遍历等等。

递归需要满足的三个条件：

1. 一个问题的解可以分解为几个子问题的解
2. 这个问题与分解之后的子问题，除了数据规模不同，求解思路完全一样
3. 存在递归终止条件

如何编写递归代码？
写出递推公式，找到终止条件
写递归代码的关键就是找到如何将大问题分解为小问题的规律，并且基于此写出递推公式，然后再推敲终止条件，最后将递推公式和终止条件翻译成代码。

理解起来比较吃力？
把它抽象成一个递推公式，不用想一层层的调用关系，不要试图用人脑去分解递归的每个步骤。

递归代码要警惕堆栈溢出

为什么递归代码容易造成堆栈溢出呢？
函数调用会使用栈来保存临时变量。每调用一个函数，都会将临时变量封装为栈帧压入内存栈，等函数执行完成返回时，才出栈。系统栈或者虚拟机栈空间一般都不大。如果递归求解的数据规模很大，调用层次很深，一直压入栈，就会有堆栈溢出的风险。

如何预防堆栈溢出呢？

1. 我们可以通过在代码中限制递归调用的最大深度的方式来解决这个问题。递归调用超过一定深度（比如1000）之后，我们就不继续往下再递归了，直接返回报错。
2. 但这种做法并不能完全解决问题，因为最大允许的递归深度跟当前线程剩余的栈空间大小有关，事先无法计算。如果实时计算，代码过于复杂，就会影响代码的可读性。所以，如果最大深度比较小，比如10、50，就可以用这种方法，否则这种方法并不是很实用。

递归代码要警惕重复计算

为了避免重复计算，我们可以通过一个数据结构（比如散列表）来保存已经求解过的f(k)。当递归调用到f(k)时，先看下是否已经求解过了。如果是，则直接从散列表中取值返回，不需要重复计算，这样就能避免刚讲的问题了。

其他问题
在时间效率上，递归代码里多了很多函数调用，当这些函数调用的数量较大时，就会积聚成一个可观的时间成本。在空间复杂度上，因为递归调用一次就会在内存栈中保存一次现场数据，所以在分析递归代码空间复杂度时，需要额外考虑这部分的开销。

可以将递归代码改为迭代循环的非递归写法

对于递归代码，你有什么好的调试方法呢？

1. 打印日志发现，递归值。
2. 结合条件断点进行调试。

• AsyncTask封装了线程池和Handler,它主要是为了方便开发者在子线程中更新UI。
• HandlerThread是一种具有消息循环的线程，在它的内部可以使用Handler。
• IntentService是一个服务，系统对其进行了封装使其可以更方便地执行后台任务，IntentService 内部采用HandlerThread来执行任务，当任务执行完毕后IntentService 会自动退出。 它不容易被系统杀死从而可以尽量保证任务的执行。

11.1 主线程和子线程

• 主线程：进程所拥有的线程，主要处理界面交互相关的逻辑。
• 子线程：除主线程之外都是子线程，主要用于执行耗时操作。

11.2 Android中的线程形态

11.2.1 AsyncTask

轻量级的异步任务类，可以执行后台任务以及在子线程中进行UI操作。

主要方法：

1. onPreExecute()
2. doInBackground(Params…params)：
3. onProgressUpdate(Progress…values)
4. onPostExecute(Result result)
5. onCancelled()
6. execute(Params...params)

11.2.2 AsyncTask的工作原理

1. AsyncTask构造方法中：
   1. 实例化Handler，类型是InternalHandler，用于切换到主线程
   2. 实例化mWorker，类型是WorkerRunnable，封装了Params和Result；
   3. 实例化mFuture，类型是FutureTask，参数为mWorker。FutureTask是一个并发类，在这里它充当了Runnable的作用。
2. 执行任务
   1. execute方法会调用executeOnExecutor(sDefaultExecutor, params)。
      1. 参数sDefaultExecutor，类型为SerialExecutor，是一个串行的线程池，一个进程中所有的AsyncTask全部在这个串行的线程池中排队执行。
      2. SerialExecutor#execute。(1) ArrayDeque.offer(Runnable)。把FutureTask对象插入到任务队列mTasks中；(2) scheduleNext()。如果没有正在活动的任务，或者当一个任务执行完后，会调用scheduleNext方法执行下一个任务，直到所有的任务都被执行。scheduleNext中，调用THREAD_POOL_EXECUTOR.execute()，真正地执行任务。
   2. executeOnExecutor
      1. 调用onPreExecute()
      2. exec.execute(mFuture);线程池执行。
3. 响应结果
   1. mWorker的call()中调用doInBackground(mParams)和 postResult()
   2. postResult中，Handler调用sendToTarget()发送消息。
   3. InternalHandler中，onProgressUpdate和finish。

4. 结束或取消onCancelled、onPostExecute

   从Android 3.0 开始，默认情况下AsyncTask是串行执行的，可以调用executeOnExecutor方法并行执行。

11.2.3 HandlerThread

• HandlerThread本质上是一个线程类，它继承了Thread；
• HandlerThread有自己的内部Looper对象，可以进行looper循环；
• 通过获取HandlerThread的looper对象传递给Handler对象，可以在handleMessage方法中执行异步任务。
• 创建HandlerThread后必须先调用HandlerThread.start()方法，Thread会先调用run方法，创建Looper对象。
• 当不需要HandlerThread时，通过HandlerThread.quit()/quitSafely()方法来终止线程的执行

11.2.4 IntentService

可自动创建子线程来执行任务，且任务执行完毕后自动退出。

• 在IntentService.onCreate()里创建一个Handle对象即HandlerThread，利用其内部的Looper会实例化一个ServiceHandler对象；
• 任务请求的Intent会被封装到Message并通过ServiceHandler发送给Looper的MessageQueue，最终在HandlerThread中执行；
• 在ServiceHandler.handleMessage()中会调用IntentService.onHandleIntent()，可在该方法中处理后台任务的逻辑。

11.3 Android中的线程池

线程池的优点：

• 重用线程池中的线程，避免线程的创建和销毁带来的性能消耗；
• 有效控制线程池的最大并发数，避免大量的线程之间因互相抢占系统资源而导致阻塞现象；
• 能够进行线程管理，提供定时/循环间隔执行等功能。

Android中的线程池的概念来源于Java中的Executor, Executor是一个接口，真正的线程池的实现为ThreadPoolExecutor。ThreadPoolExecutor 提供了一系列参数来配置线程池，通过不同的参数可以创建不同的线程池。

11.3.1 ThreadPoolExecutor

ThreadPoolExecutor构造方法：

public ThreadPoolExecutor(
    int corePoolSize,   //核心线程数
    int maximumPoolSize,//最大线程数
    long keepAliveTime,//非核心线程超时时间
    TimeUnit unit,//keepAliveTime参数的时间单位
    BlockingQueue<Runnable> workQueue,//任务队列
    ThreadFactory threadFactory,//线程工厂，可创建新线程
    RejectedExecutionHandler handler//饱和策略
)

ThreadPoolExecutor的默认工作策略：

• 如果线程池中的线程数量未达到核心线程数，则会直接启动一个核心线程执行任务。
• 若线程池中的线程数量已达到或者超过核心线程数量，则任务会被插入到任务列表等待执行。
• 若任务无法插入到任务列表中，往往由于任务列表已满，此时如果：
  • 线程数量未达到线程池最大线程数，则会启动一个非核心线程执行任务；
  • 线程数量已达到线程池规定的最大值，则拒绝执行此任务

如果条件为否：核心线程 > 任务列表 > 非核心线程 > 拒接任务。

AsyncTask的THREAD_POOL_EXECUTOR线程池配置参数：

• 核心线程数：CPU_COUNT - 1，最小为2最大为4;
• 线程池的最大线程数：CPU_COUNT * 2+ 1;
• 核心线程无超时机制，非核心线程在闲置时的超时时间为30秒;
• 任务队列的容量为128。

11.3.2 线程池的分类

• FixedThreadPool：
  • 含义：线程数量固定的线程池，所有线程都是核心线程，当线程空闲时不会被回收。
  • 特点：能快速响应外界请求。
• CachedThreadPool：
  • 含义：线程数量不定的线程池（最大线程数为Integer.MAX_VALUE），只有非核心线程，空闲线程有超时机制，60s超时回收。
  • 特点：适合于执行大量的耗时较少的任务
• ScheduledThreadPool：
  • 含义：核心线程数量固定，非核心线程数量不定。
  • 特点：定时任务和固定周期的任务。
• SingleThreadExecutor：
  • 含义：只有一个核心线程，可确保所有的任务都在同一个线程中按顺序执行。
  • 特点：无需处理线程同步问题。

11.1 Dalvik虚拟机

Dalvik虚拟机(Dalvik Virtual Machine )，简称Dalvik VM或者DVM。DVM是Google专门为Android平台开发的虚拟机，它运行在Android运行时库中。需要注意的是DVM并不是一个Java 虚拟机(以下简称JVM)。

11.1.1 DVM与JVM的区别

DVM之所以不是一个 JVM,主要原因是DVM并没有遵循JVM规范来实现， DVM与JVM主要有以下区别。

1. 基于的架构不同
   JVM基于栈则意味着需要去栈中读写数据，所需的指令会更多,这样会导致速度变慢，对于性能有限的移动设备，显然不是很适合的。DVM是基于寄存器的，它没有基于栈的虚拟机在复制数据时而使用的大量的出入栈指令，同时指令更紧凑、更简洁。但是由于显式指定了操作数,所以基于寄存器的指令会比基于栈的指令要大，但是由于指令数量的减少，总的代码数不会增加多少。

2. 执行的字节码不同
   在Java SE程序中，Java类被编译成一个或多个.class文件，并打包成jar文件，而后JVM会通过相应的.class文件和jar文件获取相应的字节码。执行顺序为.java文件→.class 文件→.jar文件。
   而DVM会用dx工具将所有的.class文件转换为一个.dex文件，然后DVM会从该dex文件读取指令和数据。执行顺序为.java文件→.class文件一→.dex文件。

   jar 文件里面包含多个.class文件，每个.class文件里面包含了该类的常量池、类信息、属性等。当JVM加载该jar文件的时候，会加载里面的所有的.class文件，JVM的这种加载方式很慢，对于内存有限的移动设备并不合适。而在.apk文件中只包含了一个.dex文件，这个.dex文件将所有的.class里面所包含的信息全部整合在一起了，这样再加载就加快了速度。.class 文件存在很多的冗余信息，dex 工具会去除冗余信息，并把所有的.class文件整合到.dex文件中，减少了IO操作，加快了类的查找速度。
   

3. DVM允许在有限的内存中同时运行多个进程
   DVM经过优化,允许在有限的内存中同时运行多个进程。在Android中的每一个应用都运行在一个DVM实例中，每一个DVM实例都运行在一个独立的进程空间中，独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。

4. DVM由Zygote创建和初始化
   我们在第2章学习过Zygote，它是一个DVM进程，同时也用来创建和初始化DVM实例。每当系统需要创建一个应用程序时 ，Zygote 就会fock 自身，快速地创建和初始化一个DVM实例，用于应用程序的运行。对于一些只读的系统库，所有的DVM实例都会和Zygote共享一块内存区域，节省了内存开销。

5. DVM有共享机制.
   DVM拥有预加载一共 享的机制，不同应用之间在运行时可以共享相同的类，拥有更 高的效率。而JVM机制不存在这种共享机制，不同的程序,打包以后的程序都是彼此独立的,即便它们在包里使用了同样的类，运行时也都是单独加载和运行的，无法进行共享。

6. DVM早期没有使用JIT编译器
   JVM使用了JIT编译器(Just In Time Compiler,即时编译器)，而DVM早期没有使用JIT编译器。早期的DVM每次执行代码，都需要通过解释器将dex代码编译成机器码，然后交给系统处理，效率不是很高。为了解决这一问题，从Android 2.2版本开始DVM使用了JIT 编译器，它会对多次运行的代码(热点代码)进行编译，生成相当精简的本地机器码(Native Code)，这样在下次执行到相同逻辑的时候，直接使用编译之后的本地机器码，而不是每次都需要编译。需要注意的是，应用程序每一次重新运行的时候，都要重做这个编译工作，因此每次重新打开应用程序，都需要JIT编译。

11.1.2 DVM架构

首先Java编译器编译的.class文件经过DX工具转换为.dex文件，.dex文件由类加载器处理，接着解释器根据指令集对Dalvik字节码进行解释、执行，最后交于Linux处理。

11.1.3 DVM的运行时堆

DVM的运行时堆使用标记一清除(Mark一Sweep) 算法进行GC，它由两个Space以及多个辅助数据结构组成，两个Space分别是Zygote Space (Zygote Heap)和Allocation Space(Active Heap)。Zygote Space用来管理Zygote进程在启动过程中预加载和创建的各种对象，Zygote Space中不会触发GC,在Zygote进程和应用程序进程之间会共享Zygote Space。在Zygote进程fork第一个子进程之前，会把Zygote Space分为两个部分，原来的已经被使用的那部分堆仍旧叫Zygote Space， 而未使用的那部分堆就叫Allocation Space， 以后的对象都会在Allocation Space上进行分配和释放。Allocation Space不是进程间共享的，在每个进程中都独立拥有一份。除了这两个Space，还包含以下数据结构。

• Card Table: 用于DVM Concurrent GC，当第一次进行垃圾标记后，记录垃圾信息。
• Heap Bitmap: 有两个Heap Bitmap， 一个用来记录上次GC存活的对象，另一个用来记录这次GC存活的对象。
• Mark Stack: DVM的运行时堆使用标记一清除(Mark一 Sweep)算法进行GC，MarkStack就是在GC的标记阶段使用的，它用来遍历存活的对象。

11.1.4 DVM的GC日志

在10.6.2节中提到了Java虚拟机的GC日志。DVM和ART的GC日志与Java虚拟机的日志有较大的区别。在DVM中每次垃圾收集都会将GC日志打印到logcat中，具体的格式为:

D/dalvikvm: <GC Reason> <Amount freed>， <Heap stats>，<External memory stats>,<Pause t ime>

可以看到DVM的日志共有5个信息，其中GCReason有很多种，这里将它单独拿出来进行介绍。

1.引起GC的原因
GC Reason就是引起GC的原因，有以下几种。

• GC_CONCURRENT: 当堆开始填充时，并发GC可以释放内存。
• GC_FOR_MALLOC:当堆内存已满时，App尝试分配内存而引起的GC，系统必须停止App并回收内存。
• GC_HPROF_DUMP_HEAP:当你请求创建HPROF文件来分析堆内存时出现的GC。
• GC_EXPLICIT: 显式的GC，例如调用System.gc() (应该避免调用显式的GC,信任GC会在需要时运行)。
• GC_EXTERNAL_ALLOC: 仅适用于API级别小于等于10， 且用于外部分配内存的GC。

2.其他的信息
除了引起GC的原因，其他的信息如下。

• Amount freed: 本次GC释放内存的大小。
• Heap_stats: 堆的空闲内存百分比(已用内存) / (堆的总内存)。
• External_memory_stats: API小于等于级别10的内存分配(已分配的内存) / (引起GC的阈值)。
• Pausetime:暂停时间，更大的堆会有更长的暂停时间。并发暂停时间会显示两个暂停时间，即一个出现在垃圾收集开始时，另一个出现在垃圾收集快要完成时。

3.实例分析

D/dalvikvm: GC CONCURRENT freed 2012K, 63号 free 3213K/9291K, external 4501K/5161K,paused 2ms+2ms

这个GC日志的含义为:引起GC的原因是GC_CONCURRENT;本次GC释放的内存为2012KB; 堆的空闲内存百分比为63%， 已用内存为3213KB，堆的总内存为9291KB;暂停的总时长为4ms。

11.2 ART虚拟机

ART (Android Runtime)虚拟机是Android 4.4发布的,用来替换Dalvik虚拟机，Android4.4默认采用的还是DVM,系统会提供一 个选项来开启ART。在Android 5.0版本中默认采用了ART, DVM从此退出历史舞台。

11.2.1 ART与DVM的区别

1. 从11.1节我们知道，DVM中的应用每次运行时,字节码都需要通过JIT编译器编译为机器码，这会使得应用程序的运行效率降低。而在ART中，系统在安装应用程序时会进行一次AOT (ahead of time compilation, 预编译)，将字节码预先编译成机器码并存储在本地，这样应用程序每次运行时就不需要执行编译了，运行效率会大大提升，设备的耗电量也会降低。这就好比我们在线阅读漫画，DVM是我们阅读到哪就加载哪，ART则是直接加载一章的漫画,虽然一开始加载速度有些慢,但是后续的阅读体验会很流畅。采用AOT也会有缺点，主要有两个:第一个是AOT会使得应用程序的安装时间变长，尤其是一些复杂的应用;第二个是字节码预先编译成机器码，机器码需要的存储空间会多一些。为了解决上面的缺点，Android 7.0版本中的ART加入了即时编译器JIT，作为AOT的一个补充，在应用程序安装时并不会将字节码全部编译成机器码，而是在运行中将热点代码编译成机器码，从而缩短应用程序的安装时间并节省了存储空间。
2. DVM是为32位CPU设计的，而ART支持64位并兼容32位CPU,这也是DVM被淘汰的主要原因之一。
3. ART对垃圾回收机制进行了改进，比如更频繁地执行并行垃圾收集，将GC暂停由2次减少为1次等。
4. ART的运行时堆空间划分和DVM不同。

11.2.2 ART的运行时堆

与DVM的GC不同的是，ART采用了多种垃圾收集方案，每个方案会运行不同的垃圾收集器,默认是采用了CMS(Concurrent Mark一Sweep)方案,该方案主要使用了sticky一CMS和partial一CMS。根据不同的CMS方案，ART的运行时堆的空间也会有不同的划分，默认是由4个Space和多个辅助数据结构组成的，4个Space分别是Zygote Space、AllocationSpace、Image Space和Large Object Space。Zygote Space、Allocation Space和DVM中的作用是一样的，Image Space用来存放一些预加载类, Large Object Space用来分配一些大对象(默认大小为12KB)，其中Zygote Space和Image Space是进程间共享的。采用标记一清除算法的运行时堆空间划分如图11一3所示。

除了这四个Space，ART的Java堆中还包括两个Mod Union Table, 一个Card Table,两个Heap Bitmap,两个Object Map，以及三个Object Stack。

11.2.3 ART的GC日志

ART的GC日志与DVM不同，ART会为那些主动请求的垃圾收集事件或者认为GC速度慢时才会打印GC日志。GC速度慢指的是GC暂停超过5ms或者GC持续时间超过100ms。如果App未处于可察觉的暂停进程状态，那么它的GC不会被认为是慢速的。
ART的GC日志具体的格式为:

I/art: <GC_Reason> <GC_Name> <0bjects_freed> (<Size_freed>) AllocSpace Objects,<Large_objects_freed> (<Large_object_size_freed>) <Heap_stats> LOS objects,
<Pause time(s)>

1.引起GC原因
ART的引起GC原因(GC_Reason) 要比DVM多一些，有以下几种。

• Concurrent: 并发GC,不会使App的线程暂停，该GC是在后台线程运行的，并不会阻止内存分配。
• Alloc: 当堆内存已满时，App尝试分配内存而引起的GC，这个GC会发生在正在.分配内存的线程中。
• Explicit: App 显示的请求垃圾收集，例如调用System.gc()。与DVM一样，最佳做法是应该信任GC并避免显式地请求GC,显式地请求GC会阻止分配线程并不必要地浪费CPU周期。如果显式地请求GC导致其他线程被抢占,那么有可能会导致jank(App同一帧画了多次)。
• NativeAlloc: Native 内存分配时，比如为Bitmaps或者RenderScript分配对象，这会导致Native内存压力，从而触发GC。
• CollectorTransition: 由堆转换引起的回收，这是运行时切换GC而引起的。收集器转换包括将所有对象从空闲列表空间复制到碰撞指针空间(反之亦然)。 当前，收集器转换仅在以下情况下出现:在内存较小的设备.上，App将进程状态从可察觉的暂停状态变更为可察觉的非暂停状态(反之亦然)。
• HomogeneousSpaceCompact: 齐性空间压缩是指空闲列表到压缩的空闲列表空间，通常发生在当App已经移动到可察觉的暂停进程状态时。这样做的主要原因是减少了内存使用并对堆内存进行碎片整理。
• DisableMovingGc: 不是真正触发GC的原因，发生并发堆压缩时，由于使用了GetPrimitiveArrayCritical，收集会被阻塞。在一般情况下，强烈建议不要使用GetPrimitiveArrayCritical，因为它在移动收集器方面具有限制。
• HeapTrim: 不是触发GC的原因，但是请注意，收集会一直被阻塞，直到堆内存整理完毕。

2.垃圾收集器名称
GC_Name指的是垃圾收集器名称，有以下几种。

• Concurrent Mark Sweep (CMS)：CMS 收集器是一种以获取最短收集暂停时间为目标的收集器，采用了标记一清除算法实现。它是完整的堆垃圾收集器，能释放除了Image Space外的所有的空间。
• Concurrent Partial Mark Sweep：部分完整的堆垃圾收集器，能释放除了Image Space和Zygote Space外的所有空间。
• Concurrent Sticky Mark Sweep：粘性收集器，基于分代的垃圾收集思想，它只能释放自.上次GC以来分配的对象。这个垃圾收集器比一个完整的或部分完整的垃圾收集器扫描得更频繁，因为它更快并且有更短的暂停时间。
• Marksweep + Semispace：非并发的GC,复制GC用于堆转换以及齐性空间压缩(堆碎片整理)。

3.其他信息

• Objects freed：本次GC从非Large Object Space中回收的对象的数量。
• Size_ freed： 本次GC从非Large Object Space中回收的字节数。
• Large objects freed：本次GC从Large Object Space中回收的对象的数量。
• Large object size freed：本次GC从Large Object Space中回收的字节数。
• Heap stats：堆的空闲内存百分比，即(已用内存) / (堆的总内存)。
  Pause times： 暂停时间， 暂停时间与在GC运行时修改的对象引用的数量成比例。目前，ART的CMS收集器仅有一次暂停，它出现在GC的结尾附近。移动的垃圾收集器暂停时间会很长，会在大部分垃圾回收期间持续出现。

4.实例分析

I/art : Explicit concurrent mark sweep GC freed 104710 (7MB) AllocSpace objects,21 (416KB) LOS objects， 33号free, 25MB/ 38MB, paused 1.230ms total 67.21 6ms

这个GC日志的含义为引起GC原因是Explicit; 垃圾收集器为CMS收集器;释放对象的数量为104710个，释放字节数为7MB;释放大对象的数量为21个，释放大对象字节数为416KB;堆的空闲内存百分比为33%，已用内存为25MB,堆的总内存为38MB; GC暂停时长为1.230ms， GC总时长为67.216ms。

11.3 DVM和ART的诞生

11.4 本章小结

• 方法是如何被执行的
• 局部变量存哪里？
• 调用栈与线程
• 线程封闭

方法是如何被执行的

int a = 7；
int[] b = fibonacci(a);
int[] c = b;

当调用 fibonacci(a) 的时候，CPU 要先找到方法 fibonacci() 的地址，然后跳转到这个地址去执行代码，最后 CPU 执行完方法 fibonacci() 之后，要能够返回。首先找到调用方法的下一条语句的地址：也就是int[] c=b;的地址，再跳转到这个地址去执行。

“CPU 去哪里找到调用方法的参数和返回地址？”

通过 CPU 的堆栈寄存器。CPU 支持一种栈结构，先入后出。因为这个栈是和方法调用相关的，因此经常被称为调用栈。

例如，有三个方法 A、B、C，他们的调用关系是 A->B->C（A 调用 B，B 调用 C），在运行时，会构建出下面这样的调用栈。每个方法在调用栈里都有自己的独立空间，称为栈帧，每个栈帧里都有对应方法需要的参数和返回地址。当调用方法时，会创建新的栈帧，并压入调用栈；当方法返回时，对应的栈帧就会被自动弹出。也就是说，栈帧和方法是同生共死的。

局部变量存哪里？

局部变量的作用域是方法内部，也就是说当方法执行完，局部变量就没用了，局部变量应该和方法同生共死。此时你应该会想到调用栈的栈帧，调用栈的栈帧就是和方法同生共死的，所以局部变量放到调用栈里那儿是相当的合理。事实上，的确是这样的，局部变量就是放到了调用栈里。

Java中new 出来的对象是在堆里，局部变量是在栈里。局部变量是和方法同生共死的，一个变量如果想跨越方法的边界，就必须创建在堆里。

调用栈与线程

两个线程可以同时用不同的参数调用相同的方法，那调用栈和线程之间是什么关系呢？答案是：每个线程都有自己独立的调用栈。因为如果不是这样，那两个线程就互相干扰了。如下面这幅图所示，线程 A、B、C 每个线程都有自己独立的调用栈。

现在，让我们回过头来再看篇首的问题：Java 方法里面的局部变量是否存在并发问题？现在你应该很清楚了，一点问题都没有。因为每个线程都有自己的调用栈，局部变量保存在线程各自的调用栈里面，不会共享，所以自然也就没有并发问题。

线程封闭

方法里的局部变量，因为不会和其他线程共享，所以没有并发问题，这个思路很好，已经成为解决并发问题的一个重要技术，同时还有个响当当的名字叫做线程封闭，比较官方的解释是：仅在单线程内访问数据。

采用线程封闭技术的案例非常多，例如从数据库连接池里获取的连接 Connection，在 JDBC 规范里并没有要求这个 Connection 必须是线程安全的。数据库连接池通过线程封闭技术，保证一个 Connection 一旦被一个线程获取之后，在这个线程关闭 Connection 之前的这段时间里，不会再分配给其他线程，从而保证了 Connection 不会有并发问题。

课后思考

常听人说，递归调用太深，可能导致栈溢出。你思考一下原因是什么？有哪些解决方案呢？

答：
栈溢出原因：
因为每调用一个方法就会在栈上创建一个栈帧，方法调用结束后就会弹出该栈帧，而栈的大小不是无限的，所以递归调用次数过多的话就会导致栈溢出。而递归调用的特点是每递归一次，就要创建一个新的栈帧，而且还要保留之前的环境（栈帧），直到遇到结束条件。所以递归调用一定要明确好结束条件，不要出现死循环，而且要避免栈太深。
解决方法：

1. 简单粗暴，不要使用递归，使用循环替代。缺点：代码逻辑不够清晰；
2. 限制递归次数；
3. 使用尾递归，尾递归是指在方法返回时只调用自己本身，且不能包含表达式。编译器或解释器会把尾递归做优化，使递归方法不论调用多少次，都只占用一个栈帧，所以不会出现栈溢出。然鹅，Java没有尾递归优化。

请求发送者与接收者解耦——命令模式

命令模式（Command Pattern）是一种数据驱动的设计模式，它属于行为型模式。请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。

介绍

意图：将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。
主要解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
何时使用：在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。
如何解决：通过调用者调用接受者执行命令，顺序：调用者→接受者→命令。
关键代码：定义三个角色：1、received 真正的命令执行对象 2、Command 3、invoker 使用命令对象的入口
应用实例：struts 1 中的 action 核心控制器 ActionServlet 只有一个，相当于 Invoker，而模型层的类会随着不同的应用有不同的模型类，相当于具体的 Command。
优点： 1、降低了系统耦合度。 2、新的命令可以很容易添加到系统中去。
缺点：使用命令模式可能会导致某些系统有过多的具体命令类。
使用场景：认为是命令的地方都可以使用命令模式，比如： 1、GUI 中每一个按钮都是一条命令。 2、模拟 CMD。
注意事项：系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作，也可以考虑使用命令模式，见命令模式的扩展。

最经典的、最常用的：冒泡排序、插入排序、选择排序、归并排序、快速排序、计数排序、基数排序、桶排序。

如何分析一个“排序算法”？

1. 排序算法的执行效率
   1. 最好情况、最坏情况、平均情况时间复杂度
   2. 时间复杂度的系数、常数 、低阶
   3. 比较次数和交换（或移动）次数
2. 排序算法的内存消耗
3. 排序算法的稳定性

原地排序算法，就是特指空间复杂度是 O(1) 的排序算法。

稳定性：如果待排序的序列中存在值相等的元素，经过排序之后，相等元素之间原有的先后顺序不变。

冒泡排序（Bubble Sort）

冒泡排序只会操作相邻的两个数据。每次冒泡操作都会对相邻的两个元素进行比较，看是否满足大小关系要求。如果不满足就让它俩互换。一次冒泡会让至少一个元素移动到它应该在的位置，重复 n 次，就完成了 n 个数据的排序工作。

经过一次冒泡操作之后，6 这个元素已经存储在正确的位置上。要想完成所有数据的排序，我们只要进行 6 次这样的冒泡操作就行了。

// 冒泡排序，a表示数组，n表示数组大小
public void bubbleSort(int[] a, int n) {
  if (n <= 1) return;
 
 for (int i = 0; i < n; ++i) {
    // 提前退出冒泡循环的标志位
    boolean flag = false;
    for (int j = 0; j < n - i - 1; ++j) {
      if (a[j] > a[j+1]) { // 交换
        int tmp = a[j];
        a[j] = a[j+1];
        a[j+1] = tmp;
        flag = true;  // 表示有数据交换      
      }
    }
    if (!flag) break;  // 没有数据交换，提前退出
  }
}

有序度：数组中具有有序关系的元素对的个数。满有序度:完全有序。
逆序度：逆序度的定义正好跟有序度相反。
逆序度 = 满有序度 - 有序度
我们排序的过程就是一种增加有序度，减少逆序度的过程，最后达到满有序度，就说明排序完成了。

冒泡排序包含两个操作原子，比较和交换。每交换一次，有序度就加 1。不管算法怎么改进，交换次数总是确定的，即为逆序度，也就是n*(n-1)/2–初始有序度。

插入排序

一个有序的数组，我们往里面添加一个新的数据后，如何继续保持数据有序呢？很简单，我们只要遍历数组，找到数据应该插入的位置将其插入即可。

插入排序具体是如何借助上面的思想来实现排序的呢？

我们将数组中的数据分为两个区间，已排序区间和未排序区间。初始已排序区间只有一个元素，就是数组的第一个元素。插入算法的核心思想是取未排序区间中的元素，在已排序区间中找到合适的插入位置将其插入，并保证已排序区间数据一直有序。重复这个过程，直到未排序区间中元素为空，算法结束。

插入排序也包含两种操作，一种是元素的比较，一种是元素的移动。当我们需要将一个数据 a 插入到已排序区间时，需要拿 a 与已排序区间的元素依次比较大小，找到合适的插入位置。找到插入点之后，我们还需要将插入点之后的元素顺序往后移动一位，这样才能腾出位置给元素 a 插入。

对于不同的查找插入点方法（从头到尾、从尾到头），元素的比较次数是有区别的。但对于一个给定的初始序列，移动操作的次数总是固定的，就等于逆序度。

// 插入排序，a表示数组，n表示数组大小
public void insertionSort(int[] a, int n) {
  if (n <= 1) return;

  for (int i = 1; i < n; ++i) {
    int value = a[i];
    int j = i - 1;
    // 查找插入的位置
    for (; j >= 0; --j) {
      if (a[j] > value) {
        a[j+1] = a[j];  // 数据移动
      } else {
        break;
      }
    }
    a[j+1] = value; // 插入数据
  }
}

选择排序

选择排序算法的实现思路有点类似插入排序，也分已排序区间和未排序区间。但是选择排序每次会从未排序区间中找到最小的元素，将其放到已排序区间的末尾。

解答开篇

问：冒泡排序和插入排序的时间复杂度都是 O(n2)，都是原地排序算法，为什么插入排序要比冒泡排序更受欢迎呢？

答：冒泡排序的数据交换要比插入排序的数据移动要复杂，冒泡排序需要 3 个赋值操作，而插入排序只需要 1 个。

总结

11.1概述329

11.2HotSpot虚拟机内的即时编译器329

11.2.1解释器与编译器330

11.2.2编译对象与触发条件332

11.2.3编译过程337

11.2.4查看及分析即时编译结果339

11.3编译优化技术345

11.3.1优化技术概览346

11.3.2公共子表达式消除350

11.3.3数组边界检查消除351

11.3.4方法内联352

11.3.5逃逸分析354

11.4Java与C/C++的编译器对比356

11.5本章 小结358

12.1 Bitmap的高效加载

BitmapFactory类提供了四类方法：decodeFile、decodeResource、decodeStream和decodeByteArray，分别用于支持从文件系统、资源、输入流以及字节数组中加载出一个Bitmap对象，其中decodeFile和decodeResource又间接调用了decodeStream方法，这四类方法最终是在Android的底层实现的，对应着BitmapFactory类的几个native方法。

如何高效地加载Bitmap 呢?其实核心思想也很简单，那就是采用BitmapFactory.Options来加载所需尺寸的图片。通过BitmapFactory.Options来缩放图片，主要是用到了它的inSampleSize参数，即采样率。

通过采样率即可有效地加载图片,那么到底如何获取采样率呢?获取采样率也很简单，遵循如下流程:

1. 将BitmapFactory.Options的inJustDecodeBounds参数设为true并加载图片。
2. 从BitmapFactory.Options 中取出图片的原始宽高信息，它们对应于outWidth 和outHeight参数。
3. 根据采样率的规则并结合目标View的所需大小计算出采样率inSampleSize。
4. 将BitmapFactory.Options的inJustDecodeBounds 参数设为false, 然后重新加载图片。

这里说明一下inJustDecodeBounds参数，当此参数设为true时，BitmapFactory 只会解析图片的原始宽/高信息，并不会去真正地加载图片，所以这个操作是轻量级的。

12.2 Android中的缓存策略

缓存策略：内次缓存+存储缓存。当应用打算从网络上请求一张图片时，程序首先从内存中去获取，如果内存中没有那就从存储设备中去获取，如果存储设备中也没有，那就从网络上下载这张图片。

一般来说， 缓存策略主要包含缓存的添加、获取和删除这三类操作。删除缓存目前常用的一种缓存算法是LRU（Least Recently Used）,LRU是近期最少使用算法，它的核心思想是当缓存满时，会优先淘汰那些近期最少使用的缓存对象。采用LRU算法的缓存有两种：LruCache和DiskLruCache，LruCache用于实现内存缓存，而DiskLruCache则充当了存储设备缓存。

12.2.1 LruCache

LruCache它是一个泛型类，它内部采用一个LinkedHashMap，当强引用的方式存储外界的缓存对象，其提供了get和put方法来完成缓存的获取和添加操作，当缓存满时，LruCache会移除较早使用的缓存对象，然后再添加新的缓存对象。

• 强引用：直接的对象引用
• 软引用：当一个对象只有软引用存在时，系统内存不足时此对象会被gc回收。
• 弱引用：当一个对象只有弱引用存在时，此对象会随时被gc回收。

LruCache是线程安全的，因为用到了LinkedHashMap。

• sizeOf 计算缓存对象的大小
• LruCache.get(key) 获取一个缓存对象
• LruCache.put(key, bitmap) 添加一个缓存对象
• LruCache.remove删除一个指定的缓存对象。
• entryRemoved 移除旧缓存时会调用
  • 可以进行一些资源回收工作

12.2.2 DiskLruCache

DiskLruCache用于实现存储设备缓存，即磁盘存储，它通过将缓存对象写入文件系统从而实现缓存的效果。

1. DiskLruCache 的创建 open
2. DiskLruCache 的缓存添加 edit commit abort
3. DiskLruCache的缓存查找和删除 get remove delete

12.2.3 ImageLoader的实现

一般来说，一个优秀的ImageLoader应该具备如下功能：

• 图片的同步加载
• 图片的异步加载
• 图片压缩
• 内存缓存
• 磁盘缓存
• 网络拉取

实现步骤：

1. 图片压缩功能的实现
   1. 根据宽高修改BitmapFactory.Options采样率
2. 内存缓存和磁盘缓存的实现
   1. LruCache和DiskLruCache
3. 同步加载和异步加载接口的设计
   1. 使用线程池和Handler

12.3 ImageLoader的使用

12.3.1 照片墙效果

12.3.2 优化列表的卡顿现象

• 不要在getView中执行耗时操作。
• 控制异步任务的执行频率。可以考虑在列表滑动的时候，停止加载图片，尽管这个过程是异步的，等列表停下来以后在加载图片仍然可以获得良好的用户体验。
• 开启硬件加速可以解决莫名的卡顿问题，通过设置android:hardwareAccelerated = "true"即可为Activity开启硬件加速。

• 一、封装共享变量
• 二、识别共享变量间的约束条件
• 三、制定并发访问策略

一、封装共享变量

面向对象思想里面有一个很重要的特性是封装，封装的通俗解释就是将属性和实现细节封装在对象内部，外界对象只能通过目标对象提供的公共方法来间接访问这些内部属性。

利用面向对象思想写并发程序的思路：将共享变量作为对象属性封装在内部，对所有公共方法制定并发访问策略。

实际工作中，经常要面临的情况往往是有很多的共享变量，对于一些不会发生变化的共享变量，建议你用 final 关键字来修饰。这样既能避免并发问题，也能很明了地表明你的设计意图。

二、识别共享变量间的约束条件

识别共享变量间的约束条件非常重要。因为这些约束条件，决定了并发访问策略。

例如，库存管理里面有个合理库存的概念，库存量不能太高，也不能太低，它有一个上限和一个下限。但是容易忽视了一个约束条件，就是库存下限要小于库存上限。

public class SafeWM {
  // 库存上限
  private final AtomicLong upper =
        new AtomicLong(0);
  // 库存下限
  private final AtomicLong lower =
        new AtomicLong(0);
  // 设置库存上限
  void setUpper(long v){
    // 检查参数合法性
    if (v < lower.get()) {
      throw new IllegalArgumentException();
    }
    upper.set(v);
  }
  // 设置库存下限
  void setLower(long v){
    // 检查参数合法性
    if (v > upper.get()) {
      throw new IllegalArgumentException();
    }
    lower.set(v);
  }
  // 省略其他业务代码
}

当你看到代码里出现 if 语句的时候，就应该立刻意识到可能存在竞态条件，导致并发问题。
在设计阶段，我们一定要识别出所有共享变量之间的约束条件，如果约束条件识别不足，很可能导致制定的并发访问策略南辕北辙。

三、制定并发访问策略

制定并发访问策略，是一个非常复杂的事情。应该说整个专栏都是在尝试搞定它。不过从方案上来看，无外乎就是以下“三件事”。

1. 避免共享：避免共享的技术主要是利于线程本地存储以及为每个任务分配独立的线程。
2. 不变模式：这个在 Java 领域应用的很少，但在其他领域却有着广泛的应用，例如 Actor 模式、CSP 模式以及函数式编程的基础都是不变模式。
3. 管程及其他同步工具：Java 领域万能的解决方案是管程，但是对于很多特定场景，使用 Java 并发包提供的读写锁、并发容器等同步工具会更好。

除了这些方案之外，还有一些宏观的原则需要你了解。这些宏观原则，有助于你写出“健壮”的并发程序。这些原则主要有以下三条。

1. 优先使用成熟的工具类：Java SDK 并发包里提供了丰富的工具类，基本上能满足你日常的需要，建议你熟悉它们，用好它们，而不是自己再“发明轮子”，毕竟并发工具类不是随随便便就能发明成功的。
2. 迫不得已时才使用低级的同步原语：低级的同步原语主要指的是 synchronized、Lock、Semaphore 等，这些虽然感觉简单，但实际上并没那么简单，一定要小心使用。
3. 避免过早优化：安全第一，并发程序首先要保证安全，出现性能瓶颈后再优化。在设计期和开发期，很多人经常会情不自禁地预估性能的瓶颈，并对此实施优化，但残酷的现实却是：性能瓶颈不是你想预估就能预估的。

课后思考

本期示例代码中，类 SafeWM 不满足库存下限要小于库存上限这个约束条件，那你来试试修改一下，让它能够在并发条件下满足库存下限要小于库存上限这个约束条件。

答：

1. setUpper() 跟 setLower() 都加上 "synchronized" 关键字。不要太在意性能，老师都说了，避免过早优化。

2. 如果性能有问题，可以把 lower 跟 upper 两个变量封装到一个类中，例如

   public class Boundary {
   private final lower;
   
   private final upper;
   
   public Boundary(long lower, long upper) {
   
       if(lower >= upper) {
   
           // throw exception
   
       }
   
       this.lower = lower;
   
       this.upper = upper;
   
   }
   
   }
   

   移除 SafeVM 的 setUpper() 跟 setLower() 方法，并增入 setBoundary(Boundary boundary) 方法。

归并排序和快速排序都用到了分治思想。

归并排序的原理

如果要排序一个数组，我们先把数组从中间分成前后两部分，然后对前后两部分分别排序，再将排好序的两部分合并在一起，这样整个数组就都有序了。

归并排序使用的就是分治思想。分治，顾名思义，就是分而治之，将一个大问题分解成小的子问题来解决。小的子问题解决了，大问题也就解决了。

分治算法一般都是用递归来实现的。分治是一种解决问题的处理思想，递归是一种编程技巧。

归并排序的递推公式和终止条件：

递推公式：
merge_sort(p…r) = merge(merge_sort(p…q), merge_sort(q+1…r))

终止条件：
p >= r 不用再继续分解

伪代码：

// 归并排序算法, A是数组，n表示数组大小
merge_sort(A, n) {
  merge_sort_c(A, 0, n-1)
}

// 递归调用函数
merge_sort_c(A, p, r) {
  // 递归终止条件
  if p >= r  then return

  // 取p到r之间的中间位置q
  q = (p+r) / 2
  // 分治递归
  merge_sort_c(A, p, q)
  merge_sort_c(A, q+1, r)
  // 将A[p...q]和A[q+1...r]合并为A[p...r]
  merge(A[p...r], A[p...q], A[q+1...r])
}

merge()函数过程和伪代码

merge(A[p...r], A[p...q], A[q+1...r]) {
  var i := p，j := q+1，k := 0 // 初始化变量i, j, k
  var tmp := new array[0...r-p] // 申请一个大小跟A[p...r]一样的临时数组
  while i<=q AND j<=r do {
    if A[i] <= A[j] {
      tmp[k++] = A[i++] // i++等于i:=i+1
    } else {
      tmp[k++] = A[j++]
    }
  }
  
  // 判断哪个子数组中有剩余的数据
  var start := i，end := q
  if j<=r then start := j, end:=r
  
  // 将剩余的数据拷贝到临时数组tmp
  while start <= end do {
    tmp[k++] = A[start++]
  }
  
  // 将tmp中的数组拷贝回A[p...r]
  for i:=0 to r-p do {
    A[p+i] = tmp[i]
  }
}

归并排序的性能分析

• 归并排序是一个稳定的排序算法
• 归并排序的时间复杂度是O(nlogn)
• 归并排序的空间复杂度是O(n)

缺点：归并排序不是原地排序算法。

快速排序的原理

如果要排序数组中下标从 p 到 r 之间的一组数据，我们选择 p 到 r 之间的任意一个数据作为 pivot（分区点）。我们遍历 p 到 r 之间的数据，将小于 pivot 的放到左边，将大于 pivot 的放到右边，将 pivot 放到中间。

根据分治、递归的处理思想，我们可以用递归排序下标从 p 到 q-1 之间的数据和下标从 q+1 到 r 之间的数据，直到区间缩小为 1，就说明所有的数据都有序了。

递推公式和终止条件：

递推公式：
quick_sort(p…r) = quick_sort(p…q-1) + quick_sort(q+1… r)

终止条件：
p >= r

伪代码：

// 快速排序，A是数组，n表示数组的大小
quick_sort(A, n) {
  quick_sort_c(A, 0, n-1)
}
// 快速排序递归函数，p,r为下标
quick_sort_c(A, p, r) {
  if p >= r then return
  
  q = partition(A, p, r) // 获取分区点
  quick_sort_c(A, p, q-1)
  quick_sort_c(A, q+1, r)
}

原地分区函数partition()伪代码：

partition(A, p, r) {
  pivot := A[r]
  i := p
  for j := p to r-1 do {
    if A[j] < pivot {
      swap A[i] with A[j]
      i := i+1
    }
  }
  swap A[i] with A[r]
  return i

过程如图：

快速排序的性能分析

• 快排是一种原地、不稳定的排序算法。
• 时间复杂度最差情况：T(n) = O(n2)；平均情况：T(n) = O(nlogn)。

归并排序和快速排序的异同：

• 归并排序的处理过程是由下到上的，先处理子问题，然后再合并。
• 而快排正好相反，它的处理过程是由上到下的，先分区，然后再处理子问题。
• 归并排序虽然是稳定的、时间复杂度为 O(nlogn) 的排序算法，但是它是非原地排序算法。
• 快速排序通过设计巧妙的原地分区函数，可以实现原地排序，解决了归并排序占用太多内存的问题。

内容小结

• 归并排序和快速排序是两种稍微复杂的排序算法，它们用的都是分治的思想，代码都通过递归来实现，过程非常相似。理解归并排序的重点是理解递推公式和 merge() 合并函数。同理，理解快排的重点也是理解递推公式，还有 partition() 分区函数。
• 归并排序算法是一种在任何情况下时间复杂度都比较稳定的排序算法，这也使它存在致命的缺点，即归并排序不是原地排序算法，空间复杂度比较高，是 O(n)。正因为此，它也没有快排应用广泛。
• 快速排序算法虽然最坏情况下的时间复杂度是 O(n2)，但是平均情况下时间复杂度都是 O(nlogn)。不仅如此，快速排序算法时间复杂度退化到 O(n2) 的概率非常小，我们可以通过合理地选择 pivot 来避免这种情况。

12.1 Java中的ClassLoader

类加载子系统，主要作用就是通过多种类加载器（ClassLoader）来查找和加载Class文件到Java虚拟机中。

12.1.1 ClassLoader的类型

• 系统类加载器
  • Bootstrap ClassLoader
  • Extensions ClassLoader
  • Application ClassLoader
• 自定义类加载器

Bootstrap ClassLoader 引导类加载器
C/C++代码实现的加载器，用于加载指定的JDK核心类库，比如java.lang.、java.util.等系统类。它用来加载以下目录中的类库 :

• $JAVA HOME/jre/lib 目录。
• -Xbootclasspath 参数指定的目录 。
  Java 虚拟机的启动就是通过 Bootstrap ClassLoader 创建一个初始类来完成的。

Extensions ClassLoader
Java 中的实现类为 ExtClassLoader，因此可以简称为ExtClassLoader，它用于加载 Java的拓展类，提供除了系统类之外的额外功能。 ExtClassLoader用来加载以下目录中的类库:

• 加载$JAVA_HOME/jre/lib/ext 目录。
• 系统属性 java.ext.dir所指定的目录。

Application ClassLoader
简称为APPClassLoader，又称为System ClassLoader（系统类加载器），它用来加载以下目录的类库：

• 当前程序的Classpath目录。
• 系统属性java.class.path指定的目录。

12.1.2 ClassLoader的继承关系

12.1.3 双亲委托模式

双亲委托模型：

1. 首先判断该Class是否已经加载，如果没有则委托父加载器进行查找
2. 依次进行递归，直到委托到最顶层的Bootstrap ClassLoader
3. 如果Bootstrap ClassLoader找到了该Class，直接返回；如果没有找到，则继续依次向下查找，如果还没找到最后交由自身去查找。

双亲委托模型的好处：

• 避免重复加载。
• 更加安全。比如无法通过自定义String类替代系统的String类。

12.1.4 自定义ClassLoader

系统提供的类加载器只能够加载指定目录下的 jar 包和 Class 文件，如果想要加载网络上的或者 D 盘某一文件中的 jar 包和 Class 文件则需要自定义 ClassLoader。实现自定义ClassLoader 需要如下两个步骤:

1. 定义一个自定义 ClassLoade 并继承抽象类 ClassLoader。
2. 复写 findClass 方法，并在 findClass 方提中调用 defineClass 方法。

12.2 Android中的ClassLoader

12.2.1 ClassLoader的类型

12.2.2 ClassLoader的继承关系

12.2.3 ClassLoader的加载过程

12.2.4 BootClassLoader的创建

12.2.5 PathClassLoader的创建

12.3 本章小结 311

对象间的联动——观察者模式

当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知它的依赖对象。观察者模式属于行为型模式。

介绍

意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。
何时使用：一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。
如何解决：使用面向对象技术，可以将这种依赖关系弱化。
关键代码：在抽象类里有一个 ArrayList 存放观察者们。
应用实例： 1、拍卖的时候，拍卖师观察最高标价，然后通知给其他竞价者竞价。 2、西游记里面悟空请求菩萨降服红孩儿，菩萨洒了一地水招来一个老乌龟，这个乌龟就是观察者，他观察菩萨洒水这个动作。
优点： 1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。
缺点： 1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
使用场景：

• 一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这些方面封装在独立的对象中使它们可以各自独立地改变和复用。
• 一个对象的改变将导致其他一个或多个对象也发生改变，而不知道具体有多少对象将发生改变，可以降低对象之间的耦合度。
• 一个对象必须通知其他对象，而并不知道这些对象是谁。
• 需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。

注意事项： 1、JAVA 中已经有了对观察者模式的支持类。 2、避免循环引用。 3、如果顺序执行，某一观察者错误会导致系统卡壳，一般采用异步方式。

撤销功能的实现——备忘录模式

备忘录模式（Memento Pattern）保存一个对象的某个状态，以便在适当的时候恢复对象。备忘录模式属于行为型模式。

介绍

意图：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
主要解决：所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。
何时使用：很多时候我们总是需要记录一个对象的内部状态，这样做的目的就是为了允许用户取消不确定或者错误的操作，能够恢复到他原先的状态，使得他有"后悔药"可吃。
如何解决：通过一个备忘录类专门存储对象状态。
关键代码：客户不与备忘录类耦合，与备忘录管理类耦合。
应用实例：1、后悔药。 2、打游戏时的存档。 3、Windows 里的 ctri + z。 4、IE 中的后退。 4、数据库的事务管理。
优点：1、给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。 2、实现了信息的封装，使得用户不需要关心状态的保存细节。
缺点：消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。
使用场景： 1、需要保存/恢复数据的相关状态场景。 2、提供一个可回滚的操作。
注意事项： 1、为了符合迪米特原则，还要增加一个管理备忘录的类。 2、为了节约内存，可使用原型模式+备忘录模式。

13.1 热修复的产生

13.2 热修复框架的种类和对比

13.3 资源修复

13.3.1 Instant Run概述

Instant Run是Android Studio 2.0以后新增的一个运行机制， 能够显著减少开发人员第二次及以后的构建和部署时间。在没有使用Instant Run前，我们编译部署应用程序的流程如图所示。

从图13一1可以看出,传统的编译部署需要重新安装App和重启App,这显然会很耗时,Instant Run会避免这一情况， 如图所示。

从上图可以看出InstantRun的构建和部署都是基于更改的部分的。InstantRun部署有三种方式，Instant Run会根据代码的情况来决定采用哪种部署方式，无论哪种方式都不需要重新安装App,这一点就已经提高了不少的效率。

• Hotswap:从名称也可以看出HotSwap是效率最高的部署方式，代码的增量改变不需要重启App,甚至不需要重启当前的Activity。 修改一个现有方法中的代码时会采用Hot Swap。
• Warm Swap: App不需重启，但是Activity 需要重启。修改或删除一个现有的资源文件时会采用WarmSwap。
• Cold Swap: App 需要重启，但是不需要重新安装。采用Cold Swap的情况很多，比如添加、删除或修改一个字段和方法、添加一个类等。

13.3.2 Instant Run的资源修复

Instant Run中的资源热修复可以简单地总结为两个步骤:

1. 创建新的AssetManager, 通过反射调用addAssetPath方法加载外部的资源，这样新创建的AssetManager就含有了外部资源。
2. 将AssetManager类型的mAssets字段的引用全部替换为新创建的AssetManager。

13.4 代码修复

代码修复主要有3个方案，分别是底层替换方案、类加载方案和Instant Run方案。

13.4.1 类加载方案

类加载方案基于Dex分包方案，什么是Dex分包方案呢?这个得先从65536限制和LinearAlloc限制说起。

1. 65536限制

随着应用功能越来越复杂，代码量不断地增大，引入的库也越来越多，可能会在编译时提示如下异常:

com. android. dex. DexIndexOverflowException: method ID not in [0， 0xffff] : 65536

这说明应用中引用的方法数超过了最大数65536个。产生这一问题的原因就是系统的65536限制，65536 限制的主要原因是DVM Bytecode的限制，DVM指令集的方法调用指令invoke-kind索引为16bits, 最多能引用65535个方法。

2. LinearAlloc 限制

在安装应用时可能会提示INSTALL_FAILED_DEXOPT,产生的原因就是LinearAlloc限制，DVM中的LinearAlloc是一个固定的缓存区，当方法数超出了缓存区的大小时会报错。

为了解决65536限制和LinearAlloc限制，从而产生了Dex分包方案。Dex 分包方案主要做的是在打包时将应用代码分成多个Dex,将应用启动时必须用到的类和这些类的直接引用类放到主Dex中，其他代码放到次Dex中。当应用启动时先加载主Dex，等到应用启动后再动态地加载次Dex，从而缓解了主Dex的65536限制和LinearAlloc限制。

Dex分包方案主要有两种，分别是Google官方方案、Dex自动拆包和动态加载方案。

在12.2.3节中学习了ClassLoader的加载过程，其中一个环节就是调用DexPathList 的findClass的方法，如下所示:

 public Class<?> findClass(String name, List<Throwable> suppressed) {
        for (Element element : dexElements) {//1
            Class<?> clazz = element.findClass(name, definingContext, suppressed);//2
            if (clazz != null) {
                return clazz;
            }
        }
        if (dexElementsSuppressedExceptions != null) {
            suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
        }
        return null;
    }

Element内部封装了DexFile，DexFile用于加载dex文件，因此每个dex文件对应一个Element。

多个Element组成了有序的Element数组dexElements。当要查找类时，会在注释1处遍历Element数组dexElements（相当于遍历dex文件数组），注释2处调用Element的findClass方法，其方法内部会调用DexFile的loadClassBinaryName方法查找类。如果在Element中（dex文件）找到了该类就返回，如果没有找到就接着在下一个Element中进行查找。
根据上面的查找流程，我们将有bug的类Key.class进行修改，再将Key.class打包成包含dex的补丁包Patch.jar，放在Element数组dexElements的第一个元素，这样会首先找到Patch.dex中的Key.class去替换之前存在bug的Key.class，排在数组后面的dex文件中的存在bug的Key.class根据ClassLoader的双亲委托模式就不会被加载，这就是类加载方案，如下图所示。

类加载方案需要重启App后让ClassLoader重新加载新的类，为什么需要重启呢？这是因为类是无法被卸载的，因此要想重新加载新的类就需要重启App，因此采用类加载方案的热修复框架是不能即时生效的。
虽然很多热修复框架采用了类加载方案，但具体的实现细节和步骤还是有一些区别的：

• QQ空间的超级补丁和Nuwa是按照上面说得将补丁包放在Element数组的第一个元素得到优先加载。
• 微信Tinker将新旧apk做了diff，得到patch.dex，然后将patch.dex与手机中apk的classes.dex做合并，生成新的classes.dex，然后在运行时通过反射将classes.dex放在Element数组的第一个元素。
• 饿了么的Amigo则是将补丁包中每个dex 对应的Element取出来，之后组成新的Element数组，在运行时通过反射用新的Element数组替换掉现有的Element 数组。

采用类加载方案的主要是以腾讯系为主，包括微信的Tinker、QQ空间的超级补丁、手机QQ的QFix、饿了么的Amigo和Nuwa等等。

13.4.2 底层替换方案

与类加载方案不同的是，底层替换方案不会再次加载新类，而是直接在Native层修改原有类，由于是在原有类进行修改限制会比较多，不能够增减原有类的方法和字段，如果我们增加了方法数，那么方法索引数也会增加，这样访问方法时会无法通过索引找到正确的方法，同样的字段也是类似的情况。

底层替换方案和反射的原理有些关联，就拿方法替换来说，

1. 方法反射我们可以调用java.lang.Class.getDeclaredMethod.invoke()
2. invoke方法是个native方法，对应Jni层的代码为：art/runtime/native/java_lang_reflect_Method.cc
3. Method_invoke函数中又调用了InvokeMethod函数：art/runtime/reflection.cc
4. 然后可以获取传入的javaMethod（Key的show方法）在ART虚拟机中对应的一个ArtMethod指针，ArtMethod结构体中包含了Java方法的所有信息，包括执行入口、访问权限、所属类和代码执行地址等等
5. ArtMethod结构中比较重要的字段是dex_cache_resolved_methods_和的entry_point_from_quick_compiled_code_，它们是方法的执行入口，当我们调用某一个方法时（比如Key的show方法），就会取得show方法的执行入口，通过执行入口就可以跳过去执行show方法。替换ArtMethod结构体中的字段或者替换整个ArtMethod结构体，这就是底层替换方案。

AndFix采用的是替换ArtMethod结构体中的字段，这样会有兼容问题，因为厂商可能会修改ArtMethod结构体，导致方法替换失败。Sophix采用的是替换整个ArtMethod结构体，这样不会存在兼容问题。

底层替换方案直接替换了方法，可以立即生效不需要重启。采用底层替换方案主要是阿里系为主，包括AndFix、Dexposed、阿里百川、Sophix。

13.4.3 Instant Run方案

除了资源修复，代码修复同样也可以借鉴Instant Run的原理， 可以说Instant Run的出现推动了热修复框架的发展。
Instant Run在第一次构建apk时，使用ASM在每一个方法中注入了类似如下的代码：

IncrementalChange localIncrementalChange = $change;//1
        if (localIncrementalChange != null) {//2
            localIncrementalChange.access$dispatch(
                    "onCreate.(Landroid/os/Bundle;)V", new Object[] { this,
                            paramBundle });
            return;
        }

1. 其中注释1处是一个成员变量localIncrementalChange ，它的值为\(change，\)change实现了IncrementalChange这个抽象接口。
2. 当我们点击InstantRun时，如果方法没有变化则$change为null，就调用return，不做任何处理。
3. 如果方法有变化，就生成替换类，
   1. 这里我们假设MainActivity的onCreate方法做了修改，就会生成替换类MainActivity$override，这个类实现了IncrementalChange接口，同时也会生成一个AppPatchesLoaderImpl类，
   2. 这个类的getPatchedClasses方法会返回被修改的类的列表（里面包含了MainActivity），
   3. 根据列表会将MainActivity的$change设置为MainActivity$override，因此满足了注释2的条件，会执行MainActivity$override的access$dispatch方法，
   4. accessdispatch方法中会根据参数'onCreate.(Landroid/os/Bundle;)V;'，执行'MainActivityoverride'的onCreate方法，从而实现了onCreate方法的修改。

借鉴Instant Run的原理的热修复框架有Robust和Aceso。

13.5 动态链接库的修复

Android平台的动态链接库主要指的是so库，为了更好地理解，本章动态链接库简称为so。热修复框架的so的修复的主要是更新so，换句话说就是重新加载so，因此so的修复的基础原理就是加载。

13.5.1 System的load和loadLibarary方法

加载so主要用到了System类的load和loadLibarary方法。

• System的load方法传入的参数是so在磁盘的完整路径,用于加载指定路径的so。
• System的loadLibrary方法传入的参数是so的名称，用于加载App安装后自动从apk包中复制到/data/data/ packagename/lib下的so。

1. System的load方法

1. Runtime.getRuntime()会得到当前Java应用程序的运行环境Runtime
2. 调用了doLoad方法，并将加载该类的类加载器作为参数传入进去:
3. doLoad方法会调用native方法nativeLoad

2. System的loadLibrary方法

1. 先调用Runtime的loadLibrary0方法，loadLibrary0方法分为两个部分，一个是传入的ClassLoader不为null的部分，另一个是ClassLoader为null的部分
2. 我们先来看ClassLoader 为null的部分。先遍历getLibPaths方法，这个方法会返回java.library.path选项配置的路径数组，然后拼接出so路径作为参数调用doLoad方法中。
3. 当ClassLoader不为null时，先通过ClassLoader的findLibrary方法来得到fileName，然后调用doLoad 方法。
4. findLibrary：ClassLoader的findLibrary方法在实现类BaseDexClassLoader中实现，然后会调用DexPathList的findLibrary方法，这和13.3.1 节讲到的DexPathList的findClass方法类似，
   1. 在NativeLibraryElement数组中的每一个NativeLibraryElement对应一个so库，
   2. 然后调用NativeLibraryElement的findNativeLibrary方法就可以返回so的路径。结合的类加载方案，就可以得到so的修复的一种方案，就是：
   3. 将so补丁插入到NativeLibraryElement数组的前部，让so补丁的路径先被返回，并调用Runtime的doLoad方法进行加载，
   4. 在doLoad方法中会调用native 方法nativeLoad。

13.5.2 nativeLoad方法分析

LoadNativeLibrary函数的行数很多，这里来做一个总结，LoadNativeLibrary 函数主要做了如下3方面工作：

1. 判断so是否被加载过，两次ClassLoader是否是同一个，避免so重复加载。
2. 打开so并得到so句柄，如果so句柄获取失败,就返回false。创建新的SharedLibrary,如果传入path对应的library 为空指针，就将新创建的SharedIibrary赋值给library, 并将library存储到libraries_中。
3. 查找JNI_OnLoad 的函数指针，根据不同情况设置was_successful 的值，最终返回该was_successful。

讲到这里总结一下so修复主要有两个方案:

1. 将so补丁插入到NativeLibraryElement数组的前部，让so补丁的路径先被返回和加载。
2. 调用System的load方法来接管so的加载入口。

13.6 本章小结

三种时间复杂度是 O(n)：桶排序、计数排序、基数排序。
因为这些排序算法的时间复杂度是线性的，所以我们把这类排序算法叫作线性排序。

今天学习重点的是掌握这些排序算法的适用场景。

桶排序（Bucket sort）

首先，我们来看桶排序。桶排序，顾名思义，会用到“桶”，核心思想是将要排序的数据分到几个有序的桶里，每个桶里的数据再单独进行排序。桶内排完序之后，再把每个桶里的数据按照顺序依次取出，组成的序列就是有序的了。

桶排序看起来很优秀，那它是不是可以替代我们之前讲的排序算法呢？

答案当然是否定的。桶排序对要排序数据的要求是非常苛刻的。

• 首先，要排序的数据需要很容易就能划分成 m 个桶，并且，桶与桶之间有着天然的大小顺序。这样每个桶内的数据都排序完之后，桶与桶之间的数据不需要再进行排序。
• 其次，数据在各个桶之间的分布是比较均匀的。如果数据经过桶的划分之后，有些桶里的数据非常多，有些非常少，很不平均，那桶内数据排序的时间复杂度就不是常量级了。在极端情况下，如果数据都被划分到一个桶里，那就退化为 O(nlogn) 的排序算法了。

桶排序比较适合用在外部排序中。所谓的外部排序就是数据存储在外部磁盘中，数据量比较大，内存有限，无法将数据全部加载到内存中。

计数排序（Counting sort）

计数排序其实是桶排序的一种特殊情况。
当要排序的 n 个数据，所处的范围并不大的时候，比如最大值是 k，我们就可以把数据划分成 k 个桶。每个桶内的数据值都是相同的，省掉了桶内排序的时间。

计数排序只能用在数据范围不大的场景中，如果数据范围 k 比要排序的数据 n 大很多，就不适合用计数排序了。而且，计数排序只能给非负整数排序，如果要排序的数据是其他类型的，要将其在不改变相对大小的情况下，转化为非负整数。

基数排序（Radix sort）

基数排序是按照低位先排序，然后收集；再按照高位排序，然后再收集；依次类推，直到最高位。有时候有些属性是有优先级顺序的，先按低优先级排序，再按高优先级排序。最后的次序就是高优先级高的在前，高优先级相同的低优先级高的在前。基数排序基于分别排序，分别收集，所以是稳定的。

基数排序对要排序的数据是有要求的，需要可以分割出独立的“位”来比较，而且位之间有递进的关系，如果 a 数据的高位比 b 数据大，那剩下的低位就不用比较了。除此之外，每一位的数据范围不能太大，要可以用线性排序算法来排序，否则，基数排序的时间复杂度就无法做到 O(n) 了

说到Hook技术得先提到逆向工程，逆向工程源于商业及军事领域中的硬件分析，其主要目的是在不能轻易获得必要的生产信息的情况下，直接从成品分析，推导出产品的设计原理。

逆向分析分为静态分析和动态分析，其中静态分析指的是一种在不执行程序的情况下对程序行为进行分析的技术;动态分析是指在程序运行时对程序进行调试的技术。

Hook技术就属于动态分析，它不仅在Android平台中被应用，早在Windows平台中就已经被应用了。

14.1 Hook技术概述

我们知道应用程序进程之间是彼此独立的，应用程序进程和系统进程之间也是如此，想要在应用程序进程更改系统进程的某些行为很难直接实现，有了Hook 技术，我们就可以在进程间进行行为更改，如图所示。

可以看到Hook可以将自己融入到它所要劫持的对象(对象B)所在的进程中，成为系统进程的一部分，这样我们就可以通过Hook来更改对象B的行为。被劫持的对象(对象B)，称作Hook点，为了保证Hook的稳定性，Hook点一般选择容易找到并且不易变化的对象，静态变量和单例就符合这一条件。

14.2 Hook技术分类

Hook技术知识点比较多，因此Hook技术根据不同的角度会有很多种分类，这里介绍其中的三种分类。

• 根据Hook的API语言划分，分为Hook Java和Hook Native。
  • Hook Java主要通过反射和代理来实现，应用于在SDK开发环境中修改Java代码。
  • HookNative则应用于在NDK开发环境和系统开发中修改Native代码。
• 根据Hook的进程划分，分为应用程序进程Hook和全局Hook。
  • 应用程序进程Hook只能Hook当前所在的应用程序进程。
  • 应用程序进程是Zygote进程fock出来的，如果对Zygote进行Hook, 就可以实现Hook系统所有的应用程序进程，这就是全局Hook。
• 根据Hook的实现方式划分，分为如下两种。
  • 通过反射和代理实现，只能Hook当前的应用程序进程。
  • 通过Hook框架来实现，比如Xposed， 可以实现全局Hook, 但是需要root。

Hook Native、全局Hook和通过Hook框架实现这些分类和插件化技术关联不大，本章主要需要学习的是Hook Java,想要更好地学习Hook Java,首先要了解代理模式。

14.3 代理模式

代理模式也叫委托模式，是结构型设计模式的一一种。在现实生活中我们用到类似代理模式的场景有很多，比如代购、代理上网、打官司等。

定义：为其他对象提供一种代理以控制对这个对象的访问称为代理模式。

在代理模式中有如下角色。

• Subject: 抽象主题类，声明真实主题与代理的共同接口方法。
• RealSubject: 真实主题类，定义了代理所表示的集体对象，客户端通过代理类间接调用真实主题类的方法。
• Proxy: 代理类，持有对真实主题类的引用，在其所实现的接口方法中调用真实主题类中相应的接口方法执行。
• Client: 客户端类。

14.3.1 代理模式简单实现

14.3.2 动态代理的简单实现

从编码的角度来说，代理模式分为静态代理和动态代理。

• 静态代理，在代码运行前就已经存在了代理类的class编译文件

• 动态代理则是在代码运行时通过反射来动态地生成代理类的对象，并确定到底来代理谁。Java 提供了动态的代理接口InvocationHandler,实现该接口需要重写invoke方法。

1. 创建代理类，实现InvocationHandler接口

2. 客户端类代码：

   public class Client {
       public static void main(String[] args) {
   
           //创建LiuWangShu
   
           IShop liuwangshu = new LiuWangShu() ;
   
           //创建动态代理
   
           DynamicPurchasing mDynamicPurchasing = new DynamicPurchasing(liuwangshu) ; 
   
           //创建LiuWangShu的ClassLoader
   
           ClassLoader loader = liuwangshu.getClass().getClassLoader() ;
   
           //动态创建代理类
   
           IShop purchasing = (IShop)Proxy.newProxyInstance(loader, new Class[] {IShop.class}, mDynamicPurchasing) ;
   
           purchasing.buy() ;
   
       }
   
   }
   

14.4 Hook startActivity方法

我们知道Hook可以用来劫持对象，被劫持的对象叫作Hook点，用代理对象来替代Hook点，这样我们就可以在代理上实现自己想做的操作。这里以Hook常用的startActivity方法来举例，startActivity 方法分为两个，如下所示:

• startActivity (intent) ;
• getApplicationContext () . startActivity (intent) ;

第一个是Actvity的startActivity方法，第二个是Context的startActivity 方法。

14.4.1 Hook Activity的startActivity方法

14.4.2 Hook Context的startActivity方法

14.4.3 Hook startActivity总结

14.5 本章小结

14.1　什么是线程

14.1.1　使用线程给其他任务提供机会

14.2　中断线程

14.3　线程状态

14.3.1　新创建线程

14.3.2　可运行线程

14.3.3　被阻塞线程和等待线程

14.3.4　被终止的线程

14.4　线程属性

14.4.1　线程优先级

14.4.2　守护线程

14.4.3　未捕获异常处理器

14.5　同步

14.5.1　竞争条件的一个例子

14.5.2　竞争条件详解

14.5.3　锁对象

14.5.4　条件对象

14.5.5　synchronized关键字

14.5.6　同步阻塞

14.5.7　监视器概念

14.5.8　Volatile域

14.5.9　final变量

14.5.10　原子性

14.5.11　死锁

14.5.12　线程局部变量

14.5.13　锁测试与超时

14.5.14　读/写锁

14.5.15　为什么弃用stop和suspend方法

14.6　阻塞队列

14.7　线程安全的集合

14.7.1　高效的映射、集和队列

14.7.2　映射条目的原子更新

14.7.3　对并发散列映射的批操作

14.7.4　并发集视图

14.7.5　写数组的拷贝

14.7.6　并行数组算法

14.7.7　较早的线程安全集合

14.8　Callable与Future

14.9　执行器

14.9.1　线程池

14.9.2　预定执行

14.9.3　控制任务组

14.9.4　Fork-Join框架

14.9.5　可完成Future

14.10　同步器

14.10.1　信号量

14.10.2　倒计时门栓

14.10.3　障栅

14.10.4　交换器

14.10.5　同步队列

14.11　线程与Swing

14.11.1　运行耗时的任务

14.11.2　使用Swing工作线程

14.11.3　单一线程规则

如何选择合适的排序算法？

1. 线性排序算法的时间复杂度比较低，适用场景比较特殊，所以不能选择线性排序算法。
2. 为了兼顾任意规模数据的排序，一般都会首选时间复杂度是 O(nlogn) 的排序算法来实现排序函数。
3. 归并排序并不是原地排序算法，空间复杂度是 O(n)。
4. 所以快速排序比较适合来实现排序函数。

但是，快速排序在最坏情况下的时间复杂度是 O(n²)，如何来解决这个“复杂度恶化”的问题呢？

如何优化快速排序？

为什么最坏情况下快速排序的时间复杂度是 O(n²) 呢？
如果数据原来就是有序的或者接近有序的，每次分区点都选择最后一个数据，时间复杂度就会退化为 O(n²)。** O(n²) 时间复杂度出现的主要原因还是因为我们分区点选的不够合理。**

如何来选择分区点呢？

最理想的分区点是：被分区点分开的两个分区中，数据的数量差不多。

1. 三数取中法

我们从区间的首、尾、中间，分别取出一个数，然后对比大小，取这 3 个数的中间值作为分区点。但是，如果要排序的数组比较大，那“三数取中”可能就不够了，可能要“五数取中”或者“十数取中”。

2. 随机法

随机法就是每次从要排序的区间中，随机选择一个元素作为分区点。这种方法并不能保证每次分区点都选的比较好，但是从概率的角度来看，也不大可能会出现每次分区点都选的很差的情况，所以平均情况下，这样选的分区点是比较好的。

防止快速排序递归的堆栈溢出：

1. 第一种是限制递归深度。一旦递归过深，超过了我们事先设定的阈值，就停止递归。
2. 第二种是通过在堆上模拟实现一个函数调用栈，手动模拟递归压栈、出栈的过程，这样就没有了系统栈大小的限制。

在小规模数据面前，O(n²) 时间复杂度的算法并不一定比 O(nlogn) 的算法执行时间长。
解释：在大 O 复杂度表示法中，我们会省略低阶、系数和常数，也就是说，O(nlogn) 在没有省略低阶、系数、常数之前可能是 O(knlogn + c)，而且 k 和 c 有可能还是一个比较大的数。

遍历聚合对象中的元素——迭代器模式

迭代器模式（Iterator Pattern）是 Java 和 .Net 编程环境中非常常用的设计模式。这种模式用于顺序访问集合对象的元素，不需要知道集合对象的底层表示。
迭代器模式属于行为型模式。

介绍

意图：提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。
主要解决：不同的方式来遍历整个整合对象。
何时使用：遍历一个聚合对象。
如何解决：把在元素之间游走的责任交给迭代器，而不是聚合对象。
关键代码：定义接口：hasNext, next。
应用实例：JAVA 中的 iterator。
优点： 1、它支持以不同的方式遍历一个聚合对象。 2、迭代器简化了聚合类。 3、在同一个聚合上可以有多个遍历。 4、在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码。
缺点：由于迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加，这在一定程度上增加了系统的复杂性。
使用场景： 1、访问一个聚合对象的内容而无须暴露它的内部表示。 2、需要为聚合对象提供多种遍历方式。 3、为遍历不同的聚合结构提供一个统一的接口。
注意事项：迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。

• 同步与异步
• Dubbo 源码分析

Condition 实现了管程模型里面的条件变量。

Java 语言内置的管程里只有一个条件变量，而 Lock&Condition 实现的管程是支持多个条件变量的。

那如何利用两个条件变量快速实现阻塞队列呢？

一个阻塞队列，需要两个条件变量，一个是队列不空（空队列不允许出队），另一个是队列不满（队列已满不允许入队），这个例子我们前面在介绍管程的时候详细说过。

Lock 和 Condition 实现的管程，线程等待和通知需要调用 await()、signal()、signalAll()，它们的语义和 wait()、notify()、notifyAll() 是相同的。

public class BlockedQueue<T>{
  final Lock lock =
    new ReentrantLock();
  // 条件变量：队列不满  
  final Condition notFull =
    lock.newCondition();
  // 条件变量：队列不空  
  final Condition notEmpty =
    lock.newCondition();

  // 入队
  void enq(T x) {
    lock.lock();
    try {
      while (队列已满){
        // 等待队列不满
        notFull.await();
      }  
      // 省略入队操作...
      //入队后,通知可出队
      notEmpty.signal();
    }finally {
      lock.unlock();
    }
  }
  // 出队
  void deq(){
    lock.lock();
    try {
      while (队列已空){
        // 等待队列不空
        notEmpty.await();
      }  
      // 省略出队操作...
      //出队后，通知可入队
      notFull.signal();
    }finally {
      lock.unlock();
    }  
  }
}

同步与异步

同步与异步的区别？
调用方是否需要等待结果，如果需要等待结果，就是同步；如果不需要等待结果，就是异步。

同步，是 Java 代码默认的处理方式。如果你想让你的程序支持异步，可以通过下面两种方式来实现：

1. 调用方创建一个子线程，在子线程中执行方法调用，这种调用我们称为异步调用；
2. 方法实现的时候，创建一个新的线程执行主要逻辑，主线程直接 return，这种方法我们一般称为异步方法。

Dubbo 源码分析

在 TCP 协议层面，发送完 RPC 请求后，线程是不会等待 RPC 的响应结果的。其实很简单，一定是有人帮你做了异步转同步的事情。

二分思想

随机写一个 0 到 99 之间的数字，然后你来猜我写的是什么。假设我写的数字是 23，你可以按照下面的步骤来试一试。

二分查找针对的是一个有序的数据集合，查找思想有点类似分治思想。每次都通过跟区间的中间元素对比，将待查找的区间缩小为之前的一半，直到找到要查找的元素，或者区间被缩小为 0。

时间复杂度就是 O(logn)，它是对数时间复杂度。

二分查找的递归与非递归实现

最简单的情况就是有序数组中不存在重复元素，我们在其中用二分查找值等于给定值的数据。

public int bsearch(int[] a, int n, int value) {
  int low = 0;
  int high = n - 1;

  while (low <= high) {
    int mid = (low + high) / 2;
    if (a[mid] == value) {
      return mid;
    } else if (a[mid] < value) {
      low = mid + 1;
    } else {
      high = mid - 1;
    }
  }

  return -1;
}

容易出错的 3 个地方

1. 循环退出条件
   • 注意是 low<=high，而不是 low<high。
2. mid 的取值
   1. mid=(low+high)/2 这种写法是有问题的。因为如果 low 和 high 比较大的话，两者之和就有可能会溢出。改进的方法是将 mid 的计算方式写成 low+(high-low)/2。
   2. 如果要将性能优化到极致的话，可以将除以 2 操作转化成位运算 low+((high-low)>>1)。因为相比除法运算来说，计算机处理位运算要快得多。
3. low 和 high 的更新
   • low=mid+1，high=mid-1。注意这里的 +1 和 -1，如果直接写成 low=mid 或者 high=mid，就可能会发生死循环。比如，当 high=3，low=3 时，如果 a[3] 不等于 value，就会导致一直循环不退出

递归实现：

// 二分查找的递归实现
public int bsearch(int[] a, int n, int val) {
  return bsearchInternally(a, 0, n - 1, val);
}

private int bsearchInternally(int[] a, int low, int high, int value) {
  if (low > high) return -1;

  int mid =  low + ((high - low) >> 1);
  if (a[mid] == value) {
    return mid;
  } else if (a[mid] < value) {
    return bsearchInternally(a, mid+1, high, value);
  } else {
    return bsearchInternally(a, low, mid-1, value);
  }
}

二分查找应用场景的局限性

• 首先，二分查找依赖的是顺序表结构，简单点说就是数组。
  • 其他数据结构存储的，无法应用二分查找。
• 其次，二分查找针对的是有序数据。
  • 如果有频繁的插入和删除操作，要想用二分查找，要么每次插入、删除操作之后保证数据仍然有序，要么在每次二分查找之前都先进行排序。维护有序的成本都是很高的。
• 再次，数据量太小不适合二分查找。
• 最后，数据量太大也不适合二分查找。
  • 二分查找的底层需要依赖数组这种数据结构，而数组为了支持随机访问的特性，要求内存空间连续，对内存的要求比较苛刻。

解答开篇

如何在 1000 万个整数中快速查找某个整数？

我们的内存限制是 100MB，每个数据大小是 8 字节，最简单的办法就是将数据存储在数组中，内存占用差不多是 80MB，符合内存的限制。我们可以先对这 1000 万数据从小到大排序，然后再利用二分查找算法，就可以快速地查找想要的数据了。

注意，虽然大部分情况下，用二分查找可以解决的问题，用散列表、二叉树都可以解决。但是，不管是散列表还是二叉树，都会需要比较多的额外的内存空间。如果用散列表或者二叉树来存储这 1000 万的数据，用 100MB 的内存肯定是存不下的。而二分查找底层依赖的是数组，除了数据本身之外，不需要额外存储其他信息，是最省内存空间的存储方式，所以刚好能在限定的内存大小下解决这个问题。

内容小结

今天我们学习了一种针对有序数据的高效查找算法，二分查找，它的时间复杂度是 O(logn)。

二分查找的核心思想理解起来非常简单，有点类似分治思想。即每次都通过跟区间中的中间元素对比，将待查找的区间缩小为一半，直到找到要查找的元素，或者区间被缩小为 0。但是二分查找的代码实现比较容易写错。你需要着重掌握它的三个容易出错的地方：循环退出条件、mid 的取值，low 和 high 的更新。

二分查找虽然性能比较优秀，但应用场景也比较有限。底层必须依赖数组，并且还要求数据是有序的。对于较小规模的数据查找，我们直接使用顺序遍历就可以了，二分查找的优势并不明显。二分查找更适合处理静态数据，也就是没有频繁的数据插入、删除操作。

本节介绍了一些有效的性能优化方法，主要内容包括布局优化、绘制优化、内存泄露优化、响应速度优化、ListView 优化、Bitmap 优化、线程优化以及一些性能优化建议，在介绍响应速度优化的同时还介绍了ANR日志的分析方法。

15.1.1 布局优化

布局优化的思想很简单，就是尽量减少布局文件的层级，布局中的层级少了，这就意味着Android绘制时的工作量少了，那么程序的性能自然就高了。

首先删除布局中无用的控件和层级，其次有选择地使用性能较低的ViewGroup。布局优化的另外一种手段是采用标签、 标签和ViewStub。

• 标签主要用于布局重用；
• 标签一般和配合使用，它可以降低减少布局的层级；
• ViewStub则提供了按需加载的功能，当需要时才会将ViewStub中的布局加载到内存，这提高了程序的初始化效率。

15.1.2 绘制优化

绘制优化是指View的onDraw方法要避免执行大量的操作，这主要体现在两个方面。

1. 首先，onDraw中不要创建新的局部对象，这是因为onDraw方法可能会被频繁调用，这样就会在一瞬间产生大量的临时对象，这不仅占用了过多的内存而且还会导致系统更加频繁gc，降低了程序的执行效率。
2. 另外一方面，onDraw 方法中不要做耗时的任务，也不能执行成千上万次的循环操作，尽管每次循环都很轻量级，但是大量的循环仍然十分抢占CPU的时间片，这会造成View的绘制过程不流畅。按照Google官方给出的性能优化典范中的标准，View 的绘制帧率保证60fps是最佳的，这就要求每帧的绘制时间不超过16ms ( 16ms= 1000/ 60)，虽然程序很难保证16ms这个时间，但是尽量降低onDraw方法的复杂度总是切实有效的。

15.1.3 内存泄露优化

内存泄露的优化分为两个方面，一方面是在开发过程中避免写出有内存泄露的代码，另一方 面是通过一些分析工具比如来找出潜在的内存泄露继而解决。

• 场景1:静态变量导致的内存泄露
• 场景2:单例模式导致的内存泄露
• 场景3:属性动画导致的内存泄露

15.1.4 响应速度优化和ANR日志分析

响应速度优化的核心思想是避免在主线程中做耗时操作，但是有时候的确有很多耗时操作，怎么办呢?
可以将这些耗时操作放在线程中去执行，即采用异步的方式执行耗时操作。响应速度过慢更多地体现在Activity 的启动速度上面，如果在主线程中做太多事情，会导致Activity启动时出现黑屏现象，甚至出现ANR。
Android 规定，Activity 如果5秒钟之内无法响应屏幕触摸事件或者键盘输入事件就会出现ANR，而BroadcastReceiver 如果10秒钟之内还未执行完操作也会出现ANR。
在实际开发中，ANR是很难从代码上发现的，如果在开发过程中遇到了ANR,那么怎么定位问题呢?其实当一个进程发生ANR了以后，系统会在/data/anr目录下创建一个文件traces.txt,通过分析这个文件就能定位出ANR的原因。

15.1.5 ListView和Bitmap优化

ListView的优化（适用于GridView）：

1. 首先要采用ViewHolder并避免在getView中执行耗时操作；
2. 其次要根据列表的滑动状态来控制任务的执行频率，比如当列表快速滑动时显然是不太适合开启大量的异步任务的;
3. 最后可以尝试开启硬件加速来使Listview的滑动更加流畅。

Bitmap的优化，主要是通过BitmapFactory.Options来根据需要对图片进行采样，采样过程中主要用到了BitmapFactory.Options 的inSampleSize参数。

15.1.6 线程优化

线程优化的思想是采用线程池，避免程序中存在大量的Thread。线程池可以重用内部的线程，从而避免了线程的创建和销毁所带来的性能开销，同时线程池还能有效地控制线程池的最大并发数，避免大量的线程因互相抢占系统资源从而导致阻塞现象的发生。因此在实际开发中，我们要尽量采用线程池，而不是每次都要创建一个 Thread对象。

15.1.7 一些性能优化建议

• 避免创建过多的对象;
• 不要过多使用枚举，枚举占用的内存空间要比整型大;
• 常量请使用static final来修饰;
• 使用一 些Android 特有的数据结构，比如SparseArray和Pair等，它们都具有更好的性能;
• 适当使用软引用和弱引用;
• 采用内存缓存和磁盘缓存:
• 尽量采用静态内部类，这样可以避免潜在的由于内部类而导致的内存泄露。

15.2 内存泄露分析之MAT工具

15.3 提高程序的可维护性

插件化技术和热修复技术都属于动态加载技术。

15.1 动态加载技术

在Android传统开发中，一旦应用的代码被打包成APK并被上传到各个渠道市场，我们就不能修改应用的源码了，只能通过服务器来控制应用中预留的分支代码。但是很多时候我们无法提前预知需求和突然发生的情况，也就不能提前在应用代码中预留分支代码，这时就需要采用动态加载技术。

在应用程序运行时，动态加载一些程序中原本不存在的可执行文件并运行这些文件里的代码逻辑。可执行文件总的来说分为两种，一种是动态链接库so，另一种是dex相关文件(dex 以及包含dex的jar/apk文件)。

随着应用开发技术和业务的逐步发展，动态加载技术派生出两个技术，分别是热修复技术和插件化技术，其中热修复技术主要用来修复Bug, 插件化技术则主要用于解决应用越来越庞大以及功能模块的解耦。

15.2 插件化的产生

15.2.1 应用开发的痛点和瓶颈

1. 业务复杂，模块耦合
2. 应用间的接入
3. 65536限制，内存占用大

15.2.2 插件化思想

15.2.3 插件化定义

插件化的客户端由宿主和插件两个部分组成。宿主就是指先被安装到手机中的APK,就是平常我们加载的普通APK。插件一般是指经过处理的APK.so和dex等文件，插件可以被宿主进行加载，有的插件也可以作为APK独立运行。

讲到这里就可以引出插件化的定义：将一个应用按照插件的方式进行改造的过程就叫作插件化。

在协作方面，插件可以由一个人或者一个小组来进行开发，这样各个插件之间，以及插件和宿主之间的耦合度会降低。应用间的接入和维护也变得便捷，每个应用团队只需要负责自己的那一部分就可以了。应用以及主dex的体积也会相应变小，间接地避免了65536限制。第一次加载到内存的只有淘宝主客户端，当使用到其他插件时才会加载相应插件到内存，这样就减少了内存的占用。

15.3 插件化框架对比

15.4 Activity插件化

四大组件的插件化是插件化技术的核心知识点，而Activity 插件化更是重中之重，Activity插件化主要有3种实现方式，分别是反射实现、接口实现和Hook技术实现。反射实现会对性能有所影响，主流的插件化框架没有采用此方式，关于接口实现可以阅读dynamic-load-apk的源码，目前Hook技术实现是主流，因此本章主要介绍Hook技术实现。

Hook技术实现主要有两种解决方案，一种是通过Hook IActivityManager来实现，另一种是Hook Instrumentation实现。在讲到这两个解决方案前,我们需要从整体上了解Activity的启动流程。

15.4.1 Activity的启动过程回顾

首先Launcher进程向AMS请求创建根Activity, AMS会判断根Activity所需的应用程序进程是否存在并启动，如果不存在就会请求Zygote进程创建应用程序进程。应用程序进程启动后, AMS会请求应用程序进程创建并启动根Activity。

普通Activity和根Activity的启动过程大同小异，不涉及应用程序进程的创建，与Launcher也没关系：

在应用程序进程中的Activity 向AMS请求创建普通Activity (步骤1)，AMS会对这个Activity的生命周期和栈进行管理，校验Activity等。如果Activity 满足AMS的校验，AMS就会请求应用程序进程中的ActivityThread去创建并启动普通Activity (步骤2)。

15.4.2 Hook IActivityManager方案实现

AMS存在于SystemServer 进程中,我们无法直接修改,只能在应用程序进程中做文章。可以采用预先占坑的方式来解决没有在AndroidManifest.xml 中显式声明的问题，具体做法就是先使用一个在AndroidManifest.xml中注册的Activity来进行占坑，用来通过AMS的校验。接着用插件Activity替换占坑的Activity。

1. 注册Activity进行占坑
2. 使用占坑Activity通过AMS验证
3. 还原插件Activity
4. 插件Activity的生命周期

15.4.3 Hook Instrumentation方案实现

Hook Instrumentation 实现同样也需要用到占坑Activity,与Hook IActivityManager实现不同的是，用占坑Activity替换插件Activity以及还原插件Activity 的地方不同。

15.4.4 总结

15.5 Service插件化

15.5.1 插件化方面Service与Activity的不同

我们需要了解在插件化方面Activity和Service有何不同：

• Activity是基于栈管理的，一个栈中的Activity的数量不会太多，因此插件化框架处理的插件Activity 数量是有限的，可以声明有限的占坑Activity 来实现。除去硬件和系统限制，插件化框架处理的插件Service的数量可以是近乎无限的，无法用有限的占坑Service来实现。
• 在Standard模式下多次启动同一个占坑Activity 可以创建多个Activity 实例，但是多次启动占坑Service并不会创建多个Service实例。
• 用户和界面的交互会影响到Activity 的生命周期，因此插件Activity 的生命周期需要交由系统来管理，Hook IActivityManager方案中还原插件Activity 就是为了这一点。Service的生命周期不受用户影响，可以由开发者管理生命周期，没有必要还原插件。

15.5.2 代理分发实现

Activity插件化的重点在于要保证它的生命周期，而Service插件化的重点是保证它的优先级，这就需要用一个真正的Service 来实现，而不是像占坑Activity那样起一个占坑的作用。当启动插件Service时，就会先启动代理Service,当这个代理Service 运行起来之后，在它的onStartCommand等方法里面进行分发，执行插件TargetService 的onCreate等方法,这一方案就叫作代理分发。

1. 启动代理Service
2. 代理分发

15.6 ContentProvider插件化

15.6.1 ContentProvider的启动过程回顾

15.6.2 VirtualApk的实现

1. VirtualApk 初始化
2. 启动代理ContentProvider
3. 代理分发

15.7 BroadcastReceiver的插件化

15.7.1 广播插件化思路

IntentFilter的，讲到这里我们得到了一个新思路，那就是将静态注册的BroadcastReceiver全部转换为动态注册来处理，虽然静态和动态的BroadcastReceiver 的生命周期不同，但是为了实现插件化，这个缺点显然不是关键问题。

15.7.2 VirtualApk的实现

15.8 资源的插件化

15.8.1 系统资源加载

15.8.2 VirtualApk实现

资源的插件化方案主要有两种:一种是合并资源方案，将插件的资源全部添加到宿主的Resources中，这种方案插件可以访问宿主的资源。另一 种是构建插件资源方案，每个插件都构造出独立的Resources，这种方案插件不可以访问宿主资源。VirtualApk 采用了以上两种方案。

15.9 so的插件化

so热修复主要有两种方案:

• 将so补丁插入到NativeLibraryElement数组的前部，让so补丁的路径先被返回和加载。
• 调用System的load方法来接管so的加载入口。

so的插件化的方案和so热修复第一种方案类似，简单来说就是将so插件插入到NativeLibraryElement数组中，并且将存储so插件的文件添加到nativeLibraryDirectories 集合中就可以了。

15.10 本章小结

在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。

介绍

意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
主要解决：一些方法通用，却在每一个子类都重新写了这一方法。
何时使用：有一些通用的方法。
如何解决：将这些通用算法抽象出来。
关键代码：在抽象类实现，其他步骤在子类实现。
应用实例： 1、在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。 2、西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。 3、spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，比如开启事务、获取 Session、关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就可以保存。
优点： 1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3、行为由父类控制，子类实现。
缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。
使用场景： 1、有多个子类共有的方法，且逻辑相同。 2、重要的、复杂的方法，可以考虑作为模板方法。
注意事项：为防止恶意操作，一般模板方法都加上 final 关键词。