Android中bindService是一个异步的过程，什么意思呢？使用bindService无非是想获得一个Binder服务的Proxy，但这个代理获取到的时机并非由bindService发起端控制，而是由Service端来控制，也就是说bindService之后，APP端并不会立刻获得Proxy，而是要等待Service通知APP端，具体流程可简化如下：
LayoutInflater其实是一个布局渲染工具，其本质就只是一个工具，说白了LayoutInflater的作用就是根据xml布局文件构建View树，自定义View的时候经常用到，常用的做法如下：
Android开发中经常用到ViewPager+Fragment+Adapter的场景，一般每个Fragment控制自己的刷新，但是如果想要刷新整个ViewPager怎么做呢？或者想要将缓存的Fragent给重建怎么做呢？之前做业务的时候遇到一个问题，ViewPage在第二次setAdapter的如果用的是FragmentPager并不会导致页面刷新，但是采用FragementStatePagerAdapter却会刷新？不由得有些好奇，随跟踪了部分源码，简单整理如下：
自定义View的时候经常会遇到Touch事件的处理，这些事件到底是怎么来的呢？源头是哪呢？从手指接触屏幕到MotionEvent被传送到Activity或者View，中间究竟经历了什么？
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，就来看下个中细节：
核心问题 ：先GC 还是先扩展
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申请的全部权限,