1.

1.

1.

1. MVC 模式

• 历史：
  • 最早由 Trygve Reenskaug 于 1978 年在 Smalltalk-80 系统上首次提出的一种软件设计模式。

• 定义：

  • Model（模型层）：针对业务模型，建立的数据结构和相关的类。主要负责网络请求、数据库处理、I/O 等操作。
  • View（视图层）：一般采用 XML 文件或者 Java 代码进行界面的描述，也可以使用 JavaScript+HTML 等方式作为 View 层。
  • Controller（控制层）：Android 的控制层通常在 Activity、Fragment 或由它们控制的其他业务类中。这些类主要是作为初始化页面，展示数据的操作，但是因为你 XML 视图功能太弱，所以 Activity 既要负责视图的显示又要加入控制逻辑，承担的功能过多。

• 特点：

  • Activity 并不是一个标准的 MVC 模式中的 Controller，它的首要职责是加载应用的布局和初始化用户界面，接受并处理来自用户的操作请求，进而做出响应。随着界面及其逻辑复杂度的不断提升，Activity 类的职责不断增加，以致变得庞大臃肿。
  • View 层和 Model 层相互耦合，不易开发和维护。

2. MVP 模式

• 历史：
  • MVP 是 MVC 的演化版本。

• 定义：

  • Model：主要负责数据的存取功能。Presenter 需要通过 Model 层来存储、获取数据。
  • View：负责处理用户事件和视图部分的展示。在 Android 中，它可能是 Activity、Fragment 或者是某个 View 控件。
  • Presenter：作为 View 和 Model 之间沟通的桥梁，它从 Model 层检索数据后返回给 View 层，使得 View 和 Model 之间没有耦合。

• 特点：

  • 在 MVP 里，Presenter 完全将 Model 和 View 进行了分离，主要的程序逻辑在 Presenter 里实现。
  • Presenter 与具体的 View 是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更 View 时可以保持 Presenter 的不变，这点符合面向接口编程的特点。
  • View 层理想情况下应该有简单的 set/get 方法，以及用户输入和设置界面显示的内容，除此之外就不应该有更多的内容。绝不允许 View 直接访问 Model，这是其与 MVC 的很大不同之处。

• 参考：

  • Google 官方的 MVP 实例
  • 不要再给 MVP 中 Prensenter 写接口了

• 应用：

  • 练手项目 | 基于 MVP+RxJava2+Retrofit2 的资讯类 App

3. MVVM 模式

• 历史：

  • 最早于 2005 年由微软的 WPF 和 Silverlight 的架构师 John Gossman 提出，将 Presenter 改为 ViewModel。
  • 2015 年 Google I/O 大会，Google 发布了 MVVM 架构模式的支持库 Data Binding。
  • Data Binding 官方介绍

• 定义：

  • 和 MVP 类似，不同的是 ViewModel 和 View 进行双向绑定。
  • 当 View 发生改变时，ViewModel 通知 Model 进行更新数据；同理 Model 数据更新后，ViewModel 通知 View 更新。
  • 通过 Dada Binding，我们可以通过声明式布局以精简的代码来绑定应用程序的逻辑和布局，这样就不用编写大量的类似 findViewById() 这样的模板代码了。

• 特点：

  • 在默认情况下，Binding 辅助类的名称取决于布局文件的命名，其以大写字母开头，移除下划线，后续的单词首字母大写并以 Binding 结尾，比如 ActivityMainBinding。辅助类包含了布局文件中所有的绑定关系，并会根据绑定表达式给布局文件赋值。
  • 动态更新：Data Binding 提供了 3 种动态更新机制，根据 Model 实体类的内容来动态更新 UI，分别对应于类（Observable）、字段（ObservableField）和集合类型（Observable 容器类）。通过动态更新机制，当 Model 发生变化时，就会通知 ViewModel 对 View 进行动态更新。
  • 双向绑定：Data Binding 在 Android Studio 2.1 Preview 3 版本之后，开始支持双向绑定，即如果 UI 发生变化，Model 实体类实现动态更新，前提是需要结合动态更新机制。

• 参考：

  • 深入了解 MV** 模式
  • MVC、MVP、MVVM，我到底该怎么选？

• 应用：

  • 分享一个我开发的 MVVM 架构的开源小项目

写法

写法（一）：懒汉式（线程不安全）

• 代码：

  public class Singleton {
      private static Singleton instance;
  
      // 私有的构造方法，这样除了它本身，不会被其他类实例化
      private Singleton() {}
  
      // 单例模式中，getInstance() 的写法更常见；Java 源码中 newInstance() 的写法更常见。而且从语义上来说，getInstance() 的方法名更贴近“单例”的含义
      // 通过此静态方法提供全局获取唯一可用对象的访问点
      public static Singleton getInstance() {
          if(instance == null) { // 当多个线程执行到这行代码时会产生多个实例
              intance = new Singleton();
          }
          return instance;
      }
  }
  

• 分析：这种写法懒加载（lazy loading）很明显，但致命的缺点是在多线程环境下不能正常工作（“永远不要使用线程不安全的单例” – from Tencent Bugly）。

写法（二）：懒汉式（线程安全）

• 代码：

  public class Singleton {
      private static Singleton instance;
  
      private Singleton() {}
  
      public static synchronized Singleton getInstance() { // 通过加锁🔐解决多线程不安全问题
          if(instatnce == null) {
              instance = new Singleton();
          }
          return instance;
      }
  }
  

• 分析：这种写法能够在多线程环境中很好地工作，而且看起来也具备很好的懒加载（lazy loading）能力。但是，遗憾的是，这种写法的效率很低（耗费内存），99% 的情况下不需要同步。

写法（三）：饿汉式（实例公有化）

• 代码：

  // Singleton with public final field
  public class Singleton {
  
      // 使用 public 修饰，因此无需 getInstance() 方法，可以直接拿到 instance 实例
      // 此方法由 final 来保证每次返回的都是同一个对象的引用，私有的构造方法也只会被调用一次
      public static final Singleton instance = new Singleton();
  
      private Singleton() {}
  }
  

• 分析：优点是比较简洁（不再有优势）

写法（四）：饿汉式（实例私有化）

• 代码：

  // Singleton with static factory
  // 现代的 JVM 基本都内嵌了对 static factory 方法的调用，使得 public field 方式不再有优势
  // 此方法更灵活，只需修改 getInstance() 的返回逻辑，而不需要改变 API 就可以将类改为非单例类
  public class Singleton {
      private static Singleton instance = new Singleton();
  
      private Singleton() {}
  
      public static Singleton getInstance() {
          return instance;
      }
  }
  

• 分析：这种写法基于 ClassLoader 机制从而避免了多线程环境下的同步问题。不过，instance 在类加载时就实例化（虽然导致类加载的原因有很多），在单例模式中大多都是因为调用 getInstance() 方法，但是也不能确定有其他的方式（或者其他的静态方法）导致类加载，这时候初始化 instance 显然没有达到懒加载（lazy loading）的效果。

写法（五）：饿汉式（静态代码块）

• 代码：

  public class Singleton {
      private Singleton instance = null;
  
      private Singleton() {}
  
      static {
          instance = new Singleton(); // 基静态、子静态 -> 基实例代码块、基构造 -> 子实例代码块、子构造
      }
  
      public static Singleton getInstance() {
          return this.instance;
      }
  
  }
  

• 分析：三种饿汉式差别不大，都是在类初始化时实例化 instance。

写法（六）：静态内部类（线程安全）

