攒了一个月的Android面试题及详细解答，马上年底准备起来，冲

作者: 小小小小怪兽_666 | 来源:发表于2020-11-19 16:00 被阅读0次

一个月前呢，为了巩固下自己的基础以及为以后的面试做准备，每天去找一些大厂的面试真题，然后解答下，然后自己确实也在这个过程中能复习到不少以前没有重视的问题，今天就总结下之前一个多月总结的面试题，难度不大，大佬可以直接路过，当然发发善心点个赞也是可以的❤️。

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

网页中输入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）初始状态（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。

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

保存缓存流程：

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

获取缓存流程：

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文件，从而找出类之前的引用关系。

鸿洋注：新版 LeakCanary 使用的是 shark 库分析内存，效果更好一些。

什么是类加载机制？

我们编写的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进行检查，已经加载过的类就不需要再去加载了。