前言

嗨，大家好，好久不见。这里跟大家侃侃这中间发生了什么。

一个月前呢，想准备面试，就网上随便找找面试题什么的，发现要么就是卖课的，要么就是不给详细回答的或者回答不够深的（也许是我没找到??）。反正稍微有点苦恼，因为我毕竟是个懒人，就想看看面试题，然后自己思考下，顺便看看一些参考回答，看看自己回答的全不全面等等。

于是，我就想干脆我自己做这个事吧，就算没人看，也当我自己每天复习下了。于是，我就建了一个小小公众号（小到确实没人看，哈哈哈），每天去找一些大厂的面试真题，然后解答下，然后自己确实也在这个过程中能复习到不少以前没有重视的问题，今天就总结下之前一个多月总结的面试题，难度不大，大佬可以直接路过，当然发发善心点个赞也是可以的??。

进入正题，下面为10月刊内容，每三个问题为一个小节，也就是一个专题文章，我就不具体区分了，由于字数问题，也只节选了一些问题，大家见谅。另外答的不好的地方大家也可以留言敲敲我，感谢。

10月刊内容

网页中输入url，到渲染整个界面的整个过程，以及中间用了什么协议？

1）过程分析：主要分为三步

• DNS解析。用户输入url后，需要通过DNS解析找到域名对应的ip地址，有了ip地址才能找到服务器端。首先会查找浏览器缓存，是否有对应的dns记录。再继续按照操作系统缓存—路由缓存—isp的dns服务器—根服务器的顺序进行DNS解析，直到找到对应的ip地址。
• 客户端（浏览器）和服务器交互。浏览器根据解析到的ip地址和端口号发起HTTP请求，请求到达传输层，这里也就是TCP层，开始三次握手建立连接。服务器收到请求后，发送相应报文给客户端（浏览器），客户端收到相应报文并进行解析，得到html页面数据，包括html，js，css等。
• 客户端（浏览器）解析html数据，构建DOM树，再构造呈现树（render树），最终绘制到浏览器页面上。

2）其中涉及到TCP/IP协议簇，包括DNS，TCP，IP，HTTP协议等等。

具体介绍下TCP/IP

TCP/IP一般指的是TCP/IP协议簇，主要包括了多个不同网络间实现信息传输涉及到的各种协议
主要包括以下几层：

• 应用层：主要提供数据和服务。比如HTTP，FTP，DNS等
• 传输层：负责数据的组装，分块。比如TCP，UDP等
• 网络层：负责告诉通信的目的地，比如IP等
• 数据链路层：负责连接网络的硬件部分，比如以太网，WIFI等

TCP的三次握手和四次挥手，为什么不是两次握手？为什么挥手多一次呢？

客户端简称A，服务器端简称B
1）TCP建立连接需要三次握手

• A向B表示想跟B进行连接（A发送syn包，A进入SYN_SENT状态）
• B收到消息，表示我也准备好和你连接了（B收到syn包，需要确认syn包，并且自己也发送一个syn包，即发送了syn+ack包，B进入SYN_RECV状态）
• A收到消息，并告诉B表示我收到你也准备连接的信号了（A收到syn+ack包，向服务器发送确认包ack，AB进入established状态）开始连接。

2）TCP断开连接需要四次挥手

• A向B表示想跟B断开连接（A发送fin，进入FIN_WAIT_1状态）
• B收到消息，但是B消息没发送完，只能告诉A我收到你的断开连接消息（B收到fin，发送ack，进入CLOSE_WAIT状态）
• 过一会，B数据发送完毕，告诉A，我可以跟你断开了（B发送fin，进入LAST_ACK状态）
• A收到消息，告诉B，可以他断开（A收到fin，发送ack，B进入closed状态）

3）为什么挥手多一次
其实正常的断开和连接都是需要四次：

• A发消息给B
• B反馈给A表示正确收到消息
• B发送消息给A
• A反馈给B表示正确收到消息。

但是连接中，第二步和第三步是可以合并的，因为连接之前A和B是无联系的，所以没有其他情况需要处理。而断开的话，因为之前两端是正常连接状态，所以第二步的时候不能保证B之前的消息已经发送完毕，所以不能马上告诉A要断开的消息。这就是连接为什么可以少一步的原因。

4）为什么连接需要三次，而不是两次。
正常来说，我给你发消息，你告诉我能收到，不就代表我们之前通信是正常的吗？

• 简单回答就是，TCP是双向通信协议，如果两次握手，不能保证B发给A的消息正确到达。

TCP 协议为了实现可靠传输， 通信双方需要判断自己已经发送的数据包是否都被接收方收到， 如果没收到， 就需要重发。

TCP是怎么保证可靠传输的？

• 序列号和确认号。比如连接的一方发送一段80byte数据，会带上一个序列号，比如101。接收方收到数据，回复确认号181（180+1），这样下一次发送消息就会从181开始发送了。

所以握手过程中，比如A发送syn信号给B，初始序列号为120，那么B收到消息，回复ack消息，序列号为120+1。同时B发送syn信号给A，初始序列号为256，如果收不到A的回复消息，就会重发，否则丢失这个序列号，就无法正常完成后面的通信了。

这就是三次握手的原因。

TCP和UDP的区别？

TCP提供的是面向连接，可靠的字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接（三次握手），之后才能传输数据。并且提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。

UDP 是一个简单的面向数据报的运输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于UDP在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。

所以总结下来就是：

• TCP 是面向连接的，UDP 是面向无连接的
• TCP数据报头包括序列号，确认号，等等。相比之下UDP程序结构较简单。
• TCP 是面向字节流的，UDP 是基于数据报的
• TCP 保证数据正确性，UDP 可能丢包
• TCP 保证数据顺序，UDP 不保证

可以看到TCP适用于稳定的应用场景，他会保证数据的正确性和顺序，所以一般的浏览网页，接口访问都使用的是TCP传输，所以才会有三次握手保证连接的稳定性。
而UDP是一种结构简单的协议，不会考虑丢包啊，建立连接等。优点在于数据传输很快，所以适用于直播，游戏等场景。

HTTP的几种请求方法具体介绍

常见的有四种：

• GET 获取资源，没有body，幂等性
• POST 增加或者修改资源，有body
• PUT 修改资源，有body，幂等性
• DELETE 删除资源，幂等性

HTTP请求和响应报文的格式，以及常用状态码

1）请求报文：

   //请求行（包括method、path、HTTP版本）
   GET /s HTTP/1.1
   //Headers
   Host: www.baidu.com
   Content-Type: text/plain
   //Body
   搜索****

2）响应报文

   //状态行 （包括HTTP版本、状态码，状态信息）
   HTTP/1.1 200 OK
   //Headers
   Content-Type: application/json; charset=utf-8
   //Body
   [{"info":"xixi"}]

3）常用状态码

主要分为五种类型：

• 1开头， 代表临时性消息，比如100（继续发送）
• 2开头， 代表请求成功，比如200（OK）
• 3开头， 代表重定向，比如304（内容无改变）
• 4开头， 代表客户端的一些错误，比如403（禁止访问）
• 5开头， 代表服务器的一些错误，比如500

介绍对称加密和非对称加密

1）对称加密，即加密和解密算法不同，但是密钥相同。比如DES，AES算法。

数据A --> 算法D（密钥S）--> 加密数据B
加密数据B --> 算法E（密钥S）--> 数据A

优点：
缺点：密钥有可能被破解，容易被伪造。传输过程中一旦密钥被其他人获知则可以进行数据解密。

2）非对称加密，即加密和解密算法相同，但是密钥不同。私钥自己保存，公钥提供给对方。比如RSA，DSA算法。

数据A --> 算法D（公钥）--> 加密数据B
加密数据B --> 算法D（私钥）--> 数据A

优点：安全，公钥即使被其他人获知，也无法解密数据。
缺点：需要通信双方都有一套公钥和私钥

数字签名的原理

1）首先，为什么需要数字签名？
防止被攻击，被伪造。由于公钥是公开的，别人截获到公钥就能伪造数据进行传输，所以我们需要验证数据的来源。

2）怎么签名？
由于公钥能解密 私钥加密的数据，所以私钥也能解密 公钥加密的数据。（上图非对称加密A和B代号互换即可）
所以我们用公钥进行加密后，再用私钥进行一次加密，那么私钥的这次加密就叫签名，也就是只有我自己可以进行加密的操作。所以传输数据流程就变成了加密数据和签名数据，如果解出来都是同样的数据，那么则数据安全可靠。

数据A --> 算法D（公钥）--> 加密数据B
数据A --> 算法D（私钥）--> 签名数据C

加密数据B --> 算法D（私钥）--> 数据A
签名数据C --> 算法D（公钥）--> 数据A

Base64算法是什么，是加密算法吗？

• Base64是一种将二进制数据转换成64种字符组成的字符串的编码算法，主要用于非文本数据的传输，比如图片。可以将图片这种二进制数据转换成具体的字符串，进行保存和传输。

• 严格来说，不算。虽然它确实把一段二进制数据转换成另外一段数据，但是他的加密和解密是公开的，也就无秘密可言了。所以我更倾向于认为它是一种编码，每个人都可以用base64对二进制数据进行编码和解码。

• 面试加分项：为了减少混淆，方便复制，减少数据长度，就衍生出一种base58编码。去掉了base64中一些容易混淆的数字和字母（数字0，字母O，字母I，数字1，符号+，符号/）
  大名鼎鼎的比特币就是用的改进后的base58编码，即Base58Check编码方式，有了校验机制，加入了hash值。

为什么多线程同时访问（读写）同个变量，会有并发问题？

• Java 内存模型规定了所有的变量都存储在主内存中，每条线程有自己的工作内存。
• 线程的工作内存中保存了该线程中用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。
• 线程访问一个变量，首先将变量从主内存拷贝到工作内存，对变量的写操作，不会马上同步到主内存。
• 不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量的传递均需要自己的工作内存和主存之间进行数据同步。

说说原子性，可见性，有序性分别是什么意思？

• 原子性：在一个操作中，CPU 不可以在中途暂停然后再调度，即不被中断操作，要么执行完成，要么就不执行。

• 可见性：多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

• 有序性：程序执行的顺序按照代码的先后顺序执行。

