APP 性能测试的背景
- 在任何软件的测试过程中，性能测试都是一个很重要的环节。我们一般所说的性能测试分为客户端及服务器端。针对客户端性能测试，尤其像游戏、视频类的软件，比如玩游戏不断卡顿、看视频电量消耗极快，都直接影响了用户体验。
- 对于性能测试的需求，主要来源于行业的通用标准，竞品的参考数据，历史版本的测试数据，或是直接的客户反馈等。App性能测试指标主要包括：响应、内存、CPU、FPS、GPU渲染、耗电、耗流等。
- APP性能测试的基本原理是在不同用户操作场景下通过监控APP的各项指标来识别和发现APP存在的代码质量问题并对程序进行修正和优化。
Android CPU占用
CPU使用率是性能测试是一项重要指标，CPU占用过高会使得设备运行程序出现卡顿与发热，甚至出现应用程序Crash,影响用户体验。在排除硬件环境的限制下，应用程序应该尽可能少的占用CPU。
CPU使用率原理
Android系统内核是基于Liunx,在Linux系统下CPU利用率分为用户态、系统态、空闲态，分别表示CPU处于用户态执行的时间，系统内核执行的时间，和空闲系统进程执行的时间。
平时所说的CPU利用率是指：CPU执行非系统空闲进程的时间 / CPU总的执行时间。那么这里所说的时间含义是什么呢？
- HZ：Linux 核心每隔固定周期会发出timer interrupt (时钟中断)，HZ是用来定义每一秒有几次时钟中断。例如HZ为1000，就代表每秒有1000次时钟中断。
- Jiffies：在Linux的内核中，有一个全局变量：Jiffies。 Jiffies代表时间。它的单位随硬件平台的不同而不同。jiffies的单位就是 1/HZ。
- Intel平台jiffies的单位是1/100秒，这就是系统所能分辨的最小时间间隔了。每个CPU时间片，Jiffies都要加1。
那么CPU利用率计算公式如下：
CPU使用率＝（用户态Jiffies＋系统态Jiffies）／总Jiffies
CPU测试方法
adb 命令
由于Android是基于Linux内核改造而成的操作系统，自然而然也能使用Linux的一些常用命令。比如我们可以使用top命令查看哪些进程是 CPU 的主要消耗者。
Top命令使用方法如下：
PS C:\Users\12446\Desktop> adb shell top --help
usage: top [-H] [-k FIELD,] [-o FIELD,] [-s SORT]
Show process activity in real time.
-H Show threads 显示线程
-k Fallback sort FIELDS (default -S,-%CPU,-ETIME,-PID)
-o Show FIELDS (def PID,USER,PR,NI,VIRT,RES,SHR,S,%CPU,%MEM,TIME+,CMDLINE)
-O Add FIELDS (replacing PR,NI,VIRT,RES,SHR,S from default)
-s Sort by field number (1-X, default 9)
注意:由于Android 8.0以后Google的权限限制，再也拿不到进程CPU的实时占用率，只能拿到自己本身进程的Jiffies，而由于拿不到系统整体Jiffies的情况下，就没办法衡量CPU当前的消耗状况了，也没办法根据当前CPU状态实时做一些策略调整。
adb shell top -m 100 -n 1 -d 1 -s 9
-t 显示进程名称，-s 按指定行排序，-n 在退出前刷新几次，-d 刷新间隔，-m 显示最大数量
输入adb shell top命令可以看到如下所示数据
Tasks: 124 total, 1 running, 123 sleeping, 0 stopped, 0 zombie
Mem: 3566392k total, 759068k used, 2807324k free, 15100k buffers
Swap: 0k total, 0k used, 0k free, 512064k cached
400%cpu 0%user 0%nice 0%sys 400%idle 0%iow 0%irq 0%sirq 0%host
PID USER PR NI VIRT RES SHR S[%CPU] %MEM TIME+ ARGS
2744 u0_a40 20 0 1.2G 106M 78M S 0.3 3.0 0:02.82 com.alipay.hulu
3305 root 20 0 6.8M 3.4M 2.8M R 0.0 0.0 0:00.15 top
2948 root 20 0 2.5M 496K 464K S 0.0 0.0 0:00.00 su --daemon
2829 u0_a12 20 0 881M 60M 40M S 0.0 1.7 0:00.06 com.android.onetimei
2804 u0_a3 20 0 882M 59M 39M S 0.0 1.7 0:00.16 com.android.carrierc
2798 u0_a11 20 0 882M 58M 38M S 0.0 1.6 0:00.10 com.android.managedp
2760 u0_a2 20 0 884M 68M 47M S 0.0 1.9 0:00.24 com.android.provider
2722 u0_a1 20 0 890M 82M 60M S 0.0 2.3 0:00.51 android.process.acor
2627 u0_a39 20 0 889M 63M 42M S 0.0 1.8 0:00.14 com.google.android.w
2555 u0_a37 20 0 882M 61M 41M S 0.0 1.7 0:00.08 com.android.printspo
2539 camerase 20 0 40M 7.7M 6.7M S 0.0 0.2 0:00.16 cameraserver
2497 system 10 -10 962M 165M 126M S 0.0 4.7 0:03.44 com.vphone.launcher
2483 system 20 0 882M 60M 40M S 0.0 1.7 0:00.06 com.android.keychain
2471 u0_a8 20 0 890M 80M 57M S 0.0 2.2 0:01.90 android.process.medi
2429 u0_a9 20 0 882M 60M 39M S 0.0 1.7 0:00.03 android.ext.services
2312 system 20 0 901M 72M 50M S 0.0 2.0 0:00.12 com.android.settings
2309 wifi 20 0 10M 4.8M 4.3M S 0.0 0.1 0:00.10 wpa_supplicant -ieth
2298 radio 20 0 900M 89M 65M S 0.0 2.5 0:00.41 com.android.phone
2251 media_rw 20 0 9.1M 3.3M 2.3M S 0.0 0.0 0:00.76 sdcard -u 1023 -g 10
2240 u0_a19 20 0 965M 149M 104M S 0.0 4.2 0:02.43 com.android.systemui
解释：
Tasks: 552 total, 1 running, 510 sleeping, 0 stopped, 0 zombie
任务(进程) 系统现在共有552个进程，其中处于运行中的有1个，510个在休眠（sleep），stoped状态的有0个，zombie状态（僵尸）的有0个。
Mem: 5849960k total, 4014628k used, 1835332k free, 5756k buffers
内存状态: 物理内存总量 (5.6G) 使用中的内存总量 空闲内存总量 缓存的内存量
1TB=1024GB ,1GB=1024MB ,1MB=1024KB ,1KB=1024字节。
Swap: 2293756k total, 1039804k used, 1253952k free, 918600k cached
swap交换分区: 交换区总量 使用的交换区总量 空闲交换区总量 缓冲的交换区总量
如果出于习惯去计算可用内存数，这里有个近似的计算公式：
Mem的free + Mem的buffers + Swap的cached
按这个公式此台服务器的可用内存：1835332k + 5756k + 918600k = 2759688k(约2.6G)
800%cpu 13%user 0%nice 31%sys 756%idle 0%iow 0%irq 0%sirq 0%host
cpu状态
800%cpu -- CPU总量
13%user -- 用户空间占用CPU的百分比。
0%nice -- 改变过优先级的进程占用CPU的百分比
31%sys -- 内核空间占用CPU的百分比
756%idle -- 空闲CPU百分比
0%iow -- IO等待占用CPU的百分比
0%irq -- 硬中断（Hardware IRQ）占用CPU的百分比
0%sirq -- 软中断（Software Interrupts）占用CPU的百分比
0%host --
[7m
PID — 进程id
USER — 进程所有者
PR — 进程优先级
NI — nice值。负值表示高优先级，正值表示低优先级
VIRT — 进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
RES — 进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
SHR — 共享内存大小，单位kb
S — 进程状态。D=不可中断的睡眠状态 R=运行 S=睡眠 T=跟踪/停止 Z=僵尸进程
%CPU — 上次更新到现在的CPU时间占用百分比
%MEM — 进程使用的物理内存百分比
TIME+ — 进程使用的CPU时间总计，单位1/100秒
COMMAND — 进程名称（命令名/命令行）
按cpu排序
adb shell top -s 9
如果使用adb shell top -m 10 -s cpu会报下面错误: top: not integer: cpu
想到adb top --help命令
我的adb shell top -s命令只支持0-X数字，默认9，猜测分别指代
0 ,1 ,3 ,4 ,5 ,6 ,7 ,8,9 ,10 ,11 ,12
PID,USER,PR,NI,VIRT,RES,SHR,S,%CPU,%MEM,TIME+,CMDLINE
其中，9刚好代表的是cpu
SoloPi测试应用CPU
性能数据查看与记录
- 勾选性能项，Soloπ会展示对应的性能指标
在进入应用前，Soloπ会显示全局指标，进入应用后，Soloπ会显示应用最上层进程的相关性能指标。
CPU、内存指标为进程维度，响应耗时、帧率、网络为应用维度，电池为全局指标。
具体性能指标描述请参考后文性能指标一段。
-
点击悬浮窗中的应用标题，进入目标应用，切换为进程维度数据
-
点击开始按钮（绿色三角），进行性能数据录制，可进行相关操作
-
结束录制，点击终止按钮（红色圆形），Soloπ会提示录制数据存放的位置，数据保存在/sdcard/solopi/records/XXX目录下
录制数据为csv格式，包含三列，第一列为Unix时间戳，第二列为数据数值，第三列为额外字段
-
点击悬浮窗右上角关闭键（红色"X"）可关闭悬浮窗，需要手动回到性能测试页面，可在录制数据查看一项中查看之前录制过的数据。
-
在录制项筛选中，可以选择之前录制的各项数据进行观看，内存与CPU会记录在顶层出现过的进程的数据。如果发生了进程切换，会记录前后10次数据。
-
当录制项过多时，可以点击右上角删除图标，对旧数据进行删除。
-
环境加压
Soloπ提供了环境加压的功能，可以提供CPU与内存加压
由于android系统的调度，CPU与内存加压均存在一定限制，当应用处于后台状态时，CPU加压占比会遭到一定程度的限制，而内存加压过大可能导致Soloπ被系统进行回收
自动化获取性能数据
前面我们使用adb命令获取CPU数据，但是如果想批量获取性能数据，使用命令一个个查询会非常的不方便，我们可以使用Python自动化代码来自动获取性能数据，代码实现如下：
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# @Time : 2022/6/11 21:23
# @Author : shisuiyi
# @File : autoApp_cup_meminfo .py
# @Software: win10 Tensorflow1.13.1 python3.9
import csv
from matplotlib import pyplot as plt
import os
import time
class Monitoring(object):
def __init__(self, count, pkg):
self.pkg = pkg # 包名
self.counter = count # 统计次数
self.cpudata = [("timestamp", "cpustatus")] # cpu性能数据
def getCurrentTime(self):
'''获取当前的时间戳'''
currentTime = time.strftime("%H:%M:%S", time.localtime())
return currentTime
def getCurrentDate(self):
'''获取当前日期'''
datetime = time.strftime("%Y-%m-%d %H_%M_%S")
return datetime
def monitoring_cpu(self):
'''cpu监控'''
result = os.popen(" adb shell top -m 100 -n 1 -d 1 -s 9 | findstr " + str(self.pkg)) # 获取cpu性能指标数据
res = result.readline().split(" ") # 根据返回数据进行分割
print(res)
if res == ['']: # 返回数据为空时处理
print('no data')
else:
print(res)
if 'S' in res:
index = res.index('S')
else:
index = res.index('R')
cpuvalue = res[index + 1] # 获取cpu数据
if cpuvalue == '':
cpuvalue = '0'
currenttime = self.getCurrentTime()
print("current time is:" + currenttime)
print("cpu used is:" + cpuvalue)
self.cpudata.append([currenttime, cpuvalue])
def get_cpu_datas(self):
'''连续获取cpu性能数据'''
while self.counter > 0:
self.monitoring_cpu()
self.counter = self.counter - 1
time.sleep(2)
def saveDataToCSV(self, data_type):
'''
存储性能测试数据
:param data_type:
:return:
'''
now = self.getCurrentDate()
if data_type == 'cpu':
csvnmame = './cpustatus_' + now + '.csv'
csvfile = open(csvnmame, 'w', encoding='utf8', newline='')
writer = csv.writer(csvfile)
writer.writerows(self.cpudata)
csvfile.close()
return csvnmame
else:
print('data_type error!')
def drawing(self,csvnmame):
# 加载CSV文件
file = csvnmame
with open(file) as f:
# 加载CSV模块阅读器
reader = csv.reader(f)
# 读取第一行表头
header_row = next(reader)
# 依次读取每行，并保存日期，cpu数据
dates, cpudatas = [], []
for row in reader:
current_date = row[0]
cpudata = float(row[1])
dates.append(current_date)
cpudatas.append(cpudata)
# 图像分辨率，尺寸设置
fig = plt.figure(dpi=128, figsize=(10, 6))
# 标题设置
plt.title('CpuStatus for date')
# X轴标签设置，自动更新格式
plt.xlabel(header_row[0])
fig.autofmt_xdate()
# Y轴标签和坐标范围设置
plt.ylabel(header_row[1])
plt.ylim(0, 100)
# 刻度设置
plt.tick_params(axis='both', which='both', labelsize=4)
# 根据数据画折线图
plt.plot(dates, cpudatas, linewidth=3, c='blue', alpha=0.5)
# 图像显示
plt.savefig((f'{file}')+'.png')
plt.show()
if __name__ == '__main__':
m = Monitoring(20, 'com.netease')
m.get_cpu_datas()
name = m.saveDataToCSV('cpu')
m.drawing(name)
内存使用率
从操作系统的角度来说，内存就是一块数据存储区域，是可被操作系统调度的资源。在多任务（进程）的操作系统中，内存管理尤为重要，操作系统需要为每一个进程合理的分配内存资源。所以可以从操作系统对内存分配和回收两方面来理解内存管理机制。
分配机制：为每一个任务（进程）分配一个合理大小的内存块，保证每一个进程能够正常的运行，同时确保进程不会占用太多的内存。
回收机制：当系统内存不足的时候，需要有一个合理的回收再分配机制，以保证新的进程可以正常运行。
内存分类
在Linux里面，一个进程占用的内存有不同种说法，有四种形式：
- VSS- Virtual Set Size 虚拟耗用内存
- RSS- Resident Set Size实际使用物理内存
- PSS- Proportional Set Size 按比例使用的物理内存
- USS- Unique Set Size 进程独自占用的物理内存
VSS
VSS是单个进程全部可访问的地址空间，其大小可能包括还尚未在内存中驻留的部分。对于确定单个进程实际内存使用大小，VSS用处不大。
RSS
RSS是单个进程实际占用的内存大小，RSS不太准确的地方在于它包括该进程所使用共享库全部内存大小。对于一个共享库，可能被多个进程使用，实际该共享库只会被装入内存一次。
PSS
PSS不同于RSS，它只是按比例包含其所使用的共享库大小。PSS相对于RSS计算共享库内存大小是按比例的。例如：3个进程使用同一个占用30个内存页的共享库。对于三个进程中的任何一个，PSS 将只包括10个内存页。 PSS 是一个非常有用的数字，因为系统中全部进程以整体的方式被统计， 对于系统中的整体内存使用是比较准确的统计。
USS
USS是单个进程私有的内存大小，即该进程独占的内存部分。USS揭示了运行一个特定进程在的真实内存增量大小。如果进程终止，USS就是实际被返还给系统的内存大小。
说明：
一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS
实际在统计查看某个进程内存占用情况的时候，看PSS是比较客观的
Android 内存测试
获取设备内存信息
在Linux操作系统中，/proc是一个位于内存中的伪文件系统(in-memory pseudo-file system)。该目录下保存的不是真正的文件和目录，而是一些运行时信息，如系统内存、磁盘io、设备挂载信息和硬件配置信息等。
使用命令adb shell cat /proc/meminfo查看设备的整体内存使用情况。
PS C:\Users\12446\Desktop> adb shell cat /proc/meminfo
MemTotal: 3566392 kB
MemFree: 2198376 kB
MemAvailable: 2979152 kB
Buffers: 86852 kB
Cached: 783012 kB
SwapCached: 0 kB
Active: 741664 kB
Inactive: 565176 kB
Active(anon): 439240 kB
Inactive(anon): 27952 kB
Active(file): 302424 kB
Inactive(file): 537224 kB
Unevictable: 256 kB
Mlocked: 256 kB
HighTotal: 3219400 kB
HighFree: 2071780 kB
LowTotal: 346992 kB
LowFree: 126596 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 40 kB
Writeback: 0 kB
AnonPages: 437168 kB
Mapped: 369552 kB
Shmem: 30232 kB
Slab: 37780 kB
SReclaimable: 14588 kB
SUnreclaim: 23192 kB
KernelStack: 6352 kB
PageTables: 9328 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1783196 kB
Committed_AS: 16437568 kB
VmallocTotal: 122880 kB
VmallocUsed: 81660 kB
VmallocChunk: 21228 kB
DirectMap4k: 16376 kB
DirectMap4M: 368640 kB
PS C:\Users\12446\Desktop>
部分参数含义如下：
MemTotal: 表示可供系统支配的内存,系统从开机到加载完成，操作系统内核要保留一些内存，最后剩下可供系统支配的内存就是MemTotal。
- MemFree:表示系统尚未使用的内存。
- MemAvailable：应用程序可用内存大小。
系统中有些内存虽然已被使用但是可以回收的，比如cache可以回收，
所以MemFree不能代表全部可用的内存，这部分可回收的内存加上MemFree才是系统可用的内存，
即：MemAvailable≈MemFree+系统回收内存，它是内核使用特定的算法计算出来的，是一个估计值。
它与MemFree的关键区别点在于，MemFree是说的系统层面，MemAvailable是说的应用程序层面。
- Cached: 缓冲区内存大小。
- Buffers: 缓存区内存大小。
获取指定包的内存占用情况
我们可以使用adb命令来测试指定进程包名的内存使用详细情况，命令格式如下：
adb shell dumpsys meminfo [pkg or pid]
命令执行之后如下所示
C:\Users\12446>adb shell dumpsys meminfo 3397
Applications Memory Usage (in Kilobytes):
Uptime: 4356982 Realtime: 4356982
** MEMINFO in pid 3397 [com.netease.cloudmusic] **
Pss Private Private Swap Heap Heap Heap
Total Dirty Clean Dirty Size Alloc Free
------ ------ ------ ------ ------ ------ ------
Native Heap 0 0 0 0 38912 33641 5270
Dalvik Heap 24831 24700 0 0 29009 21757 7252
Dalvik Other 1258 1256 0 0
Stack 912 912 0 0
Ashmem 132 132 0 0
Other dev 16 0 12 0
.so mmap 7699 1532 1252 0
.apk mmap 7234 124 16 0
.ttf mmap 287 0 88 0
.dex mmap 16189 8 7644 0
.oat mmap 5072 0 384 0
.art mmap 4638 4228 0 0
Other mmap 3156 4 448 0
Unknown 28135 28064 0 0
TOTAL 99559 60960 9844 0 67921 55398 12522
1,484K: sdcard (pid 2250)
App Summary: drmserver (pid 1881)
Pss(KB)
------
Java Heap: 2892883)
Native Heap: 09)
Code: 11048
Stack: 912 1803)
Graphics: 082)
Private Other: 299160)
System: 28755
546K: lmkd (pid 1873)
TOTAL: 99559 TOTAL SWAP (KB): 0
484K: servicemanager (pid 1874)
Objects335K: debuggerd (pid 1744)
Views: 435 ViewRootImpl: 1
AppContexts: 6 Activities: 1
Assets: 3 AssetManagers: 5
Local Binders: 63 Proxy Binders: 35
Parcel memory: 19 Parcel count: 76
Death Recipients: 3 OpenSSL Sockets: 0
WebViews: 0(pid 1884)
4,904K: mediaserver (pid 1887)
SQL 4,662K: media.extractor (pid 1886)
MEMORY_USED: 851(pid 1879)
PAGECACHE_OVERFLOW: 281 MALLOC_SIZE: 62
2,103K: cameraserver (pid 2518)
DATABASES2,094K: mediadrmserver (pid 1885)
pgsz dbsz Lookaside(b) cache Dbname
4 236 375 18/37/19 /data/user/0/com.netease.cloudmusic/databases/cloudmusic.db 1,526K: logd (pid 1737)
4 24 29 1/16/2 /data/user/0/com.netease.cloudmusic/databases/web_cache_info.db 1,484K: sdcard (pid 2250)
4 20 81 1217/868/25 /data/user/0/com.netease.cloudmusic/databases/netease_apm.db 1,331K: adbd (pid 1800)
4 24 20 1/16/2 /storage/emulated/0/netease/utils/wu.dat
4 48 88 52/41/21 /data/user/0/com.netease.cloudmusic/databases/mobidroid.sqlite 896K: healthd (pid 1869)
4 52 52 2/17/3 /data/user/0/com.netease.cloudmusic/databases/transfer.db
734K: gatekeeperd (pid 1803)
Asset Allocationsinstalld (pid 1882)
zip:/data/app/com.netease.cloudmusic-1/base.apk:/resources.arsc: 1331K
560K: su (pid 2911)
C:\Users\12446>K: lmkd (pid 1873)
536K: dumpsys (pid 4525)
484K: servicemanager (pid 1874)
335K: debuggerd (pid 1744)
324K: ueventd (pid 1141)
264K: debuggerd:signaller (pid 1751)
82,177K: System
82,177K: system (pid 2172)
76,506K: Persistent
58,958K: com.android.systemui (pid 2241)
17,548K: com.android.phone (pid 2298)
55,859K: Foreground
41,956K: com.android.gallery3d (pid 4347 / activities)
13,903K: android.process.media (pid 2565)
4,963K: Visible
4,963K: android.ext.services (pid 2427)
41,784K: Perceptible
41,784K: com.alipay.hulu (pid 2719 / activities)
35,770K: A Services
35,770K: com.netease.cloudmusic:play (pid 3473)
48,034K: Home
48,034K: com.vphone.launcher (pid 2522 / activities)
139,669K: B Services
100,601K: com.netease.cloudmusic (pid 3397 / activities)
39,068K: com.netease.cloudmusic:browser (pid 3443)
123,454K: Cached
38,824K: com.netease.cloudmusic:cmMP1 (pid 3454)
29,869K: com.android.systemui:screenshot (pid 4274)
12,131K: android.process.acore (pid 2465)
11,031K: com.android.settings (pid 2311)
6,724K: com.android.providers.calendar (pid 2793)
5,566K: com.google.android.webview:webview_service (pid 2638)
5,483K: com.android.printspooler (pid 2506)
4,908K: com.android.managedprovisioning (pid 2814)
4,560K: com.android.carrierconfig (pid 2829)
4,358K: com.android.onetimeinitializer (pid 2861)
Total PSS by category:
190,269K: Unknown
100,012K: .dex mmap
89,950K: .so mmap
88,107K: Dalvik
60,984K: .oat mmap
44,825K: .art mmap
39,863K: .apk mmap
24,186K: Other mmap
23,744K: Ashmem
12,216K: Dalvik Other
9,871K: .ttf mmap
8,552K: Stack
533K: Other dev
160K: .jar mmap
32K: Native
0K: Cursor
0K: Gfx dev
0K: EGL mtrack
0K: GL mtrack
0K: Other mtrack
Total RAM: 3,566,392K (status normal)
Free RAM: 2,930,922K ( 123,454K cached pss + 310,708K cached kernel + 2,496,760K free)
Used RAM: 689,694K ( 569,850K used pss + 119,844K kernel)
Lost RAM: -54,224K
Tuning: 128 (large 192), oom 184,320K, restore limit 61,440K (high-end-gfx)
重点关注参数
一般情况下横轴仅需关注Pss Total和Private Dirty列。 Private Dirty表示进程独占内存。
- Native Heap：Native代码分配的内存。native进程采用C/C++实现，不包含dalvik实例的linux进程，/system/bin/目录下面的程序文件运行后都是以native进程形式存在的.
- Dalvik Heap：Java对象分配的占据内存
其他参数 - Dalvik Other：类数据结构和索引占据内存。
- Stack：栈内存
- Ashmem：不以dalvik- 开头的内存区域，匿名共享内存用来提供共享内存通过分配一个多个进程可以共享的带名称的内存块。匿名共享内存（Anonymous Shared Memory-Ashmem。Android匿名共享内存是基于Linux共享内存的，都是在tmpfs文件系统上新建文件，并将其映射到不同的进程空间，从而达到共享内存的目的，只是Android在Linux的基础上进行了改造，并借助Binder+fd文件描述符实现了共享内存的传递。
- Other dev：内部driver占用的内存
- .so mmap C库代码占用的内存
- .jar mmap java文件代码占用的内存
- .apk mmap apk代码占用的内存
- .ttf mmap ttf文件代码占用的内存
- .dex mmap dex文件代码占用内存。类函数的代码和常量占用的内存，dex mmap是映射classex.dex文件，Dalvik虚拟机从dex文件加载类信息和字符串常量等。Dex文件有索引区和Data区
- Other mmap 其它文件占用的内存
重点关注如下几个字段：
- Native/Dalvik 的 Heap 信息
具体在上面的第一行和第二行，它分别给出的是JNI层和Java层的内存分配情况，如果发现这个值一直增长，则代表程序可能出现了内存泄漏。 - Total 的 PSS 信息
这个值就是你的应用真正占据的内存大小，通过这个信息，你可以轻松判别手机中哪些程序占内存比较大了。
启动耗时
应用启动是整个App工序的第一道流程。对于开发者，一般需要在应用启动过程中进行初始化工作，启动页的UI展示。而对于用户来说，启动速度的快慢则极大地影响了使用体验，并且间接地影响了用户的留存率。
应用的启动方式
冷启动：当启动应用时，后台没有该应用的进程，这时系统会首先会创建一个新的进程分配给该应用，这种启动方式就是冷启动。
热启动：当启动应用时，后台已有该应用的进程，这种启动方式叫热启动。
一般测试过程中更多的关注冷启动时间。
adb 命令方式获取
通过命令adb shell am start -W [PackageName]/[PackageName.MainActivity]获取启动时间。
C:\Users\12446> adb shell am start -W com.lemon.lemonban/.activity.MainActivity
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.lemon.lemonban/.activity.MainActivity }
Status: ok
LaunchState: COLD
Activity: com.lemon.lemonban/.activity.MainActivity
TotalTime: 677
WaitTime: 679
Complete
这里面涉及到三个时间，ThisTime、TotalTime 和 WaitTime。
- ThisTime 表示启动一连串 Activity 的最后一个 Activity 的启动耗时。
- TotalTime 表示新应用启动的耗时，包括新进程的启动和 Activity 的启动，但不包括前一个应用 Activity pause 的耗时。也就是说，开发者一般只要关心 TotalTime 即可，这个时间才是自己应用真正启动的耗时。
- WaitTime 就是总的耗时，包括前一个应用 Activity pause的时间和新应用启动的时间。
Solopi
响应耗时计算工具
Soloπ响应耗时计算工具，通过录屏分帧的方式自动识别起始点和结束点，精确计算耗时。
响应耗时计算
特性
- 模拟用户视觉，计算结果更贴近用户体验
- 自动记录点击起始点，自动识别屏幕变化结束点
- 通过OpenCV进行图像识别
- 支持原生应用、H5、游戏
- 支持启动耗时、页面跳转耗时、列表滑动耗时、动画耗时
使用方法
- 进入Soloπ性能测试页面，点击启动耗时计算。
- 建议默认参数无需修改，点击启动按钮，会弹出录制浮窗。
- 切换至待测应用，并进入操作路径的起始页面。
如果不需要关注细微的动画，请将二值对比差异设置为2%
- 点击开始录制（按钮会变为结束录制），然后在被测应用界面执行操作
- 当页面停止变化后，点击结束录制。几秒后会显示测试结果。
注意事项
- 结束页存在轮播图？
- 请在进入结果页后，在轮播图变化前点击结束录制
- 测试结果异常：过大，过小，或为负数？
- 本次结果失效，请重新测算。结果以多次测算后稳定的结果为准。
- 结束录制后，一直阻塞在计算中？
- 请关闭浮窗，退出Soloπ，重新打开耗时计算工具进行测算。
评论