• 代码：

  public class Singleton {
  
      private static class SingletonHolder { // 私有的静态内部类
          private static final Singleton INSTANCE = new Singleton();
      }
  
      private Singleton() {}
  
      public static final Singleton getInstance() {
          return SingletonHolder.INSTANCE;
      }
  }
  

• 分析：这种写法同样利用了 ClassLoader 的类加载机制来保证初始化 instance 时只有一个线程。它跟饿汉式写法不同的是（很细微的差别）：饿汉式是只要 Singleton 类被加载了，那么 instance 就会被实例化（没有达到懒加载的效果），而静态内部类的写法是即使 Singleton 类被加载了，instance 却不一定被实例化。因为 SingletonHolder 内部类没有被主动使用过，只有显示通过调用 getInstance() 方法时，才会显示加载 SingletonHolder 类，从而实例化 instance。想象一下，如果实例化 instance 很消耗资源，我想让它延迟加载；另一方面，我不希望在 Singleton 类加载时就实例化，因为我不能确保 Singleton 类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化 instance 显然是不合适的。这个时候，静态内部类的写法相比饿汉式写法就显得很合理。

写法（七）：双重检验锁（线程安全）

• 代码：

  public class Singleton {
      // volatile 关键字的作用：保证内存可见性、保证有序性（禁止指令重排），但不保证原子性
      // 大部分情况下不加 volatile 也是可以的，但如果发生指令重排，则会在第二次 check 处导致线程不安全
      private volatile static Singleton instance; 
  
      private Singleton() {}
  
      public static Singleton getInstance() {
          if(instance == null) { // 第一次 check，避免不必要的同步
              synchronized(Singleton.class) { // 仅同步实例化的代码块
                  if(instance == null) { // 第二次 check，保证线程安全
                      instance = new Singleton();
                  }
              }
          }
          return instance;
      }
  }
  

• 分析：这种写法是第二种写法的升级版，不过在 JDK 1.5 之后，双重校验锁才能达到单例效果。

写法（八）：枚举（线程安全）

• 代码：

  public enum Singleton {
      INSTANCE;
  
      // 枚举同普通类一样，可以有自己的成员变量和方法
      public void do() {
          System.out.println("Do whatever you want");
      }
  }
  

• 分析：这种写法是 《Effective Java》 作者 Josh Bloch 提倡的方式，它不仅能避免多线程同步问题（创建枚举默认就是线程安全的），而且还能防止反序列化重新创建新的对象，可谓是很坚强的壁垒。不过，个人认为由于在 JDK 1.5 中才加入 enum 特性，用这种方式写不免让人感觉生疏。在实际工作中，也很少见有人这么写过。

• 优点：

  • 枚举单例写法简单：肉眼可见。
  • 枚举可解决线程安全问题：反序列化后，可以发现内部使用了 static、final 修饰每一个枚举项。
  • 枚举可避免反序列化破坏单例：普通类的反序列化会使用反射，反序列化后的对象是重新 new 出来的，这就破坏了单例，而枚举的序列化和反序列化是有特殊定制的。

• 参考：为什么我墙裂建议大家使用枚举来实现单例

写法（九）：CAS 方式

• 代码：

  public class Singleton {
      // AtomicReference 是原子引用类型，用来以原子方式更新复杂类型
      private static final AtomicReference<Singleton> INSTANCE = new AtomicReference<Singleton> ();
  
      private Singleton() {}
  
      public static Singleton getInstance() {
          for(;;) {
              Singleton instance = INSTANCE.get();
              if(instance != null) {
                  return instance;
              }
              instance = new Singleton();
              // CAS 方法有两个参数 expect 和 update，以原子方式实现了比较并设置的功能
              // 如果当前值等于 expect，则更新为 update 并返回 true；否则不更新并返回 false
              if(INSTANCE.compareAndSet(null, instance)) {
                  return instance;
              }
          }
      }
  }
  

• 分析：

  • 上面几种线程安全的单例写法，虽然没有在代码中显示的使用 synchronized（除了双重校验锁写法），但是，都是借助了 ClassLoader 的线程安全机制。而 ClassLoader 的线程安全机制底层也是使用了 synchronized 的；ClassLoader 的 loadClass() 方法在加载类的时候使用了 synchronized 关键字。也正是因为这样， 除非被重写，这个方法默认在整个类加载过程中都是同步的（线程安全的）。
  • 优点：不需要使用传统的锁机制来保证线程安全，CAS 是一种基于忙等待的算法，依赖底层硬件的实现，相对于锁它没有线程切换和阻塞的额外消耗，可以支持较大的并行度。
  • 缺点：如果忙等待一直执行不成功(一直在死循环中)，会对 CPU 造成较大的执行开销。而且，这种写法如果有多个线程同时执行 singleton = new Singleton(); 也会比较耗费堆内存。

• 参考：不使用synchronized和lock，如何实现一个线程安全的单例？

写法（十）：Lock 方式

• 代码：

  // 类似双重校验锁写法
  public class Singleton {
         private static Singleton instance = null;
         private static Lock lock = new ReentrantLock();
  
         private Singleton() {}
  
         public static Singleton getInstance() {
             if(instance == null) {
                 lock.lock(); // 显式调用，手动加锁
                 if(instance == null) {
                     instance = new Singleton();
                 }
                 lock.unlock(); // 显式调用，手动解锁
             }
             return  instance;
         }
  }
  

• 参考：你写的单例是线程安全的吗？

对比

总结

• 有两种场景可能导致非单例的情况（还有一种克隆的场景）：

  • 场景一：如果单例由不同的类加载器加载，那便有可能存在多个单例类的实例。假设不是远端存取，例如一些 servlet 容器，对每个 servlet 使用完全不同的类加载器，这样的话如果有两个 servlet 访问一个单例类，它们就会有各自的实例。

    • 解决办法：

      private static Class getClass(String className) throws ClassNotFoundException {
          ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
      
          if(classLoader = null) {
              classLoader = Singleton.class.getClassLoader();
          }
      
          return (classLoader.loadClass(className));
      }
      

  • 场景二：如果 Singleton 实现了 java.io.Serializable 接口，那么这个类的实例就可能被序列化和反序列化。不论如何，如果序列化一个单例类的对象，接下来反序列多个那个对象，那就会有多个单例类的实现。

    • 解决办法：

      public class Singleton implements Serializable {
          public static Singleton INSTANCE = new Singleton();
      
          protected Singleton() {}
      
          private Object readResolve() {
              return INSTANCE;
          }
      }
      

• 就个人来说，更倾向第三种（饿汉式）和第五种（静态内部类），简单易懂，而且在 JVM 层实现了线程安全（如果不是多个类加载器的情况）。

  • 一般情况下，会使用第三种（饿汉式），只有在要明确实现懒加载效果时才会使用第五种（静态内部类）。
  • 另外 ，如果涉及到反序列化创建对象时会尝试使用第六种（枚举）的方式来实现单例。不过，尽量保证我们程序是线程安全的，而且尽量不会使用懒汉式。
  • 如果有其他特殊需求，可能会使用第七种（双重校验锁）方式，毕竟，JDK 1.5 已经没有双重检查锁定的问题了。

• 一般来说，第一种（懒汉式，线程不安全）不算单例，第三种（饿汉式，线程安全）和第四种（饿汉式，静态代码块变种）就是一种。如果算的话，第五种（静态内部类）也可以分开写了。所以，一般单例都是六种写法，即：懒汉式、饿汉式、静态内部类、枚举、双重校验锁、CAS 方式。

参考

