从UI控件内容更改到被重新绘制到屏幕上，这中间到底经历了什么？另外，连续两次setTextView到底会触发几次UI重绘呢？为什么Android APP的帧率最高是60FPS呢，这就是本文要讨论的内容。
电商或者内容类APP中，H5通常都会占据一席之地,Native跟H5通信会必不可少，比如某些场景H5通知native去分享，native通知H5局部刷新等，Android本身也提供这样的接口，比如addJavascriptInterface、loadUrl(“javascript:…“），而需要支持的能力也要是双工的。
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工具而言，它用一种很直观的方式呈现可能超时的节点，该工具及其原理也是本文的重点：