Android 面试题(附答案)

时间 2019-11-16

原文原文链接

Android 面试题(附答案)

Java面试题

GC机制

垃圾回收须要完成两件事：找到垃圾，回收垃圾。找到垃圾通常的话有两种方法：javascript

引用计数法： 当一个对象被引用时，它的引用计数器会加一，垃圾回收时会清理掉引用计数为0的对象。但这种方法有一个问题，比方说有两个对象 A 和 B，A 引用了 B，B 又引用了 A，除此以外没有别的对象引用 A 和 B，那么 A 和 B 在咱们看来已是垃圾对象，须要被回收，但它们的引用计数不为 0，没有达到回收的条件。正由于这个循环引用的问题，Java 并无采用引用计数法。前端
可达性分析法： 咱们把 Java 中对象引用的关系看作一张图，从根级对象不可达的对象会被垃圾收集器清除。根级对象通常包括 Java 虚拟机栈中的对象、本地方法栈中的对象、方法区中的静态对象和常量池中的常量。回收垃圾的话有这么四种方法：java
标记清除算法： 顾名思义分为两步，标记和清除。首先标记到须要回收的垃圾对象，而后回收掉这些垃圾对象。标记清除算法的缺点是清除垃圾对象后会形成内存的碎片化。面试
复制算法： 复制算法是将存活的对象复制到另外一块内存区域中，并作相应的内存整理工做。复制算法的优势是能够避免内存碎片化，缺点也显而易见，它须要两倍的内存。算法
标记整理算法： 标记整理算法也是分两步，先标记后整理。它会标记须要回收的垃圾对象，清除掉垃圾对象后会将存活的对象压缩，避免了内存的碎片化。设计模式
分代算法： 分代算法将对象分为新生代和老年代对象。那么为何作这样的区分呢？主要是在Java运行中会产生大量对象，这些对象的生命周期会有很大的不一样，有的生命周期很长，有的甚至使用一次以后就再也不使用。因此针对不一样生命周期的对象采用不一样的回收策略，这样能够提升GC的效率。数组

新生代对象分为三个区域：Eden 区和两个 Survivor 区。新建立的对象都放在 Eden区，当 Eden 区的内存达到阈值以后会触发 Minor GC，这时会将存活的对象复制到一个 Survivor 区中，这些存活对象的生命存活计数会加一。这时 Eden 区会闲置，当再一次达到阈值触发 Minor GC 时，会将Eden区和以前一个 Survivor 区中存活的对象复制到另外一个 Survivor 区中，采用的是我以前提到的复制算法，同时它们的生命存活计数也会加一。浏览器

这个过程会持续不少遍，直到对象的存活计数达到必定的阈值后会触发一个叫作晋升的现象：新生代的这个对象会被放置到老年代中。老年代中的对象都是通过屡次 GC 依然存活的生命周期很长的 Java 对象。当老年代的内存达到阈值后会触发 Major GC，采用的是标记整理算法。缓存

JVM内存区域的划分，哪些区域会发生 OOM

JVM 的内存区域能够分为两类：线程私有和区域和线程共有的区域。线程私有的区域：程序计数器、JVM 虚拟机栈、本地方法栈线程共有的区域：堆、方法区、运行时常量池安全

程序计数器。 每一个线程有有一个私有的程序计数器，任什么时候间一个线程都只会有一个方法正在执行，也就是所谓的当前方法。程序计数器存放的就是这个当前方法的JVM指令地址。
JVM虚拟机栈。 建立线程的时候会建立线程内的虚拟机栈，栈中存放着一个个的栈帧，对应着一个个方法的调用。JVM 虚拟机栈有两种操做，分别是压栈和出站。栈帧中存放着局部变量表、方法返回值和方法的正常或异常退出的定义等等。
本地方法栈。 跟 JVM 虚拟机栈比较相似，只不过它支持的是 Native 方法。
堆。堆是内存管理的核心区域，用来存放对象实例。几乎全部建立的对象实例都会直接分配到堆上。因此堆也是垃圾回收的主要区域，垃圾收集器会对堆有着更细的划分，最多见的就是把堆划分为新生代和老年代。
方法区。方法区主要存放类的结构信息，好比静态属性和方法等等。
运行时常量池。运行时常量池位于方法区中，主要存放各类常量信息。

其实除了程序计数器，其余的部分都会发生 OOM。

堆。一般发生的 OOM 都会发生在堆中，最多见的可能致使 OOM 的缘由就是内存泄漏。
JVM虚拟机栈和本地方法栈。 当咱们写一个递归方法，这个递归方法没有循环终止条件，最终会致使 StackOverflow 的错误。固然，若是栈空间扩展失败，也是会发生 OOM 的。
方法区。方法区如今基本上不太会发生 OOM，但在早期内存中加载的类信息过多的状况下也是会发生 OOM 的。

类加载过程

Java 中类加载分为 3 个步骤：加载、连接、初始化。

加载。 加载是将字节码数据从不一样的数据源读取到JVM内存，并映射为 JVM 承认的数据结构，也就是 Class 对象的过程。数据源能够是 Jar 文件、Class 文件等等。若是数据的格式并非 ClassFile 的结构，则会报 ClassFormatError。
连接。 连接是类加载的核心部分，这一步分为 3 个步骤：验证、准备、解析。
- 验证。 验证是保证JVM安全的重要步骤。JVM须要校验字节信息是否符合规范，避免恶意信息和不规范数据危害JVM运行安全。若是验证出错，则会报VerifyError。
- 准备。 这一步会建立静态变量，并为静态变量开辟内存空间。
- 解析。 这一步会将符号引用替换为直接引用。
初始化。 初始化会为静态变量赋值，并执行静态代码块中的逻辑。

双亲委派模型

类加载器大体分为3类：启动类加载器、扩展类加载器、应用程序类加载器。

启动类加载器主要加载 jre/lib下的jar文件。
扩展类加载器主要加载 jre/lib/ext 下的jar文件。
应用程序类加载器主要加载 classpath 下的文件。

所谓的双亲委派模型就是当加载一个类时，会优先使用父类加载器加载，当父类加载器没法加载时才会使用子类加载器去加载。这么作的目的是为了不类的重复加载。

Java 中的集合类

HashMap 的原理

HashMap 的内部能够看作数组+链表的复合结构。数组被分为一个个的桶(bucket)。哈希值决定了键值对在数组中的寻址。具备相同哈希值的键值对会组成链表。须要注意的是当链表长度超过阈值(默认是8)的时候会触发树化，链表会变成树形结构。

把握HashMap的原理须要关注4个方法：hash、put、get、resize。

hash方法。 将 key 的 hashCode 值的高位数据移位到低位进行异或运算。这么作的缘由是有些 key 的 hashCode 值的差别集中在高位，而哈希寻址是忽略容量以上高位的，这种作法能够有效避免哈希冲突。
put 方法。 put 方法主要有如下几个步骤：
- 经过 hash 方法获取 hash 值，根据 hash 值寻址。
- 若是未发生碰撞，直接放到桶中。
- 若是发生碰撞，则以链表形式放在桶后。
- 当链表长度大于阈值后会触发树化，将链表转换为红黑树。
- 若是数组长度达到阈值，会调用 resize 方法扩展容量。
get方法。 get 方法主要有如下几个步骤：
- 经过 hash 方法获取 hash 值，根据 hash 值寻址。
- 若是与寻址到桶的 key 相等，直接返回对应的 value。
- 若是发生冲突，分两种状况。若是是树，则调用 getTreeNode 获取 value；若是是链表则经过循环遍历查找对应的 value。
resize 方法。 resize 作了两件事：
- 将原数组扩展为原来的 2 倍
- 从新计算 index 索引值，将原节点从新放到新的数组中。这一步能够将原先冲突的节点分散到新的桶中。

