aaaaaaaaaaaa

 

工作描述: 参与 W1T项目，N23T 等项目，主要负责 systrace 分析等，涉及应用响应，冷热启动，卡顿等问题。

掌握技能：流畅卡顿类问题的分析，systrace 的抓取和分析、adb 常用命令，Linux 常用命令，常用分析工具的使用，lowmemory 问题的定位，相关 log 文件的分析等。 静态内存的抓取方式，如何在 systrace 定为低内存的方法。


开机内存拆解 ：主要是针对静态内存的拆解，像是使用dumpsys meminfo（PSS Total等信息）一般这些信息测试同学都会直接提供，我们拿过来拆解就行，对拆解出来有异常的数据，寻找对应owner确认就行，针对单独进程- showmap来拆解很详细
/proc/meminfo  --- kernel space的内存信息 （free+cache+buffer+iototal） dumpsys meminfo --- Android space的内存信息
开机时间：拆解（kernel层，上层扫包，加载server，bootloader，lk，kernel）.......................

模型类：整机模型（启动 ，滑动，退出） 老化模型（老化前后丢帧（内存低 cpu负载高，丢帧，预期以内）） QOE（模型类）

响应类问题：点击到画面动，launcher开始动，看是tp点击的时候慢了，还是launcher动画慢
内存原因，调整lmk内存回收，kswapd 水位 （swap zram），lmkd minfree psi（vmpre…有缺陷不使用）
主观卡顿流畅类：分析卡顿原因（是否真正的问题，比如fps切换，首次打开资源加载，dex2oat等）（systrace-Running，Runnable，sleeping？）python [systrace.py](http://systrace.py/) -t 时间 抓取信息 -o 生成文件 -b %buffSize%
vsync-app， app main thread ：input ，layout ，animation等资源加载，Render Thread 渲染完送buffer到bufferqueue，送的同时会进行GPU绘制
vsync-sf，获取buffer，disaply绘制，GPU绘制等。
**技术面指标模型，用户面指标模型：根据表格数据，找到具体影响大的应用，或者topapp等，先定位应用，然后再具体分析到底是什么原因
用户面指标也是类似，先定位找到异常阶段，查看是什么应用引起的，之后再进行具体的分析。
老化模型-主要针对差异大的应用进行单独分析，确定具体情况，首先要确认引起恶化的原因是什么，后台因素，内存，或者大量io类操作**

chrt -f 1 -p pid 优先级

taskset -p 16进制核 pid  绑核

**running长：**大小核摆核情况，大小核频率，是否限频，提频合不合理，或应用自己的逻辑，可抓取simpleperf查看具体逻辑，simpleperf record --app %1 --duration 5 -g -o 或-pid
调整cpu的一些策略，oppo 的orms

runnable ：大量的io，cpu-state（0 1 2）切换时间，cpu优先级，cpu是否存在抢占行为,以及是否有低内存的影响（HeapTeskDeam，kswapd）首先会占用cpu资源，可能带来大量的io，造成Runnable时间段过多
io拆解：可抓取iotrace，有专门的工具进行量化，也可打开android_fs抓取
sleeping：寻找唤醒源头，查看具体是什么行为影响，什么方法造成的影响

kswapd：kswapd：定期检查阈值（或内存不够的时候），修改主要就是水位 watermaek low min high
proc/zoneinfo/low min high 水位
水位与min_free_kbytes剩余最小内存有关 vm.min_free_kbytes：系统保留给内核用的内存。和水位有关，决定min的值
lru算法，把活跃的不活跃的统计起来
drity page，writr back回写到磁盘中，大量io造成卡顿
kswapd主要回收匿名页 文件页

lmkd （user space）：传统minfree（水位），较多使用 psi，根据多个情况计算出内存压力情况，进行内存回收
跑分：基础信息 平台，物料（cpu GPU MEM能力），策略，基线，版本，密度，分辨率，

**应用冷启动**：

应用冷启动：确认软件版本，是否第一次启动加载资源，进行后台优化，编译模式，有什么外部影响，应用自己逻辑，加载资源(zygote fork binderapplication oncreae onstart 绘制 )

**在桌面上冷启动一个 Android App 为例**，应用冷启动的整个流程包含了从用户触摸屏幕到应用完全显示的整个流程，其中涉及到

1. 触摸屏中断处理阶段（tp）
2. InputReader 和 InputDispatcher 处理 input 事件阶段（system_server）
3. Launcher 处理 input 事件阶段
4. SystemServer 处理启动事件(start intent activity)
5. 启动动画 (桌面动效或应用自己的动画)
6. 应用启动和自身逻辑阶段

**具体的阶段**

1. 请求阶段 1.发起请求 2.解析Intent 3.创建ActivityRecord 4.分配Task 5.Pause前台activity 6.Resume请求的activity
2. 进程启动阶段 7.AMS请求创建进程 8.Zygote fork进程 9.初始化 Runtime 10.注册进程到system_server 11.创建application
3. Activity初始化阶段 12.真正地start activity 13.加载activity 14.初始化窗口
4. Activity显示阶段 15.新建DecorView 16.新建ViewRootImpl 17.添加到Display 18.显示

**Trace**

CreateThreadPool→PostFork→Zygoteinit→ActivityThreadMain→bindApplication→activityStart→activityResume→Choreographer#doFrame

**起点：点击桌面图标**

从zygote进程中fork创建一个新进程给应用

ActivityThreadMain：反射创建`ActivityThread`对象并执行其`main`函数，进行主线程的初始化工作

Application：加载应用自身的逻辑 + 三方 SDK 初始化耗时（三方资源），主要为应用的一些dex文件资源

前期是创建进程加载的一些资源文件，之后才算是正式的activity初始化

activityStart：启动应用应用，在systrace上表现为activitystart，更详细的是进行activity的一个生命周期流程，相当于onCreate：创建Acticity，创建应用窗口啊什么的（inflate啊什么的）

activityResume：相当于onResume，相当于把应用切换到前台

Choreographer#doFrame：进行**应用UI布局与绘制，do frame加载布局文件（measure、layout、draw等），平常说的 算是应用启动第一帧**

之后可能还会进行一步activityStart，页面的创建于切换，然后还会绘制一帧

Choreographer#doFrame：之后绘制的这一帧算是主activity绘制的第一帧，（之后的内容并没有完全加载）

最后界面完全显示才算是一个完整的冷启动，但日常分析可能更倾向于以第一帧为结束点。

**冷启动优化**

**确认软件版本，包名，是否第一次启动加载资源，进行后台优化，编译模式，有什么外部影响，应用自己逻辑，加载资源**

**确认应用编译方式，**

**dex优化编译的几种状态 以及优缺点**

从 Android O 开始，有四个官方支持的过滤器：

verify：只运行 DEX 代码验证。

quicken：运行 DEX 代码验证，并优化一些 DEX 指令，以获得更好的解译器性能。

speed：运行 DEX 代码验证，并对所有方法进行 AOT 编译。

speed-profile：运行 DEX 代码验证，并对配置文件中列出的方法进行 AOT 编译

应用主线程是否跑在大核上，频率是否满频，是否有其他进程抢占（低内存时kswapd0（确认Memory状态：dumpsys meminfo信息，kernel-log中lowmemoryKiller & kswapd线程非常多；proc/meminfo），io block（有大量读写发生，后台打开大量应用，有应用更新或下载资源；低内存会触发Low Memory killer进程频繁进行扫描和查杀进程）)）