• 《单例模式的七种写法》
• 《那么静，那么美，单例模式》
• 《那些年，我们一起写过的“单例模式”》

1. 单一职责原则

• 概念：

  • 英文是 Single Responsibility Principle，简称 SRP，简单说，就是一个类只做一件事。
  • 这个设计原则备受争议却又及其重要，因为单一原则的划分界限并不是很清晰，很多时候都需要个人经验来界定。所以，最大的问题就是对职责的定义，类的职责是什么，以及怎么划分类的职责。
  • 单一职责原则并不意味着一个类只能有一个方法，而是说这个类中的方法所做的工作是高度相关的，即高内聚。

• 优点：

  • 变更引起的风险降低。
  • 可读性提高，容易维护，方便扩展。
  • 类的复杂性降低，实现什么职责都有清晰明确的定义。

2. 里氏替换原则

• 概念：

  • 里氏替换原则依赖于继承、多态两大面向语言特性。简单来说，里氏替换原则就是所有引用基类、接口的地方必须能够透明地使用其子类的对象。
  • 通俗来说，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，调用方可能根本就不需要知道是父类还是子类。但是，反过来不行。
  • 很多框架就是这样实现的，框架定义一系列相关的逻辑骨架与抽象，使得调用方可以将自己的实现注入到框架中，从而实现各种功能。

• 优点：

  • 代码共享，减少了代码量。
  • 提高了代码的可扩展性。
  • 提高了代码的重用性。

• 缺点：

  • 继承是侵入性的，只要继承，就必须拥有父类的所有属性和方法。
  • 降低了代码的灵活性，可能使子类中多了一些方法属性约束。
  • 增强了耦合性，当父类需要修改时，必须要考虑到子类。

3. 依赖倒置原则

• 概念：

  • 高层模块不应该依赖底层模块，两者都应该依赖其抽象。抽象不应该依赖细节，而细节应该依赖抽象。
  • Java 中，抽象就是指接口或抽象类，细节就是实现类。
  • 简单来说，就是面向接口编程，或者面向抽象编程。

• 优点：

  • 可扩展性好，耦合度低。
  • 可读性高，可维护性好。
  • 降低并行开发风险，稳定性高。

4. 开闭原则

• 概念：

  • 开闭原则是面向对象编程中最基础的设计原则。
  • 一个软件实体如类、模块和方法应该对扩展开放、对修改关闭。
  • 当软件需要变化时，应尽量通过扩展方式实现变化，而不是通过修改已有代码的方式。

• 优点：

  • 增加稳定性。
  • 可扩展性高。

5. 接口隔离原则

• 概念：

  • 客户端不应该依赖它不需要的接口。
  • 一个类对另一个类的依赖应该建立在最小的接口上。
  • 当一个接口太大时，需要将它分割成一些更细小的接口。

• 优点：

  • 降低耦合性。
  • 增强可读性。
  • 隐藏实现细节。

6. 迪米特原则

• 概念：

  • 迪米特原则也称为最少知识原则（Least Knowledge Principle）。
  • 一个对象应该对其他对象有最少的了解，类似于接口隔离原则中的最小接口概念。
  • 还有一个英文解释：Only talk to your immedate friends（只与直接的朋友通信）。

• 优点：

  • 降低复杂度。
  • 降低耦合度。
  • 增加稳定性。

1. 什么是单元测试？

答：开发人员编写的、用于检测在特定条件下目标代码正确性的代码。

2. 单元测试的优点？

答：

• 便于后期重构：用单元测试尽量覆盖程序中的每一项功能的正确性，这样就算是开发后期，也可以有保障地增加功能或更改程序结构，而不用担心这个过程会破坏原来的功能。单元测试为代码的重构提供了保障，只要重构代码之后单元测试全部运行通过，那么，在很大程度上表示这次重构没有引入新的 Bug，当然这是建立在完整、有效的单元测试覆盖率的基础上。
• 优化设计：编写单元测试将使用户从调用者的角度观察、思考，特别是是 TDD 的开发方式，迫使设计者把程序设计成易于调用和可测试的，并且解除软件中的耦合。
• 文档记录：单元测试时一种无价的文档，是展示类或方法如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。
• 具有回归性：自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地快速运行测试，而不是将代码部署到设备上，然后再手动地覆盖各种执行路径，这样的操作效率很低。

3. 单元测试具体要测试哪些内容？

答：

• 边界条件（CORRECT）：

  • 一致性（Conformance）：值是否和预期一致。可以理解为当输入并不是预期的标准数据时，被测试方法是否可以正确地输出预期结果或抛出异常。例如，要实现一个加法功能，有两个 EditText 分别输入两个整型数字，但当用户输入的不是整型而是文字时如何处理。
  • 有序性（Ordering）：值是否像期望的那样是无序或有序的。
  • 区间性（Range）：值是否位于合理的最小值和最大值之间。例如，圆的角度为 1~360 度，当用户设置进来的角度为 400 度时如何处理。
  • 依赖性（Reference）：代码是否引用了一些不在代码本身控制范围之内的外部资源，当这些外部资源存在或不存在时代码是否可以产生相应的预期结果。例如需要将图片缓存到 SD 卡中，如果 SD 卡被移除或者没有 SD 卡我们做和处理。
  • 存在性（Existence）：值是否存在。测试方法是否可以处理值不存在的情况，例如对象为 null 的情况下得到的结果是什么。
  • 基数性（Cardinatity）：是否恰好有足够的值。这里的基数指的是计数，测试方法是否可以正确计数，并检查最后的计数值。
  • 时间性（Time）：所有事情的发生是否是有序的、是否在正确的时刻、是否恰好及时。与时间相关的问题有：相对时间（时间上的顺序）、绝对时间（消耗的时间和时钟上的时间）、并发问题。例如，方法调用的时间顺序、代码超时、不同的本地时间、多线程同步等。

• 覆盖执行路径：软件是由做种执行路径组成的，对于单元测试而言，覆盖各执行路径也是保证软件正确性运行的一个重要方面。

4. 介绍一下 JUnit？

答：JUnit 是一个基于 Java 语言的单元测试框架，它由敏捷开发先驱 Kent Beck 和 GOF 之一的 Erich Gamma 创建，逐渐成为源于 Kent Beck 的 sUnit 的 xUnit 家族中最为成功的一个。

5. JUnit 的执行流程？

答：

• 开发人员需要新建一个继承自 TestCase 的类，然后在该测试类中添加测试函数。
• 测试函数必须以 test 开头，并且是 public 的。
• 在每个 TestCase 被执行之前都会调用 setup() 方法进行初始化。
• 在 TestCase 结束之前会调用 tearDown() 函数进行一些扫尾工作。
• 需要注意的是，每个测试方法、TestCase 之间并没有什么关联，它们的执行顺序也不一定是代码中的顺序。因此，测试方法之间不要存在依赖性。

6. JUnit 中的断言和失败提示有哪些？

答：

• 断言函数：

  • assertEquals()：判断两个值或者两个对象是否相等。该函数有两个参数，参数 1 为预期的值，参数 2 为计算得到的值。通过判断两个值是否相等得出结果，如果相等 那么测试通过，否则测试失败。
  • assertTrue() 与 assertFalse()：验证真与假，只有一个 boolean 类型的参数。当参数与 assert 后面的 true 或者 false 对应时则表示通过，否则失败。
  • assertNull() 与 assertNotNull()：只有一个 Object 类型的参数，用于对对象判空或者非空。
  • assertSame() 与 assertNotSame()：前者用于判断两个对象是否是同一个对象；后者则是判断两个对象不是同一个。与 assertEquals() 不同的是，assertSame() 强调的是两个对象为同一个对象，而 assertEquals() 只有两个对象相等即可，即调用 equals() 方法时返回 true。

