Return to Video

04-02 Memory,_GC,_and_Performance

  • 0:00 - 0:03
    不是所有指令都执行得又快又好,
  • 0:03 - 0:08
    下面介绍内存及它如何影响系统运行。
  • 0:08 - 0:12
    普遍认为,多数程序语言接近硬件或高性能。
  • 0:12 - 0:14
    如C语言 C++语言和Fortran。
  • 0:14 - 0:18
    通常程序工程师会自己管理内存。
  • 0:18 - 0:20
    高手工程师对内存的分配,
  • 0:20 - 0:25
    会慎重理处理,
  • 0:25 - 0:26
    并在未来结束使用时再次分配。
  • 0:26 - 0:31
    一旦确认何时及怎样分配内存,
  • 0:31 - 0:35
    内存管理的品质就仰赖于工程师的技能跟效率。
  • 0:35 - 0:36
    责任重大啊!
  • 0:36 - 0:40
    实际情况是工程师们,
  • 0:40 - 0:42
    不都会去追踪那零碎的内存碎片。
  • 0:42 - 0:45
    程序开发是件混乱又疯狂的过程,
  • 0:45 - 0:49
    内存通常都没办法完全被释放。
  • 0:49 - 0:53
    这些被囚禁的内存块叫内存漏洞。
  • 0:53 - 0:58
    内存漏洞占用了大量资源,这些资源其实可以更好地使用。
  • 0:58 - 1:01
    为减少漏洞引起的混乱、负担、甚至资金损失,
  • 1:01 - 1:05
    便有了内存管理语言。
  • 1:05 - 1:09
    这些语言在运行时跟踪内存分配,
  • 1:09 - 1:12
    以便当程序不再需要时释放系统内存。
  • 1:12 - 1:16
    完全不用工程师亲自操作。
  • 1:16 - 1:20
    这项内存回收艺术或科学,在内存管理环境下叫垃圾清理。
  • 1:20 - 1:24
    这个设计概念是在1959年,
  • 1:24 - 1:30
    当初为了解决lisp语言问题,由John McCarthy发明的。
  • 1:30 - 1:33
    垃圾清理的基本概念有:
  • 1:33 - 1:37
    第一,找到未来无法存取的数据。
  • 1:37 - 1:40
    例如所有不受指令操控的内存。
  • 1:40 - 1:44
    第二,回收被利用过资源。
  • 1:44 - 1:47
    原理简单。但是2百万行编码,
  • 1:47 - 1:51
    跟4gigs的分配,在实际操作时却非常困难。
  • 1:51 - 1:53
    如果现在,在程序中有20000个分配。
  • 1:53 - 1:57
    垃圾清理定会让人困惑。
  • 1:57 - 1:58
    哪一个是没用的?
  • 1:58 - 2:01
    或者,
  • 2:01 - 2:04
    何时启动垃圾清理释放内存?
  • 2:04 - 2:06
    这些问题其实很复杂。
  • 2:06 - 2:10
    好在50年来,我们找到了解决问题的方法。
  • 2:10 - 2:12
    就是Android Runtime中的垃圾清理。
  • 2:12 - 2:15
    比McCarthy最初的方法更高级,
  • 2:15 - 2:19
    速度快且是非侵入性的。
  • 2:19 - 2:23
    经由分配类型,
  • 2:23 - 2:24
    及系统如何有效地组织分配以利GC的运行,
  • 2:24 - 2:28
    并作为新的配置。
  • 2:28 - 2:30
    所有影响android runtime的内存堆都被分割到空间中,
  • 2:30 - 2:33
    根据这些特点,哪些数据适合放到什么空间,
  • 2:33 - 2:37
    取决于哪个Android版本。
  • 2:37 - 2:39
    最重要的一点是,
  • 2:39 - 2:41
    每个空间都有预设的大小,
  • 2:41 - 2:44
    在分配目标时要跟踪综合大小,
  • 2:44 - 2:47
    且空间不断地扩大,系统需要执行垃圾清理。
  • 2:47 - 2:52
    以确保内存分配的正常运行。
  • 2:52 - 2:54
    值得一提的是使用不同的Android runtime,
  • 2:54 - 2:57
    GC的运行方式就会不同。
  • 2:57 - 3:01
    例如在Dalvik中很多GC是停止世界事件,
  • 3:01 - 3:05
    意思是很多指令的运行直到操作完成才会停止。
  • 3:05 - 3:09
    当这些GCs所用时间超过一般值,
  • 3:09 - 3:11
    或者一大堆一起执行会耗费庞大的幀象时间,
  • 3:11 - 3:14
    这是很麻烦的事情。
  • 3:14 - 3:14
    坦白讲,
  • 3:14 - 3:18
    Android工程师花费大量时间降低干扰,
  • 3:18 - 3:21
    确保这些程序以最快的速度运行。
  • 3:21 - 3:25
    话虽如此,在指令中影响程序执行的问题仍然存在。
  • 3:25 - 3:29
    首先程序在任意帧内执行GCs所用的时间越多,
  • 3:29 - 3:33
    消除少于16毫秒的呈像障碍,
  • 3:33 - 3:35
    所必需的时间就会变少。
  • 3:35 - 3:38
    如果有许多GCs或一大串指令一个接一个地操作,
  • 3:38 - 3:42
    帧象时间很可能会超过16毫秒的呈像障碍。
  • 3:42 - 3:47
    这会导致隐形的碰撞或闪躲。
  • 3:47 - 3:50
    其次,指令流程可能造成GCs强制执行的次数增多。
  • 3:50 - 3:55
    或者,执行时间超过正常值。
  • 3:55 - 3:59
    例如,在一个长期运行的循环最内侧分配囤积对象,
  • 3:59 - 4:02
    很多数据就会污染内存堆。
  • 4:02 - 4:06
    马上就会有许多GCs启动。
  • 4:06 - 4:09
    由于这一额外的内存压力,
  • 4:09 - 4:12
    虽然内存环境管理良好,
  • 4:12 - 4:13
    就算比其他语言复杂,
  • 4:13 - 4:17
    内存漏洞仍会产生。
  • 4:17 - 4:20
    这些漏洞在GCs启动时,通过无法被释放的数据污染内存堆,
  • 4:20 - 4:24
    严重降低可用空间的总量,
  • 4:24 - 4:27
    并以常规方式强制GC的执行。
  • 4:27 - 4:29
    就是这样,
  • 4:29 - 4:33
    如果要减少任意帧内启动GC的次数,
  • 4:33 - 4:36
    需要着重优化程式的内存使用量。
  • 4:36 - 4:39
    从指令的角度看,或许很难追踪这些问题的起因,
  • 4:39 - 4:41
    但是,
  • 4:41 - 4:45
    多亏Android SDK拥有一组不错的工具,
  • 4:45 - 4:46
    任你选择。
Title:
04-02 Memory,_GC,_and_Performance
Description:

04-02 Memory,_GC,_and_Performance

more » « less
Video Language:
English
Team:
Udacity
Project:
ud825 - Android Performance
Duration:
04:47

Chinese, Simplified subtitles

Revisions Compare revisions