实际项目过程中，有用到多线程并发问题的例子吗？

有，比如单例模式。
由于单例模式的特殊性，可能被程序中不同地方多个线程同时调用，所以为了避免多线程并发问题，一般要采用volatile+Synchronized的方式进行变量，方法保护。

    private volatile static Singleton singleton;

    public static Singleton getSingleton4() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }

        }
        return singleton;
    }

介绍几种启动模式。

• standard,默认模式，每次启动都会新建一个Activity实例，并进入当前任务栈
• singleTop，如果要启动的Activity在栈顶存在实例，则不会重新创建Activity，而是直接使用栈顶的Activity实例，并回调onNewIntent方法。
• singleTask，如果要启动的Activity在栈中存在实例，则不会重新创建Activity，而是直接使用栈里的Activity实例，并回调onNewIntent方法。并且会把这个实例放到栈顶，之前在这个Activity之上的都会被出栈销毁。
• singleInstance，有点单例的感觉，就是所启动的Activity会单独放在一个任务栈里，并且后续所有启动该Activity都会直接用这个实例，同样被重复调用的时候会调用并回调onNewIntent方法。

Activity依次A→B→C→B，其中B启动模式为singleTask，AC都为standard，生命周期分别怎么调用？如果B启动模式为singleInstance又会怎么调用？B启动模式为singleInstance不变，A→B→C的时候点击两次返回，生命周期如何调用。

1)A→B→C→B,B启动模式为singleTask

• 启动A的过程，生命周期调用是 (A)onCreate→(A)onStart→(A)onResume
• 再启动B的过程，生命周期调用是 (A)onPause→(B)onCreate→(B)onStart→(B)onResume→(A)onStop
• B→C的过程同上
• C→B的过程，由于B启动模式为singleTask，所以B会调用onNewIntent，并且将B之上的实例移除，也就是C会被移出栈。所以生命周期调用是 (C)onPause→(B)onNewIntent→(B)onRestart→(B)onStart→(B)onResume→(C)onStop→(C)onDestory

2)A→B→C→B,B启动模式为singleInstance

• 如果B为singleInstance，那么C→B的过程，C就不会被移除，因为B和C不在一个任务栈里面。所以生命周期调用是 (C)onPause→(B)onNewIntent→(B)onRestart→(B)onStart→(B)onResume→(C)onStop

3)A→B→C,B启动模式为singleInstance,点击两次返回键

• 如果B为singleInstance，A→B→C的过程，生命周期还是同前面一样正常调用。但是点击返回的时候，由于AC同任务栈，所以C点击返回，会回到A，再点击返回才回到B。所以生命周期是：(C)onPause→(A)onRestart→(A)onStart→(A)onResume→(C)onStop→(C)onDestory。

• 再次点击返回，就会回到B，所以生命周期是：(A)onPause→(B)onRestart→(B)onStart→(B)onResume→(A)onStop→(A)onDestory。

屏幕旋转时Activity的生命周期，如何防止Activity重建。

• 切换屏幕的生命周期是：onConfigurationChanged->onPause->onSaveInstanceState->onStop->onDestroy->onCreate->onStart->onRestoreInstanceState->onResume

• 如果需要防止旋转时候，Activity重新创建的话需要做如下配置：
  在targetSdkVersion的值小于或等于12时，配置 android:configChanges="orientation"，
  在targetSdkVersion的值大于12时，配置 android:configChanges="orientation|screenSize"。

线程的三种启动方式

1）继承thread类

    class MyThread :Thread(){
        override fun run() {
            super.run()
        }
    }

    fun test(){
        var t1=MyThread()
        t1.start()
    }

2)实现runnable接口

    class MyRunnable : Runnable {
        override fun run() {

        }
    }

    fun test() {
        var t1 = Thread(MyRunnable(),"test")
        t1.start()
    }

3)实现 Callable 接口

    class MyCallThread : Callable<String> {
        override fun call(): String {
            return "i got it"
        }

    }

    fun test() {
        var task = FutureTask(MyCallThread())
        var t1 = Thread(task, "test")
        t1.start()
        try {
            //获取结果
            var result = task.get()
        } catch (e: Exception) {
        }
    }

也有人表示其实是两个方法，因为第三个方法FutureTask也是实现了Runnable的方法，只不过表现方法不一样，然后带返回值。这个大家面试的时候可以都说上，然后说说自己的见解，毕竟要让面试官多多看到你的知识面。

线程run和start的区别

• start方法,用start方法来启动线程，真正实现了多线程运行，这时无需等待run方法体中的代码执行完毕而直接继续执行后续的代码。通过调用Thread类的 start()方法来启动一个线程，这时此线程处于就绪（可运行）状态，并没有运行，一旦得到cpu时间片，就开始执行run()方法，这里的run()方法 称为线程体，它包含了要执行的这个线程的内容，Run方法运行结束，此线程随即终止。

• run方法，run方法只是类的一个普通方法而已，如果直接调用Run方法，程序中依然只有主线程这一个线程，其程序执行路径还是只有一条，还是要顺序执行，还是要等待run方法体执行完毕后才可继续执行下面的代码，这样就没有达到写线程的目的。

简单的说就是：
调用start方法方可启动线程，而run方法只是thread类中的一个普通方法调用，不用启动新线程，还是在主线程里执行。

线程的几种状态，相互之间是如何转化的

1） 初始状态（New）。新创建了一个线程对象就进入了初始状态，也就是通过上述新建线程的几个方法就能进入该状态。

2） 可运行状态，就绪状态(RUNNABLE)。线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取cpu 的使用权。以下几种方式会进入可运行状态：

• 调用start方法。
• 拿到对象锁
• 调用yield方法

3）运行状态(RUNNING)。可运行状态(runnable)的线程获得了cpu 时间片 ，执行程序代码。线程调度程序从可运行池中选择一个线程作为当前线程，就会进入运行状态。

4）阻塞状态(BLOCKED)。线程正在运行的时候，被暂停，通常是为了等待某个时间的发生（比如说某项资源就绪）之后再继续运行。wait，sleep,suspend等方法都可以导致线程阻塞。

5）死亡状态(DEAD)。线程run()、main() 方法执行结束，或者因异常退出了run()方法，则该线程结束生命周期。死亡的线程不可再次复生。

String是java中的基本数据类型吗？是可变的吗？是线程安全的吗？

• String不是基本数据类型，java中把大数据类型是：byte, short, int, long, char, float, double, boolean
• String是不可变的
• String是不可变类，一旦创建了String对象，我们就无法改变它的值。因此，它是线程安全的，可以安全地用于多线程环境中

为什么要设计成不可变的呢？如果String是不可变的，那我们平时赋值是改的什么呢？

1）为什么设计不可变

• 安全。由于String广泛用于java类中的参数，所以安全是非常重要的考虑点。包括线程安全，打开文件，存储数据密码等等。
• String的不变性保证哈希码始终一，所以在用于HashMap等类的时候就不需要重新计算哈希码，提高效率。
• 因为java字符串是不可变的，可以在java运行时节省大量java堆空间。因为不同的字符串变量可以引用池中的相同的字符串。如果字符串是可变得话，任何一个变量的值改变，就会反射到其他变量，那字符串池也就没有任何意义了。

2）平时使用双引号方式赋值的时候其实是返回的字符串引用,并不是改变了这个字符串对象

浅谈一下String, StringBuffer，StringBuilder的区别？String的两种创建方式，在JVM的存储方式相同吗？

String是不可变类，每当我们对String进行操作的时候，总是会创建新的字符串。操作String很耗资源,所以Java提供了两个工具类来操作String - StringBuffer和StringBuilder。

StringBuffer和StringBuilder是可变类，StringBuffer是线程安全的，StringBuilder则不是线程安全的。所以在多线程对同一个字符串操作的时候，我们应该选择用StringBuffer。由于不需要处理多线程的情况，StringBuilder的效率比StringBuffer高。

1） String常见的创建方式有两种

• String s1 = “Java”
• String s2 = new String("Java")

2）存储方式不同

• 第一种，s1会先去字符串常量池中找字符串"Java”，如果有相同的字符则直接返回常量句柄，如果没有此字符串则会先在常量池中创建此字符串，然后再返回常量句柄，或者说字符串引用。

• 第二种，s2是直接在堆上创建一个变量对象，但不存储到字符串池 ，调用intern方法才会把此字符串保存到常量池中

线程池是干嘛的，优点有哪些？

线程池主要用作管理子线程，优点有：

• 重用线程池中的线程，避免频繁创建和销毁线程所带来的内存开销。
• 有效控制线程的最大并发数，避免因线程之间抢占资源而导致的阻塞现象。
• 能够对线程进行简单的管理，提供定时执行以及指定时间间隔循环执行等功能。

线程池的构造方法每个参数是什么意思，执行任务的流程

    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {}

• corePoolSize：核心线程数。默认情况下线程池是空的，只是任务提交时才会创建线程。如果当前运行的线程数少于corePoolSize，则会创建新线程来处理任务；如果等于或者等于corePoolSize,则不再创建。如果调用线程池的prestartAllcoreThread方法，线程池会提前创建并启动所有的核心线程来等待任务。
• maximumPoolSize：线程池允许创建的最大线程数。如果任务队列满了并且线程数小于maximumPoolSize时，则线程池仍然会创建新的线程来处理任务。
• keepAliveTime：非核心线程闲置的超时事件。超过这个事件则回收。如果任务很多，并且每个任务的执行时间很短，则可以调大keepAliveTime来提高线程的利用率。另外，如果设置allowCoreThreadTimeOut属性来true时，keepAliveTime也会应用到核心线程上。
• TimeUnit：keepAliveTime参数的时间单位。可选的单位有天Days、小时HOURS、分钟MINUTES、秒SECONDS、毫秒MILLISECONDS等。
• workQueue：任务队列。如果当前线程数大于corePoolSzie，则将任务添加到此任务队列中。该任务队列是BlockingQueue类型的，即阻塞队列。
• ThreadFactory：线程工厂。可以使用线程工厂给每个创建出来的线程设置名字。一般情况下无须设置该参数。
• RejectedExecutionHandler：拒绝策略。这是当前任务队列和线程池都满了时所采取的应对策略，默认是AbordPolicy，表示无法处理新任务，并抛出RejectedExecutionException异常。

