手机性能测评之自定义获取gfxinfo信息

本文探讨了Android系统中2D渲染性能的评估方法。介绍了Google推出的Project Butter带来的60fps动画支持,并讨论了开发者选项及gfxinfo工具的使用限制。最终提供了一个利用反射获取gfxinfo数据的方案。

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

概述

我们知道android系统的显示是需要cpu和gpu的配合。cpu先将数据(如:bitmap/material等)准备好,然后交给gpu进行图像合成,然后刷到LCD上面。
Google在Jelly Bean(4.1)的推出了Project Butter(黄油计划),让系统的渲染和动画都使用vsync的方式,支持高达60fps的动画效果,换算一下也就是说绘制一帧的时间是16ms。
有了这个理论支持,我们就可以让不同手机跑相同的2D场景,拿到每一帧的绘制时间,然后根据这个时间长短来判断每个手机的跑2D场景的能力。

现有手段

开发者选项

进入开发者选项,然后打开Monitoring-->Profile GPU rendering -->On Screen as bars后,会出现如下的结果


developer_profile.png


其中,水平的那条绿线表示的就是16ms的基准线,垂直的线则表示每帧绘制所花费的时间。根据前面的理论可以知道,超过水平绿线的帧是超过了16ms的绘制时间,如果超过的帧越多,则表示该界面会越卡顿。

gfxinfo

其实这个方式是上面方式的手动版,需要使用命令

adb shell dumpsys gfxinfo [Package Name]

来抓取graphic的信息,但是这个命令只能抓取前128帧的数据。网上已经有很多使用和分析方法,这里不再累述。可以查看以下链接。
android developer
国内Falcon Pro为例的翻译版

疑难

如果我们想做一款评测软件,期望的动作是,用户点击开始评测,然后软件自己跑2D场景,一段时间后,给出一个分数来表示这段时间每帧绘制是否卡顿,以此来表示该机器2D处理能力。
但上面的二种方式无疑不合适该需求。

解决方案

只有看下gfxinfo的实现,然后写一个程序对其实现进行包装,获得每帧的绘制时间后,再对这个结果进行处理。
dumpsys实现原理中的gfxinfo实例讲解可以知道,如果想要在程序里面dump数据需要dump权限

android.Manifest.permission.DUMP

但是三方app是没办法拿到该权限的。
那我们能不能直接执行权限检查通过后的

 mActivityManagerService.dumpGraphicsHardwareUsage(fd, pw, args);

代码呢?

由于该方法是私有方法,如果想调用只能使用反射,但是该方式又是属于AMS的,属于systemserver这个进程,和我们三方app不是同一个进程,也不能使用反射,所以这条路也不通。

救命稻草

没有办法,只有继续看dumpGraphicsHardwareUsage的实现。
gfxinfo实例讲解知道,最后正真触发dump动作的地方是在ActivityThread的ApplicationThread类。
看到ActivityThread,是不是十分激动?!!没错,这个ActivityThread其实表示的就是一个应用程序的Process,我们三方应用当然也有这个ActivityThread。所以,我们可以从这里动手!
虽然ApplicationThread是一个私有的内部类,但是因为和我们的测评程序在一个进程,所以我们可以使用反射的方法执行想要的函数.
核心代码如下:

Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");
Method currentActivityThreadMethod = activityThreadClass.getDeclaredMethod("currentActivityThread");
currentActivityThreadMethod.setAccessible(true);
ActivityThread currentActivityThread = (ActivityThread)currentActivityThreadMethod.invoke(null);


Class<?> application = Class.forName("android.app.ActivityThread$ApplicationThread");
Method method = application.getDeclaredMethod("dumpGfxInfo",new Class[]{FileDescriptor.class, String[].class});
method.setAccessible(true);
method.invoke(currentActivityThread.getApplicationThread() , fd , new String[]{"com.example.hly.fpsdetection"});

其中,fd是保存gfxinfo信息的fd,可以将信息存在SD卡内上,也可以存在其他任意可读写位置。
com.example.hly.graphicdemo是demo程序的包名,表示dump的是当前程序的graphic信息。当然这里是可以替换成其他任意包名。

注意:

当我们得到gfxinfo的信息后,还不能直接使用,需要对保存的fd文件进行文本解析,拿出Draw Process Execute三项的时间相加才是最后一帧绘制所花的时间。 这里并没有做文件解析相关的介绍.

selinux的限制

虽然以上代码可以dump出gfxinfo得信息,但是一般手机默认是没有在开发者选项中开启Profile GPU rendering的,所以dump出得信息中没有最重要的Draw Process Execute这三列的信息。
想要有这3列信息必须要在开发者选项中打开Profile GPU rendering。

在selinux默认没有开启的手机中可以通过如下代码打开Profile GPU rendering:

SystemProperties.set("debug.hwui.profile", "true");

其中"true":表示的是Profile GPU rendering中"in adb shell dumpsys gfxinfo"那一栏,不会在屏幕上显示图案
而"visual_bars":表示的是"Onscreen as bars"那一栏,则会在屏幕上显示出图案
"false" :表示"Off"那一栏,关闭profile,是默认值

