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++, Portran などもそうですが
  • 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 番目は
  • 1:33 - 1:37
    例えば 将来的にアクセスできない
    プログラムやコードが
  • 1:37 - 1:40
    参照するあるメモリ内の
    データオブジェクトが見つかった時
  • 1:40 - 1:44
    2 番目は そのオブジェクトが
    使用するリソースを取り戻します
  • 1:44 - 1:47
    理論的には単純な概念ですが
    2 万行のコードと 4GB の割当メモリを
  • 1:47 - 1:51
    持つ場合
    かなり複雑になります
  • 1:51 - 1:53
    今その話をしています
    ガベージコレクションは凄いことができると
  • 1:53 - 1:57
    プログラムが 20,000 の
    割当を持つ場合なら
  • 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 ランタイムの
    ガベージコレクターは
  • 2:12 - 2:15
    マッカーシーの当初の提案よりも
    洗練されたものになりました
  • 2:15 - 2:19
    できるだけ早く
    そして干渉しないようにです
  • 2:19 - 2:23
    Android ランタイムのメモリヒープを
    効果的に分配することは
  • 2:23 - 2:24
    割当タイプに基づいており
    さらに
  • 2:24 - 2:28
    将来のGCイベントに割り当てることで
    ベストなシステム運用かできるようになります
  • 2:28 - 2:30
    また 新しいオブジェクトにも
    割り当てられ
  • 2:30 - 2:33
    使用している Android ランタイムの
    バージョンにより
  • 2:33 - 2:37
    置かれるべきベストな
    スペースを考慮してくれます
  • 2:37 - 2:39
    そして ここが
    需要な部分です
  • 2:39 - 2:41
    各スペースの大きさの設定は
  • 2:41 - 2:44
    割当られたオブジェクトによります
    そして それらの合計サイズも追跡しており
  • 2:44 - 2:47
    スペースサイズが大きくなると
    ガベージコレクションを実行して
  • 2:47 - 2:52
    将来の割当のためにメモリを開放することを
    システムは必要とします
  • 2:52 - 2:54
    GC イベントの価値は
    Android ランタイムで
  • 2:54 - 2:57
    使用しているものに応じて
    異なる動作をすることにあります
  • 2:57 - 3:01
    たとえば多くの Dalvik は
    GC イベントが終わるまで
  • 3:01 - 3:05
    実行中の管理コードを
    停止するようにしています
  • 3:05 - 3:09
    GC は通常よりも時間がかかる時や
    大幅なフレームレートを占有された時
  • 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
    まずは GC は多くの時間を与えられた
    フレームの中で消費していることを
  • 3:29 - 3:33
    理解する必要があります
    そして残りのロジックは
  • 3:33 - 3:35
    1000 分の 16 以下のレンダリングバリアを
    維持するために使われます
  • 3:35 - 3:38
    もし多くの GC や長い何かが
    お互い右に発生したら
  • 3:38 - 3:42
    たぶんフレームのプロセス時間が
    1000 分の 16 秒を超えていることを意味するので
  • 3:42 - 3:47
    ユーザーに良いようには
    見えないでしょう
  • 3:47 - 3:50
    次に コードの流れによっては
    GC がより多く動いたり
  • 3:50 - 3:55
    普通の状態よりも長く
    作動することがあると理解してください
  • 3:55 - 3:59
    たとえば あるオブジェクトのかたまりの中に
    より長い時間をかけてループするように
  • 3:59 - 4:02
    割り当てるなら 多くのオブジェクトで
    複雑になったメモリヒープを
  • 4:02 - 4:06
    早くたくさんの GC で
    片づけさせることで
  • 4:06 - 4:09
    追加的なメモリ活用を
    手伝うことおができます
  • 4:09 - 4:12
    ですが
    私たちのメモリ管理環境からは
  • 4:12 - 4:13
    相変わらずメモリリークが起きています
  • 4:13 - 4:17
    だとしても 他の言語を作ることは
    容易ではありません
  • 4:17 - 4:20
    メモリリークは使用可能なスペースを減らし
  • 4:20 - 4:24
    定期的に GC イベントを
    強制終了させてしまうため
  • 4:24 - 4:27
    オブジェクト使用からの熱を
    効果的に解除できなくなります
  • 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

Japanese subtitles

Revisions Compare revisions