关于掉帧问题

众所周知,Android程序的大多数代码操作都必须执行在主线程,例如系统事件(例如设备屏幕发生旋转),输入事件(例如用户点击滑动等),程序回调服务,UI绘制以及闹钟事件等等。那么我们在上述事件或者方法中插入的代码也将执行在主线程。

一旦我们在主线程里面添加了操作复杂的代码,这些代码就很可能阻碍主线程去响应点击/滑动事件,阻碍主线程的UI绘制等等。我们知道,为了让屏幕的刷新帧率达到60fps,我们需要确保16ms内完成单次刷新的操作。一旦我们在主线程里面执行的任务过于繁重就可能导致接收到刷新信号的时候因为资源被占用而无法完成这次刷新操作,这样就会产生掉帧的现象,刷新帧率自然也就跟着下降了(一旦刷新帧率降到20fps左右,用户就可以明显感知到卡顿不流畅了)。

为了避免上面提到的掉帧问题,我们需要使用多线程的技术方案,把那些操作复杂的任务移动到其他线程当中执行,这样就不容易阻塞主线程的操作,也就减小了出现掉帧的可能性。

–摘自http://hukai.me/android-performance-patterns-season-5/

使用hismartperf(推测与SmartPerf - Host相关)分析卡顿问题可按以下方法进行: - **抓取数据**:利用SmartPerf - Host提供的FrameTimeline率分析功能,抓取记录每一的渲染数据。在如下场景代码中,使用Grid实现网格布局,界面上下滑动有卡顿现象时,就可以运用此功能抓取数据。示例代码如下: ```typescript @Entry @Component struct Index { @State children: number[] = Array.from<undefined, number>(Array(2000).fill(undefined), (_v: undefined, k) => k); build() { Scroll() { Grid() { ForEach(this.children, (item: number) => { GridItem() { Stack() { Stack() { Stack() { Text(item.toString()) .fontSize(32) } } } } }, (item: number) => item.toString()) } .columnsTemplate('1fr 1fr 1fr 1fr') .columnsGap(0) .rowsGap(0) .size({ width: "100%", height: "100%" }) } } } ``` - **分析数据**:该功能会自动标识其中的卡顿,并提供同时段的系统Trace信息,开发者可据此高效分析卡顿位置和原因。同时,要关注率相关数据,左侧数字代表当前所处的率档位,右侧数字代表实际Render Service(RS)绘制率,即从应用触发到绘制再到最后的硬件送显整个过程中的实时率。即使观察不到页面刷新,但RS一直在执行也可能导致耗电增加,例如重复的视图虽被视为无效不送显,但RS仍会进行绘制 [^3]。 - **功耗相关分析**:在进行功耗相关问题定位时,首先关闭USB充电模式,使用Profiler实时监控观察温度以及功耗变化,明确问题的具体场景以及功耗来源;然后开启Frame录制,通过Trace进行CPU频点与负载分析 [^4]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值