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++語言
  • 0:14 - 0:18
    和Fortran 通常程式設計師自己管理內存
  • 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
    由John McCarthy發明的 當初是為了解決lisp語言的問題
  • 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
    比MacCarthy最初的方法更高級
  • 2:15 - 2:19
    速度快且是非侵入性的
  • 2:19 - 2:23
    經由分配類型
  • 2:23 - 2:24
    及系統如何有效地組織分配以利GC的運行
  • 2:24 - 2:28
    并作為新的配置
  • 2:28 - 2:30
    所有影響androids runtimes的內存堆都被分割到空間中
  • 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, Traditional subtitles

Revisions Compare revisions