移动端性能

本文探讨了Chromium WebView 62版本的稳定性及其在手机App中的性能表现,介绍了性能监控方法,如Appium结合WebViewContext和executescript,以及webviewdomainsocket的使用。同时,覆盖了线上监控策略,包括数据采集与系统性能数据监测,深入分析了内存、CPU、渲染对客户端的影响,并详细阐述了卡顿现象的原因及解决思路。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

chromium渲染手机app的webview 62版本是最稳定的
在这里插入图片描述

性能

https://github.com/w3c/web-performance
https://developers.google.com/web/tools/chrome-devtools/evaluate-performance
在这里插入图片描述
在这里插入图片描述

  • 列出整个网页加载的时间在这里插入图片描述
  • 查看与network一样的API,列举出所有的资源,显示每个Entries
    在这里插入图片描述
  • 打印第三个json格式显示出来
    在这里插入图片描述 在这里插入图片描述
    综合上述,性能获取办法
  • Appium + WebView Context + execute script + perfermance api
    自动化时切换到webview,注入js使用execute script,使用performance api,得到数据传入监控记录
  • webview domain socket + forward + websocket
    测webview的domain socket(包括chromedriver也是使用的domain socket), 然后forward到本地,然后通过websocket调里面的数据,websocket可以与webview的调试句柄进行连接,执行里面的命令,执行js、各种点击,获取结果,将数据导入即可。

线上监控

生产环境:在代码中注入js,传回每次的性能数据
测试环境:数据采集(appium/selenium)+监控系统
在这里插入图片描述

系统性能数据,资源利用率

发热量/内存泄露,和资源释放对客户端的影响较大,但是cpu 和 内存 尚可,无须费心关注
黑盒:
adb shell top -u -o %CPU,%MEM,RES,CMDLINE -b -d 1 -n 1
-o:打印 pid user PR IN VIRT RES SHR S
-p:pid
-u:user,多数使用-u
-h:打印线程
-s:根据字段数排序
-d:每几秒统计一次
-n: (top 的bug )后面的数字不可过大,次数
-q:去掉头信息

实时打印的话,可以写个循环
while true;do
adb shell top -u -o %CPU,%MEM,RES,CMDLINE -b -d 1 -n 1;
done

-u怎样来获取:ps -ef | grep xueqiu
在这里插入图片描述
RES:虚拟内存,是app的申请的内存,不管是否使用,我先申请了,所以以此数据为准
SHR:共享内存,是一些第三方so的内存
RES内存是一个大概的统计,若是查看具体的内存大小,可使用如下命令
adb shell dumpsys meminfo com.xueqiu.android

黑盒测试内存泄露
adb shell dumpsys meminfo com.xueqiu.android
在这里插入图片描述
对比如上两个值,通常Private Dirty是会比pss total的值小一点点,且会及时释放。但是此测试方法不够精准。

adb shell dumpsys netstats detail:统计网络情况

一些性能相关的资源利用率都在手机的/proc/进程uid 文件下,需手机root权限

卡顿

普及:1秒24帧,当你一秒内看到画面是连续的,是24张图片一起的
android的标准比上面高,标准是人眼感知的流畅度不能小于60fps
影响因素:内存,cpu,render

  • 内存:内存垃圾回收,耽误的时间越久,越慢(内存抖动/fullgc)
  • cpu:cpu处理数据的时候包括GPU(计算耗时)
  • render:是说布局足够复杂,一环套一环,过度绘制也会造成卡顿释放的越慢(布局复杂/overdraw)
    过度绘制:

可使用设备的setting下开发者模式里的过度GPU绘制

在这里插入图片描述
统计跳帧:
adb shell dumpsys gfxinfo $package
total frames render: 总共绘制了多少帧
janky frames: 跳帧比例,没有进行及时的绘制
有1%的帧是在61ms以上
5%的帧是在48ms以上
10%的帧是在42ms以上
50%的帧是在26ms以上
在这里插入图片描述

开发者模式下 - GPU 呈现模式分析-在屏幕上显示为条形图

systrace --最权威剖析技术

使用这个测试方法,可查看到具体的函数的某一帧,查找问题
只适用于python2.7
./systrace.py -l 列举所有支持的性能数据分类
./systrace.py -t 10 收集10s左右的系统性能数据
./systrace.py -t 10 -j 保存一份 json 数据文件用于编程分析

白盒测试内存泄漏:代码中嵌入 LeakCanary 的 app

monitor

在这里插入图片描述
点击app时,系统会首先创建一个进程linux,向cpu发起指令,分配内存,这是进程创建端过程,会启动android的虚拟机例如art/dalvik
然后才是你写的java或者kotil代码,应用开始创建,执行java逻辑,启动线程开始渲染用户界面

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值