分清起点和终点 

**running长**：大小核摆核情况，大小核频率，应用逻辑，可抓取simpleperf查看具体逻辑，simpleperf record --app %1 --duration 5 -g -o 或-pid

调整cpu的一些策略，oppo 的orms


**runnable** ：大量的io，cpu-state（0 1 2）切换时间，cpu优先级，cpu是否存在抢占行为,以及是否有低内存的影响（HeapTeskDeam，kswapd）首先会占用cpu资源，可能带来大量的io，造成Runnable时间段过多


**sleeping**：寻找唤醒源头，查看具体是什么行为影响，什么方法造成的影响


**io拆解**：可抓取iotrace，有专门的工具进行量化，也可打开android_fs抓取


**判断是否存在Low Memory**

- **Kswapd0排名靠前很有可能发生Low memory状况：**CPU top3
- **Trace中“Uninterruptible Sleep”状态 block 在如下几个地方：**“do_page_faultbalance_dirty_pages_ratelimitedwait_on_page_bit_killable__lock_page_or_retry__lock_pagewait_on_page_bit”等
- **IO read量远远大于write量**memory回收导致read行为不断重复，不断推升I/O量

**low Memory优化**

1. 优化系统进程内存占用

2. 减少reserved memory

3. 限制后台

**修改DEFAULT_MAX_CACHED_PROCESSES=32 可以改为16/8**

