1.简述在横竖屏切换的过程中，Activity的生命周期。
答：横竖屏切换的生命周期：

onPause() --> onSaveInstanceState() --> onStop() --> onDestory() --> onCreate() --> onStart() --> onRestoreInstanceState() --> onResume()

在Activity由于异常情况下终止时，系统会调用 onSaveInstanceState 来保存当前 Activity 的状态。这个方法的调用是在onStop之前，它和onPause没有既定的时序关系，该方法只有在Activity被异常终止的情况下调用。当异常终止的Activity被重建之后，系统会调用onRestoreInstanceState，并且把Activity销毁时onSaveInstanceState方法所保存的Bundle对象参数同时传递给onRestoreInstanceState和onCreate方法。因为，可以通过onRestoreInstanceState方法来恢复Activity的状态，该方法的调用时机是在onStart之后。其中，onCreate和onRestoreInstanceState方法来恢复Activity状态的区别：onRestoreInstanceState回调则表明其中Bundle对象非空，不用加非空判断，而onCreate需要非空判断，建议使用onRestoreInstanceState。
可以通过在AndroidManifest文件的Activity中指定如下属性来避免横竖屏切换：android:configChanges = "orientation| screenSize"
2.Activity的Flags
答：可以在启动Activity时，通过Intent.addFlags()方法设置。

• FLAG_ACTIVITY_NEW_TASK 即 singleTask
• FLAG_ACTIVITY_SINGLE_TOP 即 singleTop
• FLAG_ACTIVITY_CLEAR_TOP
  Android四种启动模式
  1.标准模式（standard）：每启动一次Activity，就会创建一个新的Activity实例并置于栈顶。谁启动了这个Activity，那么这个Activity就运行在启动它的那个Activity所在的栈中。 应用场景：一般我们不主动设置启动模式，都是标准模式。
  2.栈顶模式(singleTop)：如果栈顶存在该activity的实例，则复用，不存在新建放入栈顶。 应用场景：（1）点击通知跳详情 （2）新闻详情页，点击推荐新闻条目
  3.栈内模式(singleTask)：如果栈内存在该activity的实例，会将该实例上边的activity全部出栈，将该实例置于栈顶，如果不存在，则创建 应用场景： （1）APP的home页面，如果跳转到其他页面后又要跳回来 （2）浏览器的主页
  4.单例模式(singleInstance):新开一个任务栈，该栈内只存放当前实例 应用场景：项目中语音通话功能，来电话显示页面采用的就是singleinstance模式
  如何设置： 清单文件中，activity节点下lauchmode属性 如果使用了栈顶或栈内模式，通过onNewIntent回调中的Intent参数来接收传递的内容

3.一个应用程序有几个Context？
在应用程序中Context的具体实现子类就是：Activity、Service和Application。那么Context数量=Activity数量+Service数量+1。那么为什么四大组件中只有Activity和Service继承Context呢？BroadcastReceiver和ContextPrivider并不是Context的子类，它们所持有的Context都是其他地方传过去的，所以并不计入Context总数。
4.SparseArray实现原理
SparseArray可以翻译为稀疏数组，从字面上可以理解为松散不连续的数组。虽然叫做Array，但它却是存储K-V的一种数据结构。其中Key只能是int类型，而Value是Object类型。

public class SparseArray<E> implements Cloneable {
    // 用来标记此处的值已被删除
    private static final Object DELETED = new Object();
    // 用来标记是否有元素被移除
    private boolean mGarbage = false;
    // 用来存储key的集合
    private int[] mKeys;
    // 用来存储value的集合
    private Object[] mValues;
    // 存入的元素个数
    private int mSize;
    
    // 默认初始容量为10
    public SparseArray() {
        this(10);
    }

    public SparseArray(int initialCapacity) {
        if (initialCapacity == 0) {
            mKeys = EmptyArray.INT;
            mValues = EmptyArray.OBJECT;
        } else {
            mValues = ArrayUtils.newUnpaddedObjectArray(initialCapacity);
            mKeys = new int[mValues.length];
        }
        mSize = 0;
    }
    
    // ...省略其他代码

}

