Android O 推出出了Background Execution Limits，减少后台应用内存使用及耗电，一个很明显的应用就是不准后台应用通过startService启动服务，这里有两个问题需要弄清楚，第一：什么状态下startService的属于后台启动service；第二：如果想要在后台startService，如何兼容，因此分如下几个问题分析下
Android为了保证系统及应用的安全性，在安装APK的时候需要校验包的完整性，同时，对于覆盖安装的场景还要校验新旧是否匹配，这两者都是通过Android签名机制来进行保证的，本文就简单看下Android的签名与校验原理，分一下几个部分分析下：
mmap是Linux中常用的系统调用API，用途广泛，Android中也有不少地方用到，比如匿名共享内存，Binder机制等。本文简单记录下Android中mmap调用流程及原理。mmap函数原型如下：
Android依托Java型虚拟机，OOM是经常遇到的问题，那么在快达到OOM的时候，系统难道不能回收部分界面来达到缩减开支的目的码？在系统内存不足的情况下，可以通过AMS及LowMemoryKiller杀优先级低的进程，来回收进程资源。但是这点对于前台OOM问题并没有多大帮助，因为每个Android应用有一个Java内存上限，比如256或者512M，而系统内存可能有6G或者8G，也就是说，一个APP的进程达到OOM的时候，可能系统内存还是很充足的，这个时候，系统如何避免OOM的呢？ios是会将不可见界面都回收，之后再恢复，Android做的并没有那么彻底，简单说：对于单栈（TaskRecord）应用，在前台的时候，所有界面都不会被回收，只有多栈情况下，系统才会回收不可见栈的Activity。注意回收的目标是不可见栈（TaskRecord）的Activity。
APP开发中，卡顿绝对优化的大头，Google为了帮助开发者更好的定位问题，提供了不少工具，如Systrace、GPU呈现模式分析工具、Android Studio自带的CPU Profiler等，主要是辅助定位哪段代码、哪块逻辑比较耗时，影响UI渲染，导致了卡顿。拿Profile GPU Rendering工具而言，它用一种很直观的方式呈现可能超时的节点，该工具及其原理也是本文的重点：
APP开发中经常会有这种需求：在浏览器或者短信中唤起APP，如果安装了就唤起，否则引导下载。对于Android而言，这里主要牵扯的技术就是deeplink，也可以简单看成scheme，Android一直是支持scheme的，但是由于Android的开源特性，不同手机厂商或者不同浏览器厂家处理的千奇百怪，有些能拉起，有些不行，本文只简单分析下link的原理，包括deeplink，也包括Android6.0之后的AppLink。其实个人认为，AppLink可以就是deeplink，只不过它多了一种类似于验证机制，如果验证通过，就设置默认打开，如果验证不过，则退化为deeplink，如果单从APP端来看，区别主要在Manifest文件中的android:autoVerify=”true”，如下，
Memory Profiler 是 Android Studio自带的内存分析工具，可以帮助开发者很好的检测内存的使用，在出现问题时，也能比较方便的分析定位问题。