来自Android面试官性能优化面试-10-连炮，你能顶住么？(1)

1. 减少 OOM ，可以提高程序的稳定性。

2. 减少卡顿，提高应用流畅性。

3. 减少内存占用，提高应用后台存活性。

4. 减少程序异常，降低应用 Crash 率, 提高稳定性。

那么我基于这四点，我的程序做了如下优化:

• 1.减少 OOM

在应用开发阶段我比较喜欢用 LeakCanary 这款性能检测工具，好处是它能实时的告诉我具体哪个类发现了内存泄漏(如果你对 LeakCanary 的原理了解的话，可以说一说它是怎么检测的)。

还有我们要明白为什么应用程序会发送 OOM ，又该怎么去避免它？

发生 OOM 的场景是当申请 1M 的内存空间时，如果你要往该内存空间存入 2M 的数据，那么此时就会发生 OOM。

在应用程序中我们不仅要避免直接导致 OOM 的场景还要避免间接导致 OOM 的场景。间接的话也就是要避免内存泄漏的场景。

内存泄漏的场景是这个对象不再使用时，应用完整的执行最后的生命周期，但是由于某些原因，对象虽然已经不再使用，仍然会在内存中存在而导致 GC 不会去回收它，这就意味着发生了内存泄漏。(这里可以介绍下 GC 回收机制，回收算法，知识点尽量往外扩展而不脱离本题)

最后在说一下在实际开发中避免内存泄漏的场景:

1. 资源型对象未关闭: Cursor,File

2. 注册对象未销毁: 广播，回调监听

3. 类的静态变量持有大数据对象

4. 非静态内部类的静态实例

5. Handler 临时性内存泄漏: 使用静态 + 弱引用，退出即销毁

6. 容器中的对象没清理造成的内存泄漏

7. WebView: 使用单独进程

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

• 2.减少卡顿

怎么减少卡顿? 那么我们可以从 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);
}
}
}
​
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);
}
}
}

• 1. 基于 Choreographer 回调函数 postFrameCallback 来监控

​
3. 基于开源框架 rabbit-client 来监控
​
怎么避免卡顿：
​
一定要避免在主线程中做耗时任务，总结一下 Android 中主线程的场景:
​1\. UI 生命周期的控制 ​ 2\. 系统事件的处理 ​ 3\. 消息处理 ​ 4\. 界面布局 ​ 5\. 界面绘制 ​ 6\. 界面刷新 ​ 7\. ... ​
还有一个最重要的就是避免内存抖动，不要在短时间内频繁的内存分配和释放。
​
基于这几点去说卡顿肯定是没有问题的。

• 3.减少内存占用

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

1. AutoBoxing(自动装箱): 能用小的坚决不用大的。

2. 内存复用

3. 使用最优的数据类型

4. 枚举类型: 使用注解枚举限制替换 Enum

5. 图片内存优化（这里可以从 Glide 等开源框架去说下它们是怎么设计的）

6. 选择合适的位图格式

7. bitmap 内存复用，压缩

8. 图片的多级缓存

9. 基本数据类型如果不用修改的建议全部写成 static final,因为 它不需要进行初始化工作，直接打包到 dex 就可以直接使用，并不会在 类 中进行申请内存

10. 字符串拼接别用 +=，使用 StringBuffer 或 StringBuilder

11. 不要在 onMeause, onLayout, onDraw 中去刷新 UI

12. 尽量使用 C++ 代码转换 YUV 格式，别用 Java 代码转换 RGB 等格式，真的很占用内存

• 4.减少程序异常

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

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

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

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

程序员:

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

面试官:

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

程序员:

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

1. 显示原理:

• 绘制原理:

• 刷新原理:

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

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

1. 卡顿的根本原因:

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

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

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

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

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

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

2. 基于开源框架 BlockCanary 来监控

3. 基于开源框架 rabbit-client 来监控

4. 怎么可以提高程序运行流畅

1.布局优化:

1.1 布局优化分析工具:

1.2 优化方案:

4. 提升动画性能

5. 尽量别用补间动画，改为属性动画，因为通过性能监控发现补间动画重绘非常频繁

6. 使用硬件加速提高渲染速度，实现平滑的动画效果。

7. 怎么避免卡顿：

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

1. UI 生命周期的控制

2. 系统事件的处理

3. 消息处理

4. 界面布局

5. 界面绘制

6. 界面刷新

7. …

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

4、怎么保证 APP 的稳定运行?

程序员:

保证程序的稳定我们可以从内存、代码质量、Crash、ANR、后台存活等知识点来展开优化。

面试官:

那你具体说说你是怎么做的？

程序员:

1.内存

可以从第二点内存优化来说明

2.代码质量

1. 团队之前相互代码审查，保证了代码的质量，也可以学习到了其它同事码代码的思想。

2. 使用 Link 扫描代码，查看是否有缺陷性。

3. Crash

1. 通过实现 Thread.UncaughtExceptionHandler 接口来全局监控异常状态，发生 Crash 及时上传日志给后台，并且及时通过插件包修复。

2. Native 线上通过 Bugly 框架实时监控程序异常状况，线下局域网使用 Google 开源的 breakpad 框架。发生异常就搜集日志上传服务器(这里要注意的是日志上传的性能问题，后面省电模块会说明)

4. ANR

最后

如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。

欢迎大家一起交流讨论啊~

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

的，请给我留言。一定会认真查询，修正不足。谢谢。

[外链图片转存中…(img-YFYzZEsR-1714657359382)]

欢迎大家一起交流讨论啊~

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！