其中，拒绝策略有四种：

• AbordPolicy:无法处理新任务，并抛出RejectedExecutionException异常。
• CallerRunsPolicy:用调用者所在的线程来处理任务。此策略提供简单的反馈控制机制，能够减缓新任务的提交速度。
• DiscardPolicy：不能执行的任务，并将该任务删除。
• DiscardOldestPolicy:丢弃队列最近的任务，并执行当前的任务。

执行任务流程：

• 如果线程池中的线程数量未达到核心线程的数量，会直接启动一个核心线程来执行任务。
• 如果线程池中的线程数量已经达到或者超过核心线程的数量，那么任务会被插入到任务队列中排队等待执行。
• 如果任务队列无法插入新任务，说明任务队列已满，如果未达到规定的最大线程数量，则启动一个非核心线程来执行任务。
• 如果线程数量超过规定的最大值，则执行拒绝策略-RejectedExecutionHandler。

Android线程池主要分为哪几类，分别代表了什么？

主要有四类：FixedThreadPool、CachedThreadPool、SingleThreadExecutor、ScheduledTheadPool

1） FixedThreadPool——可重用固定线程数的线程池

    public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, nThreads,
                                      0L, TimeUnit.MILLISECONDS,
                                      new LinkedBlockingQueue<Runnable>());
    }

• 线程数量固定且都是核心线程：核心线程数量和最大线程数量都是nThreads；
• 都是核心线程且不会被回收，快速相应外界请求；
• 没有超时机制，任务队列也没有大小限制；
• 新任务使用核心线程处理，如果没有空闲的核心线程，则排队等待执行。

2. CachedThreadPool——按需创建的线程池

    public static ExecutorService newCachedThreadPool() {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                      60L, TimeUnit.SECONDS,
                                      new SynchronousQueue<Runnable>());
    }

• 线程数量不定，只有非核心线程，最大线程数任意大：传入核心线程数量的参数为0，最大线程数为Integer.MAX_VALUE；
• 有新任务时使用空闲线程执行，没有空闲线程则创建新的线程来处理。
• 该线程池的每个空闲线程都有超时机制，时常为60s（参数：60L, TimeUnit.SECONDS），空闲超过60s则回收空闲线程。
• 适合执行大量的耗时较少的任务，当所有线程闲置超过60s都会被停止，所以这时几乎不占用系统资源。

3. SingleThreadExecutor——单线程的线程池

    public static ExecutorService newSingleThreadExecutor() {
        return new FinalizableDelegatedExecutorService
            (new ThreadPoolExecutor(1, 1,
                                    0L, TimeUnit.MILLISECONDS,
                                    new LinkedBlockingQueue<Runnable>()));
    }

• 只有一个核心线程，所有任务在同一个线程按顺序执行。
• 所有的外界任务统一到一个线程中，所以不需要处理线程同步的问题。

4. ScheduledThreadPool——定时和周期性的线程池

    private static final long DEFAULT_KEEPALIVE_MILLIS = 10L;

    public ScheduledThreadPoolExecutor(int corePoolSize) {
        super(corePoolSize, Integer.MAX_VALUE,
              DEFAULT_KEEPALIVE_MILLIS, MILLISECONDS,
              new DelayedWorkQueue());
    }

• 核心线程数量固定，非核心线程数量无限制；
• 非核心线程闲置超过10s会被回收；
• 主要用于执行定时任务和具有固定周期的重复任务；

索引是什么，优缺点

数据库索引,是数据库管理系统中一个排序的数据结构,以协助快速查询,更新数据库中表的数据.索引的实现通常使用B树和变种的B+树(mysql常用的索引就是B+树)

优点

• 通过创建索引,可以在查询的过程中,提高系统的性能
• 通过创建唯一性索引,可以保证数据库表中每一行数据的唯一性
• 在使用分组和排序子句进行数据检索时,可以减少查询中分组和排序的时间

缺点

• 创建索引和维护索引要耗费时间,而且时间随着数据量的增加而增大
• 索引需要占用物理空间,如果要建立聚簇索引,所需要的空间会更大
• 在对表中的数据进行增加删除和修改时需要耗费较多的时间,因为索引也要动态地维护

事务四大特性

数据库事务必须具备ACID特性，ACID是Atomic（原子性）、Consistency（一致性）、Isolation（隔离性）和Durability（持久性）的英文缩写。

• 原子性

一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样。

• 一致性

事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。

• 隔离性

指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。

• 持久性

指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

讲讲几个范式

范式的英文名称是Normal Form，它是英国人E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的。范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。

• 第一范式就是属性不可分割，每个字段都应该是不可再拆分的。比如一个字段是姓名（NAME），在国内的话通常理解都是姓名是一个不可再拆分的单位，这时候就符合第一范式；但是在国外的话还要分为FIRST NAME和LAST NAME，这时候姓名这个字段就是还可以拆分为更小的单位的字段，就不符合第一范式了。

• 第二范式就是要求表中要有主键，表中其他其他字段都依赖于主键，因此第二范式只要记住主键约束就好了。比如说有一个表是学生表，学生表中有一个值唯一的字段学号，那么学生表中的其他所有字段都可以根据这个学号字段去获取，依赖主键的意思也就是相关的意思，因为学号的值是唯一的，因此就不会造成存储的信息对不上的问题，即学生001的姓名不会存到学生002那里去。

• 第三范式就是要求表中不能有其他表中存在的、存储相同信息的字段，通常实现是在通过外键去建立关联，因此第三范式只要记住外键约束就好了。比如说有一个表是学生表，学生表中有学号，姓名等字段，那如果要把他的系编号，系主任，系主任也存到这个学生表中，那就会造成数据大量的冗余，一是这些信息在系信息表中已存在，二是系中有1000个学生的话这些信息就要存1000遍。因此第三范式的做法是在学生表中增加一个系编号的字段（外键），与系信息表做关联。

Recycleview和listview区别

• Recycleview布局效果更多，增加了纵向，表格，瀑布流等效果
• Recycleview去掉了一些api，比如setEmptyview，onItemClickListener等等，给到用户更多的自定义可能
• Recycleview去掉了设置头部底部item的功能，专向通过viewholder的不同type实现
• Recycleview实现了一些局部刷新，比如notifyitemchanged
• Recycleview自带了一些布局变化的动画效果，也可以通过自定义ItemAnimator类实现自定义动画效果
• Recycleview缓存机制更全面，增加两级缓存，还支持自定义缓存逻辑

Recycleview有几级缓存，缓存过程？

Recycleview有四级缓存，分别是mAttachedScrap(屏幕内)，mCacheViews(屏幕外)，mViewCacheExtension(自定义缓存)，mRecyclerPool(缓存池)

• mAttachedScrap(屏幕内)，用于屏幕内itemview快速重用，不需要重新createView和bindView
• mCacheViews(屏幕外)，保存最近移出屏幕的ViewHolder，包含数据和position信息，复用时必须是相同位置的ViewHolder才能复用，应用场景在那些需要来回滑动的列表中，当往回滑动时，能直接复用ViewHolder数据，不需要重新bindView。
• mViewCacheExtension(自定义缓存)，不直接使用，需要用户自定义实现，默认不实现。
• mRecyclerPool(缓存池)，当cacheView满了后或者adapter被更换，将cacheView中移出的ViewHolder放到Pool中，放之前会把ViewHolder数据清除掉，所以复用时需要重新bindView。

四级缓存按照顺序需要依次读取。所以完整缓存流程是：

1. 保存缓存流程：

• 插入或是删除itemView时，先把屏幕内的ViewHolder保存至AttachedScrap中
• 滑动屏幕的时候，先消失的itemview会保存到CacheView，CacheView大小默认是2，超过数量的话按照先入先出原则，移出头部的itemview保存到RecyclerPool缓存池（如果有自定义缓存就会保存到自定义缓存里），RecyclerPool缓存池会按照itemview的itemtype进行保存，每个itemTyep缓存个数为5个，超过就会被回收。

2. 获取缓存流程：

• AttachedScrap中获取，通过pos匹配holder——>获取失败，从CacheView中获取，也是通过pos获取holder缓存
  ——>获取失败，从自定义缓存中获取缓存——>获取失败，从mRecyclerPool中获取
  ——>获取失败，重新创建viewholder——createViewHolder并bindview。

需要注意的是，如果从缓存池找到缓存，还需要重新bindview。

说说RecyclerView性能优化。

• bindViewHolder方法是在UI线程进行的，此方法不能耗时操作，不然将会影响滑动流畅性。比如进行日期的格式化。
• 对于新增或删除的时候，可以使用diffutil进行局部刷新，少用全局刷新
• 对于itemVIew进行布局优化，比如少嵌套等。
• 25.1.0 (>=21)及以上使用 Prefetch 功能，也就是预取功能，嵌套时且使用的是LinearLayoutManager，子RecyclerView可通过setInitialPrefatchItemCount设置预取个数
• 加大RecyclerView缓存，比如cacheview大小默认为2，可以设置大点，用空间来换取时间，提高流畅度
• 如果高度固定，可以设置setHasFixedSize(true)来避免requestLayout浪费资源，否则每次更新数据都会重新测量高度。

void onItemsInsertedOrRemoved() {
   if (hasFixedSize) layoutChildren();
   else requestLayout();
}

• 如果多个 RecycledView 的 Adapter 是一样的，比如嵌套的 RecyclerView 中存在一样的 Adapter，可以通过设置 RecyclerView.setRecycledViewPool(pool); 来共用一个 RecycledViewPool。这样就减少了创建VIewholder的开销。
• 在RecyclerView的元素比较高，一屏只能显示一个元素的时候，第一次滑动到第二个元素会卡顿。这种情况就可以通过设置额外的缓存空间，重写getExtraLayoutSpace方法即可。

new LinearLayoutManager(this) {
    @Override
    protected int getExtraLayoutSpace(RecyclerView.State state) {
        return size;
    }
};

