Indonesian subtitles

← 04-02 Memory,_GC,_and_Performance

04-02 Memory,_GC,_and_Performance

Get Embed Code
13 Languages

Showing Revision 9 created 01/26/2016 by sp16.

  1. Sekarang semua kode kita
    berjalan cepat dan mengagumkan,
  2. mari kita berbicara lebih banyak
    mengenai memori
  3. dan bagaimana bisa mempengaruhi
    kinerja dalam sistem kita.
  4. Banyak bahasa pemrograman yang
    dikenal dekat dengan perangkat keras,
  5. atau lebih tepatnya, kinerja tinggi,
    seperti C, C ++, dan Fortran,
  6. biasanya membutuhkan programmer
    untuk mengelola memorinya sendiri.
  7. Secara efektif programmer
    bertanggung jawab atas
  8. mengalokasikan blok memori dan kemudian
    suatu saat mengalokasikan kembali
  9. saat mereka sudah selesai menggunakannya.
  10. Karena Anda yang menentukan
    kapan dan berapa banyak memori
  11. yang dialokasikan secara gratis,
  12. seluruh kualitas pengelolaan memori
  13. tergantung pada
    keterampilan dan efektivitasmu.
  14. Itu tanggung jawab yang besar.
  15. Dan secara realitas, programmer
    tidak selalu yang terbaik dalam melacak
  16. semua potongan-potongan memori.
  17. Maksudku pikirkanlah,
    pengembangan produk itu sulit dan
  18. proses gila dan sering memori
    berakhir tidak dibebaskan dengan benar.
  19. Blok memori yang tidak bisa dibebaskan ini
  20. disebut kebocoran memori
  21. dan mereka hanya diam
    memonopoli sumber daya,
  22. yang bisa Anda gunakan
    lebih baik atau di tempat lain.
  23. Untuk mengurangi kekacauan ini, stres,
    dan terkadang kerugian uang yang besar,
  24. yang disebabkan oleh kebocoran memori,
    manajemen bahasa memori diciptakan.
  25. Runtime bahasa-bahasa tersebut
    melacak alokasi memori dan
  26. melepas memori kembali ke sistem
    ketika tidak lagi dibutuhkan oleh
  27. aplikasi itu sendiri, semua tanpa
    intervensi dari programmer.
  28. Seni ini, atau lebih tepatnya ilmu,
  29. dari reklamasi memori
    dalam lingkungan memori yang dikelola
  30. dikenal sebagai koleksi sampah,
    konsep ini diciptakan oleh
  31. John McCarthy pada tahun 1959
  32. untuk memecahkan masalah
    dalam bahasa pemrograman LISP.
  33. Prinsip dasar koleksi sampah
    adalah sebagai berikut, nomor satu,
  34. temukan objek data di sebuah program
    yang tidak dapat diakses di masa depan,
  35. contohnya, setiap memori yang
    tidak lagi direferensikan oleh kode.
  36. Dan nomor dua, merebut kembali sumber
    daya yang digunakan oleh objek tersebut.
  37. Konsep sederhana dalam teori, tapi
    cukup kompleks setelah Anda memiliki
  38. dua juta baris kode dan
    empat pekerjaan senilai alokasi.
  39. Pikirkan tentang hal itu, pengumpulan
    sampah dapat benar-benar degil,
  40. maksudku, jika Anda punya sekitar 20.000
    alokasi dalam program Anda sekarang.
  41. Mana yang tidak diperlukan lagi?
  42. Atau lebih baik lagi, saat Anda harus
    mengeksekusi pengumpulan sampah
  43. untuk membebaskan
    memori yang tidak digunakan?
  44. Pertanyaan-pertanyaan ini
    sebenarnya sangat sulit dan
  45. untungnya kami memiliki inovasi selama
    50 tahun untuk memperbaikinya,
  46. yang mengapa
    kolektor sampah di Android Runtime,
  47. agak sedikit lebih canggih
    dari proposal awal McCarthy.
  48. Alat ini dibuat untuk menjadi lebih cepat
    dan tidak menggangu sebisa mungkin.
  49. Efektif timbunan memori di Androids
    Runtimes tersegmentasi ke dalam ruang,
  50. berdasarkan jenis alokasi
  51. dan cara terbaik sistem dapat mengatur
    alokasi untuk GC di masa depan.
  52. Sebagai objek baru dialokasikan,
  53. karakteristik ini dibawa ke akun
    ruang yang paling sesuai untuk ditempatkan
  54. dan tergantung versi
    Android Runtime yang Anda gunakan.
  55. Dan inilah bagian pentingnya.
  56. Setiap ruang memiliki ukuran set,
  57. saat objek dialokasikan,
    kami terus melacak ukuran gabungan,
  58. dan saat ruang mulai tumbuh,
    sistem akan perlu mengeksekusi
  59. koleksi sampah dalam rangka membebaskan
    memori untuk alokasi masa depan.
  60. Sekarang sangat berharga menempatkan
    bahwa GC akan berperilaku berbeda
  61. tergantung pada
    Android Runtime yang Anda gunakan.
  62. Misalnya, di Dalvik banyak GC
    menghentikan peristiwa dunia,
  63. itu artinya bahwa
    setiap kode yang berjalan
  64. akan berhenti sampai operasi selesai.
  65. Yang bisa sangat bermasalah,
  66. saat GC memakan waktu
    lebih lama dari biasanya
  67. atau ada banyak peristiwa
    terjadi sekaligus,
  68. karena akan signifikan memakan
    frame time [kerangka waktu] Anda.
  69. Dan harus jelas,
    para insinyur Android
  70. telah menghabiskan banyak waktu
    memastikan peristiwa ini
  71. secepat mungkin untuk mengurangi
    interupsi, hal itu bisa dikatakan,
  72. mereka masih dapat menyebabkan
    beberapa masalah kinerja aplikasi
  73. di dalam kodemu.
  74. Pertama, memahami bahwa
    lebih banyak waktu aplikasi Anda
  75. menghabiskan melakukan GC
    di frame yang diberikan
  76. semakin sedikit waktu
    sisa logika yang diperlukan
  77. untuk menjaga Anda di bawah
    16 milidetik penghalang rendering.
  78. Jadi jika Anda punya banyak GC
    atau proses setelahnya,
  79. mungkin membuat kerangka waktu
    pemrosesan Anda melebihi 16 milidetik
  80. penghalang rendering,
  81. yang menyebabkan hitching [nebeng]
    terlihat atau jank untuk pengguna Anda.
  82. Kedua, memahami aliran kode Anda
    dapat melakukan jenis pekerjaan yang
  83. memaksa GC terjadi lebih sering,
  84. atau membuat mereka bertahan
    lebih lama dari durasi normal.
  85. Misalnya, jika Anda mengalokasikan
  86. menimbun benda
    di bagian dalam loop [lingkaran]
  87. yang berjalan untuk waktu lama,
  88. maka itu akan mengotori
    tumpukan memorimu
  89. dengan banyak objek dan Anda
    akan berakhir mengeluarkan banyak GC
  90. dengan cepat,
    karena tekanan memori tambahan ini.
  91. Dan meskipun kita berada dalam
    lingkungan memori yang dikelola,
  92. kebocoran memori masih bisa terjadi.
  93. Meskipun mereka tidak semudah
    untuk menciptakan sebagai bahasa lain.
  94. Kebocoran ini dapat mencemari panas
    dengan objek yang tak bisa dibebaskan
  95. selama GC terjadi,
  96. efektif mengurangi jumlah
    ruang yang dapat Anda gunakan dan
  97. memaksa banyak GC yang harus dimulai,
  98. secara teratur sebagai hasilnya.
    Itu adalah kesepakatannya, maksudku,
  99. Jika Anda ingin mengurangi jumlah GC
  100. yang terjadi di dalam frame,
  101. Maka Anda perlu fokus pada mengoptimalkan
    penggunaan memori aplikasi Anda.
  102. Dari perspektif kode,
  103. mungkin akan sulit untuk melacak
    dari mana masalah seperti ini berasal,
  104. tapi untungnya, SDK Android memiliki
    set alat yang kuat yang Anda inginkan.
  105. Mari kita lihat.