• 失败提示函数：

  • failNotEquals()：该函数有 3 个参数，第一个参数为失败时的提示信息；参数 2 为期望值，参数 3 为实际值。当两个对象不相等时测试抛出参数 1 的错误信息，否则测试通过。
  • failNotSame() 与 failSame()：failNotSame() 与 failNotEquals() 参数一致，不同的是 failNotSame() 两个对象不是同一个对象时抛出参数 1 的错误信息，否则测试通过。
  • fail(String) 与 fail()：fail(String) 直接抛出当前测试用例参数 1 中的错误信息，而 fail() 则会给出默认的错误信息。

7. JUnit 中怎样运行多个测试类？

答：同时运行多个测试类可以使用 TestSuite，TestSuite 是用来执行多个测试类的集合。使用 JUnit 4 有两种实现方式：

• 通过 JUnit4TestAdapter 包装测试类，并且将 JUnit4TestAdapter 对象添加到 TestSuite 中。
• 使用注解，包括 @RunWith(Suite.class)、@Suite.SuiteClasses 等。

8. Android 平台中的单元测试框架是？

答：

• JUnit 是针对 Java 平台的测试框架，Google 在 JUnit 的基础上进行了扩展，使之能够在 Android 上运行测试用例。
• Android 平台下所有的测试类都是 InstrumentationTestCase 的子类，它的内部封装了 Instrumentation 对四大组件进行操作。
• InstrumentationTestCase 继承自 JUnit 的 TestCase。

9. 怎样使用 Instrumentation 进行 Android 平台上的单元测试？

答：

• 需要 Context 的测试用例：Android 提供了一个 AndroidTestCase 来运行与 Android 平台相关的测试类。它有一个 mContext 字段，可以通过这个 Context 来完成测试工作。
• 测试 Activity：Android 提供了一个 ActivityUnitTestCase 类用来对 Activity 进行单元测试。通过 ActivityUnitTestCase 用户可以启动某个 Activity、测试布局、Intent 参数等内容，使得我们对 Activity 能够做一些简单的单元测试。
• 测试 Service：Android 提供了 ServiceTestCase 类来测试 Service。它提供了一个 startService() 方法来启动 Service，在 startService() 方法中又会调用 Service 的 onStartCommand() 方法。此外，它还提供了启动 Service 的另外一种方式，也就是 bindService()。
• 测试 ContentProvider：Android 提供了 ProviderTestCase2，它提供了一个用于测试的 ContentResolver，可以通过 getMockContentResolver() 方法得到。获取 ContentResolver 之后，就可以根据指定的 Uri 对表进行操作。

1. 什么是 TDD？

答：

• 定义：TDD 的全称叫做 Test-Driven Development，即测试驱动开发。它是一种软件开发流程，由敏捷的“极限编程”引入。
• 原理：先写出测试用例，然后再写功能代码。确保所有对外暴露的代码都可测试，并且通过测试。

2. TDD 的具体流程？

答：

1. 新建一个测试类，添加测试用例。
2. 新建功能实现类。
3. 运行测试，由于功能类未完成，测试失败。
4. 补充功能类，实现功能。
5. 再次运行测试，使得测试通过。
6. 重复这个过程完成整个应用的开发。

3. TDD 的优缺点？

答：

• 优点：

  • 代码可测试：它从测试出发，保证了代码的可测试性。
  • 耦合度低：在测试的过程中，为了可测试的需求，开发人员必须将一些逻辑从 UI 等难于测试的地方解耦出来，使得系统的耦合度降低，使得代码粒度更小，结构清晰。
  • 测试覆盖率：具有一定的测试覆盖率，可以为后续的升级维护提供正确性保证。

• 缺点：上手难度较高，开发人员需要一定的能力以及一段时间的适应才能驾驭这种方法。

4. 怎样使用 TDD？

答：建议使用 Robolectric，它将测试运行在 JVM 之上，省去了测试部署、加载到模拟器的耗时操作，同时避免了一些由于 Stub 引起的问题。

1. Android 中创建定时任务的方式？

答：Android 中的定时任务一般有两种实现方式，一种是使用 Java API 里提供的 Timer 类；一种是使用 Android 中的 Alarm 机制。这两种方式在大多数情况下都能实现类似的效果。

• Timer：

  • 缺点：明显的短板是，它不太适合那些需要长期在后台运行的定时任务。因为休眠策略，Android 手机会在长时间不操作的情况下自动让 CPU 进入到睡眠状态，这就有可能导致 Timer 中的定时任务无法正常运行。

• Alarm：

  • 特点：Alarm 具有唤醒 CPU 的功能，它可以保证在大多数情况下需要执行定时任务的时候 CPU 都能正常工作。需要注意的是，唤醒 CPU 和唤醒屏幕完全不是一个概念。

2. 【笔试题】手写一个使用 Alarm 机制创建定时任务的 Demo？

答：

• Demo：

  public class LongRunningService extends Service {
      @Override
      public IBinder onBind(Intent intent) {
          return null;
      }
  
      @Override
      public int onStartCommand(Intent intent, int flags, int startId) {
          new Thread(new Runnable() { // 开启一个子线程执行定时任务，这比放在主线程更加准确，因为逻辑操作也是耗时的
              @Override
              public void run() {
                  // 在这里执行具体的逻辑操作
              }
          }).start();
          AlarmManager manager = (AlarmManager) getSystemService(ALARM_SERVICE); // 获取一个 AlarmManager 实例
          int anHour = 60 * 60 * 1000;
  
          // 使用 SystemClock.elapsedRealtime() 方法可以获取到系统开机至今所经历时间的毫秒数
          // 使用 System.currentTimeMillis() 方法可以获取到 1970 年 1 月 1 日 0 点至今所经历时间的毫秒数
          long triggerAtTime = SystemClock.elapsedRealtime() + anHour;
          Intent i = new Intent(this, LongRunningService.class);
          PendingIntent pi = PendingIntent.getService(this, 0, i, 0);
  
          // 第一个参数是一个整型参数，用于指定 AlarmManager 的工作类型，有 4 种值可选
              // ELAPSED_REALTIME：表示让定时任务的出发时间从系统开机开始算起，但不会唤醒 CPU
              // ELAPSED_REALTIME_WAKEUP：同样表示让定时任务的触发时间从系统开机开始算起，但会唤醒 CPU
              // RTC：表示让定时任务的触发时间从 1970 年1 月 1 日 0 点开始算起，但不会唤醒 CPU
              // RTC_WAKEUP：同样表示让定时任务的触发时间从 1970 年 1 月 1 日 0 点开始算起，但会唤醒 CPU
          // 第二个参数是定时任务的触发时间，以毫秒为单位。要和第一个参数匹配，即开机配开机，RTC 配 RTC
              // 所以，也可以写成：long triggerTime = System.currentTimeMillis() + 10 * 1000; manager.set(AlarmManager.RTC_WAKEUP, triggerAtTime, pendingIntent);
          // 第三个参数是一个 PendingIntent，在创建通知那一节里第一次用到用于给通知增加点击功能
          manager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, triggerAtTime, pi); // 在后台服务中每隔一小时执行一次定时任务
          return super.onStartCommand(intent, flags, startId);
      }
  }
  
  // 启动定时服务
  Intent intent = new Intent(context, LongRunningService.class);
  context.startService(intent);
  

