Showing Revision 7 created 01/30/2016 by QA_SP_9_TK.

1. Title:
   04-04 Memory_Leaks
2. Description:

   04-04 Memory_Leaks

3. 280 0:00 - 0:04
   Objeler oluşturulurken veya
   yok edilirken, Android Java Dili ile
4. 4310 0:04 - 0:08
   ilgili en iyi şeylerden biri de
   kullanırken çok dikkat etmeniz
5. 8470 0:08 - 0:11
   gerekmeyen bellek ortamı
   tarafından yönetilmesidir.
6. 11060 0:11 - 0:14
   Bir yandan bu iyi gözükürken,
   burada yüzey altında
7. 13970 0:14 - 0:17
   gizlenmiş bazı gizli
   performans problemleri vardır.
8. 17330 0:17 - 0:20
   Unutmayın, Android çalışırken
   oluşan bellek yığınları
9. 20470 0:20 - 0:24
   tahsis edilme türüne ve sistemin
   sonraki GC olaylarını nasıl daha iyi
10. 23720 0:24 - 0:28
    organize edeceğine bağlı olarak
    alanlarda parçalara ayrılır.
11. 27840 0:28 - 0:31
    Ve her alan kendine ayrılmış
    bellek boyutuna sahiptir.
12. 30580 0:31 - 0:34
    Objenin birleştirilmiş boyutu
    alandaki, kendi sınırına
13. 34140 0:34 - 0:38
    ulaşmaya başladığında, çöp toplama
    olayı yer kazanmak için başlatılır
14. 38050 0:38 - 0:40
    ve gereksiz objeler kaldırılır.
15. 39612 0:40 - 0:44
    Bu GC olayları, genelde performans
    açısından farkedilen bir problem değildir.
16. 43795 0:44 - 0:47
    Fakat bunların çoğu defalarca
    tekrar eder ve frame zamanını
17. 46809 0:47 - 0:49
    diliminizi hızlıca tüketebilir.
18. 48805 0:49 - 0:51
    Daha fazla GC yapmak için
    zaman harcarsınız
19. 50725 0:51 - 0:54
    render veya ses yayını gibi şeyleri
    yapmak için daha az zamanınız olur.
20. 54122 0:54 - 0:58
    Geliştiricilerin genel olarak
    maruz kaldığı ve birçok GC'nin
21. 57632 0:58 - 1:01
    oluşmasına neden olan şey
    bellek sızıntısı olarak bilinir.
22. 60792 1:01 - 1:04
    Bellek sızıntısı, uygulamanın artık
    kullanmadığı nesnelerdir ancak
23. 64272 1:04 - 1:07
    çöp toplayıcısı bunların
    kullanılmadığını fark edemez.
24. 67402 1:07 - 1:11
    Sonuç olarak yığında hâlâ bekliyorlar
    ve diğer objeler için serbest
25. 70632 1:11 - 1:13
    bırakılması gereken önemli
    bir alanı kaplıyorlar.
26. 73282 1:13 - 1:15
    Bellek sızıntısı devam ettikçe
27. 74542 1:15 - 1:19
    yığın üretimiyle uygun alanlar
    gittikçe küçülmeye devam eder.
28. 78802 1:19 - 1:22
    Öyle ki bu, normal program yürütmesine
    daha fazla alan açmak için
29. 82230 1:22 - 1:25
    daha fazla GC'nin daha sık
    yürütüleceği anlamına gelir.
30. 85490 1:25 - 1:29
    Sızıntıları bulmak ve
    düzeltmek alengirli bir iştir.
31. 88530 1:29 - 1:30
    Bazı sızıntıları oluşturması kolaydır,
32. 90350 1:30 - 1:34
    programın kullanmadığı objelere
    döngüsel gönderme yapmak gibi.
33. 93790 1:34 - 1:35
    Diğerleri o kadar kolay değildir.
34. 95410 1:35 - 1:40
    Örneğin, yüklenmeleri sırasında
    sınıf yükleyici nesneleri tutmak gibi.
35. 99580 1:40 - 1:43
    Her iki durumda da, akıcı çalışan
    hızlı bir uygulama, mevcut olan
36. 103030 1:43 - 1:46
    bellek sızıntılarına karşı
    uyanık ve duyarlı olmalıdır.
37. 105640 1:46 - 1:48
    Yani, kodunuz bir çok farklı
    aygıt üzerinde
38. 108160 1:48 - 1:49
    çalışacak ve
39. 109270 1:49 - 1:52
    hepsi aynı bellek alanına ve
    boyutuna sahip olmayacaktır.
40. 111980 1:52 - 1:55
    Neyse ki, Android SDK içerisinde
    sızıntıların nerede olabileceğini
41. 115420 1:55 - 1:58
    görmemize yardımcı olan
    basit bir araç var.
42. 118100 1:58 - 1:59
    Haydi buna bir bakalım.