本篇是Android后台杀死系列的第二篇，主要讲解ActivityMangerService是如何恢复被后台杀死的进程的（基于4.3 ），在开篇FragmentActivity及PhoneWindow后台杀死处理机制中，简述了后台杀死所引起的一些常见问题，还有Android系统控件对后台杀死所做的一些兼容，以及onSaveInstance跟onRestoreInstance的作用于执行时机，最后说了如何应对后台杀死。但是，对于被后台杀死的进程如何恢复的并没有讲解，本篇不涉及后台杀死，比如LowmemoryKiller机制，只讲述被杀死的进程如何恢复的。假设，一个应用被后台杀死，再次从最近的任务列表唤起App时候，系统是如何处理的呢？有这么几个问题可能需要解决：
本篇是Android后台杀死系列的第三篇，前面两篇已经对后台杀死注意事项，杀死恢复机制做了分析，本篇主要讲解的是Android后台杀死原理。相对于后台杀死恢复，LowMemoryKiller原理相对简单，并且在网上还是能找到不少资料的，不过，由于Android不同版本在框架层的实现有一些不同，网上的分析也多是针对一个Android版本，本文简单做了以下区分对比。LowMemoryKiller(低内存杀手)是Andorid基于oomKiller原理所扩展的一个多层次oomKiller，OOMkiller(Out Of Memory Killer)是在Linux系统无法分配新内存的时候，选择性杀掉进程，到oom的时候，系统可能已经不太稳定，而LowMemoryKiller是一种根据内存阈值级别触发的内存回收的机制，在系统可用内存较低时，就会选择性杀死进程的策略，相对OOMKiller，更加灵活。在详细分析其原理与运行机制之前，不妨自己想一下，假设让你设计一个LowMemoryKiller，你会如何做，这样一个系统需要什么功能模块呢？
对于电商App，商品详情无疑是很重要的一个模块，观察主流购物App的详情界面，发现大部分都是做成了上下两部分，上面展示商品规格信息，下面是H5商品详情，或者是嵌套了一个包含H5详情及评论列表的ViewPager界面，本文就是实现了一个兼容不同需求的上下滚动黏滞View.
自定义View是Android开发中最普通的需求，灵活控制View的尺寸是开发者面临的第一个问题，比如，为什么明明使用的是WRAP_CONTENT却跟MATCH_PARENT表现相同。在处理View尺寸的时候，我们都知道最好在onMeasure中设定好自定义View尺寸，那么究竟如何合理的选择这个尺寸呢。例如，如果要实现一个自定义ViewGroup，应该如何适配它的大小呢，直观来说，可能有以下问题需要考虑：
Android L面世之后，Google就推荐在开发项目中使用RecyclerView来取代ListView，因为RecyclerView的灵活性跟性能都要比ListView更强，但是，带来的问题也不少，比如：列表分割线都要开发者自己控制，再者，RecyclerView的测量与布局的逻辑都委托给了自己LayoutManager来处理，如果需要对RecyclerView进行改造，相应的也要对其LayoutManager进行定制。本文主要就以以下场景给出RecyclerView使用参考：
Google从4.3开始就试图引入AppOpsManager动态权限管理模型，但是，由于感觉技术不太成熟，在Release版本中，这个功能都是被隐藏掉的，所以官方Rom一直没有动态权限管理机制。直到Android6.0，为了简化安装流程且方便用户控制权限，Google正式推出了runtime permission机制，至此，Android才算有了一套成熟的动态权限管理机制。正如我们看到的，在MarshMallow之前，所有的权限都是在安装的时候授予，而在6.0之后，允许用户在运行的时候动态控制权限。
6.0之前Android的权限都是在安装的时候授予的，6.0之后，为了简化安装流程，并且方便用户控制权限，Android允许在运行的时候动态控制权限,即有些权限需要在使用到的时候动态申请，根据用户的选择需要有不同的处理.对于开发而言就是将targetSdkVersion设置为23，当运行在Android 6.0 +的手机上时，就会调用6.0相关的API，达到动态控制权限的目的。但是，如果仅仅是将targetSdkVersion设置为23，而在代码层面没有针对Android 6.0做适配，就可能在申请系统服务的时候，由于权限不足，引发崩溃。具体表现可以看下图：
ANR会影响系统整体运行吗？ 需要额外处理？？？？