**修改mCachedRestoreLevel 可以mCachedRestoreLevel/2**

4. 调整lmk参数

**调整minfree table 再kernel中 minfree table后三项阀值 ，分别增大1.x倍 1.x倍，1.x倍**

**调整lmkd 参数**

ro.lmk.medium 调小（mediaum pressure kill adj 减小， 更多进程可杀）

ro.lmk.downgrade_pressure 调大（更容易进到mediaum pressure状态）

ro.lmk.upgrade_pressure 调大（更容易进到critical pressure状态）

5. swap szie & swappiness

6. Duraspeed enable (or  做好后台管理)

**lmkd （user space）：**

**LMK（**Low Memory Killer**）原理：**传统minfree（水位），

首先通过比较当前空闲页和缓存页处于minfree阈值哪个档位，然后将对应adj设为min_adj;

然后通过冒泡排序找到oom_adj大于等于min_adj的进程，如果有多个进程时进一步找到

占用内存更大的进程kill掉。

较多使用 psi，根据多个情况计算出内存压力情况，进行内存回收

Android Q引入新模式——PSI (Pressure Stall Information)，根据注册对PSI信息的监听，并通过判断watermark，memfree，swapfree，thrashing等信息，更全面地判断当前系统压力，并进行针对性杀进程。

此模式需要依赖：

1、内核配置CONFIG_PSI=y；

2、属性ro.lmk.use_psi须不为false；

3、属性ro.config.low_ram为true，或ro.lmk.use_minfree_levels为false；

/proc/meminfo  --- kernel space的内存信息 （free+cache+buffer+iototal） dumpsys meminfo --- Android space的内存信息

开机时间：拆解（kernel层，上层扫包，加载server，bootloader，lk，kernel）.......................

模型类：整机模型（启动 ，滑动，退出） 老化模型（老化前后丢帧） QOE

响应类问题：点击到画面动，launcher开始动，看是tp点击的时候慢了，还是launcher动画慢

内存原因，调整lmk内存回收，kswapd 水位 （swap zram），lmkd minfree

