当前状况
- 安装低端机型H5页面可能存在丢帧问题
丢帧卡顿可能原因分析
现象分析
- 呈现速度缓慢: 在呈现速度缓慢的帧数较多的页面,当超过50%的帧呈现时间超过16ms毫秒时,用户感官明显卡顿。
- 帧冻结的绘制耗时超过700ms,为严重卡顿问题。
- 卡顿忽略FPS<=2的页面:因为人的视觉暂留100400ms,即FPS在2.510之间时,所以当FPS低于3时,人眼看到的并不是连续动作,即使有丢帧现象,也不会察觉。
具体问题分析
- 当前程序运行CPU运行过高
- 当前程序运行内存占用过高
定位问题
当前情况分析
- 使用Android官方提供的dumpsys工具进行分析
- 执行:
adb shell dumpsys gfxinfo com.sohu.newsclient
- 详细正文数据分析
- 执行:
Stats since: 29087419659040ns
Total frames rendered: 1771 : 本次dump收集了1771帧信息
Janky frames: 776 (43.82%) : 1711帧中有776帧超过16ms, 卡顿概率为: 43.8%
50th percentile: 14ms
90th percentile: 28ms
95th percentile: 57ms
99th percentile: 350ms
Number Missed Vsync: 60 : 垂直同步失败的帧
Number High input latency: 1533 : 处理input超市的帧
Number Slow UI thread: 96 : 因UI线程上的工作导致超时值
Number Slow bitmap uploads: 1 : 因bitmap的加载耗时的帧数
Number Slow issue draw commands: 77 : 因绘制导致耗时的帧数
Number Frame deadline missed: 120
-
Janky frames 并不代表用户视觉上的,显示在屏幕上的丢帧率,但是它可以代表有问题的帧率.
-
通过安卓组掉帧工具分析
- 可通过掉帧发生时, 具体的执行函数情况分析
- 结果: 未发现在安卓掉帧过程中有webview函数执行
内存情况分析
分析真实内存情况
- 使用Android中自带的Profile工具内存分析
正常打开正文页, 在低端手机中运行情况分析
- 数据发现:
- app heap:占用大部分内存
- image heap: 照用一部分内存
- 在app heap中"com.baidu.mobads.container.util.b"占用了大部分的内存
- 经过山总查证, 次部分是广告占用了大部分内存.
- 仔细论证内存占用关系:
- 正文页运行占用内存分别如下
- Total: 373.M
- Java: 38.7M - Java堆内存的使用量。Java堆是Java虚拟机中用于存储对象实例的一部分内存空间
- Native: 103.M - 应用程序通过本地方法(Native Method)分配的内存量。本地方法是使用C、C++或其他本地语言编写的代码,在Android开发中,通常用来执行一些高性能或者系统相关的操作。
- Graphics: 109.7M - 用于绘制图形和UI元素的内存量。包括位图、画布等图形相关的资源。
- Stack: 7.3M - 程序的调用堆栈(Call Stack)所占用的内存量。调用堆栈用于跟踪当前执行线程的方法调用顺序。
- Code: 53.2M - 应用程序加载的代码的内存量。包括应用程序的可执行代码、库文件和其他相关的代码资源。
- Other: 61.2M - 包括一些不容易归类的内存分配,例如一些系统资源、缓存或者其他一些不属于前述类别的内存使用情况。
- 结论: Native中的运行占用的大部分内存
- 对比空正文页面运行结果
-
- Total: 348.5M
- Java: 37M
- Native: 126M
- Graphics: 49.8M
- Stack: 6.8M
- Code: 48.5M
- Others: 80.3M
- 对比结论: 正文和推荐专题, 渲染评论等占用内存: 大概50M作用.
正文内存查看
- 正文正常加载内存
- 页面占用内存7.4M
- 去掉正文加载内存
- 页面占用1.8M
- 结论: H5占用内存内存为5.5M左右
滚动时内存变换
- 滚动时内存变化来自GPU渲染占用的内存变化
结论
- 正文H5页面渲染, 大概占用内存30M作用
- 正文H5页面正文部分运行占用内存5M作用
- H5未占用大量内存, 建议: 每次合板后, 检测H5占用内存
网络资料卡顿优化建议
- 参考: Android流畅度评估及卡顿优化
- 对象分配、垃圾回收(GC)、线程调度以及Binder调用 是Android系统中常见的卡顿原因
- 布局优化
- 通过减少冗余或者嵌套布局来降低视图层次结构。比如使用约束布局代替线性布局和相对布局。
- 用 ViewStub 替代在启动过程中不需要显示的 UI 控件。
- 使用自定义 View 替代复杂的 View 叠加。
- 减少嵌套层次和控件个数。
- 使用Tags:Merge标签减少布局嵌套层次,ViewStub标签推迟创建对象、延迟初始化、节省内存等。
- 减少过度绘制
- 减少主线程耗时操作
- 主线程中不要直接操作数据库,数据库的操作应该放在数据库线程中完成。
- sharepreference尽量使用apply,少使用commit,可以使用MMKV框架来代替sharepreference。
- 网络请求回来的数据解析尽量放在子线程中,不要在主线程中进行复制的数据解析操作。
- 不要在activity的onResume和onCreate中进行耗时操作,比如大量的计算等。
- 列表优化
- RecyclerView使用优化,使用DiffUtil和notifyItemDataSetChanged进行局部更新等。
- 内存优化
- 减少小对象的频繁分配和回收操作。
- 被频繁调用的紧密的循环里,避免对象分配来降低GC的压力。