• 设置RecyclerView.addOnScrollListener();来在滑动过程中停止加载的操作。
• 减少对象的创建，比如设置监听事件，可以全局创建一个，所有view公用一个listener，并且放到CreateView里面去创建监听，因为CreateView调用要少于bindview。这样就减少了对象创建所造成的消耗
• 用notifyDataSetChange时，适配器不知道整个数据集中的那些内容以及存在，再重新匹配ViewHolder时会花生闪烁。设置adapter.setHasStableIds(true)，并重写getItemId()来给每个Item一个唯一的ID，也就是唯一标识，就使itemview的焦点固定，解决了闪烁问题。

说说双重校验锁，以及volatile的作用

先回顾下双重校验锁的原型，也就是单例模式的实现：

public class Singleton {
    private volatile static Singleton mSingleton;

    private Singleton() {
    }

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

有几个疑问需要解决：

• 为什么要加锁？
• 为什么不直接给getInstance方法加锁？
• 为什么需要双重判断是否为空？
• 为什么还要加volatile修饰变量？

接下来一一解答：

• 如果不加锁的话，是线程不安全的，也就是有可能多个线程同时访问getInstance方法会得到两个实例化的对象。
• 如果给getInstance方法加锁，就每次访问mSingleton都需要加锁，增加了性能开销
• 第一次判空是为了判断是否已经实例化，如果已经实例化就直接返回变量，不需要加锁了。第二次判空是因为走到加锁这一步，如果线程A已经实例化，等B获得锁，进入的时候其实对象已经实例化完成了，如果不二次判空就会再次实例化。
• 加volatile是为了禁止指令重排。指令重排指的是在程序运行过程中，并不是完全按照代码顺序执行的，会考虑到性能等原因，将不影响结果的指令顺序有可能进行调换。所以初始化的顺序本来是这三步：
  1）分配内存空间
  2）初始化对象
  3）将对象指向分配的空间

如果进行了指令重排，由于不影响结果，所以2和3有可能被调换。所以就变成了：

1）分配内存空间
2）将对象指向分配的空间
3）初始化对象

就有可能会导致，假如线程A中已经进行到第二步，线程B进入第二次判空的时候，判断mSingleton不为空，就直接返回了，但是实际此时mSingleton还没有初始化。

synchronized和volatile的区别

• volatile本质是在告诉jvm当前变量在寄存器中的值是不确定的,需要从主存中读取,synchronized则是锁定当前变量,只有当前线程可以访问该变量,其他线程被阻塞住.
• volatile仅能使用在变量级别,synchronized则可以使用在变量,方法.
• volatile仅能实现变量的修改可见性,而synchronized则可以保证变量的修改可见性和原子性.
• volatile不会造成线程的阻塞,而synchronized可能会造成线程的阻塞.
• 当一个域的值依赖于它之前的值时，volatile就无法工作了，如n=n+1,n++等，也就是不保证原子性。
• 使用volatile而不是synchronized的唯一安全的情况是类中只有一个可变的域。

synchronized修饰static方法和修饰普通方法有什么区别

• Synchronized修饰非静态方法，实际上是对调用该方法的对象加锁，俗称“对象锁”。也就是锁住的是这个对象，即this。如果同一个对象在两个线程分别访问对象的两个同步方法，就会产生互斥，这就是对象锁，一个对象一次只能进入一个操作。

• Synchronized修饰静态方法，实际上是对该类对象加锁，俗称“类锁”。也就是锁住的是这个类，即xx.class。如果一个对象在两个线程中分别调用一个静态同步方法和一个非静态同步方法，由于静态方法会收到类锁限制，但是非静态方法会收到对象限制，所以两个方法并不是同一个对象锁，因此不会排斥。

内存泄漏是什么，为什么会发生？

内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。
简单点说，手机给我们的应用提供了一定大小的堆内存，在不断创建对象的过程中，也在不断的GC(java的垃圾回收机制)，所以内存正常情况下会保持一个平稳的值。
但是出现内存泄漏就会导致某个实例，比如Activity的实例，应用被某个地方引用到了，不能正常释放，从而导致内存占用越来越大，这就是内存泄漏。

内存泄漏发生的情况有哪些？

主要有四类情况：

• 集合类泄漏
• 单例/静态变量造成的内存泄漏
• 匿名内部类/非静态内部类
• 资源未关闭造成的内存泄漏

1）集合类泄漏

集合类添加元素后，仍引用着集合元素对象，导致该集合中的元素对象无法被回收，从而导致内存泄露。

static List<Object> mList = new ArrayList<>();
   for (int i = 0; i < 100; i++) {
       Object obj = new Object();
      mList.add(obj);
       obj = null;
    }

解决办法就是把集合也释放掉。

  mList.clear();
  mList = null;

2）单例/静态变量造成的内存泄漏

单例模式具有其静态特性，它的生命周期等于应用程序的生命周期，正是因为这一点，往往很容易造成内存泄漏。

public class SingleInstance {

    private static SingleInstance mInstance;
    private Context mContext;

    private SingleInstance(Context context){
        this.mContext = context;
    }

    public static SingleInstance newInstance(Context context){
        if(mInstance == null){
            mInstance = new SingleInstance(context);
        }
        return sInstance;
    }
}

比如这个单例模式，如果我们调用newInstance方法时候把Activity的context传进去，那么就是生命周期长的持有了生命周期短的引用，造成了内存泄漏。要修改的话把context改成context.getApplicationContext()即可。

3）匿名内部类/非静态内部类

非静态内部类他会持有他外部类的强引用，所以就有可能导致非静态内部类的生命周期可能比外部类更长，容易造成内存泄漏，最常见的就是Handler。

public class TestActivity extends Activity {
private TextView mText;
    private Handler mHandler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);


        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(100000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();

    
        mHandler. sendEmptyMessageDelayed(0, 100000);
    }

怎么修改呢？改成静态内部类，然后弱引用方式修饰外部类

public class TestActivity extends Activity {
    private TextView mText;
    private MyHandler myHandler = new MyHandler(TestActivity.this);
    private MyThread myThread = new MyThread();

    private static class MyHandler extends Handler {

        WeakReference<TestActivity> weakReference;

        MyHandler(TestActivity testActivity) {
            this.weakReference = new WeakReference<TestActivity>(testActivity);

        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            weakReference.get().mText.setText("do someThing");
        }
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        myHandler.removeCallbacksAndMessages(null);
    }

4）资源未关闭造成的内存泄漏

比如：

• 网络、文件等流忘记关闭
• 手动注册广播时，退出时忘记unregisterReceiver()
• Service 执行完后忘记 stopSelf()
• EventBus 等观察者模式的框架忘记手动解除注册

该怎么发现和解决内存泄漏？

1、使用工具，比如Memory Profiler，可以查看app的内存实时情况，捕获堆转储，就生成了一个内存快照，hprof文件。通过查看文件，可以看到哪些类发生了内存泄漏。

2、使用库，比较出名的就是LeakCanary，导入库，然后运行后，就可以发现app内的内存泄漏情况。

这里说下LeakCanary的原理：

• 监听
  首先通过ActivityLifecycleCallbacks和FragmentLifeCycleCallbacks监听Activity和Fragment的生命周期。

• 判断
  然后在销毁的生命周期中判断对象是否被回收。弱引用在定义的时候可以指定引用对象和一个 ReferenceQueue，通过该弱引用是否被加入ReferenceQueue就可以判断该对象是否被回收。

• 分析
  最后通过haha库来分析hprof文件，从而找出类之前的引用关系。

什么是类加载机制？

我们编写的java文件会在编译后变成.class文件，类加载器就是负责加载class字节码文件，class文件在文件开头有特定的文件标识，将class文件字节码内容加载到内存中，并将这些内容转换成方法区中的运行时数据结构并且ClassLoader只负责class文件的加载，至于它是否可以运行，则由执行引擎Execution Engine决定。

简单来说类加载机制就是从文件系统将一系列的 class 文件读入 JVM 内存中为后续程序运行提供资源的动作。

类加载器种类。

类加载器种类主要有四种：

• BootstrapClassLoader：启动类加载器，使用C++实现
• ExtClassLoader：扩展类加载器，使用Java实现
• AppClassLoader：应用程序类加载器，加载当前应用的classpath的所有类
• UserDefinedClassLoader：用户自定义类加载器

属于依次继承关系，也就是上一级是下一级的父加载器。

什么是双亲委派机制，为什么这么设计？

当一个类加载器收到了类加载的请求，它不会直接去加载这类，而是先把这个请求委派给父加载器去完成，依次会传递到最上级也就是启动类加载器，然后父加载器会检查是否已经加载过该类，如果没加载过，就会去加载，加载失败才会交给子加载器去加载，一直到最底层，如果都没办法能正确加载，则会跑出ClassNotFoundException异常。

举例：

• 当Application ClassLoader 收到一个类加载请求时，他首先不会自己去尝试加载这个类，而是将这个请求委派给父类加载器Extension ClassLoader去完成。
• 当Extension ClassLoader收到一个类加载请求时，他首先也不会自己去尝试加载这个类，而是将请求委派给父类加载器Bootstrap ClassLoader去完成。
• 如果Bootstrap ClassLoader加载失败(在<JAVA_HOME>\lib中未找到所需类)，就会让Extension ClassLoader尝试加载。
• 如果Extension ClassLoader也加载失败，就会使用Application ClassLoader加载。
• 如果Application ClassLoader也加载失败，就会使用自定义加载器去尝试加载。
• 如果均加载失败，就会抛出ClassNotFoundException异常。

这么设计的原因是为了防止危险代码的植入，比如String类，如果在AppClassLoader就直接被加载，就相当于会被篡改了，所以都要经过老大，也就是BootstrapClassLoader进行检查，已经加载过的类就不需要再去加载了。

webView与js通信

1） Android调用JS代码

主要有两种方法：

• 通过WebView的loadUrl（）

// 调用javascript的callJS()方法
mWebView.loadUrl("javascript:callJS()");

但是这种不常用，因为它会自动刷新页面而且没有返回值，有点影响交互。

• 通过WebView的evaluateJavascript（）

mWebView.evaluateJavascript（"javascript:callJS()", new ValueCallback<String>() {
        @Override
        public void onReceiveValue(String value) {
            //此处为 js 返回的结果
        }
    });

这种就比较全面了。调用方法并且获取返回值。

2） JS调用Android端代码

主要有两种方法：

• 通过WebView的addJavascriptInterface（）进行对象映射

public class AndroidtoJs extends Object {