主观卡顿流畅类：分析卡顿原因（是否真正的问题，比如fps切换，首次打开资源加载，dex2oat等）（systrace-Running，Runnable，sleeping？）python [systrace.py](

[http://systrace.py/)](http://systrace.py/))

-t 时间 -o 参数 -b %buffSize%

技术面指标模型，用户面指标模型：根据表格数据，找到具体影响大的应用，或者topapp等，先定位应用，然后再具体分析到底是什么原因

用户面指标也是类似，先定位找到异常阶段，查看是什么应用引起的，之后再进行具体的分析。

老化模型-主要针对差异大的应用进行单独分析，确定具体情况，首先要确认引起恶化的原因是什么，后台因素，内存，或者大量io类操作

kswapd：kswapd：定期检查阈值，修改主要就是水位 watermaek low min high（主要high-low）

proc/zoneinfo/low min high 水位

水位与min_free_kbytes剩余最小内存有关 vm.min_free_kbytes：系统保留给内核用的内存。和水位有关，决定min的值

lru算法，把活跃的不活跃的统计起来

drity page，writr back回写到磁盘中，大量io造成卡顿

kswapd主要回收匿名页 文件页  

跑分：基础信息 平台，物料（cpu GPU MEM能力），策略，基线，版本，密度，分辨率，

lmkd：minfree  psi（内存压力） vmpressure（不怎么使用）

**开机内存拆解**：

MemTotal = DRAM_Size - Reserved memory.（总大小-预留内存）

Reserved memory = HW reserved + Kernel reserved（硬件预留+kernel预留）

可用内存=used pss + used kernel

**可用内存**=pss（free+cache+buffer+ion主要拆解的是进程占用内存） + kernel（MEMINFO_SHMEM + MEMINFO_SLAB_UNRECLAIMABLE + MEMINFO_PAGE_TABLES + MEMINFO_VM_ALLOC_USED + MEMINFO_KERNEL_STACK(Optional）

**冷启动：**

**应用冷启动**：

**在桌面上冷启动一个 Android App 为例**，应用冷启动的整个流程包含了从用户触摸屏幕到应用完全显示的整个流程，其中涉及到

1. 触摸屏中断处理阶段（tp）
2. InputReader 和 InputDispatcher 处理 input 事件阶段（system_server）
3. Launcher 处理 input 事件阶段
4. SystemServer 处理启动事件(start intent activity)
5. 启动动画 (桌面动效或应用自己的动画)
6. 应用启动和自身逻辑阶段

**具体的阶段**

1. 请求阶段 1.发起请求 2.解析Intent 3.创建ActivityRecord 4.分配Task 5.Pause前台activity 6.Resume请求的activity
2. 进程启动阶段 7.AMS请求创建进程 8.Zygote fork进程 9.初始化 Runtime 10.注册进程到system_server 11.创建application
3. Activity初始化阶段 12.真正地start activity 13.加载activity 14.初始化窗口
4. Activity显示阶段 15.新建DecorView 16.新建ViewRootImpl 17.添加到Display 18.显示

起点：点击桌面图标

从zygote进程中fork创建一个新进程给应用

ActivityThreadMain：反射创建`ActivityThread`对象并执行其`main`函数，进行主线程的初始化工作

Application：加载应用自身的逻辑 + 三方 SDK 初始化耗时（三方资源），主要为应用的一些dex文件资源

前期是创建进程加载的一些资源文件，之后才算是正式的activity初始化

activityStart：启动应用应用，在systrace上表现为activitystart，更详细的是进行activity的一个生命周期流程，相当于onCreate：创建Acticity，创建应用窗口啊什么的（inflate啊什么的）

activityResume：相当于onResume，相当于把应用切换到前台

Choreographer#doFrame：进行**应用UI布局与绘制，do frame加载布局文件（measure、layout、draw等），平常说的 算是应用启动第一帧**

之后可能还会进行一步activityStart，页面的创建于切换，然后还会绘制一帧

Choreographer#doFrame：之后绘制的这一帧算是主activity绘制的第一帧，（之后的内容并没有完全加载）

最后界面完全显示才算是一个完整的冷启动，但日常分析可能更倾向于以第一帧为结束点。

**2.绘制显示的流程是怎么样的**

vsync-app， app main thread ：input ，layout ，animation等资源加载，Render Thread 渲染完送buffer到bufferqueue，

vsync-sf，获取buffer，disaply绘制，GPU绘制等。



**卡顿问题分析**

1，**桌面卡顿**


**高负载可能需要关注的点：**

1）.CPU 超大核最高频无法满足应用主线程算力需求的卡顿-----应用高负载

2）.系统后台负载高，影响前台应用主线程的执行，导致卡顿-----系统高负载

1CPU 当前频率的判断：

2是否限频：查看当前Cpu 的Min/Max 频率

3查看当前温度：main log 中搜索horae 关键字

4查看当前CPU 的负载情况：（Wall duration）/(Selected range)/8

5通过日志查看高负载进程CPU 的负载情况：

6查看线程的调度时延：

2，**滑动卡顿**

滑动场景丢帧，我们一般看主线程是否有特别的出帧耗时长，但是由于目前Android 系统都采用 3 
buffer，存在 buffer 缓存的情况下，即使 App 出帧稍慢，也不一定不连贯，所以从 sf 侧判断是否丢帧才是准确的。

1). **整机卡顿**：项目初期，显示驱动经常在调试，这块容易出问题，导致整机卡顿，任何界面滑动都会卡顿。我们可以先check sf 主线程，如果每一帧sf 主线程都合成耗时长，整机就基本处于卡顿状态，任何滑动都卡顿。

2). **cpu 类问题**

1. cpu 调度类问题:重要线程跑在小核
2. cpu 频率类问题：某些滑动场景下，需要算力时候，此时 cpu 算力却下降

3). **多媒体类问题**

