面试官--说一下你做过哪些性能优化-项目中遇见的卡顿问题怎么解决的？(1)

2301_82243733

已于 2024-05-03 15:53:35 修改

阅读量794

点赞数 26

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

于 2024-05-03 15:53:33 首次发布

本文链接：https://blog.csdn.net/2301_82243733/article/details/138418056

版权

程序员专栏收录该内容

214 篇文章 2 订阅

订阅专栏

7、WebView: 使用单独进程

其实这些都是基础，把它记下就行了。记得多了在实际开发中就有印象了。

2.减少卡顿

怎么减少卡顿? 那么我们可以从 2 个原理方面来探讨卡顿的根本原因，第一个原理方面是绘制原理，另一个就是刷新原理。

1、绘制原理:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

2、刷新原理:

View 的 requestLayout 和 ViewRootImpl##setView 最终都会调用 ViewRootImpl 的 requestLayout 方法，然后通过 scheduleTraversals 方法向 Choreographer 提交一个绘制任务，然后再通过 DisplayEventReceiver 向底层请求 vsync 垂直同步信号，当 vsync 信号来的时候，会通过 JNI 回调回来，在通过 Handler 往消息队列 post 一个异步任务，最终是 ViewRootImpl 去执行绘制任务，最后调用 performTraversals 方法，完成绘制。

详细流程可以参考下面流程图:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

卡顿的根本原因:

从刷新原理来看卡顿的根本原理是有两个地方会造成掉帧:

一个是主线程有其它耗时操作，导致doFrame 没有机会在 vsync 信号发出之后 16 毫秒内调用；

还有一个就是当前doFrame方法耗时，绘制太久，下一个 vsync 信号来的时候这一帧还没画完，造成掉帧。

既然我们知道了卡顿的根本原因，那么我们就可以监控卡顿，从而可以对卡顿优化做到极致。我们可以从下面四个方面来监控应用程序卡顿:

1、基于 Looper 的 Printer 分发消息的时间差值来判断是否卡顿。

//1. 开启监听
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, “ActivityThread”));

//2. 只要分发消息那么就会在之前和之后分别打印消息
public static void loop() {
final Looper me = myLooper();
if (me == null) {
throw new RuntimeException(“No Looper; Looper.prepare() wasn’t called on this thread.”);
}
final MessageQueue queue = me.mQueue;
…

for (;😉 {
Message msg = queue.next(); // might block
…
//分发之前打印
final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}

…
try {
//分发消息
msg.target.dispatchMessage(msg);
…
//分发之后打印
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
}
}

2、基于 Choreographer 回调函数 postFrameCallback 来监控

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

3、基于开源框架 BlockCanary 来监控

4、基于开源框架 rabbit-client 来监控

怎么避免卡顿：

一定要避免在主线程中做耗时任务，总结一下 Android 中主线程的场景：

1、UI 生命周期的控制
2、系统事件的处理
3、消息处理
4、界面布局
5、界面绘制
6、界面刷新
7、…

还有一个最重要的就是避免内存抖动，不要在短时间内频繁的内存分配和释放。

基于这几点去说卡顿肯定是没有问题的。

3、减少内存占用

可以从如下几个方面去展开说明:

1、AutoBoxing(自动装箱): 能用小的坚决不用大的。
2、内存复用
3、使用最优的数据类型
4、枚举类型: 使用注解枚举限制替换 Enum
5、图片内存优化（这里可以从 Glide 等开源框架去说下它们是怎么设计的）

选择合适的位图格式
bitmap 内存复用，压缩
图片的多级缓存

6、基本数据类型如果不用修改的建议全部写成 static final,因为它不需要进行初始化工作，直接打包到 dex 就可以直接使用，并不会在类中进行申请内存
7、字符串拼接别用 +=，使用 StringBuffer 或 StringBuilder
8、不要在 onMeause, onLayout, onDraw 中去刷新 UI
9、尽量使用 C++ 代码转换 YUV 格式，别用 Java 代码转换 RGB 等格式，真的很占用内存

4、减少程序异常

减少程序异常那么我们可以从稳定性和 Crash 来分别说明。

这个我们将在第四点会详细的介绍程序的稳定性和 Crash 。

如果说出这些，再实际开发中举例说明一下怎么解决的应该是没有问题的。

3、你在项目中有没有遇见卡顿问题？是怎么排查卡顿？又是怎么优化的?

程序员：

有遇见, 比如在主线程中做耗时操作、频繁的创建对象和销毁对象导致 GC 回收频繁、布局的层级多等。

面试官：

嗯，那具体说说是怎么优化的。

程序员：

这里我们还是可以从显示原理和优化建议来展开说明，参考如下：

1、显示原理：

绘制原理：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

刷新原理：

详细流程可以参考下面流程图:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

1、卡顿的根本原因：

从刷新原理来看卡顿的根本原理是有两个地方会造成掉帧:

一个是主线程有其它耗时操作，导致doFrame 没有机会在 vsync 信号发出之后 16 毫秒内调用；

还有一个就是当前 doFrame 方法耗时，绘制太久，下一个 vsync 信号来的时候这一帧还没画完，造成掉帧。

既然我们知道了卡顿的根本原因，那么我们就可以监控卡顿，从而可以对卡顿优化做到极致。我们可以从下面四个方面来监控应用程序卡顿:

基于 Looper 的 Printer 分发消息的时间差值来判断是否卡顿。

//1. 开启监听
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, “ActivityThread”));

…
try {
//分发消息
msg.target.dispatchMessage(msg);
…
//分发之后打印
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
}
}