    // 定义JS需要调用的方法
    // 被JS调用的方法必须加入@JavascriptInterface注解
    @JavascriptInterface
    public void hello(String msg) {
        System.out.println("JS调用了Android的hello方法");
    }
}

mWebView.addJavascriptInterface(new AndroidtoJs(), "test");


//js中：
function callAndroid(){
     // 由于对象映射，所以调用test对象等于调用Android映射的对象
     test.hello("js调用了android中的hello方法");
}

这种方法虽然很好用，但是要注意的是4.2以后，对于被调用的函数以@JavascriptInterface进行注解，否则容易出发漏洞，因为js方可以通过反射调用一些本地命令，很危险。

• 通过 WebViewClient 的shouldOverrideUrlLoading ()方法回调拦截 url

这种方法是通过shouldOverrideUrlLoading回调去拦截url，然后进行解析，如果是之前约定好的协议，就调用相应的方法。

// 复写WebViewClient类的shouldOverrideUrlLoading方法
mWebView.setWebViewClient(new WebViewClient() {
        @Override
        public boolean shouldOverrideUrlLoading(WebView view, String url) {
			Uri uri = Uri.parse(url);                                 
            // 如果url的协议 = 预先约定的 js 协议
            if ( uri.getScheme().equals("js")) {
			// 如果 authority  = 预先约定协议里的 webview，即代表都符合约定的协议
            	if (uri.getAuthority().equals("webview")) {
            		System.out.println("js调用了Android的方法");
            		// 可以在协议上带有参数并传递到Android上
            		HashMap<String, String> params = new HashMap<>();
            		Set<String> collection = uri.getQueryParameterNames();
				}
            	return true;
            }
            return super.shouldOverrideUrlLoading(view, url);
            }
        }
    );

如何避免WebView内存泄露

WebView的内存泄露主要是因为在页面销毁后，WebView的资源无法马上释放所导致的。现在主流的是两种方法：

1）不在xml布局中添加webview标签，采用在代码中new出来的方式，并在页面销毁的时候去释放webview资源

//addview
private WeakReference<BaseWebActivity> webActivityReference = new WeakReference<BaseWebActivity>(this);
mWebView = new BridgeWebView(webActivityReference .get());
webview_container.addView(mWebView);


//销毁
ViewParent parent = mWebView.getParent();
if (parent != null) {
    ((ViewGroup) parent).removeView(mWebView);
}
mWebView.stopLoading();
mWebView.getSettings().setJavaScriptEnabled(false);
mWebView.clearHistory();
mWebView.clearView();
mWebView.removeAllViews();
mWebView.destroy()；
mWebView=null；

2）另起一个进程加载webview，页面销毁后干掉这个进程。但是这个方法的麻烦之处就在于进程间通信。

使用方法很简单，xml文件中写出进程名即可，销毁的时候调用System.exit(0)

<activity android:name=".WebActivity"
   android:process=":remoteweb"/>

System.exit(0)   

webView还有哪些可以优化的地方

• 提前初始化或者使用全局WebView。首次初始化WebView会比第二次初始化慢很多。初始化后，即使WebView已释放，但一些多WebView共用的全局服务/资源对想仍未释放，而第二次初始化不需要生成，因此初始化变快。

• DNS采用和客户端API相同的域名，DNS解析也是耗时比较多的部分，所以用客户端API相同的域名因为其DNS会被缓存，所以打开webView的时候就不会再耗时在DNS上了

• 对于JS的优化，尽量不要用偏重的框架，比如React。其次是高性能要求页面还是需要后端渲染。最后就是app中的网页框架要统一，这样就可以对js进行缓存和复用。

这里有美团团队的总结方案，如下：

• WebView初始化慢，可以在初始化同时先请求数据，让后端和网络不要闲着。
• 后端处理慢，可以让服务器分trunk输出，在后端计算的同时前端也加载网络静态资源。
• 脚本执行慢，就让脚本在最后运行，不阻塞页面解析。
• 同时，合理的预加载、预缓存可以让加载速度的瓶颈更小。
• WebView初始化慢，就随时初始化好一个WebView待用。
• DNS和链接慢，想办法复用客户端使用的域名和链接。
• 脚本执行慢，可以把框架代码拆分出来，在请求页面之前就执行好。

Activity、View、Window 之间的关系。

每个 Activity 包含了一个 Window 对象，这个对象是由 PhoneWindow 做的实现。而 PhoneWindow 将 DecorView 作为了一个应用窗口的根 View，这个 DecorView 又把屏幕划分为了两个区域：一个是 TitleView，一个是ContentView，而我们平时在 Xml 文件中写的布局正好是展示在 ContentView 中的。

说说Android的事件分发机制完整流程，也就是从点击屏幕开始，事件会怎么传递。

我觉得事件分发机制流程可以分为三部分，分别是从外传里，从里传外，消费之后。

1）首先，从最外面一层传到最里面一层：

如果当前是viewgroup层级，就会判断 onInterceptTouchEvent 是否为true，如果为true，则代表事件要消费在这一层级，不再往下传递。接着便执行当前 viewgroup 的onTouchEvent方法。如果onInterceptTouchEvent为false，则代表事件继续传递到下一层级的 dispatchTouchEvent方法，接着一样的代码逻辑，一直到最里面一层的view。

伪代码解释：

public boolean dispatchTouchEvent(MotionEvent event) {
    boolean isConsume = false;
    if (isViewGroup) {
        if (onInterceptTouchEvent(event)) {
            isConsume = onTouchEvent(event);
        } else {
            isConsume = child.dispatchTouchEvent(event);
        }

    } else {
        //isView
        isConsume = onTouchEvent(event);
    }
    return isConsume;
}

2）到最里层的view之后，view本身还是可以选择消费或者传到外面。

到最里面一层就会直接执行onTouchEvent方法，这时候，view有没有权利拒绝消费事件呢？ 按道理view作为最底层的，应该是没有发言权才对。但是呢，秉着公平公正原则，view也是可以拒绝的，可以在onTouchEvent方法返回false，表示他不想消费这个事件。那么它的父容器的onTouchEvent又会被调用，如果父容器的onTouchEvent又返回false，则又交给上一级。一直到最上层，也就是Activity的onTouchEvent被调用。

伪代码解释：

public void handleTouchEvent(MotionEvent event) {
    if (!onTouchEvent(event)) {
        getParent.onTouchEvent(event);
    }
}

3）消费之后

当某一层viewGroup的onInterceptTouchEvent为true，则代表当前层级要消费事件。如果它的onTouchListener被设置了的话，则onTouch会被调用，如果onTouch的返回值返回true，则onTouchEvent不会被调用。如果返回false或者没有设置onTouchListener，则会继续调用onTouchEvent。而onClick方法则是设置了onClickListener则会被正常调用。

伪代码解释：

public void consumeEvent(MotionEvent event) {
    if (setOnTouchListener) {
        int tag = onTouch();
        if (!tag) {
            onTouchEvent(event);
        }
    } else {
        onTouchEvent(event);
    }

    if (setOnClickListener) {
        onClick();
    }
}

解决滑动冲突的办法。

解决滑动冲突的根本就是要在适当的位置进行拦截，那么就有两种解决办法：

• 外部拦截：从父view端处理，根据情况决定事件是否分发到子view
• 内部拦截：从子view端处理，根据情况决定是否阻止父view进行拦截，其中的关键就是requestDisallowInterceptTouchEvent方法。

1）外部拦截法，其实就是在onInterceptTouchEvnet方法里面进行判断，是否拦截，见代码：

    //外部拦截法：父view.java		
    @Override
    public boolean onInterceptTouchEvent(MotionEvent ev) {
        boolean intercepted = false;
        //父view拦截条件
        boolean parentCanIntercept;

        switch (ev.getActionMasked()) {
            case MotionEvent.ACTION_DOWN:
                intercepted = false;
                break;
            case MotionEvent.ACTION_MOVE:
                if (parentCanIntercept) {
                    intercepted = true;
                } else {
                    intercepted = false;
                }
                break;
            case MotionEvent.ACTION_UP:
                intercepted = false;
                break;
        }
        return intercepted;

    }

还是比较简单的，直接判断拦截条件，然后返回true就代表拦截，false就不拦截，传到子view。注意的是ACTION_DOWN状态不要拦截，如果拦截，那么后续事件就直接交给父view处理了，也就没有拦截不拦截的问题了。

2. 内部拦截法，就是通过requestDisallowInterceptTouchEvent方法让父view不要拦截。

    //父view.java			
    @Override
    public boolean onInterceptTouchEvent(MotionEvent ev) {
        if (ev.getActionMasked() == MotionEvent.ACTION_DOWN) {
            return false;
        } else {
            return true;
        }
    }