• 优化：

  • 从 Android 4.4 系统开始，Alarm 任务的触发时间将会变得不准确，有可能会延迟一段时间后任务才能得到执行。
  • 这并不是个 bug，而是系统在耗电性方面进行的优化。系统会自动检测目前有多少 Alarm 任务存在，然后将触发时间相近的几个任务放在一起执行，这就可以大幅度减少 CPU 被唤醒的次数，从而有效延长电池的使用时间。

• 更准确的方案：

  • 如果要求 Alarm 任务的执行时间必须准确无误，Android 仍然提供了解决方案：使用 AlarmManager 的 setExact() 方法来代替 set() 方法，就基本上可以保证任务能够准时执行了。
  • 如果要求 Alarm 任务即使在 Doze 模式下也必须正常执行，Android 还是提供了解决方案：调用 AlarmManager 的 setAndAllowWhileIdle() 或 setExactAndAllowWhileIdle() 方法就能让定时任务即使在 Doze 模式下也能正常执行。

3. 什么是 Doze 模式？

答：

• 在 Android 6.0 系统中，Google 加入了一个全新的 Doze 模式，可以大幅度延长电池的使用寿命。

• Doze 模式：

  • 当用户设备是 Android 6.0 或以上系统时，如果该设备未插接电源，处于静止状态（Android 7.0 中删除了这一条件），且屏幕关闭了一段时间后，就会进入 Doze 模式。
  • 在 Doze 模式下，系统会对 CPU、网络、Alarm 等活动进行限制，从而延长了电池的使用寿命。
  • 系统不会一直处于 Doze 模式，而是会间歇性地退出 Doze 模式一小段时间，在这段时间中，应用就可以去完成它们的同步操作、Alarm 任务等。随着设备进入 Doze 模式的时间越长，间歇性退出 Doze 模式的时间间隔也会越长，从而更好地把控电池使用寿命。

• Doze 模式下受限的功能：

  • 网络访问被禁止。
  • 系统忽略唤醒 CPU或者屏幕操作。
  • 系统不再执行 WIFI 扫描。
  • 系统不再执行同步服务。
  • Alarm 任务将会在下次退出 Doze 模式的时候执行。

4. 什么是多窗口模式？

答：

• 多窗口模式：允许用户在同一个屏幕中同时打开两个应用程序。

• 进入方式：

  • 在 Overview 列表界面长按任意一个活动的标题，将该活动拖动到屏幕突出显示的区域，就可以进入多窗口模式。
  • 打开任意一个程序，长按 Overview 按钮，也可以进入多窗口模式。

• 退出方式：

  • 再次长按 Overview 按钮。
  • 将屏幕中央的分隔线向屏幕任意一个方向拖动到底。

• 多窗口模式下的生命周期：

  • 多窗口模式并不会改变活动原有的生命周期，只是会将用户最近交互过的那个活动设置为运行状态，而将另外一个可见活动设置为暂停状态。
  • 如果这时用户又去和暂停的活动进行交互，那么该活动就变成运行状态，之前处于运行状态的活动变成暂停状态。
  • 进入多窗口模式的活动和横竖屏切换都是默认重新创建活动的，因为活动的大小发生了比较大的变化。
  • 需要注意的是，在多窗口模式下，用户仍然可以看到处于暂停状态的应用，所以像抖音、快手、直播等视频类的应用在此时就应该能继续播放视频才对。因此，最好不要在活动的 onPause() 方法中去处理视频播放器的暂停逻辑，而是应该在 onStop() 方法中去处理，并且在 onStart() 方法恢复视频的播放。

• 改变多窗口模式下活动被重新创建这一默认行为：

  • 在 AndroidManifest.xml 文件中对活动做如下配置：android:configChanges="orientation|keyboardHidden|screenSize|screenLayout">。
  • 配置之后，不管是进入多窗口模式，还是横竖屏切换，活动都不会被重新创建，而是会将屏幕发生变化的事件通知到 Activity 的 onConfigurationChanged() 方法中，所以，如有需要可以重写这个方法。

• 禁用多窗口模式：

  • 禁用方式：在 AndroidManifest.xml 的 <application> 或 <activity> 标签中加入如下属性即可：android:resizeableActivity="false"。如果不配置，默认值为 true。
  • 局限：属性 android:resizeableActivity 只有在项目的 targetSdkVersion 指定成 24 或更高的时候才会有用，否则该属性无效（即使进入多窗口模式，但可能无法正常工作）。
  • 解决方案：Android 规定，如果项目指定的 targetSdkVersion 低于 24，并且活动是不允许横竖屏切换的，那么该应用也将不支持多窗口模式。
  • 禁用横竖屏切换：默认情况下应用是允许横竖屏切换的，如果要禁用，可以在 AndroidManifest.xml 中配置：android:screenOrientation="portrait"（该属性还有很多其他值可选，但最常用的就是 portrait 和 landscape）。

5. Lambda 表达式在 Android 中的应用？

答：

• Java 8 中的特色功能有：Lambda 表达式、stream API、接口默认实现等。

  • stream API 和接口默认实现等特性都只支持 Android 7.0 及以上的系统。
  • Lambda 表达式最低兼容到 Android 2.3 系统。

• Lambda 表达式：本质上是一种匿名方法，没有方法名，也没有访问修饰符和返回值类型，使用它来编写代码将会更加简洁易读（相对而言）。

• Android 中使用 Lambda 表达式：

  • Lambda 适用于函数式接口，即只有一个方法的接口（开启线程、点击事件等）。

  • 在 app/build.gradle 中添加如下配置：

    android {
        ...
        defaultConfig {
            ...
            jackOptions.enabled = true
        }
        compileOptions {
            sourceCompatibility JavaVersion.VERSION_1_8
            targetCompatibility JavaVersion.VERSION_1_8
        }
    }
    

  • Demo1：

    // 传统方式
    new Thread(new Runnable() {
        @Override
        public void run() {
            // 处理具体的逻辑
        }
    }).start();
    
    // 使用 Lambda 表达式
    new Thread(() -> {
        // 处理具体的逻辑
    }).start();
    

  • Demo2：

    // 自定义的函数式接口，且方法有参数和返回值
    public interface MyListener {
        String doSomething(String a, int b); 
    }
    
    // 使用 Lambda 表达式创建 MyListener 接口的匿名实现
    MyListener listener = (String a, int b) -> {
        String result = a + b;
        return result;
    }
    
    // 简化版本
    MyListener listener = (a, b) -> {
        String result = a + b;
        return result;
    }
    

  • Demo3：

    // 给按钮设置点击事件
    
    // 传统方式
    Button button = (Button) fiindViewById(R.id.button);
    button.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            // 处理点击事件
        }
    });
    
    // 使用 Lambda 表达式
    Button button = (Button) findViewById(R.id.button);
    button.setOnClickListener((v) -> {
        // 处理点击事件
    });
    
    // 简化版本：当接口的实现方法有且只有一个参数的时候，还可以将参数外的括号省略
    Button button = (Button) findViewById(R.id.button);
    button.setOnClickListener(v -> {
        // 处理点击事件
    });
    

6. Android 10.0 中的新特性？

答：参考Android 10.0 来了，居然有这新特性！

1. 什么是 Material Design？

答：

• 定义：Material Design 是 Google 在 推出的一套全新的界面设计语言。它基于传统优秀的设计原则、结合丰富的创意和科技，包含了视觉、运动、交互效果等特性。

