Return to Video

04-02 Memory,_GC,_and_Performance

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

Indonesian subtitles

Revisions Compare revisions