Android面试(附答案)

时间 2019-12-05

原文原文链接

写在开头

因为杭州的房价实在过高，因此我可耻的跑路到了西安。几个月前在西安买了房，因此最近总结了一些还算全面的Android面试题。还好成功的经过了西安努比亚的面试，虽然不是阿里、网易这种级别的公司，但对我一个毕业两年的Android开发来讲，算是成功的从小公司跳到大公司。javascript

Java面试题

GC机制

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

引用计数法

当一个对象被引用时，它的引用计数器会加一，垃圾回收时会清理掉引用计数为0的对象。但这种方法有一个问题，比方说有两个对象A和B，A引用了B，B又引用了A，除此以外没有别的对象引用A和B，那么A和B在咱们看来已是垃圾对象，须要被回收，但它们的引用计数不为0，没有达到回收的条件。正由于这个循环引用的问题，Java并无采用引用计数法。java

可达性分析法

咱们把Java中对象引用的关系看作一张图，从根级对象不可达的对象会被垃圾收集器清除。根级对象通常包括Java虚拟机栈中的对象、本地方法栈中的对象、方法区中的静态对象和常量池中的常量。
回收垃圾的话有这么四种方法：git

标记清除算法

顾名思义分为两步，标记和清除。首先标记到须要回收的垃圾对象，而后回收掉这些垃圾对象。标记清除算法的缺点是清除垃圾对象后会形成内存的碎片化。github

复制算法

复制算法是将存活的对象复制到另外一块内存区域中，并作相应的内存整理工做。复制算法的优势是能够避免内存碎片化，缺点也显而易见，它须要两倍的内存。面试

标记整理算法

标记整理算法也是分两步，先标记后整理。它会标记须要回收的垃圾对象，清除掉垃圾对象后会将存活的对象压缩，避免了内存的碎片化。算法

分代算法

分代算法将对象分为新生代和老年代对象。那么为何作这样的区分呢？主要是在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"这个属性，另外一个就是同一个应用开启多个进程来扩大一个应用的总内存空间。第二种方法其实就很常见了，比方说我使用过个推的SDK，个推的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经过Binder驱动返回服务端的代理对象。
客户端拿到服务端的代理对象后便可进行进程间通讯。

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方法会调用全部子View的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覆盖DELETE便可，在这里能够避免数组元素的移动，从而提升了效率。若是value不为DELETE，会判断mGarbage，若是为true，则会调用gc()方法压缩数组，以后会找到合适的索引，将索引以后的键值对后移，插入新的键值对，这个过程当中可能会触发数组的扩容。

图片加载如何避免OOM

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

等比缩小长宽。咱们知道Bitmap的建立是经过BitmapFactory的工厂方法，decodeFile()、decodeStream()、decodeByteArray()、decodeResource()。这些方法中都有一个Options类型的参数，这个Options是BitmapFactory的内部类，存储着BItmap的一些信息。Options中有一个属性：inSampleSize。咱们经过修改inSampleSize能够缩小图片的长宽，从而减小BItmap所占内存。须要注意的是这个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三方库的源码分析

因为源码分析篇幅太大，因此这里之贴出个人源码分析的连接(掘金)。

大体是这么一个流程：
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中与订阅者相关的全部类型

数据结构与算法

手写快排

手写归并排序

手写堆以及堆排序

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

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

这个问题其实仍是靠平时的积累，对我来讲的话，最有成就感的就是开发了KCommon这个项目，它大大提高了个人开发效率。