• 发展：

  • 2014 年 Google I/O 大会， Google 推出 Material Design。
  • 从 Android 5.0 系统开始，Google 将所有内置应用都使用 Material Design 风格进行设计。
  • 2015 年 Google I/O 大会，Google 推出了一个 Design Support 库，这个库将 Material Design 中最具代表性的一些控件和效果进行了封装，使得开发者可以轻松地将自己的应用 Material 化。

• 官方文章：https://material.google.com

2. 怎样理解 Toolbar？

答：

• ActionBar 和 Toolbar 的对比？

  • 每个活动最顶部的那个标题栏就是 ActionBar，由于自身设计的原因，ActionBar 只能位于活动的顶部，不能实现一些 Material Design 的效果。官方不再建议使用 ActionBar，而是更加推荐使用 Toolbar。
  • Toolbar 不仅继承了 ActionBar 的所有功能，而且灵活性很高，和可以配合其他控件来完成一些 Material Design 的效果。
  • 在 Fragment 中最好不要直接使用 Toolbar 或者 ActionBar，复用的时候可能会出现意想不到的效果。

• 主题 Theme.AppCompat.NoActionBar 和 Theme.AppCompat.Light.NoActionBar 的区别？

  • 在 AndroidManifest.xml 文件的 application 标签下，有一个 theme 属性，这个属性指定了一个 AppTheme 的主题，资源文件中这个 AppTheme 主题的 parent 默认是 Theme.AppCompat.Light.DarkActionBar。
  • Theme.AppCompat.NoActionBar：表示深色主题，它会将界面的主题颜色设为深色，陪衬颜色设为淡色。
  • Theme.AppCompt.Light.NoActionBar：表示淡色主题，它会将界面的主题颜色设为淡色，陪衬颜色设为深色。

• AppTheme 中的几个属性分别什么意思？

  • colorPrimary：应用标题栏的颜色。
  • colorPrimaryDark：系统状态栏的颜色。
  • textColorPrimary：应用标题栏中文字的颜色。
  • windowBackground：应用界面背景颜色。
  • navigationBarColor：应用底部导航栏颜色。
  • `colorAccent：不只是用来指定一个按钮的颜色（比如FAB），更多表达一个**强调**的意思，比如一些控件的选中状态也会使用colorAccent` 的颜色。

• 解释一下 activity_main.xml 布局文件中 Toobar 标签主要属性的作用？

  <FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
  
      // 布局文件中指定一个 xmlns:app 的命名空间是因为：
      // Material Design 是在 Android 5.0 系统中才出现的，很多的 Material 属性在 5.0 之前的系统中并不存在
      // 为了兼容之前的老系统，就不能使用 android:attribute 这样的写法了，而是应该使用 app:attribute
      xmlns:app="http://schemas.android.com/apk/res-auto"
      android:layout_width="match_parent"
      android:layout_height="match_parent" >
  
      <android.support.v7.widget.Toolbar // Toolbar 控件是 appcompat-v7 库提供的
          android:id="@+id/toolbar"
          android:layout_width="match_parent"
          android:layout_height="?attr/actionBarSize" // 高度设置为 actionBar 的高度
          android:background="?arrr/colorPrimary" // 背景色
  
          // 前提是在 style.xml 中将程序的主题指定了淡色主题
          // 所以 Toolbar 上面的各种元素就会自动使用深色系，这是为了和主体颜色区分开
          // 但是这个效果很差，之前使用 ActionBar 时文字都是白色的，现在变成黑色会很难看
          // 为了能让 Toolbar 单独使用深色主题，而不受 styles.xml 中程序主题影响，这里使用 android:theme 属性进行单独制定
          // 但这也单独制定后又有新问题，如果 Toolbar 中有菜单项，那么弹出的菜单项也会变成深色主题，这样就再次变得很难看
          // 所以这里使用了 app:popupTheme 属性，将单独弹出的菜单项指定成了淡色主题
          android:theme="@style/ThemeOverlay.AppCompat.DarkActionBar" // 即，影响标题栏内文字的颜色
          app:popupTheme="@style/ThemeOverlay.AppCompat.Light" /> // 即，影响标题栏内菜单项的颜色
  </FrameLayout>
  
  // 使用 Toolbar
  Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
  setSupportActionBar(toolbar);
  

• 解释一下下面 action 按钮布局文件 toolbar.xml 中 item 标签主要属性的作用？

  <menu xmlns:android="http://schemas.android.com/apk/res/android"
      xmlns:app="http://schemas.android.com/apk/res-auto"> // 使用 app 命名空间兼容低版本系统
      <item // 使用 <item> 标签定义 action 按钮，Toolbar 中的 action 按钮只会显示图标、菜单中的 action 按钮只会显示文字
          android:id="@+id/backup"
          android:icon="@drawable/ic_backup"
          android:title="Backup"
          app:showAsAction="always" /> // always 表示永远显示在 Toolbar 中，如果屏幕空间不够则不显示
  
      <item // 使用 <item> 标签定义 action 按钮，Toolbar 中的 action 按钮只会显示图标、菜单中的 action 按钮只会显示文字
          android:id="@+id/delete"
          android:icon="@drawable/ic_delete"
          android:title="Delete"
          app:showAsAction="ifRoom" /> // ifRoom 表示屏幕空间足够的情况下显示在 Toolbar 中，不够的话就显示在菜单中
  
      <item // 使用 <item> 标签定义 action 按钮，Toolbar 中的 action 按钮只会显示图标、菜单中的 action 按钮只会显示文字
          android:id="@+id/settings"
          android:icon="@drawable/ic_settings"
          android:title="Settings"
          app:showAsAction="never" /> // never 表示不显示在 Toolbar 中，只显示在菜单中
  </menu>
  
  // 使用 toolbar.xml
  public boolean onCreateOptionsMenu(Menu menu) {
      getMenuInflater().inflate(R.menu.toolbar, menu);
      return true;
  }
  

3. 使用 DrawerLayout 和 NavigationView 实现一个滑动菜单 Demo？

答：

• MainActivity：

  public class MainActivity extends AppCompatActivity {
      private Toolbar mToolbar;
      private DrawerLayout mDrawerLayout;
      private NavigationView mNavView; // 使用 NavigationView 需要在 app/build.gradle 文件的 dependencies 闭包中添加依赖
  
      @Override
      protected void onCreate(Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
          setContentView(R.layout.activity_main);
          mToolbar = (Toolbar) findViewById(R.id.toolbar);
          mDrawableLayout = (DrawerLayout) findViewById(R.id.drawer_layout);
          mNavView = (NavigationView) findVieById(R.id.nav_view);
  
          ActionBar actionBar = getSupportActionBar(); // 这里这个 ActionBar 实例的具体实现是由 Toolbar 来完成的
          if(actionBar != null) { // 在 Toolbar 的最左边加上一个导航按钮，实际上这个按钮叫作 HomeAsUp 按钮，默认图标是一个返回的箭头
              actionBar.setDisplayHomeAsUpEnabled(true); // 让导航按钮显示出来
              actionBar.setHomeAsUpIndicator(R.drawable.ic_menu); // 设置导航按钮图标
          }
  
          mNavView.setCheckedItem(R.id.nav_call); // 将 Call 菜单项设置为默认选中
          mNavView.setNavigationItemSelectedListener(new NavigationView.OnNavigationItemSelectedListener() { // 设置菜单项选中的监听器
              @Override
              public boolean onNavigationItemSelected(MenuItem item) {
                  mDrawerLayout.closeDrawers(); // 将滑动菜单关闭
                  return true;
              }
          });
      }
  
      @Override
      public boolean onOptionsItemSelected(MenuItem item) {
          switch (item.getItemId()) {
              case android.R.id.home: // HomeAsUp 按钮的 id 永远都是 android.R.id.home
                  // 将滑动菜单展示出来，方法要求传入一个 Gravity 参数，这里为了保证行为和 XML 中定义的一致，传入 GravityCompat.START
                  mDrawerLayout.openDrawer(GravityCompat.START);
                  break;
              default:
                  break;
          }
          return true;
      }
  }
  

