Android App卡顿分析,以及使用Choreographer进行帧率统计监测

1、背景:

卡顿是最影响App用户体验的原因之一。卡顿造成的原因多种多样,简单列举一下
 
1、布局层级过多,设置无用的背景色,布局中添加了多种不必要的背景色,导致view绘制的时候多次绘制,引起卡顿
2、布局太复杂,嵌套过多,例如RelativeLayout 相比LinearLayout,可以有效减少布局层级,层级太复杂,会影响view的measure时间,进而造成卡顿。
3、内存使用不当,主线程做了大量计算或者IO操作等,这样就不举例说明了。

2、性能问题常用检测方法

检测app绘制性能的方法多种多样:

如针对对于布局层级过多,可以使用开发者选项-->调用GPU过度绘制 方式查看。

针对布局复杂,可以用Hierarchy Viewer

也可以使用腾讯提供的性能检测工具:GT(GitHub地址:https://github.com/FanGuangcheng/GT)

 然而,这所有的检测方法都是开发阶段进行的,当我们的app投放到市场之后,我们不知道用户那边使用的真实场景是怎样的。

我们开发、测试进行的性能检测,都是针对我们的开发机器,没法真实模拟用户场景,比如用户多种多样的机型、内存大小、app使用状态、SD卡使用状态等等。
因此我们需要一种线上的监测机制,实时统计用户的卡顿数据,获得用户使用的第一手资料,并有针对性的对某些功能页面进行优化,更好的提升用户体验。



3、android绘制原理

* Android 16ms原理*:Android系统每隔16ms会发出VSYNC信号重绘我们的界面(Activity).为什么是16ms, 因为Android设定的刷新率是60FPS(Frame Per Second), 也就是每秒60帧的刷新率, 约合16ms刷新一次.
如下图所示:
16ms

如图中所示,每隔16ms,系统都会发出VSYNC信号,如果这时候我们的画面(view)准备好了,我们的view绘制就会很流畅。如果我们在这个16ms间隔内,没有准备好画面(view),那么这一次绘制,就不会展示在屏幕上,就相当于少绘制了一帧,画面就会出现卡顿,断断续续。 如下图所示

卡顿的原因

4、Choreographer 监测掉帧原理

在Choreographer中有个回调接口,FrameCallback。

public interface FrameCallback
{
public void doFrame(long frameTimeNanos);
}

doFrame 的注释如下:* Called when a new display frame is being rendered.
就是说,当新的一帧被绘制的时候被调用。
因此我们利用这个特性,可以统计两帧绘制的时间间隔。
主要流程如下:
* 1、实现Choreographer.FrameCallback接口,比如实现类是FrameSkipMonitor
* 2、在doFrame中统计两帧绘制的时间,代码与注释如下:
@Override
public void doFrame(long frameTimeNanos) {
if (mLastFrameNanoTime != 0) {//mLastFrameNanoTime 上一次绘制的时间
long frameInterval = frameTimeNanos - mLastFrameNanoTime;//计算两帧的时间间隔
//如果时间间隔大于最小时间间隔,3*16ms,小于最大的时间间隔,60*16ms,就认为是掉帧,累加统计该时间
//此处解释一下原因: 因为正常情况下,两帧的间隔都是在16ms以内 ,如果我们统计到的两帧间隔时间大于三倍的普通绘制时间,我们就认为是出现了卡顿,之所以设置最大时间间隔,是为了有时候页面不刷新绘制的时候,不做统计处理
if (frameInterval > MIN_FRAME_TIME && frameInterval < MAX_FRAME_TIME) {
long time = 0;
if (mSkipRecordMap.containsKey(mActivityName)) {
time = mSkipRecordMap.get(mActivityName);
}
mSkipRecordMap.put(mActivityName, time + frameInterval);//统计时间
}
}
mLastFrameNanoTime = frameTimeNanos;
Choreographer.getInstance().postFrameCallback(this);
Runtime.getRuntime().maxMemory();
}

  • 3、启动监测
    public void start() {
    Choreographer.getInstance().postFrameCallback(FrameSkipMonitor.getInstance());
    }

  • 4、上报处理
    在doFrame选中,我们已经统计到了想要的数据,然后我们将time的值除以16600000(因为我们统计的时间是纳秒),就是掉帧的数字。

demo源码地址:https://github.com/FanGuangcheng/FrameSkipMonitor
源码简要解读:
最重要的两个类
FrameSkipMonitor:统计绘制间隔的时间处理操作。
MyActivityLifeCycle:activity相关的跳转纪录操作,通过纪录,就可以统计每个页面的掉帧卡顿时间。



参考资料:
1、http://www.jianshu.com/p/1fb065c806e6
2 、https://mp.weixin.qq.com/s?__biz=MzAxMzYyNDkyNA==&mid=2651332439&idx=1&sn=ba542ffeb494d827b9009d4e2128ed5c&scene=1&srcid=0818mFLqkkIMoS7vzjxTOEq2&key=8dcebf9e179c9f3a440c75502cc03ba23f09db161f5a3a4bd15acbdaa6b2ac0e641552d3b40a09b753739924009c9bfb&ascene=0&uin=Mjc3OTU3Nzk1&devicetype=iMac+MacBookPro10%2C1+OSX+OSX+10.10.5+build%2814F1909%29&version=11020201&pass_ticket=jzkG1H7kXvY27npmMnFUaa1eMShQT4c0PYd9r8wDanabk59MHU0ynkDd6oxen8jH
<think>嗯,用户想分析Android系统卡顿的原因和解决方法。首先,我需要回忆一下Android系统的工作原理,可能涉及资源管理、硬件性能、软件优化等方面。卡顿通常发生在UI渲染不流畅或者应用响应延迟,所以可能的原因包括CPU过载、内存不足、I/O阻塞、代码效率低等。 接下来,要结合用户提供的引用内容。引用[1]提到Android Studio有监控和分析工具,这可能帮助开发者检测性能问题。比如使用Profiler工具查看CPU、内存使用情况。引用[4]讲到了可扩展性和实时处理,这可能关联到系统资源管理和后台进程的影响,比如过多的后台服务占用资源导致卡顿。 然后,我需要组织回答的结构。先分析原因,再提供解决方法。可能的原因分几个大类,比如硬件限制、系统层问题、应用层问题、系统设置等。每个大类下再细分具体因素,比如硬件包括CPU、内存、存储;系统层包括渲染机制、后台进程、碎片化;应用层包括代码质量、第三方库、内存泄漏等。 解决方法部分需要对应原因,例如硬件问题可能建议清理存储或更换设备,系统层优化可以调整开发者选项中的动画缩放,使用轻量级ROM。应用层则需要使用性能分析工具,优化代码,避免内存泄漏。另外,引用[3]提到的Google文件系统的设计原则,可能对数据存储和I/O优化有参考,但不确定是否直接相关,可能需要排除。 还要考虑用户可能的身份,是普通用户还是开发者。如果是开发者,可能需要更深入的技术方案,比如使用StrictMode检测主线程操作。如果是普通用户,建议更偏向于系统设置调整和应用管理。但用户的问题中提到“分析”,可能用户有一定的技术背景,所以需要兼顾两者。 最后,生成相关问题,帮助用户进一步探索。比如如何检测内存泄漏,如何优化布局渲染,第三方库的影响等。确保问题覆盖用户可能关心的其他方面,同时促进深入学习。</think>### Android系统卡顿分析与解决方法 #### 一、卡顿根本原因分析 1. **硬件资源瓶颈** - CPU负载过高:后台进程过多或应用存在死循环(如$O(n^2)$时间复杂度算法) - 内存不足:频繁触发GC(垃圾回收)导致暂停,可用内存低于阈值$Mem_{free} < 100MB$ - 存储性能下降:当磁盘剩余空间低于$5\%$时,随机读写速度可能降低$80\%$[^1] 2. **系统层问题** - UI渲染超时:未满足Android渲染管线16ms/帧的要求(对应$60FPS$) - 后台服务竞争:如定位服务持续占用资源$\int_{t1}^{t2} CPU_{usage} \geq 90\%$ - 系统碎片化:不同厂商ROM对$$SurfaceFlinger$$的调度策略存在差异[^2] 3. **应用层问题** - 主线程阻塞:网络请求/SQL查询未异步执行 - 内存泄漏:未释放的Activity实例导致$$Heap_{size} \geq Heap_{max} \times 80\%$$ - 过度绘制:单个像素点被重复绘制$N \geq 4$次 #### 二、系统级优化方案 1. **硬件资源监控** ```shell adb shell dumpsys meminfo # 查看内存分布 adb shell top -n 1 | grep <package> # 获取CPU占用率 ``` 2. **渲染管线优化** - 开启GPU渲染模式分析: ```java // 开发者选项中启用"HWUI渲染模式分析" ViewDebug.setLayoutParameter(view, "traceHWUI", "true"); ``` - 使用$$Choreographer.FrameCallback$$监测帧率 3. **I/O性能调优** - 采用ReactiveX实现异步读写: ```kotlin Single.fromCallable { readFile() } .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) ``` #### 三、应用开发最佳实践 1. **内存泄漏检测** ```gradle debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.9.1' ``` 当检测到泄漏时输出: $$Leak_{trace} = GC Root \rightarrow Activity \rightarrow ViewTree$$ 2. **布局优化策略** - 使用约束布局减少层级: ```xml <androidx.constraintlayout.widget.ConstraintLayout> <View android:id="@+id/view1" app:layout_constraintTop_toTopOf="parent"/> </androidx.constraintlayout.widget.ConstraintLayout> ``` - 通过$$merge$$标签消除冗余ViewGroup 3. **线程管理模型** ```kotlin CoroutineScope(Dispatchers.Default).launch { val data = withContext(Dispatchers.IO) { fetchData() } withContext(Dispatchers.Main) { updateUI(data) } } ``` #### 四、系统设置建议 1. 开启"强制进行GPU渲染" 2. 限制后台进程数(开发者选项) 3. 使用$$adb shell settings put global transition_animation_scale 0$$关闭过渡动画
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值