程序员:
有做过,目前的项目内存优化还是挺多的,要不我先说一下优化内存有什么好处吧?咱们不能盲目的去优化!
有的时候对于自己熟悉的领域,一定要主动出击,自己主导这场面试。
面试官:
可以。
Ps:这里大多数面试官会同意你的请求,除非遇见装B的。
程序员:
好处:
-
减少 OOM ,可以提高程序的稳定性。
-
减少卡顿,提高应用流畅性。
-
减少内存占用,提高应用后台存活性。
-
减少程序异常,降低应用 Crash 率, 提高稳定性。
那么我基于这四点,我的程序做了如下优化:
- 1.减少 OOM
在应用开发阶段我比较喜欢用 LeakCanary 这款性能检测工具,好处是它能实时的告诉我具体哪个类发现了内存泄漏(如果你对 LeakCanary 的原理了解的话,可以说一说它是怎么检测的)。
还有我们要明白为什么应用程序会发送 OOM ,又该怎么去避免它?
发生 OOM 的场景是当申请 1M 的内存空间时,如果你要往该内存空间存入 2M 的数据,那么此时就会发生 OOM。
在应用程序中我们不仅要避免直接导致 OOM 的场景还要避免间接导致 OOM 的场景。间接的话也就是要避免内存泄漏的场景。
内存泄漏的场景是这个对象不再使用时,应用完整的执行最后的生命周期,但是由于某些原因,对象虽然已经不再使用,仍然会在内存中存在而导致 GC 不会去回收它,这就意味着发生了内存泄漏。(这里可以介绍下 GC 回收机制,回收算法,知识点尽量往外扩展而不脱离本题)
最后在说一下在实际开发中避免内存泄漏的场景:
-
资源型对象未关闭: Cursor,File
-
注册对象未销毁: 广播,回调监听
-
类的静态变量持有大数据对象
-
非静态内部类的静态实例
-
Handler 临时性内存泄漏: 使用静态 + 弱引用,退出即销毁
-
容器中的对象没清理造成的内存泄漏
-
WebView: 使用单独进程
其实这些都是基础,把它记下就行了。记得多了在实际开发中就有印象了。
- 2.减少卡顿
怎么减少卡顿? 那么我们可以从 2 个原理方面来探讨卡顿的根本原因,第一个原理方面是绘制原理,另一个就是刷新原理。
- 绘制原理:
- 刷新原理:
View 的 requestLayout 和 ViewRootImpl##setView 最终都会调用 ViewRootImpl 的 requestLayout 方法,然后通过 scheduleTraversals 方法向 Choreographer 提交一个绘制任务,然后再通过 DisplayEventReceiver 向底层请求 vsync 垂直同步信号,当 vsync 信号来的时候,会通过 JNI 回调回来,在通过 Handler 往消息队列 post 一个异步任务,最终是 ViewRootImpl 去执行绘制任