什么状况下 Java 会产生死锁，如何定位、修复，手写死锁

sleep 和 wait 的区别

sleep 方法是 Thread 类中的静态方法，wait 是 Object 类中的方法
sleep 并不会释放同步锁，而 wait 会释放同步锁
sleep 能够在任何地方使用，而 wait 只能在同步方法或者同步代码块中使用
sleep 中必须传入时间，而 wait 能够传，也能够不传，不传时间的话只有 notify 或者 notifyAll 才能唤醒，传时间的话在时间以后会自动唤醒

join 的用法

join 方法一般是保证线程间顺序调度的一个方法，它是 Thread 类中的方法。比方说在线程 A 中执行线程 B.join()，这时线程 A 会进入等待状态，直到线程 B 执行完毕以后才会唤醒，继续执行A线程中的后续方法。

join 方法能够传时间参数，也能够不传参数，不传参数实际上调用的是 join(0)。它的原理实际上是使用了 wait 方法，join 的原理以下：

public final synchronized void join(long millis)
    throws InterruptedException {
        long base = System.currentTimeMillis();
        long now = 0;

        if (millis < 0) {
            throw new IllegalArgumentException("timeout value is negative");
        }

        if (millis == 0) {
            while (isAlive()) {
                wait(0);
            }
        } else {
            while (isAlive()) {
                long delay = millis - now;
                if (delay <= 0) {
                    break;
                }
                wait(delay);
                now = System.currentTimeMillis() - base;
            }
        }
    }
复制代码

volatile和synchronize的区别

Java中的线程池

线程通讯

Java中的并发集合

Java中生产者与消费者模式

生产者消费者模式要保证的是当缓冲区满的时候生产者再也不生产对象，当缓冲区空时，消费者再也不消费对象。实现机制就是当缓冲区满时让生产者处于等待状态，当缓冲区为空时让消费者处于等待状态。当生产者生产了一个对象后会唤醒消费者，当消费者消费一个对象后会唤醒生产者。

三种种实现方式：wait 和 notify、await 和 signal、BlockingQueue。

wait 和 notify

//wait和notify
import java.util.LinkedList;

public class StorageWithWaitAndNotify {
    private final int                MAX_SIZE = 10;
    private       LinkedList<Object> list     = new LinkedList<Object>();

