你告诉我太卡了，那是你不晓得性能优化之app卡顿优化(1)

最新推荐文章于 2024-07-25 11:03:45 发布

2401_84132723

最新推荐文章于 2024-07-25 11:03:45 发布

阅读量985

点赞数 29

分类专栏：程序员文章标签：性能优化

本文链接：https://blog.csdn.net/2401_84132723/article/details/137423134

版权

程序员专栏收录该内容

432 篇文章 0 订阅

订阅专栏

详解一下这个带圈的F：

整个坐标，横轴为时间，从左到右时间刻度增加，代表各项指标随着时间的变化
带圈的F : 有绿色，黄色和红色。其中绿色表示绘制正常，无需我们去关心，需要关注的是黄色和红色，特别是红色。
鼠标点击其中一个红色的F，然后按键盘 G键，就会出现红色的竖线，每两根红线之间代表一帧的时长(大部分手机的屏幕刷新频率还是60帧，所以每次绘制大概是 16.67MS)，这个F之所以是红色，是因为这一次的UI绘制时长远远超过了1帧，如果UI在1帧时间之内无法完成，便会造成掉帧，一旦掉帧，在用户的感知下，就是卡顿.

看下图：

使用鼠标拖拽，可以通过图形界面看到这一次绘制所花费的时长：为 116.868ms

在下面的Alert栏中发现了疑似掉帧元凶

这里反映出，是我们的 bitmap图上传导致了掉帧。我们继续把下面两个箭头开，能够看到：

这里的英文描述，则是谷歌工程师给我们的建议.我来大概翻译一下这段话：

第一段的 description意思是：修改/新绘制的位图必须上传到GPU。因为如果上传的总像素量很大，这是很昂贵的，所以每帧减少这个动画/上下文中位图的波动量。

第二段 description的意思是：生成这个帧的工作被重新调度了几毫秒，这是jank的功劳。确保UI线程上的代码不会阻塞其他线程上的工作，并且后台线程(例如网络或位图加载)在android.os上运行。进#THREAD_PRIORITY_BACKGROUND或更低，因此它们不太可能中断UI线程。这些后台线程应该在内核进程的调度部分以130或更高的优先级出现。总的来说，就是 Bitmap的使用不当导致掉帧，解决方法大概是：bitmap太大了要裁剪成合适的大小或者在背景线程去加载至于更加具体的其他掉帧情况的解决方法，就要根据具体遇到的情况去查资料了。

关于Trace.beginSection 和 Trace.endSection
这两个api是androidSdk自带的，作用是给systrace加上tag，加了tag，就会在systrace图形上反映出我们这两个api之间囊括的一段代码的执行情况。简单来说，就是你在一段代码的前后，加上 Trace.beginSection 和 Trace.endSection ，像这样：

那么，你在 systrace图形上就会发现这个。

可见，我们代码的执行耗时等情况可以反映在 systrace图形上，点击上面红框的区域，就会在 systrace界面底部发现：

如果加了tag的代码的执行耗时超过了一帧时长（16.67MS），则说明这一段代码造成了UI主线程掉帧，用户就有可能感觉到卡顿。

这里有个坑
如果你上面加了trace.beginSection和endSection，你在图形中还是没有看到你自己设置的tag，那么检查一下你的 systrace命令，是不是没有加 -a [app包名]

做个结论

上述例子，我使用的是app冷启动时抓的systrace，所以这里的掉帧，就是反映出冷启动过程中代码写的有问题。注意，抓systrace的时间不要太长，必须在systrace开始执行之后再操作app。

在发现掉帧的情况之后，看alert就能看出谷歌给我们的app优化方向建议，虽然还没有完全解决问题，但是至少确定了一个大方向,知道了大概哪一段代码出了问题。

TraceView

在app代码中加入 Debug.startMethodTracing("/sdCard/zhouzhou");和 Debug.stopMethodTracing(); 然后运行app，确保能够执行上面两个代码包含的代码片段。比如像这样：

坑坑

上面的代码，如果你加了之后运行直接抛了异常，检查一下你有没有加这个权限：<uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

接下来，找到这个文件，导出到电脑上:

然后就要用到我们最先说道的DDMS，先打开DDMS，File- openFile 打开刚才的.trace文件

这里包含了这段代码中所有的方法调用。

表格说明

上方有一张表格，每一列的说明如下：

这么多东西，我们不可能全都关注，只需要关注两个：

CpuTime/Call 函数平均执行时间较长的函数；(耗时较长的函数)

Call+RecurCalls/Total，调用次数非常频繁的函数。如果发现，上面两个指标超乎寻常，比如调用次数特别多，每一次调用耗费时间特别长的，而且又能够是我们自己写的方法，那么基本上就能确定优化点了。

关于过度绘制

概念：如果屏幕的一片区域，在渲染的过程中，被绘制了太多次，则称为过度绘制。如何检查:

上图是mumu模拟器的设置界面，我们点击 显示过度绘制区域,就会发现界面颜色发生了变化：

颜色由浅到深，越深，表示过渡绘制会越严重。大致有以下几种颜色:

白色：没有过度绘制。

蓝色：Overdraw 一倍。像素绘制了两次，能够接受，但是如果整个界面都是蓝色的，那么说明还是有绘制的浪费，可以节约一层绘制。

绿色：Overdraw 两倍。尝试优化。

浅红：Overdraw 三倍。

暗红：Overdraw 四倍。非常严重，必须优化。

如何优化过渡绘制？

如果你的代码中，通过过度绘制的检查，发现复杂布局显示出大量的过度绘制，那么必须要考虑 用自定义View自己去绘制。

如果你的布局xml中，有大量的嵌套，考虑 去掉某些background ，因为没有了background，UI线程就不会去做这一次绘制

如果非要用到有background的layout，那么在满足业务需求的情况下考虑 减少一定的层级。

结语

上述3个工具的使用，是我们app性能优化中必须用到的。大概思路如下

1.用systrace 抓取 .html文件，观察图形，找出掉帧的大概位置

2. 用 Trace.beginSection 和 Trace.endSection 反复推测，确定确切代码块

3. 用traceView抓取.trace日志，用DDMS打开它，寻找耗时较长的函数或次数非常多的函数，确定确切掉帧原因

三个工具需要结合使用，才能具体确定我们的 app哪里出了问题。

话题拓展

本文只给出了大致思路，并没有给出Demo，这是因为性能优化可能出现的情况太多了，无法一一列举，具体发生了什么，只有到发生之后，自行根据工具检测出的结果去推断，去论证，去解决。

**性能优化是无止境的，永远有能够优化的空间。本文只给出了大致指导方向，具体能够优化到何种程度，全看各位的自我修为。

上面的3个工具，可以用来做性能优化，但是他们的作用不仅仅是性能优化，千万不要一叶障目。比如systrace这个东西，上述文章我只用来检查了卡顿掉帧的情况，但是它其实还可以查看CPU调度情况和CPU多核分配情况，还可以检查主线程的线程状态切换情况等。

请查看完整的PDF版
(更多完整项目下载。未完待续。源码。图文知识后续上传github。)
可以点击关于我联系我获取983页完整PDF
(VX：mm14525201314)

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

尾声

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

最后想要拿高薪实现技术提升薪水得到质的飞跃。最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以为了大家能够顺利进阶中高级、架构师，我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。

当你有了学习线路，学习哪些内容，也知道以后的路怎么走了，理论看多了总要实践的。