• activity_main.xml：

  <android.support.v4.widget.DrawerLayout
      xmlns:android="http://schemas.android.com/apk/res/android"
      xmlns:app="http://schemas.android.com/apk/res-auto"
      android:id="@+id/drawer_layout"
      android:layout_width="match_parent"
      android:layout_height="match_parent">
  
      <FrameLayout
          android:layout_width="match_parent"
          android:layout_height="match_parent">
  
          <android.support.v7.widget.Toolbar
              android:id="@+id/toolbar"
              android:layout_width="match_parent"
              android:layout_height="?attr/actionBarSize"
              android:background="?attr/colorPrimary"
              android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"
              app:popupTheme="@style/ThemeOverlay.AppCompat.Light" />
  
      </FrameLayout>
  
      <android.support.design.widget.NavigationView
          android:id="@+id/nav_view"
          android:layout_width="match_parent"
          android:layout_height="match_parent"
  
          // 这个属性必须要指定，我们需要告诉 DrawerLayout 滑动菜单是在屏幕的左边还是右边
          // 指定 left 表示滑动菜单在左边，指定 right 表示滑动菜单在右边
          // 指定 start 表示会根据系统语言进行判断，如果系统语言是从左往右的，比如英语、汉语，滑动菜单就在左边；如果系统语言是从右往左的，比如阿拉伯语，滑动菜单就在右边
          android:layout_gravity="start"
  
          // 在 nav_menu.xml 布局文件标签 <menu> 中嵌套了一个 <group> 标签，然后将 group 的 checkableBehavior 属性指定为 single
          // group 表示一个组，checkableBehavior 指定为 single 表示组中所有菜单项只能单选
          app:menu="@menu/nav_menu"
          app:headerLayout="@layout/nav_header" /> // 将 nav_header.xml 文件的高度设为 180dp，这是一个 NavigationView 比较适合的高度
  
  </android.support.v4.widget.DrawerLayout>
  

4. View 的 elevation 属性的作用是？

答：elevation 属性可以给 View 指定一个高度值，高度值越大，投影范围也越大，但是投影效果越淡；高度值越小，投影范围也越小，但投影效果越浓。FloatingActionButton 中有这个属性的默认值，可以看到投影/阴影效果。

5. Snackbar 和 Toast 的区别？

答：Snackbar 不是 Toast 的替代品，它们两者之间有着不同的应用场景。

• Toast：告诉用户现在发生了什么事情，但同时用户只能被动接收这个事情，用户不能做出选择。
• Snackbar：对交互逻辑进行了扩展，不管是出现还是消失都是带有动画效果的，而且允许在提示当中加入一个可交互按钮，当用户点击按钮的时候可以执行一些额外的逻辑操作。

6. 使用 Snackbar 实现一个简单的 Demo？

答：

FloatingActionButton fab = (FloatingActionButton) findViewById(R.id.fab);
fab.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View view) {
        // 第一个参数需要传入一个 View，只要是当前页面布局的任意一个 View 都可以，Snackbar 会使用这个 View 来自动查找最外层的布局，用于展示 Snackbar
        // 第二个参数是 Snackbar 中显示的内容
        // 第三个参数是 Snackbar 的显示时长
        Snackbar.make(view, "Data deleted", Snackbar.LENGTH_SHORT)
                .setAction("Undo", new View.OnClickListener() {
                    @Override
                    public void onClick(View v) {
                        Toast.makeText(MainActivity.this, "Data restored", Toast.LENGTH_SHORT).show();
                    }
                })
                .show();
    }
});

7. 怎样理解 CoordinatorLayout？

答：

• CoordinatorLayout 是一个加强版的 FrameLayout。
• CoordinatorLayout 可以监听其所有子控件的各种事件，然后自动帮我们做出最为合理的响应，比如防止子控件之间的遮挡、子控件之间动画同步等。

8. 怎样理解 CardView？

答：

• CardView 是用于实现卡片式布局效果的重要控件，由 appcompat-v7 提供。
• CardView 也是一个 FrameLayout，只是额外提供了圆角和阴影等效果。

9. 怎样理解 AppBarLayout？

答：

• AppBarLayout 实际上是一个垂直方向的 LinearLayout。
• AppBarLayout 在内部做了很多滚动事件的封装，并应用了一些 Material Design 的设计理念。

10. 使用 CoordinatorLayout 和 AppBarLayout 等实现一个滚动流畅的 Demo？

答：

<android.support.v4.widget.DrawerLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:id="@+id/drawer_layout"
    android:layout_width="match_parent"
    androdi:layout_height="match_parent" >

    <android.support.design.widget.CoordinatorLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent" >

        <android.support.design.widget.AppBarLayout
            android:layout_width="match_parent"
            android:layout_height="wrap_content" >

            <android.support.v7.widget.Toolbar
                android:id="@+id/toolbar"
                android:layout_width="match_parent"
                android:layout_height="?attr/actionBarSize"
                android:background="?attr/colorPrimary"
                android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"
                app:popupTheme="@style/ThemeOverlay.AppCompat.Light"

                // AppBarLayout 接收到滚动事件的时候，内部的子控件可以指定如何去影响这些事件
                // scroll 表示当 RecyclerView 向上滚动的时候，Toolbar 会跟着一起向上滚动并实现隐藏
                // enterAlways 表示当 RecyclerView 向下滚动的时候，Toolbar 会跟着一起向下滚动并重新显示
                // snap 表示当 Toolbar 还没有完全隐藏或显示的时候，会根据当前滚动的距离自动选择是隐藏还是显示
                app:layout_scrollFlags="scroll|enterAlways|snap" />
        </android.support.design.widget.AppBarLayout>

        <android.support.v7.widget.RecyclerView
            android:id="@+id/recycler_view"
            android:layout_width="match_parent"
            android:layout_height="match_parent"

            // RecyclerView 滚动的时候将滚动事件通知给 AppBarLayout
            // 如果 RecyclerView 外面嵌套的有父布局，比如 SwipeRefreshLayout，则 app:layout_behavior 声明的布局行为也要移到父布局中才行
            app:layout_behavior="@string/appbar_scrolling_view_behavior" />

            ...

    </android.support.design.widget.CoordinatorLayout>

    ...

</android.support.v4.widget.DrawerLayout>

11. 怎样理解 SwipeRefreshLayout？

答：

• SwipeRefreshLayout 是用于实现下拉刷新功能的核心类，由 support-v4 提供。
• 在布局文件中，如果在 RecyclerView 的外面嵌套了一层 SwipeRefreshLayout，这样 RecyclerView 就自动拥有下拉刷新功能了。
• 需要注意的是，由于 RecyclerView 现在变成了 SwipeRefreshLayout 的子控件，因此之前使用 app:layout_behavior 声明的布局行为现在也要移到 SwipeRefreshLayout 中才行。

