Android⾯试题汇总及答案
汇总⼀下Android⾯试题，并逐渐补充答案。
最近⽐较忙，没有进⼀步整理，不过没有答案的题⽬也可以作为复习引导来⽤，后续有时间在补充吧。
Android:雨中图片
1. 说⼀下四⼤组件。
四⼤组件指Activity、Service、BroadcastReceiver、ContentProvider，这四⼤组件都需要在AndroidManifest⽂件中注册才可以使⽤。2. Ac tivity⽣命周期和四种启动模式。
⽣命周期：
onCreate: Activity第⼀次创建时必然执⾏的⽅法，我们在这个⽅法中做⼀下初始化的操作，例如加载布局，初始化控件，注册点击事件等。
onStart: 当Activity变为可见时调⽤该⽅法。
onRestart: 该⽅法在Activity由停⽌状态转变为运⾏状态时调⽤，也就是说⼀个处于后台的Activity被重新
启⽤了。（注意：后续还会调⽤onStart，不要以为onRestart之后就直接调⽤onResume了。）
onResume: 当Activity准备好和⽤户交互的时候调⽤，此时Activity必然处于栈顶，处于运⾏状态。
onPau: 当Activity不可交互时调⽤。例如被销毁时、按Home键返回桌⾯时，启动或者恢复某个Activity时。（注意：展⽰Dialog时不会调⽤onPasu，有疑问可以⾃⼰测试。）
onStop: 该⽅法在Activity完全不可见的时候调⽤。它和onPau()⽅法的主要区别在于，如果启动的新Activity是⼀个对话框式的activity，那么，onPau()⽅法会得到执⾏，⽽onStop()⽅法并不会执⾏。
温馨的小家
onDestroy: 这个⽅法在Activity被销毁之前调⽤，之后Activity的状态将变为销毁状态。
启动模式：
Standard模式:
标准模式，Standard模式是Android的默认启动模式，⽆需再Manifest⽂件中配置，这种模式下，Activity可以有多个实例，每次启动Activity，⽆论任务栈中是否已经有这个Activity的实例，系统都会创建⼀个新的Activity实例。
SingleTop模式:
栈顶复⽤模式，该模式需要在Manifest⽂件中配置。
SingleTop模式和standard模式⾮常相似，主要区别就是当⼀个singleTop模式的Activity已经位于任务栈的栈顶，再去启动它时，不会再创建新的实例，如果不位于栈顶，就会创建新的实例。
SingleTask模式：
栈内复⽤模式，该模式需要在Manifest⽂件中配置。
SingleTask模式的Activity在同⼀个Task内只有⼀个实例，如果Activity已经位于栈顶，系统不会创建新的Activity实例，和singleTop模式⼀样。但Activity已经存在但不位于栈顶时，系统就会把该Activity移到栈顶，并把它上⾯的activity出栈。
SingleInstance模式：
单例模式，该模式需要在Manifest⽂件中配置。
SingleInstance模式也是栈内单例的，但和SingleTask不同，SingleTask只是任务栈内单例，其栈内是可以有多个其他Activity实例的，且若有别的任务栈，其中也可能有该Activity；⽽SingleInstance模式的 Activity在整个系统⾥只有⼀个实例，切启动⼀SingleInstance模式的Activity时，系统会创建⼀个新的任务栈，并且这个任务栈只有他⼀个Activity。
3. Ac tivity的启动过程（不要回答⽣命周期）。
Activity的启动过程，我们可以从Context的startActivity说起，其实现是ContextImpl的startActivity，然后内部会通过Instrumentation来尝试启动Activity，这是⼀个跨进程过程，它会调⽤ams的startActivity⽅法，当ams校验完activity的合法性后，会通过ApplicationThread回调到我们的进程，这也是⼀次跨进程过程，⽽applicationThread就是⼀个binder，回调逻辑是在binder线程池中完成的，所以需要通过Handler H将其切换到ui线程，第⼀个消息是LAUNCH_ACTIVITY，它对应handleLaunchActivity，在这个⽅法⾥完成了Activity的创建和启动，接着，在activity 的onResume中，activity的内容将开始渲染到window上，然后开始绘制直到我们看见。
4. Servic e的启动⽅式及⽣命周期(参考下⽅⽰例代码)。
4. Ser vic
Service的启动⽅式分为startService和bindService两种：
startService⽅式：⽣命周期为onCreate -> onStartCommand -> onDestroy。
bindService⽅式：⽣命周期为onCreate -> onBind -> onUnbind -> onDestroy。
注意：多次startService或者bindService，onCreate⽅法也只会调⽤⼀次。
也可以混合启动：
先bind后start：⽣命周期为onCreate -> onBind -> onStartCommand。
我的极品老妈先start后bind：⽣命周期为onCreate -> onStartCommand -> onBind。
⾄于混合启动后的unbind和stop操作，结果都是⼀样的：
如果先unbind，后stop：则会依次执⾏onUnbind和onDestroy⽅法。
但是如果先stop，后unbind：则会有所不同：试图stop时，并没有任何反应，但是接下来unbind到时候，会在调⽤onUnbind后，直接调⽤onDestroy⽅法。
⽰例代码：
当应⽤程序关闭后，如果有合适的⼴播，程序也会被系统调⽤⾃动运⾏。
当⼴播为有序⼴播时：优先级⾼的先接收（不分静态和动态）。同优先级的⼴播接收器，动态优先于静态
同优先级的同类⼴播接收器，静态：先扫描的优先于后扫描的，动态：先注册的优先于后注册的。
当⼴播为默认⼴播时：⽆视优先级，动态⼴播接收器优先于静态⼴播接收器。同优先级的同类⼴播接收器，静态：先扫描的优先于后扫描的，动态：先注册的优先于后册的。
6. Co ntentPr o vider:
8. ⼦线程能更新U I吗？
Android的单线程模型模型要求必须要在UI线程更新UI，否则认为是不安全的，原则上⼦线程是不能更新UI的。在其他线程访问UI，Android给提供了如下⼀些⽅法：
Activity.runOnUiThread(Runnable)
View.post(Runnable)
View.postDelayed(Runnable, long)
Handler
说道低都是调度到主线程来完成更新UI的⼯作。
其实如果⾮要直接在⼦线程强⾏更新UI，则会得到⼀个异常：
android.view.ViewRoot$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.小公主小说
实际上，通过CalledFromWrongThreadException的堆栈信息可以追踪ViewRootImpl这个类，实际上到这个是通过其中的⼀个checkThread ⽅法，来检查当前访问的线程，如果不是UI线程，就会抛出该异常。
形容小气的成语回到问题本⾝，⼦线程真的不能更新UI吗？
实际上在如下情况中⼦线程是可以更新的UI的：
在Activity执⾏onCreate时，ViewRootImpl还没有实例化，加⼊此时⽴即new⼀个Thread更新UI，则不会抛出异常。
另外，如果我们能够通过某种⽅法，在⼦线程中拥有ViewRootImpl，那么也可以更新UI，具体⽅法就不深究了。
7. Ja va虚拟机和Da lvik虚拟机和Art的区别。
8. 进程和线程。
进程就是⼀个应⽤程序在处理机上的⼀次执⾏过程，它是⼀个动态的概念，⽽线程是进程中的⼀部分，⼀个进程可以包含多个线程。
进程和线程的关系和区别如下：
进程是cpu资源分配的最⼩单位， 线程是cpu调度的最⼩单位。
线程是进程的⼦集，⼀个进程可以有很多线程，每条线程并⾏执⾏不同的任务。
不同的进程使⽤不同的内存空间，⽽所有的线程共享⼀⽚相同的内存空间。
进程之间不能共享资源，⽽线程共享所在进程的内存空间和其它资源。
⼀个进程内可拥有多个线程，可开启新的进程，也可开启线程。
咖哩
⼀个线程只能属于⼀个进程，线程可直接使⽤同进程的资源，线程依赖于进程⽽存在。
9. 进程保活（不死进程）。
⾸先明确⼀点，“不死进程”本⾝其实是⼀个伪命题，尽量优化APP⾃⾝才是正道。
⾸先说⼀下进程的优先级：
根据进程的重要性，划分5级，优先级依次递减：
前台进程 (Foreground process)
可见进程 (Visible process)
服务进程 (Service process)
后台进程 (Background process)
琴桥空进程 (Empty process)
保活⼿段：
当前业界的Android进程保活⼿段主要分为** ⿊、⽩、灰 **三种，其⼤致的实现思路如下：
死姓
⿊⾊保活：不同的app进程，⽤⼴播相互唤醒（包括利⽤系统提供的⼴播进⾏唤醒）
所谓⿊⾊保活，就是利⽤不同的app进程使⽤⼴播来进⾏相互唤醒。举个3个⽐较常见的场景：
场景1：开机，⽹络切换、拍照、拍视频时候，利⽤系统产⽣的⼴播唤醒app
场景2：接⼊第三⽅SDK也会唤醒相应的app进程，如微信sdk会唤醒微信，⽀付宝sdk会唤醒⽀付宝。由此发散开去，就会直接触发了下⾯的 场景3
场景3：假如你⼿机⾥装了⽀付宝、淘宝、天猫、UC等阿⾥系的app，那么你打开任意⼀个阿⾥系的app后，有可能就顺便把其他阿⾥系的app给唤醒了。（只是拿阿⾥打个⽐⽅，其实BAT系都差不多）
⽩⾊保活：启动前台Service
⽩⾊保活⼿段⾮常简单，就是调⽤系统api启动⼀个前台的Service进程，这样会在系统的通知栏⽣成⼀个Notification，⽤来让⽤户知道有这样⼀个app在运⾏着，哪怕当前的app退到了后台。如⾳乐APP的可操作的通知。
灰⾊保活：利⽤系统的漏洞启动前台Service
灰⾊保活，这种保活⼿段是应⽤范围最⼴泛。它是利⽤系统的漏洞来启动⼀个前台的Service进程，与普通的启动⽅式区别在于，它不会在系统通知栏处出现⼀个Notification，看起来就如同运⾏着⼀个后台Service进程⼀样。这样做带来的好处就是，⽤户⽆法察觉到你运⾏着⼀个前台进程（因为看不到Notification），但你的进程优先级⼜是⾼于普通后台进程的。那么如何利⽤系统的漏洞呢，⼤致的实现思路和代码如下：
思路⼀：API < 18，启动前台Service时直接传⼊new Notification()； 思路⼆：API >= 18，同时启动两个id相同的前台Service，然后再将后启动的Service做stop处理
下⾯补充⼀下Android的杀进程机制：
熟悉Android系统的童鞋都知道，系统出于体验和性能上的考虑，app在退到后台时系统并不会真正的kill掉这个进程，⽽是将其缓存起来。打开的应⽤越多，后台缓存的进程也越多。在系统内存不⾜的情况下，系统开始依据⾃⾝的⼀套进程回收机制来判断要kill掉哪些进程，以腾出内存来供给需要的app。这套杀进程回收内存的机制就叫 Low Memory Killer ，