但在selinux默认开启的手机中,三方app在设置debug.hwui.profile这个属性值的时候会被拒绝。
只能说现在手机安全系数是越来越高,被限制后唯一的解决办法就是:

引导用户开启Profile GPU rendering   = =!!!

下载

github demo

<think>嗯,用户想要了解如何对移动应用程序客户端进行性能测试,包括关键指标和工具推荐。这个问题很专业,用户可能是移动应用测试工程师或者开发人员。 从用户的问题来看,ta需要的是实操性很强的指导。结合之前的引用内容,特别是引用[2]提到要从不同角色关注点出发总结性能指标,引用[4]强调了Android客户端的电量测试特点,这些都是重要参考。 用户可能真正关心的是如何落地执行测试,而不仅仅是理论。ta可能面临的实际困难包括:不知道要测哪些具体指标、找不到合适的工具、缺乏测试方法。考虑到移动端有Android和iOS两大平台,需要分别说明。 关于关键指标,应该覆盖用户最直观感受到的性能维度:启动速度、界面流畅度、资源消耗、稳定性等。其中引用[4]特别提到的电量测试需要重点展开,因为这是移动端特有的痛点。 工具推荐要区分平台特性:Android可以用adb获取底层数据,iOS依赖Xcode工具链。同时要考虑用户的技术水平,推荐一些图形化工具如PerfDog会更友好。 测试方法部分需要结构化说明,从测试环境搭建到具体执行步骤。考虑到用户可能是新手,要强调真机测试的重要性,以及如何模拟不同网络条件。 最后生成的问题要帮助用户深入理解,比如工具对比、指标优化方法等,这样用户可以根据实际需求继续探索。</think>以下是针对移动应用程序客户端性能测试的完整指南,涵盖关键指标、测试工具及实施步骤: --- ### **一、关键性能指标** 1. **启动时间** - **冷启动**:应用首次加载时间(从点击图标到首页渲染完成) - **热启动**:应用后台唤醒时间(从后台切换到前台) *目标值:冷启动≤1.5秒,热启动≤0.5秒* [^2] 2. **界面流畅度** - **帧率(FPS)**:≥60 FPS为流畅,Android可通过`adb shell dumpsys gfxinfo`获取 - **卡顿率**:1秒内帧数<40的占比需<5% [^4] 3. **资源消耗** - **CPU占用**:核心线程占比≤70%,避免长时间满载 - **内存占用**:PSS(实际物理内存)需<设备总内存的30% - **电量消耗**:后台每小时耗电≤3%,前台≤15%/小时 [^4] 4. **网络性能** - API请求响应时间:95%的请求≤1秒 - 弱网环境(2G/3G)下功能可用性 5. **稳定性** - **崩溃率(Crash Rate)**:<0.1%(日活万分之⼀) - **ANR率**(Android):主线程阻塞>5秒的发生率<0.05% --- ### **二、测试工具推荐** #### **1. 多平台通用工具** | 工具 | 特点 | |---------------|----------------------------------------------------------------------| | **PerfDog** | 腾讯出品,支持Android/iOS,无需Root,可测FPS/CPU/内存/网络流量 [^2] | | **GT** | 开源的随身调测平台,支持自定义性能数据采集(如功耗、帧率) | | **SoloPi** | 阿里开源自动化工具,录制回放+性能监测(内存泄漏检测) | #### **2. Android专属工具** ```bash # ADB命令示例(需USB调试): adb shell dumpsys meminfo <package_name> # 内存详情 adb shell top -n 1 | grep <package_name> # 实时CPU占用 adb shell batterystats --reset # 电量测试初始化 ``` #### **3. iOS专属工具** - **Xcode Instruments**: - Time Profiler(CPU分析) - Energy Log(电量消耗) - Core Animation(FPS检测) #### **4. 云测试平台** - **AWS Device Farm**:真机集群测试,支持性能监控 - **Sauce Labs**:自动化脚本+性能报告生成 [^1] --- ### **三、测试实施步骤** 1. **环境搭建** - 使用真机(非模拟器),关闭后台无关进程 - 设置网络代理(如Charles)模拟弱网/高延迟 2. **场景设计** - 高频操作:页面跳转、列表滑动、大图加载 - 极端场景:低电量模式、多应用切换压测 3. **数据采集** ```mermaid graph LR A[启动测试] --> B[记录冷/热启动时间] C[滑动测试] --> D[采集FPS/卡顿次数] E[长时间运行] --> F[监控内存泄漏] ``` 4. **分析优化** - 定位瓶颈:Traceview(Android)/ Instruments(iOS)分析函数耗时 - 内存优化:MAT工具分析Heap Dump,排查未释放对象 > **案例**:某电商App通过PerfDog发现图片加载卡顿,优化为懒加载+WebP格式后,FPS从45提升至58,冷启动时间减少40% [^2]。 --- ### **四、常见问题规避** - **内存泄漏**:单例持有Context、Handler未解绑 - **ANR触发**:主线程执行数据库操作/网络请求 - **电量过高**:频繁唤醒CPU(如冗余后台定位) ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值