1. Render SwapBuffer 耗时长**:**App 的渲染线程中 eglSwapBuffersWithDamageKHR 
耗时严重，导致App 绘制一帧耗时长
2. Render dequeueBuffer 耗时长

4). **线程状态异常问题**

1. App UX线程runnable:通常出现在优先级被错误设置或者在高负载情况下被高优先级线程抢占，这类问题的优化方向可暂归为cpu 调度方向
2. App UX线程D/Block IO 状态:内存分配不足

5). **三方running 长类问题**

App 主线程耗时长导致，systrace 表现为 App 主线程 running 时间长，绘制一帧超过一个 vsync 周期，同时 sf 并没有可用buffer 去消耗。这类 case 重点排查 cpu freq 以及调度问题，同时参考对比机的卡顿表现.

3, **页面切换卡顿**

手指按下屏幕认为点击事件开始（down事件），手指抬起离开屏幕认为点击事件结束（up事件）。在systrace中可以通过IQ对应泳道确认点击事件起始点，第一次value为1认为是手指按下，最后一次value值为1认为是手机抬起。在页面切换卡顿问题分析中，把手指抬起作为开始点。


**亮灭屏问题分析**

1.亮灭屏流程


修改printk从“7 4 1 7” 到 ”1 4 1 7“

先通过screen_toggled: 1，interceptKeyTq code=26 筛选down=false/true等关键字过滤测试时间段。
之后根据hwirq 硬件中断时间拆分单次亮灭屏。48按下 50抬起

亮屏时，先上电再亮起，亮屏时间包括上电prepare时间。灭屏时，unprepare在backlight后，下电时间不需要考虑在灭屏时长内。

prepare+ 屏幕相关节点

关键词：sysui_status_bar_state  screen_toggled  onAuthenticated  keyguardGoingAway

sysui_status_bar_state(state|1,keyguardShowing|1,keyguardOccluded|1,bouncerShowing|1,secure|1,currentlyInsecure|1)

state:状态（0屏幕关闭1屏幕打开2锁屏）

keyguardShowing：是否显示给用户（1显示0不显示）

keyguardOccluded:是否属于活动状态（1：keyguard处于活动状态，但另一个活动正在遮挡它）

bouncerShowing：当前解锁界面是否先是给用户：1是0否

secure：用户是否设置安全解锁方法（PIN,密码）：1是0否

currentlyInsecure：当前是否解锁：1是0否

screen_toggled：0表示屏幕关闭，1表示屏幕打开，2表示已锁屏

onAuthenticated ture指纹验证成功，false表示验证失败

keyguardGoingAway：表示锁屏界面隐藏

setting powermode 所有驱动（非三星）