    //子view.java
    @Override
    public boolean dispatchTouchEvent(MotionEvent event) {
        //父view拦截条件
        boolean parentCanIntercept;

        switch (event.getActionMasked()) {
            case MotionEvent.ACTION_DOWN:
                getParent().requestDisallowInterceptTouchEvent(true);
                break;
            case MotionEvent.ACTION_MOVE:
                if (parentCanIntercept) {
                    getParent().requestDisallowInterceptTouchEvent(false);
                }
                break;
            case MotionEvent.ACTION_UP:
                break;
        }
        return super.dispatchTouchEvent(event);
    }

requestDisallowInterceptTouchEvent(true)的意思是阻止父view拦截事件，也就是传入true之后，父view就不会再调用onInterceptTouchEvent。反之，传入false就代表父view可以拦截，也就是会走到父view的onInterceptTouchEvent方法。所以需要父view拦截的时候，就传入flase，需要父view不拦截的时候就传入true。

Fragment生命周期，当hide，show，replace时候生命周期变化

1）生命周期：

• onAttach()：Fragment和Activity相关联时调用。可以通过该方法获取Activity引用，还可以通过getArguments()获取参数。
• onCreate()：Fragment被创建时调用。
• onCreateView()：创建Fragment的布局。
• onActivityCreated()：当Activity完成onCreate()时调用。
• onStart()：当Fragment可见时调用。
• onResume()：当Fragment可见且可交互时调用。
• onPause()：当Fragment不可交互但可见时调用。
• onStop()：当Fragment不可见时调用。
• onDestroyView()：当Fragment的UI从视图结构中移除时调用。
• onDestroy()：销毁Fragment时调用。
• onDetach()：当Fragment和Activity解除关联时调用。

每个调用方法对应的生命周期变化：

• add(): onAttach()->…->onResume()。
• remove(): onPause()->…->onDetach()。
• replace(): 相当于旧Fragment调用remove()，新Fragment调用add()。remove()+add()的生命周期加起来
• show(): 不调用任何生命周期方法，调用该方法的前提是要显示的 Fragment已经被添加到容器，只是纯粹把Fragment UI的setVisibility为true。
• hide(): 不调用任何生命周期方法，调用该方法的前提是要显示的Fragment已经被添加到容器，只是纯粹把Fragment UI的setVisibility为false。

Activity 与 Fragment，Fragment 与 Fragment之间怎么交互通信。

• Activity 与 Fragment通信

Activity有Fragment的实例，所以可以执行Fragment的方法，或者传入一个接口。
同样，Fragment可以通过getActivity()获取Activity的实例，也是可以执行方法。

• Fragment 与 Fragment之间通信

1）直接获取另一个Fragmetn的实例

getActivity().getSupportFragmentManager().findFragmentByTag("mainFragment");

2）接口回调
一个Fragment里面去实现接口，另一个Fragment把接口实例传进去。

3）Eventbus等框架。

Fragment遇到viewpager遇到过什么问题吗。

• 滑动的时候，调用setCurrentItem方法，要注意第二个参数smoothScroll。传false，就是直接跳到fragment，传true，就是平滑过去。一般主页切换页面都是用false。

• 禁止预加载的话，调用setOffscreenPageLimit(0)是无效的，因为方法里面会判断是否小于1。需要重写setUserVisibleHint方法，判断fragment是否可见。

• 不要使用getActivity()获取activity实例，容易造成空指针，因为如果fragment已经onDetach()了，那么就会报空指针。所以要在onAttach方法里面，就去获取activity的上下文。

• FragmentStatePagerAdapter对limit外的Fragment销毁，生命周期为onPause->onStop->onDestoryView->onDestory->onDetach, onAttach->onCreate->onCreateView->onStart->onResume。也就是说切换fragment的时候有可能会多次onCreateView，所以需要注意处理数据。

• 由于可能多次onCreateView，所以我们可以把view保存起来，如果为空再去初始化数据。见代码：

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
        if (null == mFragmentView) {
                mFragmentView = inflater.inflate(getContentViewLayoutID(), null);
                ButterKnife.bind(this, mFragmentView);
                isDestory = false;
                initViewsAndEvents();
            }
        return mFragmentView;
    }

ARouter的原理

首先，我们了解下ARouter是干嘛的？ARouter是阿里巴巴研发的一个用于解决组件间，模块间界面跳转问题的框架。
所以简单的说，就是用来跳转界面的，不同于平时用到的显式或隐式跳转，只需要在对应的界面上添加注解，就可以实现跳转，看个案例：

@Route(path = "/test/activity")
public class YourActivity extend Activity {
    ...
}

//跳转
ARouter.getInstance().build("/test/activity").navigation();

使用很方便，通过一个path就可以进行跳转了，那么原理是什么呢？

其实仔细思考下，就可以联想到，既然关键跳转过程是通过path跳转到具体的activity，那么原理无非就是把path和Activity一一对应起来就行了。没错，其实就是通过注释，通过apt技术，也就是注解处理工具，把path和activity关联起来了。主要有以下几个步骤：

• 代码里加入的@Route注解，会在编译时期通过apt生成一些存储path和activity.class映射关系的类文件
• app进程启动的时候会加载这些类文件，把保存这些映射关系的数据读到内存里(保存在map里)
• 进行路由跳转的时候，通过build()方法传入要到达页面的路由地址，ARouter会通过它自己存储的路由表找到路由地址对应的Activity.class
• 然后new Intent方法，如果有调用ARouter的withString()方法，就会调用intent.putExtra(String name, String value)方法添加参数
• 最后调用navigation()方法，它的内部会调用startActivity(intent)进行跳转

ARouter怎么实现页面拦截

先说一个拦截器的案例，用作页面跳转时候检验是否登录，然后判断跳转到登录页面还是目标页面：

   @Interceptor(name = "login", priority = 6)
    public class LoginInterceptorImpl implements IInterceptor {
        @Override
        public void process(Postcard postcard, InterceptorCallback callback) {
            String path = postcard.getPath();
            boolean isLogin = SPUtils.getInstance().getBoolean(ConfigConstants.SP_IS_LOGIN, false);
    
            if (isLogin) { 
                // 如果已经登录不拦截
                callback.onContinue(postcard);
            } else {  
                // 如果没有登录，进行拦截
                callback.onInterrupt(postcard);
            }
    
        }
    
        @Override
        public void init(Context context) {
            LogUtils.v("初始化成功"); 
        }
    
    }

    //使用
    ARouter.getInstance().build(ConfigConstants.SECOND_PATH)
                             .withString("msg", "123")
                              .navigation(this,new LoginNavigationCallbackImpl()); 
                              // 第二个参数是路由跳转的回调
         
     
    // 拦截的回调
    public class LoginNavigationCallbackImpl  implements NavigationCallback{
        @Override 
        public void onFound(Postcard postcard) {
    
        }
    
        @Override 
        public void onLost(Postcard postcard) {
    
        }
    
        @Override   
        public void onArrival(Postcard postcard) {
    
        }
    
        @Override
        public void onInterrupt(Postcard postcard) {
        	//拦截并跳转到登录页
            String path = postcard.getPath();
            Bundle bundle = postcard.getExtras();
            ARouter.getInstance().build(ConfigConstants.LOGIN_PATH)
                    .with(bundle)
                    .withString(ConfigConstants.PATH, path)
                    .navigation();
        }
    }

拦截器实现IInterceptor接口，使用注解@Interceptor，这个拦截器就会自动被注册了，同样是使用APT技术自动生成映射关系类。这里还有一个优先级参数priority，数值越小，就会越先执行。

怎么应用到组件化中

首先，在公用组件的build.gradle中添加依赖：

dependencies {
    api ‘com.alibaba:arouter-api:1.4.0‘
    annotationProcessor ‘com.alibaba:arouter-compiler:1.2.1‘
}

其次，必须在每个业务组件，也就是用到了arouter的组件中都声明annotationProcessorOptions，否则会无法通过apt生成索引文件，也就无法正常跳转了：

//业务组件的build.gradle
android {
    defaultConfig {
        javaCompileOptions {
            annotationProcessorOptions {
                arguments = [AROUTER_MODULE_NAME: project.getName()]
            }
        }
    }
}
dependencies {
    annotationProcessor ‘com.alibaba:arouter-compiler:1.2.1‘
    implementation ‘公用组件‘
}

这个arguments是用来设置给编译处理器的一些参数，这里就把[AROUTER_MODULE_NAME: project.getName()]键值对传了过去，方便Arouter使用apt的时候进行数据处理，也是Arouter库所规定的配置。

然后就可以正常使用了。

说说你对协程的理解

在我看来，协程和线程一样都是用来解决并发任务（异步任务）的方案。
所以协程和线程是属于一个层级的概念，但是对于kotlin中的协程，又与广义的协程有所不同。
kotlin中的协程其实是对线程的一种封装，或者说是一种线程框架，为了让异步任务更好更方便使用。

说下协程具体的使用

比如在一个异步任务需要回调到主线程的情况，普通线程需要通过handler切换线程然后进行UI更新等，一旦多个任务需要顺序调用，那更是很不方便，比如以下情况：

//客户端顺序进行三次网络异步请求，并用最终结果更新UI
thread{
	iotask1(parameter) { value1 ->
		iotask1(value1) { value2 ->
			iotask1(value2) { value3 ->
				runOnUiThread{
					updateUI(value3) 
				}      
		} 
	}              
}
}

简直是魔鬼调用，如果不止3次，而是5次，6次，那还得了。。

而用协程就能很好解决这个问题：

//并发请求
GlobalScope.launch(Dispatchers.Main) {
    //三次请求并发进行
	val value1 = async { request1(parameter1) }
	val value2 = async { request2(parameter2) }
	val value3 = async { request3(parameter3) }
    //所有结果全部返回后更新UI
	updateUI(value1.await(), value2.await(), value3.await())
}

//切换到io线程
suspend fun request1(parameter : Parameter){withContext(Dispatcher.IO){}}
suspend fun request2(parameter : Parameter){withContext(Dispatcher.IO){}}
suspend fun request3(parameter : Parameter){withContext(Dispatcher.IO){}}

就像是同一个线程中顺序执行的效果一样，再比如我要按顺序执行一次异步任务，然后完成后更新UI，一共三个异步任务。
如果正常写应该怎么写？

thread{
	iotask1() { value1 ->
		runOnUiThread{
			updateUI1(value1) 
			iotask2() { value2 ->
			runOnUiThread{
				updateUI2(value2) 
				iotask3() { value3 ->
				runOnUiThread{
					updateUI3(value3) 
				} 
			    }   
			}      
			}	

		}
	}
}

晕了晕了，不就是一次异步任务，一次UI更新吗。怎么这么麻烦，来，用协程看看怎么写：

    GlobalScope.launch (Dispatchers.Main) {
        ioTask1()
        ioTask1()
        ioTask1()
        updateUI1()
        updateUI2()
        updateUI3()
    }

	suspend fun ioTask1(){
        withContext(Dispatchers.IO){}
    }
    suspend fun ioTask2(){
        withContext(Dispatchers.IO){}
    }
    suspend fun ioTask3(){
        withContext(Dispatchers.IO){}
    }

    fun updateUI1(){
    }
    fun updateUI2(){
    }
    fun updateUI3(){
    }

协程怎么取消

• 取消协程作用域将取消它的所有子协程。

// 协程作用域 scope
val job1 = scope.launch { … }
val job2 = scope.launch { … }
scope.cancel()

• 取消子协程

// 协程作用域 scope
val job1 = scope.launch { … }
val job2 = scope.launch { … }
job1.cancel()

但是调用了cancel并不代表协程内的工作会马上停止，他并不会组织代码运行。
比如上述的job1，正常情况处于active 状态，调用了cancel方法后，协程会变成Cancelling 状态，工作完成之后会变成Cancelled 状态，所以可以通过判断协程的状态来停止工作。

