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自带的内存分析工具，可以帮助开发者很好的检测内存的使用，在出现问题时，也能比较方便的分析定位问题。
Android系统中，APP进程被杀后，等一会经常发现进程又起来了，这个现象同APP中Service的使用有很大关系，这里指的Service是通过startService启动的，而不是通binderSertvice启动的，binderSertvice是通Activity显示界面相关的，如果两者统一进程，binderSertvice的影响可以忽略，如果不是同一进程，Service会被重启。显示都没了那么这种情况情况下的Service也没必要启动了，但是对于通过startService启动的服务，很可能需要继续处理自己需要处理的问题，因此，可能需要重启。
Android4.0之后，系统默认开启硬件加速来渲染View，之前，理解Android硬件加速的小白文简单的讲述了硬件加速的简单模型，不过主要针对前半阶段，并没怎么说是如何使用OpenGL、GPU处理数据的，OpenGL主要处理的任务有Surface的composition及图形图像的渲染，本篇文章简单说一下后半部分的模型，这部分对于理解View渲染也有不少帮助，也能更好的帮助理解GPU渲染玄学曲线。