# Garbage Collection in Android - 1503170425

![video\_screenshot](https://2300623831-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M42R_LUyJKgBHlKjSRa%2F-M42Rc6P9yocNdfaP271%2F-M42RjfyJuBBdibqSmHr%2Fpzfzz50W5Uo.jpg?generation=1585974607964538\&alt=media)

**视频发布时间**

> 2015年3月11日

&#x20;**视频介绍**

> One of the tricks to the Java Language being an efficient language has to do with it’s Managed Memory model, which will kick off “Garbage Collection” events to clean up memory on your app’s behalf. While beneficial, these events can be challenging from a performance perspective.In this video +Colt McAnlis introduces the topic of Garbage Collection, how it works, and what you need to do to fix it.

&#x20;**视频推介语**&#x20;

> 暂无，待补充。

## 译者信息

| 翻译 | 润稿 | 终审 | 原始链接                                                     | 中文字幕                                                     | 翻译流水号      | 加入字幕组                                                                                                                                                                                     |
| -- | -- | -- | -------------------------------------------------------- | -------------------------------------------------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 贺颂 | 高冰 | -- | [ Youtube ](https://www.youtube.com/watch?v=pzfzz50W5Uo) | [ Youtube ](https://www.youtube.com/watch?v=YDA07DGjTAE) | 1503170425 | [ 加入 GDG 字幕组 ](https://github.com/gdsub/pub/tree/420613f9ff598576d7b4321d0b83923050d0d03d/Android/088-Android-Performance-Patterns/%7B%7B%20book.host%20%7D%7D/join_translator/README.md) |

## 解说词中文版：

要想写出非常棒的应用程序

让程序员保持高效率是很至关重要的

这样他们才可以将主要精力

放在真正待解决的问题上

但有时使用如此傻瓜化的开发工具

也会产生一些莫名其妙的问题

我是Colt Mcanlis

虽然Android运行时库

让程序员的工作变的

更加高效了

但还是会有一些潜在的性能隐患

你需要关心的一个头等大事就是

与内存的分配和使用相关的问题

很多被冠以高效率的编程语言 例如C C++

通常需要程序员自己

完成内存管理工作

在堆上开辟空间

需要程序员要自己编码实现

在使用不到时

也要自己进行释放内存的工作

但是如果要操作200万行打底的代码量时

会很容易在逻辑上陷入混乱

然后忘了按计划释放已经分配的内存

我们将这一部分内存称之为泄露的内存

也就是使用过后一直未被释放掉的内存

在这时 一种带有内存管理机制的编译器出现了

它把释放内存的重担从程序员身上

移走了

它会对每一段内存都进行实时追踪

当判定某段内存

不再被程序用到时

它就会自动将这部分内存释放掉

不需要程序员额外再做些什么

这听上去很棒 因为不用再操心内存管理

就有时间做点其他的什么事儿了 比如和别人争论十字型护手

跟光剑搭不搭（源自星球大战）

回到正题 在这种环境之下

回收无用内存的过程就是有名的垃圾回收

这是1959年John Mccarthy在解决

LISP上出现的问题时而提出的概念

它主要做这么2两件事儿

找到不再被引用的对象

然后回收这些对象所占用的内存

仔细想一想

垃圾回收的概念还是很模糊的

假如你为2万个对象

都分配了内存 那么哪些对象是你不再使用的呢

换句话说 应该在什么时候执行垃圾回收

释放掉内存是最佳的做法呢

这的确是一个很棘手的问题

不过谢天谢地 自垃圾回收被提出之后的50多年时间里

我们一直致力于改善它的性能

这也是为什么Android运行时库里的垃圾回收器

和当年Mccarthy提出的垃圾回收器相比

复杂的多的原因

它的执行速度更快 并且尽可能做到非侵入式

事实上 Android运行时库对堆的分段手段

要基于对象的分配方式

和系统怎样能够合理的组织这些分配

当为一个新的对象分配内存时

以上两点特性两点都要考虑进去

以使对象被放在了最合适的地方

当然也取决于你Android运行时库的版本

那关键的地方来了

每一段内存都有大小限制

当为对象分配内存时 我们会实时追踪整个程序所占的内存大小

当程序所占内存增加到一定程度时

系统就会启动垃圾回收机制

释放掉一部分内存以备不时之需

还有一点 垃圾回收

会因为Android运行时库的不同

而表现出不用的性能

比如在Dalvik虚拟机中 许多垃圾回收事件

都是stop the world（整个世界因我而停止）类型

也就是说所有正在运行的代码

都会被强制停止直到垃圾回收完成之后

当垃圾回收器执行的时间过长或者有很多垃圾回收工作要做时

就会有很大的麻烦

因为这样将会抢走帧渲染的时间

现在 ART(Android Runtime)着力改善了

垃圾回收系统的并发性

它可以避免因垃圾回收而引起的较长时间卡顿

不过在重要步骤上还是会出现较短的卡顿

我坦白交代 我们的工程师花了大把的时间

来确保垃圾回收机制

尽可能的减少卡顿

不过据说 做了这么多优化之后

垃圾回收可能还是会给你带来麻烦

首先 你要知道

在垃圾回收处理上面花的时间越多

在处理其他逻辑上面所用的时间就会越少

我们还要保证在16毫秒之内完成一次全部的刷新工作

如果有太多垃圾回收的事情要做

或者有很多耗时的操作

就会造成一些帧的处理时间超过16毫秒的上限

后果就是给用户造成卡顿或瞬移的视觉效果

第二 如果代码编写低效

可能会让垃圾回收频繁的执行

或者让垃圾回收

比正常执行的更久

比如 如果你在

一段循环语句的最里面创建了很多对象

那程序跑起来就会花很多时间在创建这些对象上面

那么就会在内存里挤下

很多冗余的对象

迫于内存大小的限制

很多垃圾回收工作就来不及执行了

想要做到面面俱到

并非易事

不过幸好Android SDK中自带了

一套强大的处理工具

试举一例 使用Android studio里内置的

Memory monitor工具

可查看应用运行时内存的使用情况

当看到内存占用下降了一截

那是垃圾回收机制发挥了作用

但如果短期内有很多这种下降折线 这意味着可能出问题了

利用Allocation Tracker工具

能看到哪些对象在内存中还活着

都是哪些代码创建了这些对象

内存争夺战是件知易行难的事

所以一定要来观看Android Performance Patterns

里的其他视频

来用更多更棒的方式帮你优化应用性能

也别忘了加入我们的G+

来获取最棒的一手信息

代码分析 你值得拥有 性能问题 永不能忘