可以看到SparseArray仅仅实现了Cloneable接口并没有实现Map接口，并且SparseArray内部维护了一个int数组和一个Object数组。在无参构造方法中调用了有参构造，并将其初始容量设置为了10。
二、SparseArray的remove()方法

// SparseArray
public void remove(int key) {
    delete(key);
}

public void delete(int key) {
    int i = ContainerHelpers.binarySearch(mKeys, mSize, key);

    if (i >= 0) {
        if (mValues[i] != DELETED) {
            mValues[i] = DELETED;
            mGarbage = true;
        }
    }
}

二分查找：

// ContainerHelpers
static int binarySearch(int[] array, int size, int value) {
    int lo = 0;
    int hi = size - 1;

    while (lo <= hi) {
        final int mid = (lo + hi) >>> 1;
        final int midVal = array[mid];

        if (midVal < value) {
            lo = mid + 1;
        } else if (midVal > value) {
            hi = mid - 1;
        } else {
            return mid;  // value found
        }
    }
    return ~lo;  // value not present
}

SparseArray的gc()方法
这个方法其实很容易理解，我们知道Java虚拟机在内存不足时会进行GC操作，标记清除法在回收垃圾对象后为了避免内存碎片化，会将存活的对象向内存的一端移动。而SparseArray中的这个gc方法其实就是借鉴了垃圾收集整理碎片空间的思想。
关于mGarbage这个参数上边已经有提到过了，这个变量会在删除元素的时候被置为true。
4.为什么 Activity.finish() 之后 10s 才 onDestroy ？
问题描述： 在A Activity启动B Activity，并结束A 页面，B页面在启动时进行大量的动画场景，源源不断的向主线程消息队列发送消息。A Activity的onPause正常执行，但是onStop与onDestory都延迟了10s才执行。为什么会出现这样的情况？
Activity 的 onStop/onDestroy 是依赖 IdleHandler 来回调的，正常情况下当主线程空闲时会调用。但是由于某些特殊场景下的问题，导致主线程迟迟无法空闲，onStop/onDestroy 也会迟迟得不到调用。但这并不意味着 Activity 永远得不到回收，系统提供了一个兜底机制，当 onResume 回调 10s 之后，如果仍然没有得到调用，会主动触发。
5HandlerThread
答：HandlerThread 是一个自带 Looper 的线程，因此只能作为子线程使用
HandlerThread 必须配合 Handler 使用，HandlerThread 线程中具体做什么事，需要在 Handler 的 callback 中进行，因为它自己的 run 方法被写死了
子线程的 Handler 与 HandlerThread 关系建立是通过构造子线程的Handler 传入 HandlerThread 的 Looper 。所以在此之前，必须先调用 mHandlerThread.start 让 run 方法跑起来 Looper 才能创建。
6.一个线程有几个Handler？一个线程有几个Looper？如何保证？
答：Handler的个数与所在线程无关，可以在线程中实例化任意多个Handler。一个线程中只有一个Looper。Looper的构造方法被声明为了private，我们无法通过new关键字来实例化Looper，唯一开放的可以实例化Looper的方法是prepare。prepare方法的源码如下：

    public static void prepare() {
        prepare(true);
    }

    private static void prepare(boolean quitAllowed) {
        if (sThreadLocal.get() != null) {
            throw new RuntimeException("Only one Looper may be created per thread");
        }
        sThreadLocal.set(new Looper(quitAllowed));
    }

