Garbage Collection in Android - 1503170425
视频发布时间
2015年3月11日
视频介绍
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.
视频推介语
暂无，待补充。
译者信息
翻译
润稿
终审
原始链接
中文字幕
翻译流水号
加入字幕组
解说词中文版：
要想写出非常棒的应用程序
让程序员保持高效率是很至关重要的
这样他们才可以将主要精力
放在真正待解决的问题上
但有时使用如此傻瓜化的开发工具
也会产生一些莫名其妙的问题
我是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+
来获取最棒的一手信息
代码分析 你值得拥有 性能问题 永不能忘
Last updated
Was this helpful?