hwirq = 48    硬件中断

screen_toggled: 1 屏幕切换

interceptKeyTq code=26 down=                powerkey

Display_state took 的log打印是三星客户特有的，指的是亮屏过程中底层驱动的耗时

按键下发
05-24 18:17:54.129 1000 978 1550 D InputManager-JNI: !@**interceptKeyBeforeQueueing**(116), action=0, interactive=false
pms启动亮屏流程
05-24 18:17:54.132 1000 978 1550 I **PowerManagerService**: Waking up from Dozing (uid=1000, reason=WAKE_REASON_POWER_BUTTON, details=android.policy:POWER)...
DisplayPowerController block screen on之后准备去绘图的时间
05-24 18:17:54.154 1000 978 1439 I **DisplayPowerController**[0]: Blocking screen on until initial contents have been drawn.
keyguard处理流程及window绘制过程
05-24 18:17:54.165 10044 2218 13884 D **KeyguardViewMediato**r: onScreenTurningOn
05-24 18:17:54.168 1000 978 2197 D **DisplayManagerService**: !@display_state requestDisplayStateInternal: OFF -> ON displayId=0
05-24 18:17:54.173 1000 978 2355 D WindowManager: mKeyguardDelegate.ShowListener.onDrawn.
05-24 18:17:54.186 1000 978 2197 D LocalDisplayAdapter: !@ display_state: OFF -> ON (id:0)
05-24 18:17:54.406 1000 978 2197 D PowerManagerUtil: !@ display_state: ON:: took 219 ms //driver 耗时
05-24 18:17:54.415 1000 978 1550 D InputManager-JNI: !@interceptKeyBeforeQueueing(116), action=1, interactive=true
05-24 18:17:54.619 1000 978 1401 D WindowManager: All windows drawn!
block screen on结束 //绘制界面完成花费的时间
05-24 18:17:54.632 1000 978 1439 I DisplayPowerController[0]: Unblocked screen on after 478 ms
亮屏流程结束
05-24 18:17:54.640 1000 978 1439 W PowerManagerService: **Screen on took** 513 ms

**4.开机时间**

bootrom-bootloader-kernel-lnit-zygote-systemserver-laucher

谈谈你平时项目中遇到的开机时间这块的优化方案（怎么看慢在哪个阶段，具体怎么优化的)

开机时间测量：开机录像，回放查看时长；通过adb导出平台提供的log；抓取开机时间log

开机时间优化：

开机log分析：(1)在开机log中，搜索“boot_progress_”以及“wm_boot_”关键词

(2).计算开机各阶段耗时，找出可优化点

(3).在开机log中，搜索“SystemServer”关键词，可以查看各个service的时间

优化方法：

PL和LK的时间优化：确认是否和同平台的机器PL或者LK耗时存在差异，比对pl和lk阶段的测试机和对比机Log，寻找耗时出现的地方，排查对应的逻辑。

kernel driver优化：比对bootprof中各个设备的init耗时

init进程优化：比对log，查找init启动各个阶段的耗时（coldboot耗时异常问题，mount耗时，IO异常（串口log、kernel log level），CPU异常（异常进程占用CPU资源），额外的服务加载导致的耗时）

Android上层的耗时：Zygote preload 加载耗时差异，PMS scan差异，开机动画的差异，上层服务启动的差异

systrace分析check点：

开机过程中系统资源是否OK？CPU是否满频、IO是否存在大量 IO block

开机过程中是否有异常的进程启动

CPU大核上是否存在不合理的占用等

**4.内存相关的回收机制是怎么样的**

在AMS中当系统内存低时，按照回收优先级释放对应进程

OOM Killer 在内存紧张时会按照优先级杀死进程

在应用程序中，当AMS任务进程需要杀死时，会先回调scheduleLowMemory（）方法，通知目标进程释放内存

直接回收：发生内存分配，而此时的剩余空闲内存不足时，会执行立即内存回收。