我们知道ThreadLocal是一个线程内部的数据存储类，当某个线程调用prepare方法的时候，会首先通过ThreadLocal检查这个线程是否已经创建了Looper,如果还没创建，则实例化Looper并将实例化后的Looper保存到ThreadLocal中，而如果ThreadLocal中已经保存了Looper，则会抛出一个RuntimeException的异常。那么意味着在一个线程中最多只能调用一次prepare方法，这样就保证了Looper的唯一性。
7.Handler线程是如何切换的？
（1）假设现在有一个线程A，在A线程中通过Looper.prepare和Looper.loop来开启Looper,并且在A线程中实例化出来一个Handler。Looper.prepare()方法被调用时会为会初始化Looper并为ThreadLocal 设置Looper，此时ThreadLocal中就存储了A线程的Looper。另外MessageQueue也会在Looper中被初始化。
（2）接着当调用Loop.loop方法时，loop方法会通过myLooper得到A线程中的Looper，进而拿到Looper中的MessageQueue，接着开启死循环等待执行MessageQueue中的方法。
（3）此时，再开启一个线程B，并在B线程中通过Handler发送出一个Message，这个Message最终会通过sendMessageAtTime方法调用到MessageQueue的equeueMessage方法将消息插入到队列。
（4）由于Looper的loop是一个死循环，当MessageQueue中被插入消息的时候，loop方法就会取出MessageQueue中的消息，并执行callback。而此时，Looper是A线程的Looper,进而调用的Message或者Handler的Callback都是执行在A线成中的。以此达到了线程的切换。
8.Handler内存泄漏的原因是什么？如何解决?
通常在使用Handler的时候回通过匿名内部类的方式来实例化Handler，而非静态的匿名内部类默认持有外部类的引用，即匿名内部类Handler持有了外部类。而导致内存泄漏的根本原因是是因为Handler的生命周期与宿主的生命周期不一致。比如说在Activity中实例化了一个非静态的匿名内部类Handler，然后通过Handler发送了一个延迟消息，但是在消息还未执行时结束了Activity，此时由于Handler持有Activity，就会导致Activity无法被GC回收，也就是出现了内存泄漏的问题。解决方式是可以把Handler声明为静态的匿名内部类，但这样一来，在Handler内部就没办法调用到Activity中的非静态方法或变量。那么最终的解决方案可以使用静态内部类 + 弱引用来解决。代码如下：

public class MainActivity extends AppCompatActivity {

    private MyHandler mMyHandler = new MyHandler(this);

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

    private void handleMessage(Message msg) {

    }

    static class MyHandler extends Handler {
        private WeakReference<Activity> mReference;

        MyHandler(Activity reference) {
            mReference = new WeakReference<>(reference);
        }

        @Override
        public void handleMessage(Message msg) {
            MainActivity activity = (MainActivity) mReference.get();
            if (activity != null) {
                activity.handleMessage(msg);
            }
        }
    }

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

9.子线程中使用Looper应该注意什么？有什么用？
子线程中开启的Looper，在没有消息时一定要调用Looper的quit或者quitSafely方法。不然子线程会一直处于阻塞状态，无法被回收，进而可能导致内存泄漏的问题。
10.MessageQueue是如何保证线程安全的？
enqueueMessage方法和next方法中的代码都加了synchronize关键字来保证线程安全

11.Handler的阻塞唤醒机制是什么？
Handler 中其实还存在着一种阻塞唤醒机制，我们都知道不断地进行循环是非常消耗资源的，有时我们 MessageQueue 中的消息都不是当下就需要执行的，而是要过一段时间，此时如果 Looper 仍然不断进行循环肯定是一种对于资源的浪费。
因此 Handler 设计了这样一种阻塞唤醒机制使得在当下没有需要执行的消息时，就将 Looper 的 loop 过程阻塞，直到下一个任务的执行时间到达或者一些特殊情况下再将其唤醒，从而避免了上述的资源浪费。
这个阻塞唤醒机制是基于 Linux 的 I/O 多路复用机制 epoll 实现的，它可以同时监控多个文件描述符，当某个文件描述符就绪时，会通知对应程序进行读/写操作。
Handler的阻塞机制的实现是在MessageQueue的next方法中，通过调用nativePollOnce的一个native方法实现的。
遇到以下情况，Java 层会调用 natvieWake 方法进行唤醒。
MessageQueue 类中调用 nativeWake 方法主要有下列几个时机：
调用 MessageQueue 的 quit 方法进行退出时，会进行唤醒
消息入队时，若插入的消息在链表最前端(最早将执行)或者有同步屏障时插入的是最前端的异步消息(最早被执行的异步消息)
移除同步屏障时，若消息列表为空或者同步屏障后面不是异步消息时
可以发现，主要是在可能不再需要阻塞的情况下进行唤醒。(比如加入了一个更早的任务，那继续阻塞显然会影响这个任务的执行)