SharedPreferences是Android提供的数据持久化的一种手段，适合单进程、小批量的数据存储与访问。为什么这么说呢？因为SharedPreferences的实现是基于单个xml文件实现的，并且，所有持久化数据都是一次性加载到内存，如果数据过大，是不合适采用SharedPreferences存放的。而适用的场景是单进程的原因同样如此，由于Android原生的文件访问并不支持多进程互斥，所以SharePreferences也不支持，如果多个进程更新同一个xml文件，就可能存在同不互斥问题，后面会详细分析这几个问题。
阅读本文之前，不妨先思考一个问题，在Android系统中，APP端View视图的数据是如何传递SurfaceFlinger服务的呢？Android系统中，View绘制的数据最终是按照一帧一帧显示到屏幕的，而每一帧都会占用一定的存储空间，在APP端执行draw的时候，数据很明显是要绘制到APP的进程空间，但是视图窗口要经过SurfaceFlinger图层混排才会生成最终的帧，而SurfaceFlinger又运行在独立的服务进程，那么View视图的数据是如何在两个进程间传递的呢，普通的Binder通信肯定不行，因为Binder不太适合这种数据量比较大的通信，那么View数据的通信采用的是什么IPC手段呢？答案就是共享内存，更精确的说是Linux的匿名共享内存。共享内存是Linux自带的一种IPC机制，Android直接使用了该模型，在绘制图形的时候，APP进程同SurfaceFlinger共用一块内存，如此以来，就不需要进行数据拷贝，只要合理的处理同步机制，效率更高，APP端绘制完毕，通知SurfaceFlinger端合成，再输出到硬件进行显示，当然，个中细节会更复杂，本文主要分析下匿名共享内存的原理及在Android，就来看下个中细节：
Android应用是建立在Java虚拟机之上的，Google为了保证同时多个APP运行，并可以及时唤醒，就为每个虚拟机设置了最大可使用内存，通过adb命令可以查看相应的几个参数，
Android6.0之后，权限分为install时的权限跟运行时权限，如果我们的targetSdkVersion>=23，install权限同runtime权限是分开的，app也要针对6.0已经做适配，没什么大问题，无论运行在旧版本还是6.0之后的手机上都ok，这也是Google推荐的适配方案。但是如果targetSdkVersion < 23 ,在6.0之后的手机上就会遇到一些问题，因为在这种情况下默认权限是全部授予的，但是可能会被用户手动取消，而Context的checkSelfPermission权限检查接口也会失效，因为这个API接口6.0之后用的是runtime-permission的模型，而targetSdkVersion < 23 时候，app只有intalled的权限，其granted值一直是true，也可以看做是全部是授权了的，就算在设置里面取消授权也不会影响installed权限的granted，而Context的checkSelfPermission的接口却是用granted这个值作为授权与否的参考，所以如果用这个接口，那得到的一定是授权了，是不准确的，如下：targetSdkVersion < 23的时候，package信息中的权限包含app申请的全部权限,
面试的时候，面试官经常跟你随便侃侃Activity的启动模式，但Activity启动牵扯的知识点其实很多，并非能单单用四个启动模式就能概括的，默认的启动模式的表现会随着Intent Flag的设置而改变，因此侃Activity启动模式大多走流程装逼，最多结合项目遇到的问题，随便刁难一下面试者，并不太容易把控，也许最后，面试官跟面试者的答案都是错了，比如在Service中必须通过设置FLAG_ACTIVITY_NEW_TASK才能启动Activity，这个时候启动Activit会有什么样的表现呢？就这一个问题，答案就要分好几个场景：
硬件加速，直观上说就是依赖GPU实现图形绘制加速，因此，软硬件加速的区别主要是指图形的绘制究竟是GPU来处理还是CPU，如果是GPU，就认为是硬件加速绘制，反之，软件绘制。在Android中也是如此，不过相对于普通的软件绘制，硬件加速还做了其他方面优化，不仅仅限定在绘制方面，绘制之前，在如何构建绘制区域上，硬件加速也做出了很大优化，因此硬件加速特性可以从下面两部分来分析：
前文Android匿名共享内存（Ashmem）原理分析了匿名共享内存，它最主要的作用就是View视图绘制，Android视图是按照一帧一帧显示到屏幕的，而每一帧都会占用一定的存储空间，通过Ashmem机制APP与SurfaceFlinger共享绘图数据，提高图形处理性能，本文就看Android是怎么利用Ashmem分配及绘制的：
在Android系统中，窗口是有分组概念的，例如，Activity中弹出的所有PopupWindow会随着Activity的隐藏而隐藏，可以说这些都附属于Actvity的子窗口分组，对于Dialog也同样如此，只不过Dialog与Activity属于同一个分组。之间已经简单介绍了窗口类型划分：应用窗口、子窗口、系统窗口，Activity与Dialog都属于应用窗口，而PopupWindow属于子窗口，Toast、输入法等属于系统窗口。只有应用窗口与系统窗口可以作为父窗口，子窗口不能作为子窗口的父窗口，也就说Activity与Dialog或者系统窗口中可以弹出PopupWindow，但是PopupWindow不能在自己内部弹出PopupWindow子窗口。日常开发中，一些常见的问题都同窗口的分组有关系，比如为什么新建Dialog的时候必须要用Activity的Context，而不能用Application的；为什么不能以PopupWindow的View为锚点弹出子PopupWindow？其实这里面就牵扯都Android的窗口组织管理形式，本文主要包含一下几点：