Jetpack 中定义的协程作用域（viewModelScope 和 lifecycleScope）可以帮助你自动取消任务，下次再详细说明，其他情况就需要自行进行绑定和取消了。

之前大家应该看过我写的启动流程分析了吧，那篇文章里我说过分析源码的目的一直都不是为了学知识而学，而是理解了这些基础，我们才能更好的解决问题。所以今天就来看看通过分析app启动流程，我们该怎么具体进行启动优化。

• App启动流程中我们能进行优化的地方有哪些？
• 具体有哪些优化方法？
• 分析启动耗时的方法

具体有哪些启动优化方法？

• 障眼法之闪屏页

为了消除启动时的白屏/黑屏，可以通过设置android:windowBackground，让人感觉一点击icon就启动完毕了的感觉。

        <activity android:name=".ui.activity.启动activity"
            android:theme="@style/MyAppTheme"
            android:screenOrientation="portrait">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <style name="MyAppTheme" parent="Theme.AppCompat.NoActionBar">
    		<item name="android:windowBackground">@drawable/logo</item>
		</style>

• 预创建Activity

对象第一次创建的时候，java虚拟机首先检查类对应的Class 对象是否已经加载。如果没有加载，jvm会根据类名查找.class文件，将其Class对象载入。同一个类第二次new的时候就不需要加载类对象，而是直接实例化，创建时间就缩短了。

• 第三方库懒加载

很多第三方开源库都说在Application中进行初始化，所以可以把一些不是需要启动就初始化的三方库的初始化放到后面，按需初始化，这样就能让Application变得更轻。

• WebView启动优化

webview第一次启动会非常耗时，具体优化方法可以看我之前的文章，关于webview的优化。

• 线程优化

线程是程序运行的基本单位，线程的频繁创建是耗性能的，所以大家应该都会用线程池。单个cpu情况下，即使是开多个线程，同时也只有一个线程可以工作，所以线程池的大小要根据cpu个数来确定。

• MultiDex 优化

由于65536方法限制，所以一般class文件要生成多个dex文件，Android5.0以下，ClassLoader加载类的时候只会从class.dex（主dex）里加载，所以要执行MultiDex.install(context)方法才能正常读取dex类。

而这个install方法就是耗时大户，会解压apk，遍历dex文件，压缩dex、将dex文件通过反射转换成DexFile对象、反射替换数组。

这里需要的方案就是今日头条方案：

1、在Application的attachBaseContext方法里，启动另一个进程的LoadDexActivity去异步执行MultiDex逻辑，显示Loading。
2、然后主进程Application进入while循环，不断检测MultiDex操作是否完成
3、MultiDex执行完之后主进程Application继续走，ContentProvider初始化和Application onCreate方法，也就是执行主进程正常的逻辑。

所以重点就是单开进程去执行MultiDex逻辑，这样就不影响APP的启动了。

分析启动耗时的方法

• Systrace + 函数插桩

也就是通过在方法的入口和出口加入统计代码，从而统计方法耗时

class Trace{
    public static void i(String tag){
        android.os.Trace.beginSection(tag);
    }

    public static void o(){
        android.os.Trace.endSection();
    }
}


void test(){
    Trace.i("test");
    System.out.println("doSomething");
    Trace.o();
}

• BlockCanary
  BlockCanary 可以监听主线程耗时的方法，就是在主线程消息循环打出日志的地入手, 当一个消息操作时间超过阀值后, 记录系统各种资源的状态, 并展示出来。所以我们将阈值设置低一点，这样的话如果一个方法执行时间超过200毫秒，获取堆栈信息。

而记录时间的方法我们之前也说过，就是通过looper()方法中循环去从MessageQueue中去取msg的时候，在dispatchMessage方法前后会有logging日志打印，所以只需要自定义一个Printer，重写println(String x)方法即可实现耗时统计了。

Activity、View、Window三者如何关联？

Activity包含了一个PhoneWindow，而PhoneWindow就是继承于Window的，Activity通过setContentView将View设置到了PhoneWindow上，而View通过WindowManager的addView()、removeView()、updateViewLayout()对View进行管理。Window的添加过程以及Activity的启动流程都是一次IPC的过程。Activity的启动需要通过AMS完成；Window的添加过程需要通过WindowSession完成。

onCreate,onResume,onStart里面，什么地方可以获得宽高

如果在onCreate、onStart、onResume中直接调用View的getWidth/getHeight方法，是无法得到View宽高的正确信息，因为view的measure过程与Activity的生命周期是不同步的，所以无法保证在这些生命周期里view
的measure已经完成。所以很有可能获取的宽高为0。

所以主要有以下三个方法来获取view的宽高：

• view.post()方法

在该方法里的runnable对象，能保证view已经绘制完成，也就是执行完measure、layout和draw方法了。

        view.post(new Runnable() {
            @Override
            public void run() {
                int width = view.getWidth();
                int hight = view.getHeight();
            }
        });

• onWindowFocusChanged方法

Activity中可以重写onWindowFocusChanged方法，该方法表示Activity的窗口得到焦点或者失去焦点的时候，所以Activitiy获取焦点时，view肯定绘制完成了，这时候获取宽高也是没问题的：

    @Override
    public void onWindowFocusChanged(boolean hasFocus) {
        super.onWindowFocusChanged(hasFocus);
        if(hasFocus){
            int width = view.getWidth();
            int hight = view.getHeight();
        }
    }

• ViewTreeObserver注册OnGlobalLayoutListener接口

ViewTreeObserver是一个观察者，主要是用来观察视图树的各种变化。OnGlobalLayoutListener的作用是当View树的状态发生改变或者View树中某view的可见性发生改变时，OnGlobalLayoutListener的onGlobalLayout方法将会被回调。因此，此时获取view的宽高也是可以的。

        ViewTreeObserver observer = title_name.getViewTreeObserver();
        observer.addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
            @Override
            public void onGlobalLayout() {
               int width = view.getWidth();
               int hight = view.getHeight();
            }
        });

为什么view.post可以获得宽高，有看过view.post的源码吗？

能获取宽高的原因肯定就是因为在此之前view 绘制已经完成，所以View.post() 添加的任务能够保证在所有 View 绘制流程结束之后才被执行。

看看post的源码：

 public boolean post(Runnable action) {
        final AttachInfo attachInfo = mAttachInfo;
        if (attachInfo != null) {
            return attachInfo.mHandler.post(action); 
        }
        // Assume that post will succeed later
        ViewRootImpl.getRunQueue().post(action);  
        return true;
    }

//RunQueue .class
     void post(Runnable action) {
            postDelayed(action, 0);
        }
 
        void postDelayed(Runnable action, long delayMillis) {
            HandlerAction handlerAction = new HandlerAction();
            handlerAction.action = action;
            handlerAction.delay = delayMillis;
 
            synchronized (mActions) {
                mActions.add(handlerAction);
            }
        }

        void executeActions(Handler handler) {
            synchronized (mActions) {
                final ArrayList<HandlerAction> actions = mActions;
                final int count = actions.size();
 
                for (int i = 0; i < count; i++) {
                    final HandlerAction handlerAction = actions.get(i);
                    handler.postDelayed(handlerAction.action, handlerAction.delay);
                }
 
                actions.clear();
            }
        }

所以在执行View.post()的方法时，那些Runnable并没有马上被执行，而是保存到RunQueue里面,然后通过executeActions方法执行，也就是通过handler，post了一个延时任务Runnable。而executeActions方法什么时候会执行呢？

private void performTraversals() {
     getRunQueue().executeActions(attachInfo.mHandler);
    ...
    performMeasure();
    ...
    performLayout();
    ...
    performDraw();
 }

可以看到在performTraversals方法中执行了，但是在view绘制之前，这是因为在绘制之前就把需要执行的runnable封装成Message发送到MessageQueue里排队了，但是Looper不会马上去取这个消息，因为Looper会按顺序取消息，主线程还有什么消息没执行完呢？其实就是当前的这个performTraversals所在的任务，所以要等下面的·performMeasure，performLayout，performDraw·都执行完，也就是view绘制完毕了，才会去执行之前我们post的那个runnable，也就是我们能在view.post方法里的runnable能获取宽高的主要原因了。

SharedPreferences是如何保证线程安全的，其内部的实现用到了哪些锁

SharedPreferences的本质是用键值对的方式保存数据到xml文件，然后对文件进行读写操作。

• 对于读操作，加一把锁就够了：

public String getString(String key, @Nullable String defValue) {
    synchronized (mLock) {
        String v = (String)mMap.get(key);
        return v != null ? v : defValue;
    }
}

• 对于写操作，由于是两步操作，一个是editor.put，一个是commit或者apply所以其实是需要两把锁的：

//第一把锁，操作Editor类的map对象
public final class EditorImpl implements Editor {
  @Override
  public Editor putString(String key, String value) {
      synchronized (mEditorLock) {
          mEditorMap.put(key, value);
          return this;
      }
  }
}


//第二把锁，操作文件的写入
synchronized (mWritingToDiskLock) {
    writeToFile(mcr, isFromSyncCommit);
}

是进程安全的吗？如果是不安全的话我们作为开发人员该怎么办？

1） SharedPreferences是进程不安全的，因为没有使用跨进程的锁。既然是进程不安全，那么久有可能在多进程操作的时候发生数据异常。

2） 我们有两个办法能保证进程安全：

• 使用跨进程组件，也就是ContentProvider，这也是官方推荐的做法。通过ContentProvider对多进程进行了处理，使得不同进程都是通过ContentProvider访问SharedPreferences。
• 加文件锁，由于SharedPreferences的本质是读写文件，所以我们对文件加锁，就能保证进程安全了。

SharedPreferences 操作有文件备份吗？是怎么完成备份的？

• SharedPreferences 的写入操作，首先是将源文件备份：

  if (!backupFileExists) {
      !mFile.renameTo(mBackupFile);
  }

• 再写入所有数据，只有写入成功，并且通过 sync 完成落盘后，才会将 Backup（.bak） 文件删除。
• 如果写入过程中进程被杀，或者关机等非正常情况发生。进程再次启动后如果发现该 SharedPreferences 存在 Backup 文件，就将 Backup 文件重名为源文件，原本未完成写入的文件就直接丢弃，这样就能保证之前数据的正确。