    public void produce() {
        synchronized (list) {
            while (list.size() == MAX_SIZE) {
                System.out.println("仓库已满：生产暂停");
                try {
                    list.wait();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }

            list.add(new Object());
            System.out.println("生产了一个新产品，现库存为：" + list.size());
            list.notifyAll();
        }
    }

    public void consume() {
        synchronized (list) {
            while (list.size() == 0) {
                System.out.println("库存为0：消费暂停");
                try {
                    list.wait();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }

            list.remove();
            System.out.println("消费了一个产品，现库存为：" + list.size());
            list.notifyAll();
        }
    }


}

复制代码

await 和 signal

import java.util.LinkedList;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;

class StorageWithAwaitAndSignal {
    private final int                MAX_SIZE = 10;
    private       ReentrantLock      mLock    = new ReentrantLock();
    private       Condition          mEmpty   = mLock.newCondition();
    private       Condition          mFull    = mLock.newCondition();
    private       LinkedList<Object> mList    = new LinkedList<Object>();

    public void produce() {
        mLock.lock();
        while (mList.size() == MAX_SIZE) {
            System.out.println("缓冲区满，暂停生产");
            try {
                mFull.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }

        mList.add(new Object());
        System.out.println("生产了一个新产品，现容量为：" + mList.size());
        mEmpty.signalAll();

        mLock.unlock();
    }

    public void consume() {
        mLock.lock();
        while (mList.size() == 0) {
            System.out.println("缓冲区为空，暂停消费");
            try {
                mEmpty.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }

        mList.remove();
        System.out.println("消费了一个产品，现容量为：" + mList.size());
        mFull.signalAll();

        mLock.unlock();
    }
}

复制代码

BlockingQueue

import java.util.concurrent.LinkedBlockingQueue;

public class StorageWithBlockingQueue {
    private final int                         MAX_SIZE = 10;
    private       LinkedBlockingQueue<Object> list     = new LinkedBlockingQueue<Object>(MAX_SIZE);

    public void produce() {
        if (list.size() == MAX_SIZE) {
            System.out.println("缓冲区已满，暂停生产");
        }

        try {
            list.put(new Object());
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println("生产了一个产品，现容量为：" + list.size());
    }

    public void consume() {
        if (list.size() == 0) {
            System.out.println("缓冲区为空，暂停消费");
        }

        try {
            list.take();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println("消费了一个产品，现容量为：" + list.size());
    }

}

复制代码

final、finally、finalize区别

final 能够修饰类、变量和方法。修饰类表明这个类不可被继承。修饰变量表明此变量不可被改变。修饰方法表示此方法不可被重写 (override)。

finally 是保证重点代码必定会执行的一种机制。一般是使用 try-finally 或者 try-catch-finally 来进行文件流的关闭等操做。

finalize 是 Object 类中的一个方法，它的设计目的是保证对象在垃圾收集前完成特定资源的回收。finalize 机制如今已经不推荐使用，而且在 JDK 9已经被标记为 deprecated。

Java 中单例模式

Java 中常见的单例模式实现有这么几种：饿汉式、双重判断的懒汉式、静态内部类实现的单例、枚举实现的单例。这里着重讲一下双重判断的懒汉式和静态内部类实现的单例。

双重判断的懒汉式：

public class SingleTon {
    //须要注意的是volatile
    private static volatile SingleTon mInstance;

    private SingleTon() {

    }

    public static SingleTon getInstance() {
        if (mInstance == null) { 
            synchronized (SingleTon.class) {
                if (mInstance == null) {
                    mInstance=new SingleTon();
                }
            }
        }

        return mInstance;
    }
}
复制代码

双重判断的懒汉式单例既知足了延迟初始化，又知足了线程安全。经过 synchronized 包裹代码来实现线程安全，经过双重判断来提升程序执行的效率。这里须要注意的是单例对象实例须要有 volatile 修饰，若是没有 volatile 修饰，在多线程状况下可能会出现问题。缘由是这样的，mInstance=new SingleTon()这一句代码并非一个原子操做，它包含三个操做：

给 mInstance 分配内存
调用 SingleTon 的构造方法初始化成员变量
将 mInstance 指向分配的内存空间（在这一步 mInstance 已经不为 null 了）

咱们知道 JVM 会发生指令重排，正常的执行顺序是1-2-3，但发生指令重排后可能会致使1-3-2。咱们考虑这样一种状况，当线程 A 执行到1-3-2的3步骤暂停了，这时候线程 B 调用了 getInstance，走到了最外层的if判断上，因为最外层的 if 判断并无 synchronized 包裹，因此能够执行到这一句，这时候因为线程 A 已经执行了步骤3，此时 mInstance 已经不为 null 了，因此线程B直接返回了 mInstance。但其实咱们知道，完整的初始化必须走完这三个步骤，因为线程 A 只走了两个步骤，因此必定会报错的。

解决的办法就是使用 volatile 修饰 mInstance，咱们知道 volatile 有两个做用：保证可见性和禁止指令重排，在这里关键在于禁止指令重排，禁止指令重排后保证了不会发生上述问题。

静态内部类实现的单例：

class SingletonWithInnerClass {

    private SingletonWithInnerClass() {

    }

    private static class SingletonHolder{
        private static SingletonWithInnerClass INSTANCE=new SingletonWithInnerClass();
    }

    public SingletonWithInnerClass getInstance() {
        return SingletonHolder.INSTANCE;
    }

}
复制代码

因为外部类的加载并不会致使内部类当即加载，只有当调用 getInstance 的时候才会加载内部类，因此实现了延迟初始化。因为类只会被加载一次，而且类加载也是线程安全的，因此知足咱们全部的需求。静态内部类实现的单例也是最为推荐的一种方式。

Java中引用类型的区别，具体的使用场景

Java中引用类型分为四类：强引用、软引用、弱引用、虚引用。

强引用： 强引用指的是经过 new 对象建立的引用，垃圾回收器即便是内存不足也不会回收强引用指向的对象。
软引用： 软引用是经过 SoftRefrence 实现的，它的生命周期比强引用短，在内存不足，抛出 OOM 以前，垃圾回收器会回收软引用引用的对象。软引用常见的使用场景是存储一些内存敏感的缓存，当内存不足时会被回收。
弱引用： 弱引用是经过 WeakRefrence 实现的，它的生命周期比软引用还短，GC 只要扫描到弱引用的对象就会回收。弱引用常见的使用场景也是存储一些内存敏感的缓存。
虚引用： 虚引用是经过 FanttomRefrence 实现的，它的生命周期最短，随时可能被回收。若是一个对象只被虚引用引用，咱们没法经过虚引用来访问这个对象的任何属性和方法。它的做用仅仅是保证对象在 finalize 后，作某些事情。虚引用常见的使用场景是跟踪对象被垃圾回收的活动，当一个虚引用关联的对象被垃圾回收器回收以前会收到一条系统通知。

Exception 和 Error的区别

Exception 和 Error 都继承于 Throwable，在 Java 中，只有 Throwable 类型的对象才能被 throw 或者 catch，它是异常处理机制的基本组成类型。

Exception 和 Error 体现了 Java 对不一样异常状况的分类。Exception 是程序正常运行中，能够预料的意外状况，可能而且应该被捕获，进行相应的处理。

Error 是指在正常状况下，不大可能出现的状况，绝大部分 Error 都会使程序处于非正常、不可恢复的状态。既然是非正常，因此不便于也不须要捕获，常见的 OutOfMemoryError 就是 Error 的子类。

Exception 又分为 checked Exception 和 unchecked Exception。

checked Exception 在代码里必须显式的进行捕获，这是编译器检查的一部分。
unchecked Exception 也就是运行时异常，相似空指针异常、数组越界等，一般是能够避免的逻辑错误，具体根据需求来判断是否须要捕获，并不会在编译器强制要求。

volatile

通常提到 volatile，就不得不提到内存模型相关的概念。咱们都知道，在程序运行中，每条指令都是由 CPU 执行的，而指令的执行过程当中，势必涉及到数据的读取和写入。程序运行中的数据都存放在主存中，这样会有一个问题，因为 CPU 的执行速度是要远高于主存的读写速度，因此直接从主存中读写数据会下降 CPU 的效率。为了解决这个问题，就有了高速缓存的概念，在每一个 CPU 中都有高速缓存，它会事先从主存中读取数据，在 CPU 运算以后在合适的时候刷新到主存中。

这样的运行模式在单线程中是没有任何问题的，但在多线程中，会致使缓存一致性的问题。举个简单的例子：i=i+1 ,在两个线程中执行这句代码，假设i的初始值为0。咱们指望两个线程运行后获得2，那么有这样的一种状况，两个线程都从主存中读取i到各自的高速缓存中，这时候两个线程中的i都为0。在线程1执行完毕获得i=1，将之刷新到主存后，线程2开始执行，因为线程2中的i是高速缓存中的0，因此在执行完线程2以后刷新到主存的i仍旧是1。

因此这就致使了对共享变量的缓存一致性的问题，那么为了解决这个问题，提出了缓存一致性协议：当 CPU 在写数据时，若是发现操做的是共享变量，它会通知其余 CPU 将它们内部的这个共享变量置为无效状态，当其余 CPU 读取缓存中的共享变量时，发现这个变量是无效的，它会重新从主存中读取最新的值。

在Java的多线程开发中，有三个重要概念：原子性、可见性、有序性。

**原子性：**一个或多个操做要么都不执行，要么都执行。
可见性： 一个线程中对共享变量(类中的成员变量或静态变量)的修改，在其余线程当即可见。
有序性： 程序执行的顺序按照代码的顺序执行。把一个变量声明为volatile，其实就是保证了可见性和有序性。可见性我上面已经说过了，在多线程开发中是颇有必要的。这个有序性仍是得说一下，为了执行的效率，有时候会发生指令重排，这在单线程中指令重排以后的输出与咱们的代码逻辑输出仍是一致的。但在多线程中就可能发生问题，volatile在必定程度上能够避免指令重排。

volatile的原理是在生成的汇编代码中多了一个lock前缀指令，这个前缀指令至关于一个内存屏障，这个内存屏障有3个做用：

确保指令重排的时候不会把屏障后的指令排在屏障前，确保不会把屏障前的指令排在屏障后。
修改缓存中的共享变量后当即刷新到主存中。
当执行写操做时会致使其余CPU中的缓存无效。

网络相关面试题

http 状态码

http 与 https 的区别？https 是如何工做的？

http 是超文本传输协议，而 https 能够简单理解为安全的 http 协议。https 经过在 http 协议下添加了一层 ssl 协议对数据进行加密从而保证了安全。https 的做用主要有两点：创建安全的信息传输通道，保证数据传输安全；确认网站的真实性。

http 与 https 的区别主要以下：

https 须要到 CA 申请证书，不多免费，于是须要必定的费用
http 是明文传输，安全性低；而 https 在 http 的基础上经过 ssl 加密，安全性高
两者的默认端口不同，http 使用的默认端口是80；https使用的默认端口是 443

https 的工做流程

提到 https 的话首先要说到加密算法，加密算法分为两类：对称加密和非对称加密。

对称加密： 加密和解密用的都是相同的秘钥，优势是速度快，缺点是安全性低。常见的对称加密算法有 DES、AES 等等。
非对称加密： 非对称加密有一个秘钥对，分为公钥和私钥。通常来讲，私钥本身持有，公钥能够公开给对方，优势是安全性比对称加密高，缺点是数据传输效率比对称加密低。采用公钥加密的信息只有对应的私钥能够解密。常见的非对称加密包括RSA等。

在正式的使用场景中通常都是对称加密和非对称加密结合使用，使用非对称加密完成秘钥的传递，而后使用对称秘钥进行数据加密和解密。两者结合既保证了安全性，又提升了数据传输效率。

https 的具体流程以下：

客户端（一般是浏览器）先向服务器发出加密通讯的请求
- 支持的协议版本，好比 TLS 1.0版
- 一个客户端生成的随机数 random1，稍后用于生成"对话密钥"
- 支持的加密方法，好比 RSA 公钥加密
- 支持的压缩方法
服务器收到请求,而后响应
- 确认使用的加密通讯协议版本，好比 TLS 1.0版本。若是浏览器与服务器支持的版本不一致，服务器关闭加密通讯
- 一个服务器生成的随机数 random2，稍后用于生成"对话密钥"
- 确认使用的加密方法，好比 RSA 公钥加密
- 服务器证书
客户端收到证书以后会首先会进行验证
- 首先验证证书的安全性
- 验证经过以后，客户端会生成一个随机数 pre-master secret，而后使用证书中的公钥进行加密，而后传递给服务器端
服务器收到使用公钥加密的内容，在服务器端使用私钥解密以后得到随机数 pre-master secret，而后根据 radom一、radom二、pre-master secret 经过必定的算法得出一个对称加密的秘钥，做为后面交互过程当中使用对称秘钥。同时客户端也会使用 radom一、radom二、pre-master secret，和一样的算法生成对称秘钥。
而后再后续的交互中就使用上一步生成的对称秘钥对传输的内容进行加密和解密。

TCP三次握手流程

Android面试题

进程间通讯的方式有哪几种

AIDL 、广播、文件、socket、管道

广播静态注册和动态注册的区别

动态注册广播不是常驻型广播，也就是说广播跟随 Activity 的生命周期。注意在 Activity 结束前，移除广播接收器。静态注册是常驻型，也就是说当应用程序关闭后，若是有信息广播来，程序也会被系统调用自动运行。
当广播为有序广播时：优先级高的先接收（不分静态和动态）。同优先级的广播接收器，动态优先于静态
同优先级的同类广播接收器，静态：先扫描的优先于后扫描的，动态：先注册的优先于后注册的。
当广播为默认广播时：无视优先级，动态广播接收器优先于静态广播接收器。同优先级的同类广播接收器，静态：先扫描的优先于后扫描的，动态：先注册的优先于后册的。

Android 性能优化工具使用（这个问题建议配合Android中的性能优化）

Android 中经常使用的性能优化工具包括这些：Android Studio 自带的 Android Profiler、LeakCanary、BlockCanary

Android 自带的 Android Profiler 其实就很好用，Android Profiler 能够检测三个方面的性能问题：CPU、MEMORY、NETWORK。

LeakCanary 是一个第三方的检测内存泄漏的库，咱们的项目集成以后 LeakCanary 会自动检测应用运行期间的内存泄漏，并将之输出给咱们。

BlockCanary 也是一个第三方检测UI卡顿的库，项目集成后Block也会自动检测应用运行期间的UI卡顿，并将之输出给咱们。

Android中的类加载器

PathClassLoader，只能加载系统中已经安装过的 apk
DexClassLoader，能够加载 jar/apk/dex，能够从 SD卡中加载未安装的 apk

Android中的动画有哪几类，它们的特色和区别是什么

Android中动画大体分为3类：帧动画、补间动画（View Animation）、属性动画（Object Animation）。

帧动画：经过xml配置一组图片，动态播放。不多会使用。
补间动画（View Animation）：大体分为旋转、透明、缩放、位移四类操做。不多会使用。
属性动画（Object Animation）：属性动画是如今使用的最多的一种动画，它比补间动画更增强大。属性动画大体分为两种使用类型，分别是 ViewPropertyAnimator 和 ObjectAnimator。前者适合一些通用的动画，好比旋转、位移、缩放和透明，使用方式也很简单经过 View.animate() 便可获得 ViewPropertyAnimator，以后进行相应的动画操做便可。后者适合用于为咱们的自定义控件添加动画，固然首先咱们应该在自定义 View 中添加相应的 getXXX() 和 setXXX() 相应属性的 getter 和 setter 方法，这里须要注意的是在 setter 方法内改变了自定义 View 中的属性后要调用 invalidate() 来刷新View的绘制。以后调用 ObjectAnimator.of 属性类型()返回一个 ObjectAnimator，调用 start() 方法启动动画便可。

补间动画与属性动画的区别：

补间动画是父容器不断的绘制 view，看起来像移动了效果,其实 view 没有变化，还在原地。
是经过不断改变 view 内部的属性值，真正的改变 view。

Handler 机制

说到 Handler，就不得不提与之密切相关的这几个类：Message、MessageQueue，Looper。

Message。 Message 中有两个成员变量值得关注：target 和 callback。
- target 其实就是发送消息的 Handler 对象
- callback 是当调用 handler.post(runnable) 时传入的 Runnable 类型的任务。post 事件的本质也是建立了一个 Message，将咱们传入的这个 runnable 赋值给建立的Message的 callback 这个成员变量。
MessageQueue。 消息队列很明显是存放消息的队列，值得关注的是 MessageQueue 中的 next() 方法，它会返回下一个待处理的消息。
Looper。 Looper 消息轮询器实际上是链接 Handler 和消息队列的核心。首先咱们都知道，若是想要在一个线程中建立一个 Handler，首先要经过 Looper.prepare() 建立 Looper，以后还得调用 Looper.loop()开启轮询。咱们着重看一下这两个方法。
- prepare()。 这个方法作了两件事：首先经过ThreadLocal.get()获取当前线程中的Looper,若是不为空，则会抛出一个RunTimeException，意思是一个线程不能建立2个Looper。若是为null则执行下一步。第二步是建立了一个Looper，并经过 ThreadLocal.set(looper)。将咱们建立的Looper与当前线程绑定。这里须要提一下的是消息队列的建立其实就发生在Looper的构造方法中。
- loop()。 这个方法开启了整个事件机制的轮询。它的本质是开启了一个死循环，不断的经过 MessageQueue的next()方法获取消息。拿到消息后会调用 msg.target.dispatchMessage()来作处理。其实咱们在说到 Message 的时候提到过，msg.target 其实就是发送这个消息的 handler。这句代码的本质就是调用 handler的dispatchMessage()。
Handler。 上面作了这么多铺垫，终于到了最重要的部分。Handler 的分析着重在两个部分：发送消息和处理消息。

*发送消息。其实发送消息除了 sendMessage 以外还有 sendMessageDelayed 和 post 以及 postDelayed 等等不一样的方式。但它们的本质都是调用了 sendMessageAtTime。在 sendMessageAtTime 这个方法中调用了 enqueueMessage。在 enqueueMessage 这个方法中作了两件事：经过 msg.target = this 实现了消息与当前 handler 的绑定。而后经过 queue.enqueueMessage 实现了消息入队。
- 处理消息。 消息处理的核心其实就是dispatchMessage()这个方法。这个方法里面的逻辑很简单，先判断 msg.callback 是否为 null，若是不为空则执行这个 runnable。若是为空则会执行咱们的handleMessage方法。

Android 性能优化

Android 中的性能优化在我看来分为如下几个方面：内存优化、布局优化、网络优化、安装包优化。

内存优化： 下一个问题就是。
布局优化： 布局优化的本质就是减小 View 的层级。常见的布局优化方案以下
- 在 LinearLayout 和 RelativeLayout 均可以完成布局的状况下优先选择 RelativeLayout，能够减小 View 的层级
- 将经常使用的布局组件抽取出来使用 \< include \>标签
- 经过 \< ViewStub \>标签来加载不经常使用的布局
- 使用 \< Merge \>标签来减小布局的嵌套层次
网络优化： 常见的网络优化方案以下
- 尽可能减小网络请求，可以合并的就尽可能合并
- 避免 DNS 解析，根据域名查询可能会耗费上百毫秒的时间，也可能存在DNS劫持的风险。能够根据业务需求采用增长动态更新 IP 的方式，或者在 IP 方式访问失败时切换到域名访问方式。
- 大量数据的加载采用分页的方式
- 网络数据传输采用 GZIP 压缩
- 加入网络数据的缓存，避免频繁请求网络
- 上传图片时，在必要的时候压缩图片
安装包优化： 安装包优化的核心就是减小 apk 的体积，常见的方案以下
- 使用混淆，能够在必定程度上减小 apk 体积，但实际效果微乎其微
- 减小应用中没必要要的资源文件，好比图片，在不影响 APP 效果的状况下尽可能压缩图片，有必定的效果
- 在使用了 SO 库的时候优先保留 v7 版本的 SO 库，删掉其余版本的SO库。缘由是在 2018 年，v7 版本的 SO 库能够知足市面上绝大多数的要求，可能八九年前的手机知足不了，但咱们也不必去适配老掉牙的手机。实际开发中减小 apk 体积的效果是十分显著的，若是你使用了不少 SO 库，比方说一个版本的SO库一共 10M，那么只保留 v7 版本，删掉 armeabi 和 v8 版本的 SO 库，一共能够减小 20M 的体积。

Android 内存优化

Android的内存优化在我看来分为两点：避免内存泄漏、扩大内存，其实就是开源节流。

其实内存泄漏的本质就是较长生命周期的对象引用了较短生命周期的对象。

常见的内存泄漏

单例模式致使的内存泄漏。 最多见的例子就是建立这个单例对象须要传入一个 Context，这时候传入了一个 Activity 类型的 Context，因为单例对象的静态属性，致使它的生命周期是从单例类加载到应用程序结束为止，因此即便已经 finish 掉了传入的 Activity，因为咱们的单例对象依然持有 Activity 的引用，因此致使了内存泄漏。解决办法也很简单，不要使用 Activity 类型的 Context，使用 Application 类型的 Context 能够避免内存泄漏。
静态变量致使的内存泄漏。 静态变量是放在方法区中的，它的生命周期是从类加载到程序结束，能够看到静态变量生命周期是很是久的。最多见的因静态变量致使内存泄漏的例子是咱们在 Activity 中建立了一个静态变量，而这个静态变量的建立须要传入 Activity 的引用 this。在这种状况下即便 Activity 调用了 finish 也会致使内存泄漏。缘由就是由于这个静态变量的生命周期几乎和整个应用程序的生命周期一致，它一直持有 Activity 的引用，从而致使了内存泄漏。
**非静态内部类致使的内存泄漏。**非静态内部类致使内存泄漏的缘由是非静态内部类持有外部类的引用，最多见的例子就是在 Activity 中使用 Handler 和 Thread 了。使用非静态内部类建立的 Handler 和 Thread 在执行延时操做的时候会一直持有当前Activity的引用，若是在执行延时操做的时候就结束 Activity，这样就会致使内存泄漏。解决办法有两种：第一种是使用静态内部类，在静态内部类中使用弱引用调用Activity。第二种方法是在 Activity 的 onDestroy 中调用 handler.removeCallbacksAndMessages 来取消延时事件。
使用资源未及时关闭致使的内存泄漏。常见的例子有：操做各类数据流未及时关闭，操做 Bitmap 未及时 recycle 等等。
使用第三方库未能及时解绑。有的三方库提供了注册和解绑的功能，最多见的就 EventBus 了，咱们都知道使用 EventBus 要在 onCreate 中注册，在 onDestroy 中解绑。若是没有解绑的话，EventBus 实际上是一个单例模式，他会一直持有 Activity 的引用，致使内存泄漏。一样常见的还有 RxJava，在使用 Timer 操做符作了一些延时操做后也要注意在 onDestroy 方法中调用 disposable.dispose()来取消操做。
属性动画致使的内存泄漏。常见的例子就是在属性动画执行的过程当中退出了 Activity，这时 View 对象依然持有 Activity 的引用从而致使了内存泄漏。解决办法就是在 onDestroy 中调用动画的 cancel 方法取消属性动画。
WebView 致使的内存泄漏。WebView 比较特殊，即便是调用了它的 destroy 方法，依然会致使内存泄漏。其实避免WebView致使内存泄漏的最好方法就是让WebView所在的Activity处于另外一个进程中，当这个 Activity 结束时杀死当前 WebView 所处的进程便可，我记得阿里钉钉的 WebView 就是另外开启的一个进程，应该也是采用这种方法避免内存泄漏。

扩大内存

为何要扩大咱们的内存呢？有时候咱们实际开发中不可避免的要使用不少第三方商业的 SDK，这些 SDK 其实有好有坏，大厂的 SDK 可能内存泄漏会少一些，但一些小厂的 SDK 质量也就不太靠谱一些。那应对这种咱们没法改变的状况，最好的办法就是扩大内存。

扩大内存一般有两种方法：一个是在清单文件中的 Application 下添加largeHeap="true"这个属性，另外一个就是同一个应用开启多个进程来扩大一个应用的总内存空间。第二种方法其实就很常见了，比方说我使用过个推的 S DK，个推的 Service 其实就是处在另一个单独的进程中。

Android 中的内存优化总的来讲就是开源和节流，开源就是扩大内存，节流就是避免内存泄漏。

Binder 机制

在Linux中，为了不一个进程对其余进程的干扰，进程之间是相互独立的。在一个进程中其实还分为用户空间和内核空间。这里的隔离分为两个部分，进程间的隔离和进程内的隔离。

既然进程间存在隔离，那其实也是存在着交互。进程间通讯就是 IPC，用户空间和内核空间的通讯就是系统调用。

Linux 为了保证独立性和安全性，进程之间不能直接相互访问，Android 是基于 Linux 的，因此也是须要解决进程间通讯的问题。

其实 Linux 进程间通讯有不少方式，好比管道、socket 等等。为何 Android 进程间通讯采用了Binder而不是 Linux

已有的方式，主要是有这么两点考虑：性能和安全

性能。 在移动设备上对性能要求是比较严苛的。Linux传统的进程间通讯好比管道、socket等等进程间通讯是须要复制两次数据，而Binder则只须要一次。因此Binder在性能上是优于传统进程通讯的。
安全。 传统的 Linux 进程通讯是不包含通讯双方的身份验证的，这样会致使一些安全性问题。而Binder机制自带身份验证，从而有效的提升了安全性。

Binder 是基于 CS 架构的，有四个主要组成部分。

Client。 客户端进程。
Server。 服务端进程。
ServiceManager。 提供注册、查询和返回代理服务对象的功能。
Binder 驱动。 主要负责创建进程间的 Binder 链接，进程间的数据交互等等底层操做。

Binder 机制主要的流程是这样的：

服务端经过Binder驱动在 ServiceManager 中注册咱们的服务。
客户端经过Binder驱动查询在 ServiceManager 中注册的服务。
ServiceManager 经过 inder 驱动返回服务端的代理对象。
客户端拿到服务端的代理对象后便可进行进程间通讯。

LruCache的原理

LruCache 的核心原理就是对 LinkedHashMap 的有效利用，它的内部存在一个 LinkedHashMap 成员变量。值得咱们关注的有四个方法：构造方法、get、put、trimToSize。

构造方法： 在 LruCache 的构造方法中作了两件事，设置了 maxSize、建立了一个 LinkedHashMap。这里值得注意的是 LruCache 将 LinkedHashMap的accessOrder 设置为了 true，accessOrder 就是遍历这个LinkedHashMap 的输出顺序。true 表明按照访问顺序输出，false表明按添加顺序输出，由于一般都是按照添加顺序输出，因此 accessOrder 这个属性默认是 false，但咱们的 LruCache 须要按访问顺序输出，因此显式的将 accessOrder 设置为 true。
get方法： 本质上是调用 LinkedHashMap 的 get 方法，因为咱们将 accessOrder 设置为了 true，因此每调用一次get方法，就会将咱们访问的当前元素放置到这个LinkedHashMap的尾部。
put方法： 本质上也是调用了 LinkedHashMap 的 put 方法，因为 LinkedHashMap 的特性，每调用一次 put 方法，也会将新加入的元素放置到 LinkedHashMap 的尾部。添加以后会调用 trimToSize 方法来保证添加后的内存不超过 maxSize。
trimToSize方法： trimToSize 方法的内部实际上是开启了一个 while(true)的死循环，不断的从 LinkedHashMap 的首部删除元素，直到删除以后的内存小于 maxSize 以后使用 break 跳出循环。

其实到这里咱们能够总结一下，为何这个算法叫 最近最少使用 算法呢？原理很简单，咱们的每次 put 或者get均可以看作一次访问，因为 LinkedHashMap 的特性，会将每次访问到的元素放置到尾部。当咱们的内存达到阈值后，会触发 trimToSize 方法来删除 LinkedHashMap 首部的元素，直到当前内存小于 maxSize。为何删除首部的元素，缘由很明显：咱们最近常常访问的元素都会放置到尾部，那首部的元素确定就是 最近最少使用 的元素了，所以当内存不足时应当优先删除这些元素。

DiskLruCache原理

设计一个图片的异步加载框架

设计一个图片加载框架，确定要用到图片加载的三级缓存的思想。三级缓存分为内存缓存、本地缓存和网络缓存。

内存缓存：将Bitmap缓存到内存中，运行速度快，可是内存容量小。本地缓存：将图片缓存到文件中，速度较慢，但容量较大。网络缓存：从网络获取图片，速度受网络影响。

若是咱们设计一个图片加载框架，流程必定是这样的：

拿到图片url后首先从内存中查找BItmap，若是找到直接加载。
内存中没有找到，会从本地缓存中查找，若是本地缓存能够找到，则直接加载。
内存和本地都没有找到，这时会从网络下载图片，下载到后会加载图片，而且将下载到的图片放到内存缓存和本地缓存中。

上面是一些基本的概念，若是是具体的代码实现的话，大概须要这么几个方面的文件：

首先须要肯定咱们的内存缓存，这里通常用的都是 LruCache。
肯定本地缓存，一般用的是 DiskLruCache，这里须要注意的是图片缓存的文件名通常是 url 被 MD5 加密后的字符串，为了不文件名直接暴露图片的 url。
内存缓存和本地缓存肯定以后，须要咱们建立一个新的类 MemeryAndDiskCache，固然，名字随便起，这个类包含了以前提到的 LruCache 和 DiskLruCache。在 MemeryAndDiskCache 这个类中咱们定义两个方法，一个是 getBitmap，另外一个是 putBitmap，对应着图片的获取和缓存，内部的逻辑也很简单。getBitmap中按内存、本地的优先级去取 BItmap，putBitmap 中先缓存内存，以后缓存到本地。
在缓存策略类肯定好以后，咱们建立一个 ImageLoader 类，这个类必须包含两个方法，一个是展现图片 displayImage(url,imageView)，另外一个是从网络获取图片downloadImage(url,imageView)。在展现图片方法中首先要经过 ImageView.setTag(url)，将 url 和 imageView 进行绑定，这是为了不在列表中加载网络图片时会因为ImageView的复用致使的图片错位的 bug。以后会从 MemeryAndDiskCache 中获取缓存，若是存在，直接加载；若是不存在，则调用从网络获取图片这个方法。从网络获取图片方法不少，这里我通常都会使用 OkHttp+Retrofit。当从网络中获取到图片以后，首先判断一下imageView.getTag()与图片的 url 是否一致，若是一致则加载图片，若是不一致则不加载图片，经过这样的方式避免了列表中异步加载图片的错位。同时在获取到图片以后会经过 MemeryAndDiskCache 来缓存图片。

Android中的事件分发机制

在咱们的手指触摸到屏幕的时候，事件实际上是经过 Activity -> ViewGroup -> View 这样的流程到达最后响应咱们触摸事件的 View。

说到事件分发，必不可少的是这几个方法：dispatchTouchEvent()、onInterceptTouchEvent()、onTouchEvent。接下来就按照Activity -> ViewGroup -> View 的流程来大体说一下事件分发机制。

咱们的手指触摸到屏幕的时候，会触发一个 Action_Down 类型的事件，当前页面的 Activity 会首先作出响应，也就是说会走到 Activity 的 dispatchTouchEvent() 方法内。在这个方法内部简单来讲是这么一个逻辑：

调用 getWindow.superDispatchTouchEvent()。
若是上一步返回 true，直接返回 true；不然就 return 本身的 onTouchEvent()。 这个逻辑很好理解，getWindow().superDispatchTouchEvent() 若是返回 true 表明当前事件已经被处理，无需调用本身的 onTouchEvent；不然表明事件并无被处理，须要 Activity 本身处理，也就是调用本身的 onTouchEvent。

getWindow()方法返回了一个 Window 类型的对象，这个咱们都知道，在 Android 中，PhoneWindow 是Window 的惟一实现类。因此这句本质上是调用了``PhoneWindow中的superDispatchTouchEvent()。`

而在 PhoneWindow 的这个方法中实际调用了mDecor.superDispatchTouchEvent(event)。这个 mDecor 就是 DecorView，它是 FrameLayout 的一个子类，在 DecorView 中的 superDispatchTouchEvent() 中调用的是 super.dispatchTouchEvent()。到这里就很明显了，DecorView 是一个 FrameLayout 的子类，FrameLayout 是一个 ViewGroup 的子类，本质上调用的仍是 ViewGroup的dispatchTouchEvent()。

分析到这里，咱们的事件已经从 Activity 传递到了 ViewGroup，接下来咱们来分析下 ViewGroup 中的这几个事件处理方法。

在 ViewGroup 中的 dispatchTouchEvent()中的逻辑大体以下：

经过 onInterceptTouchEvent() 判断当前 ViewGroup 是否拦截事件，默认的 ViewGroup 都是不拦截的；
若是拦截，则 return 本身的 onTouchEvent()；
若是不拦截，则根据 child.dispatchTouchEvent()的返回值判断。若是返回 true，则 return true；不然 return 本身的 onTouchEvent()，在这里实现了未处理事件的向上传递。

一般状况下 ViewGroup 的 onInterceptTouchEvent()都返回 false，也就是不拦截。这里须要注意的是事件序列，好比 Down 事件、Move 事件......Up事件，从 Down 到 Up 是一个完整的事件序列，对应着手指从按下到抬起这一系列的事件，若是 ViewGroup 拦截了 Down 事件，那么后续事件都会交给这个 ViewGroup的onTouchEvent。若是 ViewGroup 拦截的不是 Down 事件，那么会给以前处理这个 Down 事件的 View 发送一个 Action_Cancel 类型的事件，通知子 View 这个后续的事件序列已经被 ViewGroup 接管了，子 View 恢复以前的状态便可。

这里举一个常见的例子：在一个 Recyclerview 钟有不少的 Button，咱们首先按下了一个 button，而后滑动一段距离再松开，这时候 Recyclerview 会跟着滑动，并不会触发这个 button 的点击事件。这个例子中，当咱们按下 button 时，这个 button 接收到了 Action_Down 事件，正常状况下后续的事件序列应该由这个 button处理。但咱们滑动了一段距离，这时 Recyclerview 察觉到这是一个滑动操做，拦截了这个事件序列，走了自身的 onTouchEvent()方法，反映在屏幕上就是列表的滑动。而这时 button 仍然处于按下的状态，因此在拦截的时候须要发送一个 Action_Cancel 来通知 button 恢复以前状态。

事件分发最终会走到 View 的 dispatchTouchEvent()中。在 View 的 dispatchTouchEvent() 中没有 onInterceptTouchEvent()，这也很容易理解，View 不是 ViewGroup，不会包含其余子 View，因此也不存在拦截不拦截这一说。忽略一些细节，View 的 dispatchTouchEvent()中直接 return 了本身的 onTouchEvent()。若是 onTouchEvent()返回 true 表明事件被处理，不然未处理的事件会向上传递，直到有 View 处理了事件或者一直没有处理，最终到达了 Activity 的 onTouchEvent() 终止。

这里常常有人问 onTouch 和 onTouchEvent 的区别。首先，这两个方法都在 View 的 dispatchTouchEvent()中，是这么一个逻辑：

若是 touchListener 不为 null，而且这个 View 是 enable 的，并且 onTouch 返回的是 true，知足这三个条件时会直接 return true，不会走 onTouchEvent()方法。
上面只要有一个条件不知足，就会走到 onTouchEvent()方法中。因此 onTouch 的顺序是在 onTouchEvent 以前的。

View的绘制流程

视图绘制的起点在 ViewRootImpl 类的 performTraversals()方法，在这个方法内实际上是按照顺序依次调用了 mView.measure()、mView.layout()、mView.draw()

View的绘制流程分为3步：测量、布局、绘制，分别对应3个方法 measure、layout、draw。

测量阶段。 measure 方法会被父 View 调用，在measure 方法中作一些优化和准备工做后会调用 onMeasure 方法进行实际的自我测量。onMeasure方法在View和ViewGroup作的事情是不同的：
- View。 View 中的 onMeasure 方法会计算本身的尺寸并经过 setMeasureDimension 保存。
- ViewGroup。 ViewGroup 中的 onMeasure 方法会调用全部子 iew的measure 方法进行自我测量并保存。而后经过子View的尺寸和位置计算出本身的尺寸并保存。
布局阶段。 layout 方法会被父View调用，layout 方法会保存父 View 传进来的尺寸和位置，并调用 onLayout 进行实际的内部布局。onLayout 在 View 和 ViewGroup 中作的事情也是不同的：
- View。 由于 View 是没有子 View 的，因此View的onLayout里面什么都不作。
- ViewGroup。 ViewGroup 中的 onLayout 方法会调用全部子 View 的 layout 方法，把尺寸和位置传给他们，让他们完成自个人内部布局。
绘制阶段。 draw 方法会作一些调度工做，而后会调用 onDraw 方法进行 View 的自我绘制。draw 方法的调度流程大体是这样的：
- **绘制背景。**对应 drawBackground(Canvas)方法。
- **绘制主体。**对应 onDraw(Canvas)方法。
- 绘制子View。 对应 dispatchDraw(Canvas)方法。
- 绘制滑动相关和前景。 对应 onDrawForeground(Canvas)。

Android 源码中常见的设计模式以及本身在开发中经常使用的设计模式

Android与 js 是如何交互的

在 Android 中，Android 与js 的交互分为两个方面：Android 调用 js 里的方法、js 调用 Android 中的方法。

Android调js。 Android 调 js 有两种方法：
- WebView.loadUrl("javascript:js中的方法名")。 这种方法的优势是很简洁，缺点是没有返回值，若是须要拿到js方法的返回值则须要js调用Android中的方法来拿到这个返回值。
- WebView.evaluateJavaScript("javascript:js中的方法名",ValueCallback)。 这种方法比 loadUrl 好的是能够经过 ValueCallback 这个回调拿到 js方法的返回值。缺点是这个方法 Android4.4 才有，兼容性较差。不过放在 2018 年来讲，市面上绝大多数 App 都要求最低版本是 4.4 了，因此我认为这个兼容性问题不大。
js 调 Android。 js 调 Android有三种方法：
- WebView.addJavascriptInterface()。 这是官方解决 js 调用 Android 方法的方案，须要注意的是要在供 js 调用的 Android 方法上加上 @JavascriptInterface 注解，以免安全漏洞。这种方案的缺点是 Android4.2 之前会有安全漏洞，不过在 4.2 之后已经修复了。一样，在 2018 年来讲，兼容性问题不大。
- 重写 WebViewClient的shouldOverrideUrlLoading()方法来拦截url， 拿到 url 后进行解析，若是符合双方的规定，便可调用 Android 方法。优势是避免了 Android4.2 之前的安全漏洞，缺点也很明显，没法直接拿到调用 Android 方法的返回值，只能经过 Android 调用 js 方法来获取返回值。
重写 WebChromClient 的 onJsPrompt() 方法，同前一个方式同样，拿到 url 以后先进行解析，若是符合双方规定，便可调用Android方法。最后若是须要返回值，经过 result.confirm("Android方法返回值") 便可将 Android 的返回值返回给 js。方法的优势是没有漏洞，也没有兼容性限制，同时还能够方便的获取 Android 方法的返回值。其实这里须要注意的是在 WebChromeClient 中除了 onJsPrompt 以外还有 onJsAlert 和 onJsConfirm 方法。那么为何不选择另两个方法呢？缘由在于 onJsAlert 是没有返回值的，而 onJsConfirm 只有 true 和 false 两个返回值，同时在前端开发中 prompt 方法基本不会被调用，因此才会采用 onJsPrompt。

热修复原理

Activity 启动过程

SparseArray 原理

SparseArray，一般来说是 Android 中用来替代 HashMap 的一个数据结构。准确来说，是用来替换key为 Integer 类型，value为Object 类型的HashMap。须要注意的是 SparseArray 仅仅实现了 Cloneable 接口，因此不能用Map来声明。从内部结构来说，SparseArray 内部由两个数组组成，一个是 int[]类型的 mKeys，用来存放全部的键；另外一个是 Object[]类型的 mValues，用来存放全部的值。最多见的是拿 SparseArray 跟HashMap 来作对比，因为 SparseArray 内部组成是两个数组，因此占用内存比 HashMap 要小。咱们都知道，增删改查等操做都首先须要找到相应的键值对，而 SparseArray 内部是经过二分查找来寻址的，效率很明显要低于 HashMap 的常数级别的时间复杂度。提到二分查找，这里还须要提一下的是二分查找的前提是数组已是排好序的，没错，SparseArray 中就是按照key进行升序排列的。综合起来来讲，SparseArray 所占空间优于 HashMap，而效率低于 HashMap，是典型的时间换空间，适合较小容量的存储。从源码角度来讲，我认为须要注意的是 SparseArray的remove()、put()和 gc()方法。

remove()。 SparseArray 的 remove() 方法并非直接删除以后再压缩数组，而是将要删除的 value 设置为 DELETE 这个 SparseArray 的静态属性，这个 DELETE 其实就是一个 Object 对象，同时会将 SparseArray 中的 mGarbage 这个属性设置为 true，这个属性是便于在合适的时候调用自身的 gc()方法压缩数组来避免浪费空间。这样能够提升效率，若是未来要添加的key等于删除的key，那么会将要添加的 value 覆盖 DELETE。
gc()。 SparseArray 中的 gc() 方法跟 JVM 的 GC 其实彻底没有任何关系。``gc()` 方法的内部实际上就是一个for循环，将 value 不为 DELETE 的键值对往前移动覆盖value 为DELETE的键值对来实现数组的压缩，同时将 mGarbage 置为 false，避免内存的浪费。
put()。 put 方法是这么一个逻辑，若是经过二分查找在 mKeys 数组中找到了 key，那么直接覆盖 value 便可。若是没有找到，会拿到与数组中与要添加的 key 最接近的 key 索引，若是这个索引对应的 value 为 DELETE，则直接把新的 value 覆盖 DELET 便可，在这里能够避免数组元素的移动，从而提升了效率。若是 value 不为 DELETE，会判断 mGarbage，若是为 true，则会调用 gc()方法压缩数组，以后会找到合适的索引，将索引以后的键值对后移，插入新的键值对，这个过程当中可能会触发数组的扩容。

图片加载如何避免 OOM

咱们知道内存中的 Bitmap 大小的计算公式是：长所占像素 * 宽所占像素 * 每一个像素所占内存。想避免 OOM 有两种方法：等比例缩小长宽、减小每一个像素所占的内存。

等比缩小长宽。咱们知道 Bitmap 的建立是经过 BitmapFactory 的工厂方法，decodeFile()、decodeStream()、decodeByteArray()、decodeResource()。这些方法中都有一个 Options 类型的参数，这个 Options 是 BitmapFactory 的内部类，存储着 BItmap 的一些信息。Options 中有一个属性：inSampleSize。咱们经过修改 inSampleSize 能够缩小图片的长宽，从而减小 BItma p 所占内存。须要注意的是这个 inSampleSize 大小须要是 2 的幂次方，若是小于 1，代码会强制让inSampleSize为1。
减小像素所占内存。Options 中有一个属性 inPreferredConfig，默认是 ARGB_8888，表明每一个像素所占尺寸。咱们能够经过将之修改成 RGB_565 或者 ARGB_4444 来减小一半内存。

大图加载

加载高清大图，好比清明上河图，首先屏幕是显示不下的，并且考虑到内存状况，也不可能一次性所有加载到内存。这时候就须要局部加载了，Android中有一个负责局部加载的类：BitmapRegionDecoder。使用方法很简单，经过BitmapRegionDecoder.newInstance()建立对象，以后调用decodeRegion(Rect rect, BitmapFactory.Options options)便可。第一个参数rect是要显示的区域，第二个参数是BitmapFactory中的内部类Options。

Android三方库的源码分析

OkHttp

OkHttp源码分析

大体是这么一个流程： register：

获取订阅者的 Class 对象
使用反射查找订阅者中的事件处理方法集合
遍历事件处理方法集合，调用 subscribe(subscriber，subscriberMethod) 方法，在 subscribe 方法内：
- 经过 subscriberMethod 获取处理的事件类型 eventType
- 将订阅者 subscriber 和方法 subscriberMethod 绑在一块儿造成一个 Subscription 对象
- 经过 subscriptionsByEventType.get(eventType) 获取 Subscription 集合
  - 若是 Subscription 集合为空则建立一个新的集合，这一步目的是延迟集合的初始化
  - 拿到 Subscription 集合后遍历这个集合，经过比较事件处理的优先级，将新的 Subscription 对象加入合适的位置
- 经过typesBySubscriber.get(subscriber)获取事件类型集合
  - 若是事件类型集合为空则建立一个新的集合，这一步目的是延迟集合的初始化
  - 拿到事件类型集合后将新的事件类型加入到集合中
- 判断当前事件类型是不是 sticky
- 若是当前事件类型不是 sticky（粘性事件），subscribe(subscriber，subscriberMethod)到此终结
- 若是是 sticky，判断 EventBus 中的一个事件继承性的属性，默认是 true
  - 若是事件继承性为 true，遍历这个 Map 类型的 stickEvents，经过 isAssignableFrom 方法判断当前事件是不是遍历事件的父类，若是是则发送事件
  - 若是事件继承性为 false，经过 stickyEvents.get(eventType)获取事件并发送

post：

postSticky
- 将事件加入到 stickyEvents 这个 Map 类型的集合中
- 调用 post 方法
post
- 将事件加入当前线程的事件队列中
- 经过 while 循环不断从事件队列中取出事件并调用 postSingleEvent 方法发送事件
- 在 postSingleEvent 中，判断事件继承性，默认为true
  - 事件继承性为true，找到当前事件全部的父类型并调用 postSingleEventForEventType 方法发送事件
  - 事件继承性为 false，只发送当前事件类型的事件
    - 在 postSingleEventForEventType 中，经过 subscriptionsByEventType.get(eventClass) 获取 Subscription 类型集合
    - 遍历这个集合，调用 postToSubscription 发送事件
      - 在 postToSubscription 中分为四种状况
        
        POSTING，调用 invokeSubscriber(subscription, event) 处理事件，本质是 method.invoke() 反射
        
        MAIN，若是在主线程直接 invokeSubscriber 处理；反之经过 handler 切换到主线程调用 invokeSubscriber 处理事件
        
        BACKGROUND，若是不在主线程直接 invokeSubscriber 处理事件；反之开启一条线程，在线程中调用 invokeSubscriber 处理事件
        
        ASYNC，开启一条线程，在线程中调用 invokeSubscriber 处理事件

unregister：

删除 subscriptionsByEventType 中与订阅者相关的全部 subscription
删除 typesBySubscriber 中与订阅者相关的全部类型

数据结构与算法

手写快排

手写归并排序

手写堆以及堆排序

说一下排序算法的区别(时间复杂度和空间复杂度)

工做中解决了什么难题，作了什么有成就感的项目（这个问题必定会问到，因此确定要作准备）

这个问题欢迎你们加入Android技术开发交流群：653583088 本群提供免费的学习指导以及免费的解答不懂得问题均可以在本群提出来以后还会有职业生涯规划以及面试指导进群修改群备注：开发年限-地区-经验方便解答问题

Android 面试题(附答案)

Android 面试题(附答案)

Java面试题

GC机制

JVM内存区域的划分，哪些区域会发生 OOM

类加载过程

双亲委派模型

Java 中的集合类

HashMap 的原理

什么状况下 Java 会产生死锁，如何定位、修复，手写死锁

sleep 和 wait 的区别

join 的用法

volatile和synchronize的区别

Java中的线程池

线程通讯

Java中的并发集合

Java中生产者与消费者模式

final、finally、finalize区别

Java 中单例模式

Java中引用类型的区别，具体的使用场景

Exception 和 Error的区别

volatile

网络相关面试题

http 状态码

http 与 https 的区别？https 是如何工做的？

TCP三次握手流程

Android面试题

进程间通讯的方式有哪几种

广播静态注册和动态注册的区别

Android 性能优化工具使用（这个问题建议配合Android中的性能优化）

Android中的类加载器

Android中的动画有哪几类，它们的特色和区别是什么

Handler 机制

Android 性能优化

Android 内存优化

Binder 机制

LruCache的原理

DiskLruCache原理

设计一个图片的异步加载框架

Android中的事件分发机制

View的绘制流程

Android 源码中常见的设计模式以及本身在开发中经常使用的设计模式

Android与 js 是如何交互的

热修复原理

Activity 启动过程

SparseArray 原理

图片加载如何避免 OOM

大图加载

Android三方库的源码分析

Retrofit

RxJava

Glide

EventBus

数据结构与算法

手写快排

手写归并排序

手写堆以及堆排序

说一下排序算法的区别(时间复杂度和空间复杂度)