定期回收：专门的内核线程kswapd0定期回收内存。

Linux 内存回收的具体方法

页缓存：通过LRU算法回收文件页缓存。包括cache、buffer，通过内存映射的文件映射页。

通过换出守护进程（kswapd）执行换页，它找出最近不使用的页加入到空闲链表，其中包括应用程序内存。页面换出涉及写入文件系统或者一个交换设备，仅在配置了交换文件或设备时才可用。

OOM（Out of Memory）机制：内存耗尽终结者搜索并杀死可牺牲的进程以释放内存。

手动回收：通过修改/proc/sys/vm/drop_caches的值进行手动回收，最好再执行下sync命令回写脏页

### 内核线程定期回收

kswapd0 扫描非活动和活动内存的LRU（最近最少被使用）页列表以释放页面。定义了三个内存阈值（watermark，也称为水位）

- 最小页面阈值（pages_min）
- 低页面阈值（pages_low）
- 高页面阈值（pages_high）

**5.整机性能的分析思路策略**

**6.常见的systrace分析思路等**

出现卡顿可能的原因：

温升策略限制CPU频率

低电限核限频

GPU绘制

网络原因

内存原因

程序本身的原因

被杀问题：确定被杀进程包名-确定时间点-确定原因

卡顿问题：本地复现问题，分析trace（查看SurfaceFlinger的vsync信号，通常来说两次间隔不应超过16ms，超过说明有掉帧现象，掉帧连续超过3次说明出现卡顿，观察CPU核数在出现问题的时候是否都处于online状态，CPU频率是否处于一个较高的状态，观察CPU是否繁忙，若是繁忙状态看是否CPU主要在处理当前进程，还是说在处理其他的进程导致当前进程卡顿）

响应慢的场景：滑动响应慢，按键唤醒响应慢

响应慢分析：分kernel层和userspace两层。kernel层一般检查log输出和驱动resume流程，userspace检查客制化流程，抓取systrace log

开关机时间问题分析：抓取log，查看耗时模块，交给对应模块人进行优化，通用开机时间优化方法

**开机内存vss pss rss uss概念及区别，都包含哪些内存，大小关系**

先说结论：—般情况下有：**VSS>=RSS>=PSS>=USS**

1VSs-Virtua.1 Set size虚以耗用内存（包含共享库占用的内存）

2RSS-Resident Set size实际使用物理内存（包含共享库占用的内存）

3PSS-Proportiona1 Set size实际使用的物理内存（比例分配共享库占用的内存）

4US5-Unique Set size进程独自占用的物理内存（不包含共享库占用的内存）

区别

·VSS:Virtual Set Size虚以耗用内存（包含共享库占用的内存），即单个进程全部可访问的地址空间，其大小可能包括还尚未在内存中驻留的部分。对于确定单个进程实际内存使用大小，VSS用处不大。

·RSS:Resident Set Size实际使用物理内存包含共享库占用的内存)，即单个进程实际占用的内存大小，RSS不太准确的地方在于它包括该进程所使用共享库全部内存大小。对于一个共享库，可能被多个进程使用，实际该共享库只会被装入内存一次。

·PSS:Proportional Set Size实际使用的物理内存（比例分配共享库占用的内存）PSS相对于RSS计算共享库内存大小是按比例的。N个进程共享，该库对PSS大小的贡献只有1N。

·USS:Unique Set Size进程独自占用的物理内存（不包含共享库占用的内存）即单个进程私有的内存大小，即该进程独占的内存部分。USS揭示了运行一个特定进程在的真实内存增量大小。如果进程终止，USS就是实际被返还给系统的内存大小。

1.VSS

也写做RT或SZ,它是进程使用的虚拟内存总量，不管是否有映射了物理内存。VSS在确认单个进程实际内存使用大小过程中用处不大。