为什么需要插件化

我觉得最主要的原因是可以动态扩展功能。
把一些不常用的功能或者模块做成插件，就能减少原本的安装包大小，让一些功能以插件的形式在被需要的时候被加载，也就是实现了动态加载。

比如动态换肤、节日促销、见不得人的一些功能，就可以在需要的时候去下载相应模式的apk，然后再动态加载功能。所以一般这个功能适用于一些平台类的项目，比如大众点评美团这种，功能很多，用户很大概率只会用其中的一些功能，而且这些模块单独拿出来都可以作为一个app运行。

但是现在用的却很少了，具体情况见第三点。

插件化的原理

要实现插件化，也就是实现从apk读取所有数据，要考虑三个问题：

• 读取插件代码，完成插件中代码的加载和与主工程的互相调用
• 读取插件资源，完成插件中资源的加载和与主工程的互相访问
• 四大组件管理

1）读取插件代码，其实也就是进行插件中的类加载。所以用到类加载器就可以了。
Android中常用的有两种类加载器，DexClassLoader和PathClassLoader，它们都继承于BaseDexClassLoader。区别在于DexClassLoader多传了一个optimizedDirectory参数，表示缓存我们需要加载的dex文件的，并创建一个DexFile对象，而且这个路径必须为内部存储路径。而PathClassLoader这个参数为null，意思就是不会缓存到内部存储空间了，而是直接用原来的文件路径加载。所以DexClassLoader功能更为强大，可以加载外部的dex文件。

同时由于双亲委派机制，在构造插件的ClassLoader时会传入主工程的ClassLoader作为父加载器，所以插件是可以直接可以通过类名引用主工程的类。
而主工程调用插件则需要通过DexClassLoader去加载类，然后反射调用方法。

2）读取插件资源，主要是通过AssetManager进行访问。具体代码如下：

/**
 * 加载插件的资源：通过AssetManager添加插件的APK资源路径
 */
protected void loadPluginResources() {
    //反射加载资源
    try {
        AssetManager assetManager = AssetManager.class.newInstance();
        Method addAssetPath = assetManager.getClass().getMethod("addAssetPath", String.class);
        addAssetPath.invoke(assetManager, mDexPath);
        mAssetManager = assetManager;
    } catch (Exception e) {
        e.printStackTrace();
    }
    Resources superRes = super.getResources();
    mResources = new Resources(mAssetManager, superRes.getDisplayMetrics(), superRes.getConfiguration());
}   

通过addAssetPath方法把插件的路径穿进去，就可以访问到插件的资源了。

3）四大组件管理
为什么单独说下四大组件呢？因为四大组件不仅要把他们的类加载出来，还要去管理他们的生命周期，在AndroidManifest.xml中注册。这也是插件化中比较重要的一部分。这里重点说下Activity。

主要实现方法是通过Hook技术，主要的方案就是先用一个在AndroidManifest.xml中注册的Activity来进行占坑，用来通过AMS的校验，接着在合适的时机用插件Activity替换占坑的Activity。

Hook 技术又叫做钩子函数，在系统没有调用该函数之前，钩子程序就先捕获该消息，钩子函数先得到控制权，这时钩子函数既可以加工处理（改变）该函数的执行行为，还可以强制结束消息的传递。简单来说，就是把系统的程序拉出来变成我们自己执行代码片段。

这里的hook其实就是我们常说的下钩子，可以改变函数的内部行为。

这里加载插件Activity用到hook技术，有两个可以hook的点，分别是：

• Hook IActivityManager
  上面说了，首先会在AndroidManifest.xml中注册的Activity来进行占坑，然后合适的时机来替换我们要加载的Activity。所以我们主要需要两步操作：
  第一步：使用占坑的这个Activity完成AMS验证。
  也就是让AMS知道我们要启动的Activity是在xml里面注册过的哦。具体代码如下：

  @Override
  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            if ("startActivity".contains(method.getName())) {
                //换掉
                Intent intent = null;
                int index = 0;
                for (int i = 0; i < args.length; i++) {
                    Object arg = args[i];
                    if (arg instanceof Intent) {
                        //说明找到了startActivity的Intent参数
                        intent = (Intent) args[i];
                        //这个意图是不能被启动的，因为Acitivity没有在清单文件中注册
                        index = i;
                    }
                }
               //伪造一个代理的Intent，代理Intent启动的是proxyActivity
                Intent proxyIntent = new Intent();
                ComponentName componentName = new ComponentName(context, proxyActivity);
                proxyIntent.setComponent(componentName);
                proxyIntent.putExtra("oldIntent", intent);
                args[index] = proxyIntent;
            }

            return method.invoke(iActivityManagerObject, args);
        }

第二步：替换回我们的Activity。
上面一步是把我们实际要启动的Activity换成了我们xml里面注册的activity来躲过验证，那么后续我们就需要把Activity换回来。
Activity启动的最后一步其实是通过H（一个handler）中重写的handleMessage方法会对LAUNCH_ACTIVITY类型的消息进行处理，最终会调用Activity的onCreate方法。最后会调用到Handler的dispatchMessage方法用于处理消息，如果Handler的Callback类型的mCallback不为null，就会执行mCallback的handleMessage方法。 所以我们能hook的点就是这个mCallback。

 public static void hookHandler() throws Exception {
        Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");
        Object currentActivityThread= FieldUtil.getField(activityThreadClass ,null,"sCurrentActivityThread");//1
        Field mHField = FieldUtil.getField(activityThread,"mH");//2
        Handler mH = (Handler) mHField.get(currentActivityThread);//3
        FieldUtil.setField(Handler.class,mH,"mCallback",new HCallback(mH));
    }

public class HCallback implements Handler.Callback{
    //...
    @Override
    public boolean handleMessage(Message msg) {
        if (msg.what == LAUNCH_ACTIVITY) {
            Object r = msg.obj;
            try {
                //得到消息中的Intent(启动SubActivity的Intent)
                Intent intent = (Intent) FieldUtil.getField(r.getClass(), r, "intent");
                //得到此前保存起来的Intent(启动TargetActivity的Intent)
                Intent target = intent.getParcelableExtra(HookHelper.TARGET_INTENT);
                //将启动SubActivity的Intent替换为启动TargetActivity的Intent
                intent.setComponent(target.getComponent());
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        mHandler.handleMessage(msg);
        return true;
    }
}

用自定义的HCallback来替换mH中的mCallback即可完成Activity的替换了。

• Hook Instrumentation

这个方法是由于startActivityForResult方法中调用了Instrumentation的execStartActivity方法来激活Activity的生命周期，所以可以通过替换Instrumentation来完成，然后在Instrumentation的execStartActivity方法中用占坑SubActivity来通过AMS的验证，在Instrumentation的newActivity方法中还原TargetActivity。

public class InstrumentationProxy extends Instrumentation {
    private Instrumentation mInstrumentation;
    private PackageManager mPackageManager;
    public InstrumentationProxy(Instrumentation instrumentation, PackageManager packageManager) {
        mInstrumentation = instrumentation;
        mPackageManager = packageManager;
    }
    public ActivityResult execStartActivity(
            Context who, IBinder contextThread, IBinder token, Activity target,
            Intent intent, int requestCode, Bundle options) {
        List<ResolveInfo> infos = mPackageManager.queryIntentActivities(intent, PackageManager.MATCH_ALL);
        if (infos == null || infos.size() == 0) {
            intent.putExtra(HookHelper.TARGET_INTENsT_NAME, intent.getComponent().getClassName());//1
            intent.setClassName(who, "com.example.liuwangshu.pluginactivity.StubActivity");//2
        }
        try {
            Method execMethod = Instrumentation.class.getDeclaredMethod("execStartActivity",
                    Context.class, IBinder.class, IBinder.class, Activity.class, Intent.class, int.class, Bundle.class);
            return (ActivityResult) execMethod.invoke(mInstrumentation, who, contextThread, token,
                    target, intent, requestCode, options);
        } catch (Exception e) {
            e.printStackTrace();
        }
        return null;
    }

    public Activity newActivity(ClassLoader cl, String className, Intent intent) throws InstantiationException,
        IllegalAccessException, ClassNotFoundException {
    	String intentName = intent.getStringExtra(HookHelper.TARGET_INTENT_NAME);
    	if (!TextUtils.isEmpty(intentName)) {
        	return super.newActivity(cl, intentName, intent);
    	}
    	return super.newActivity(cl, className, intent);
	}

}

  public static void hookInstrumentation(Context context) throws Exception {
        Class<?> contextImplClass = Class.forName("android.app.ContextImpl");
        Field mMainThreadField  =FieldUtil.getField(contextImplClass,"mMainThread");//1
        Object activityThread = mMainThreadField.get(context);//2
        Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");
        Field mInstrumentationField=FieldUtil.getField(activityThreadClass,"mInstrumentation");//3
        FieldUtil.setField(activityThreadClass,activityThread,"mInstrumentation",new InstrumentationProxy((Instrumentation) mInstrumentationField.get(activityThread),
                context.getPackageManager()));
    }

市面上的一些插件化方案以及你的想法

前几年插件化还是很火的，比如Dynamic-Load-Apk（任玉刚），DroidPlugin，RePlugin（360），VirtualApk（滴滴），但是现在机会都没怎么在运营了，好多框架都最多只支持到Android9。

这是为什么呢？我觉得一个是维护成本太高难以兼容，每更新一次源码，就要重新维护一次。二就是确实插件化技术现在用的不多了，以前用插件化框架干嘛？主要是比如增加新的功能，让功能模块之间解耦。现在有RN可以进行插件化功能，有组件化可以进行项目解耦。所以用的人就不多咯。

虽然插件化用的不多了，但是我觉得技术还是可以了解的，而且热更新主要用的也是这些技术。方案可以被淘汰，但是技术不会。

参考

多线程
内存泄露
启动优化
view.post
view.post
SharedPreferences

总结

希望给大家一点帮助吧，当然文章我也会继续写的，感觉大家之前给我点的赞，嘿嘿。

大家一起加油吧！共勉！爱你们！

有一起学习的小伙伴可以关注下??。

Android面试题收录及解答10月刊