Japanese subtitles

← 04-02 Memory,_GC,_and_Performance

04-02 Memory,_GC,_and_Performance

Get Embed Code
13 Languages

Showing Revision 2 created 01/03/2016 by QA_SP_14_JAP.

  1. もうすべてのコードが素晴らしく
    そして早く動くようになりましたが
  2. メモリ管理がシステムパフォーマンスに
    与える影響について少し離しましょう
  3. ハードウェアに近いと知られる
    多くのプログラミング言語は
  4. あるいは高パフォーマンスの C,
    C++, Portran などもそうですが
  5. 一般的にプログラマは
    自分でメモリを管理できます
  6. プログラマは効率的な
    メモリ割当に責任があり
  7. いつか割当を解除される時も
    考えてメモリを割り当てる
  8. 必要があります
  9. いつ どのぐらい自由にメモリを
    割り当てるかは自分で定義できるので
  10. メモリ管理による品質は
    あなたのスキルと有効性にかかっています
  11. 責任が大きいですね
  12. ですが現実のプログラマは
    常にベストな
  13. メモリのピットとピースを
    使えるわけではありません
  14. それでこう考えました
    開発は泥だらけのプロセスで
  15. 多くの場合はメモリが
    正しく開放されない状態で終わります
  16. 未開放されたメモリブロックは
    メモリリークとよばれ
  17. 他に有効活用できるリソースを
    占有してしまいます
  18. メモリリークによる混乱やストレス
    ありえるコストの損失を減らすため
  19. 管理できるメモリ言語が
    作られました
  20. メモリ言語は実行時間中に
    メモリの割当を追跡して
  21. アプリケーションが必要としない時に
    システムメモリを開放させます
  22. プログラマの介入なしで
    すべては行われます
  23. この芸術 あるいは科学は
    メモリ管理環境でのメモリ再利用は
  24. ガベージコレクションとして知られています
    この概念は 1959 年
  25. Lisp のプログラミング言語の問題を解決するために
    John McCarthy によって作られました
  26. ガーベジーコレクションの基本的なルールは
    次の通りです 1 番目は
  27. 例えば 将来的にアクセスできない
    プログラムやコードが
  28. 参照するあるメモリ内の
    データオブジェクトが見つかった時
  29. 2 番目は そのオブジェクトが
    使用するリソースを取り戻します
  30. 理論的には単純な概念ですが
    2 万行のコードと 4GB の割当メモリを
  31. 持つ場合
    かなり複雑になります
  32. 今その話をしています
    ガベージコレクションは凄いことができると
  33. プログラムが 20,000 の
    割当を持つ場合なら
  34. 何をすることが必要ですか?
  35. いっそ使用されないメモリを
    開放するためにガベージコレクションを
  36. 実行した方がいいと思いませんか?
  37. これは実際には
    とても複雑な問題であり
  38. ありがたいことにも私たちは
    約 50 年で革新を得ており
  39. Android ランタイムの
    ガベージコレクターは
  40. マッカーシーの当初の提案よりも
    洗練されたものになりました
  41. できるだけ早く
    そして干渉しないようにです
  42. Android ランタイムのメモリヒープを
    効果的に分配することは
  43. 割当タイプに基づいており
    さらに
  44. 将来のGCイベントに割り当てることで
    ベストなシステム運用かできるようになります
  45. また 新しいオブジェクトにも
    割り当てられ
  46. 使用している Android ランタイムの
    バージョンにより
  47. 置かれるべきベストな
    スペースを考慮してくれます
  48. そして ここが
    需要な部分です
  49. 各スペースの大きさの設定は
  50. 割当られたオブジェクトによります
    そして それらの合計サイズも追跡しており
  51. スペースサイズが大きくなると
    ガベージコレクションを実行して
  52. 将来の割当のためにメモリを開放することを
    システムは必要とします
  53. GC イベントの価値は
    Android ランタイムで
  54. 使用しているものに応じて
    異なる動作をすることにあります
  55. たとえば多くの Dalvik は
    GC イベントが終わるまで
  56. 実行中の管理コードを
    停止するようにしています
  57. GC は通常よりも時間がかかる時や
    大幅なフレームレートを占有された時
  58. 問題があるときに一度起こすと
  59. 非常に問題解決に役立ちます
  60. >> 明確にしておきたいことは
  61. Android エンジニアはこのイベントに
    できるだけ速度を早くしたり
  62. フリーズを減らすための使用に
    多くの時間を使っていますが
  63. これはアプリケーションのコード内の
    パフォーマンス問題を起こす可能性があります
  64. まずは GC は多くの時間を与えられた
    フレームの中で消費していることを
  65. 理解する必要があります
    そして残りのロジックは
  66. 1000 分の 16 以下のレンダリングバリアを
    維持するために使われます
  67. もし多くの GC や長い何かが
    お互い右に発生したら
  68. たぶんフレームのプロセス時間が
    1000 分の 16 秒を超えていることを意味するので
  69. ユーザーに良いようには
    見えないでしょう
  70. 次に コードの流れによっては
    GC がより多く動いたり
  71. 普通の状態よりも長く
    作動することがあると理解してください
  72. たとえば あるオブジェクトのかたまりの中に
    より長い時間をかけてループするように
  73. 割り当てるなら 多くのオブジェクトで
    複雑になったメモリヒープを
  74. 早くたくさんの GC で
    片づけさせることで
  75. 追加的なメモリ活用を
    手伝うことおができます
  76. ですが
    私たちのメモリ管理環境からは
  77. 相変わらずメモリリークが起きています
  78. だとしても 他の言語を作ることは
    容易ではありません
  79. メモリリークは使用可能なスペースを減らし
  80. 定期的に GC イベントを
    強制終了させてしまうため
  81. オブジェクト使用からの熱を
    効果的に解除できなくなります
  82. ここで選択しなければなりません
  83. もし与えられたフレームレートの中で
    起こる GC イベントの量を減らしたい場合は
  84. アプリのメモリ使用量を最適化することに
    集中することを選ぶ必要があります
  85. コードの観点から 問題がどこから起きているかを
    特定することはとても
  86. 難しいですが
    ありがたいことに
  87. Android SDK はそれを処理するための
    強力なツールセットを持っています
  88. 見てみましょう