比如malloc一块大内存，实际上只分配了虚拟地址，并没有映射（消耗）物理地址，只有对这块内存访问时（比如memeset)才会去映射物理内存。

VSS会高估实际内存使用量，因为程序通常会分配一些内存，但可能从来没用过。

2.RSS

也作RES或者RSS,这个是进程映射的物理内存数量。用RSS来计算程序内存使用量，可能稍微好些，但是还是会有高估：因为它没有考虑到进程间共享的内存。

3.PSS

PSS中除了独享的内存外，还会加上平均共享内存（共享的内存除以共享的进程数量，所以是平均值，也并不精确，占用多少跟共享内存大小及共享进程的数量有关）

PSS是一个非常有用的数字，因为系统中全部进程以整体的方式被统计，对于系统中的整体内存使用是一个很好的描述。

如果一个进程被终止，其PSS中所使用的共享库大小将会重新按比例分配给剩下的仍在运行并且仍在使用该共享库的进程。

此种计算方式有轻微的误差，因为当某个进程中止的时候，PSS没有精确的表示被返还给整个系统的内存大小。

4.USS

Uss只统计进程的独享内存，不包含与其他进程共享的内存。

[比如A和B进程都ink了Iibc.so](http://xn--abinkiibc-9b7n334cn6n851dzu1ben3dv1d.so/),那么A或B进程统计Uss时，将把Iibc.So占用的内存去掉。

Uss是一个非常非常有用的数据，因为它揭示了运行一个特定进程的真实内存增量大小

如果进程被终止，USS就是实际被返还给系统的内存大小。

USS是针对某个进程开始有可疑内存泄露的情况，进行检测的最佳数据。

我们假如进程的内存包括：

A=映射到物理内存的共享内存，这个会包含部分active的stack空间和heap空间。

B=进程间映时和共享空间，比如shared libraries

C=分配但是从未touch的虑拟地址空间.

那么对于每个Process:

Vss=A+B+C

Rss=A+B

Uss =A

Pss=A+Bln,n是共享这个内存的Processl的数量

- *项目中内存裁剪这块怎么做的

AMS WMS PMS IMS的作用以及流程**

1. AMS 主要用于管理所有应用程序的Activity
2. WMS 管理各个窗口，隐藏，显示等
3. PMS 用来管理跟踪所有应用APK，安装，解析，控制权限等.

AMS：ActivityManagerService简称AMS,它是android中很重要的一个服务，它统筹管理着android的四大组件；统一调度各应用进程

WMS：控制所有Window的显示与隐藏以及要显示的位置

PMS

1、提供一个应用程序的所有信息（ApplicationInfo）

2、提供四大组件的信息。

3、查询permission相关信息。

4、提供包的信息。

5、安装、卸载APK。

**AMS进程管理内存管理原理及方式ad值的计算**

1. 当应用程序关闭后，后台对应的进程并没有真正的退出进程只是处于sleep状态，以便下次启动能快速启动，即关闭而不退出；
2. 当系统内存不足时，AMS会回调相应的应用程序通知释放内存；
3. 当系统内存不足时，AMS主动根据一定的优先规则退出优先级较低的进程；

**5种进程都有什么优先级，以及查杀的顺序列举两到三个服务进程**

**systrace上从app收到vsync-app信号到屏幕出图的流程**

**surfaceflinger的概念及原理**

SurfaceFlinger最主要的功能：SurfaceFlinger接受来自多个来源的数据缓冲区，对它们进行合成，然后发送到显示设备。

当VSYNC信号到达时，SurfaceFlinger会扁历它的层列表，以寻找新的缓冲区。如果找到新的缓冲区，它会获取该缓冲区；否则，它会继续使用以前获取的缓冲区。SurfaceFlinger必须始终显示内容，因此它会保留一个缓冲区。如果在某个层上没有提交缓冲区，则该层会被忽略。SurfaceFlinger在收集可见层的所有缓冲区之后，便会间问Hardware Composer应如何进行合成。