问：Activity 生命周期
答： - onCreate onStart onResume onPause onStop onDestroy
两个 Activity 跳转的生命周期：
- onCreate - onStart - onResume
- ActivityA onPause
- ActivityB onCreate
- ActivityB onStart
- ActivityB onResume
- ActivityA onStop
- ActivityB onPause
- ActivityA onRestart
- ActivityA onStart
- ActivityA onResume
- ActivityB onStop
- ActivityB onDestroy
- ActivityA onPause
- ActivityA onStop
- ActivityA onDestroy
问：启动模式
- Standard 模式 - Activity 可以有多个实例，每次启动 Activity，无论任务栈中是否已经有这个Activity的实例，系统都会创建一个新的 Activity 实例
- SingleTop 模式 - 当一个 singleTop 模式的 Activity 已经位于任务栈的栈顶，再去启动它时，不会再创建新的实例，如果不位于栈顶，就会创建新的实例
- SingleTask 模式 - 如果 Activity 已经位于栈顶，系统不会创建新的 Activity 实例，和 singleTop 模式一样，但 Activity 已经存在但不位于栈顶时，系统就会把该 Activity 移到栈顶，并把它上面的 Activity 出栈
- SingleInstance 模式 - SingleInstance 模式也是单例的，但和 singleTask 不同，singleTask 只是任务栈内单例，系统里是可以有多个 singleTask Activity 实例的，而 singleInstance Activity 在整个系统里只有一个实例，启动一 SingleInstance 时，系统会创建一个新的任务栈，并且这个任务栈只有他一个Activity
问：ANR的原因
- 耗时的网络访问
- 大量的数据读写
- 数据库操作
- 硬件操作（比如camera)
- 调用thread的join()方法、sleep()方法、wait()方法或者等待线程锁的时候
- service binder的数量达到上限
- system server中发生WatchDog ANR
- service忙导致超时无响应
- 其他线程持有锁，导致主线程等待超时
- 其它线程终止或崩溃导致主线程一直等待
问：什么是 app 热启动
答： - 当应用已经被打开， 但是被按下返回键、Home键等按键时回到桌面或者是其他程序的时候，再重新打开该app时， 这个方式叫做热启动（后台已经存在该应用进程）。热启动因为会从已有的进程中来启动，所以热启动就不会走Application这步了，而是直接走MainActivity（包括一系列的测量、布局、绘制），所以热启动的过程只需要创建和初始化一个MainActivity就行了，而不必创建和初始化Application
问：冷启动的生命周期简要流程
答： - Application 构造方法 –> attachBaseContext –> onCreate –> Activity 构造方法 –> onCreate –> 配置主体中的背景等操作 –> onStart –> onResume –> 测量、布局、绘制显示
冷启动的优化主要内容：
- 减少 onCreate()方法的工作量
- 不要让 Application 参与业务的操作
- 不要在 Application 进行耗时操作
- 不要以静态变量的方式在 Application 保存数据
- 减少布局的复杂度和层级
- 减少主线程耗时
问：为什么冷启动会有白屏黑屏问题
答： - 关键点在于加载主题样式 Theme 中的 windowBackground 等属性设置给 MainActivity 发生在 inflate 解析填充布局之前，在 onCreate、onStart、onResume 方法之前，而 windowBackground 背景默认是白色或者黑色，所以我们进入 app 的第一个界面的时候会造成先白屏或黑屏一下再进入界面，解决思路如下：
- 使用启动页背景设置 windowBackground，那么就不会有一闪的效果了
- windowBackground 使用透明色，给人一种延迟启动的感觉
- 核心根本还是在减少 application 中干的事，初始化操作都放到 SpashActivity 里面去干
问：如何理解 Context 上下文
Context 一般叫上下文或是场景，因为 Context 的确是一种有明确目标的场景，就像舞台的幕布 能够隔绝前台和后台，Context 是用户(当前层级类)和操作系统交互的助手或者界面，另外还包括当前层级对象的各种配置参数，信息，比如获取系统服务、获取内部文件（夹）路径、创建 View 操作时等都需要 Context 的参与
Application、Activity、Service 都是 Context 的间接子类，直接继承的都是 ContextWrapper
public class Application extends ContextWrapper implements ComponentCallbacks2 {...}
ContextWrapper 里面 mBase 的 Context 成员变量，像 Application 的 startActivity 这类的方法都是通过 ContextWrapper 的 mBase 完成的，在分层的角度看这样是把和操作系统的联系封装成工具类，以继承的方式提供给需要的用户，这是不是用的组合方式
当然不同层级的 Context 实现类还是有所区别的