• Demo：

  public class MainActivity extends AppCompatActivity {
      private SwipeRefreshLayout mSwipeRefresh;
  
      @Override
      protected void onCreate(Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
          setContentView(R.layout.activity_main);
          mSwipeRefresh = (SwipeRefreshLayout) findViewById(R.id.swipe_refresh);
          mSwipeRefresh.setColorSchemeResources(R.color.colorPrimary); // 设置下拉刷新进度条颜色
          // 设置下拉刷新监听器
          mSwipeRefresh.setOnRefreshListener(new SwipeRefreshLayout.OnRefreshListener() {
              @Override
              pubic void onRefresh() {
                  refreshFruits();
              }
          });
      }
  
      private void refreshFruits() {
          new Thread(new Runnable() {
              @Override
              public void run() {
                  try {
                      Thread.sleep(2000);
                  } catch(InterruptedException e) {
                      e.printStackTrace();
                  }
  
                  // 将线程切回主线程
                  runOnUiThread(new Runnable() {
                      @Override
                      public void run() {
                          initFruits();
                          adapter.notifyDataSetChanged(); // 通知数据发生了变化
                          swipeRefresh.setRefreshing(false); // 刷新事件结束，并隐藏刷新进度条
                      }
                  });
              }
          }).start();
      }
  }
  

12. 怎样理解 CollapsingToolbarLayout？

答：

• CollapsingToolbarLayout 是一个作用于 Toolbar 基础之上的布局，也是由 Design Support 库提供的，可以实现可折叠式标题栏的效果。
• CollapsingToolbarLayout 是不能独立存在的，它在设计的时候就被限定只能作为 AppBarLayout 的直接子布局来使用，而 AppBarLayout 又必须是 CoordinatorLayout 的子布局。

• Demo：

  <android.support.design.widget.CoordinatorLayout
      xmlns:android="http://schemas.android.com/apk/res/android"
      xmlns:app="http://schemas.android.com/apk/res-auto" // Material Design 开发时会用到 xmlns:app 命名空间
      android:layout_width="match_parent"
      android:layout_height="match_parent" 
      android:fitsSystemWindows="true" >
  
      // 标题栏部分
      <android.support.design.widget.AppBarLayout
          android:id="@+id/appBar"
          android:layout_width="match_parent"
          android:layout_height="250dp" // 高度指定为 250dp，视觉效果较好
          android:fitsSystemWindows="true" >
  
          // 调用 CollapsingToolbarLayout 的 setTitle() 方法设置页面标题
          <android.support.design.widget.CollapsingToolbarLayout
              android:id="@+id/collapsing_toolbar"
              android:layout_width="match_parent"
              android:layout_height="match_parent"
              android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar" // 这里要实现更加高级的 Toolbar 效果，因此需要将这个主题的指定从 Toolbar 提到上一层来
              android:fitsSystemWindows="true"
              app:contentScrim="?attr/colorPrimary" // 指定 CollapsingToolbarLayout 在趋于折叠状态以及折叠之后的背景色
  
              // 同上，也从 Toolbar 中移到上一层
              // scroll 表示 CollapsingToolbarLayout 会随着内容详情的滚动一起滚动
              // exitUntilCollapsed 表示当 CollapsingToolbarLayout 随着滚动完成折叠之后就保留在页面上，不再移除屏幕
              app:layout_scrollFlags="scroll|exitUntilCollapsed" >
  
              <ImageView
                  android:id="@+id/fruit_image_view"
                  android:layout_width="match_parent"
                  android:layout_height="match_parent"
                  android:scaleType="centerCrop"
                  android:fitsSystemWindows="true" // 表示会为系统状态栏留出空间
  
                  // 用于指定当前控件在 CollapsingToolbarLayout 折叠过程中的折叠模式
                  app:layout_collapseMode="parallax" /> // parallax 表示会在折叠的过程中产生一定的错位偏移，这种模式的视觉效果会很好
  
              <android.support.v7.widget.Toolbar
                  android:id="@+id/toolbar"
                  android:layout_width="match_parent"
                  android:layout_height="?attr/actionBarSize"
                  app:layout_collapseMode="pin" /> // pin 表示在折叠过程中位置始终保持不变
          </android.support.design.widget.CollapsingToolbarLayout>
  
      </android.support.design.widget.AppBarLayout>
  
      // 内容详情部分
      // NestedScrollView 在 ScrollView 的基础之上增加了嵌套响应滚动事件的功能
      // 由于 CoordinatorLayout 本身已经可以响应滚动事件了，因此在它的内部就需要使用 NestedScrollView 或 RecyclerView 这样的布局
      // 不管是 ScrollView 还是 NestedScrollView，它们的内部都只允许存在一个直接子布局，否则 AS 会有提示
      <android.support.v4.widget.NestedScrollView 
          android:layout_width="match_parent"
          android:layout_height="match_parent"
          app:layout_behavior="@string/appbar_scrolling_view_behavior" >
  
          <LinearLayout
              android:layout_width="match_parent"
              android:layout_heigh="match_parent"
              android:orientation="vertical" >
  
              <android.support.v7.widget.CardView
                  android:layout_width="match_parent"
                  android:layout_height="wrap_content"
                  android:layout_marginBottom="15dp"
                  android:layout_marginLeft="15dp"
                  android:layout_marginRight="15dp"
                  android:layout_marginTop="35dp"
                  app:cardCornerRadius="4dp" // 圆角
                  app:elevation="5dp" > // 阴影
  
                  <TextView
                      android:id="@+id/fruit_content_text"
                      android:layout_width="wrap_content"
                      android:layout_height="wrap_content"
                      android:layout_margin="10dp" />
              </android.support.v7.widget.CardView>
  
          </LinearLayout>
  
      </android.support.v4.widget.NestedScrollView>
  
      <android.support.design.widget.FloatingActionButton
          android:layout_width="wrap_content"
          android:layout_height="wrap_content"
          android:layout_margin="16dp"
          android:src="@drawable/ic_comment"
          app:layout_anchor="@id/appBar" // 指定将 AppBarLayout 作为一个锚点，这样悬浮按钮就会出现在标题栏的区域内
          app:layout_anchorGravity="bottom|end" /> // 将悬浮按钮定位在标题栏区域的右下角
  
  </android.support.design.widget.CoordinatorLayout>
  

13. 怎样实现沉浸式状态栏？

答：Android 5.0 系统（API 21）之后支持沉浸式系统状态栏，有两种实现方式：

• 方式一（xml 文件实现）：

  • 第一步：必须将 ImageView 布局结构以及所有父布局都设置 fitsSystemWindows 属性为 true。
  • 第二步：必须在应用的主题中将状态栏颜色指定成透明色。可以创建一个 values-21 目录，目录下创建一个 style.xml 文件，对属性 android:statusBarColor 的值指定成 @android:color/transparent 即可。因为 values-21 目录是只有 Android 5.0 即以上的系统才会去读取，所以这么声明式没有问题的。
  • 第三部，因为 Android 5.0 之前的系统无法识别新建的主题，所以对原主题文件进行修改，把 <style> 标签内去掉 android:statusBarColor 属性的指定，然后对 Activity 应用这个主题就可以了。

• 方式二（代码实现）：

  public class WeatherActivity extends AppCompatActivity {
      ...
      @Override
      protected void onCreate(Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
          if(Build.VERSION.SDK_INT >= 21) {
              View decorView = getWindow().getDecorView();
              // 表示活动的布局会显示在状态栏上面
              decorView.setSystemUiVisibility(View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN | View.SYSTEM_UI_FLAG_LAYOUT_STABLE);
              // 设置状态栏为透明色
              getWindow().setStatusBarColor(Color.TRANSPARENT);
          }
          setContentView(R.layout.activity_weather);
          ...
      }
      ...
  }