Showing Revision 2 created 01/22/2016 by sp16.

1. Title:
   04-07 Leaks_Continued_With_Heap_Viewer
2. Description:

   04-07 Leaks_Continued_With_Heap_Viewer

3. 380 0:00 - 0:07
   Yığın izleyici kullanarak, ilk GC'den sonra
   yalnızca 1.39 milyonun boş olduğunu
4. 6790 0:07 - 0:09
   görüyoruz. Bu, çöp toplayıcısının
   sızıntıdan dolayı çok fazla
5. 9370 0:09 - 0:10
   hafızayı iyileştirediğini gösterebilir.
   İkinci bir GC olayından sonra,
6. 11410 0:11 - 0:15
   yığın izleyici sistemin, bu uygulama
   için daha fazla hafızayı bölerek
7. 15010 0:15 - 0:19
   daha geniş bellek parmak izi düzenlemesine
   karar verdiğini göstermektedir.
8. 19180 0:19 - 0:22
   Yığın boyutunu 32
   megabyte'a çıkartarak, ki
9. 21890 0:22 - 0:24
   20 megabyte'dan ilk GV'de daha yukarıdadır.
10. 23915 0:24 - 0:28
    Bu sefer yığınımızda
    12.9 megabyte'ımız var.
11. 28410 0:28 - 0:31
    Bu noktada, sistem dramatik
    olarak bu uygulamanın
12. 30680 0:31 - 0:33
    daha geniş kapladığı alan
    için bunu denkleştirir.
13. 32960 0:33 - 0:36
    Genişleme tekrar ederse, bu uygulama
    kazasına neden olabilir, eğer sistem
14. 36110 0:36 - 0:38
    artık daha fazla uygulama
    için hafıza dağıtamazsa.
15. 38880 0:39 - 0:44
    O zaman unutmayın, hafıza sızıntısı
    yavaş olur ve bunlar sinsidir ve
16. 43710 0:44 - 0:46
    onaylamak için düzgün test
    ortamı gerektirir ve bu zaman alır.
17. 45780 0:46 - 0:48
    Aynı zamanda, bunun gibi bir modelin
    hafızanın meşru kullanımını
18. 48280 0:48 - 0:51
    temsil edebileceğini unutmayın.
19. 50750 0:51 - 0:52
    Örneğin, geniş grafikler veya
    fotoğrafları çalıştırmak
20. 51530 0:52 - 0:55
    için dizayn edilmiş bir
    uygulamanın olduğunu farzedin.
21. 55440 0:55 - 0:59
    Paketleme servisi burada yavaş hafıza
    sızıntısı için tetikte beklemektedir ancak
22. 58910 0:59 - 1:01
    daima uygulamanızın çekirdek
    işlevliğinin hafıza
23. 60660 1:01 - 1:03
    sonuçlarına karşı topladığınız
    verileri tartmaktadır.
24. 64530 1:05 - 1:08
    Bu noktada, SD'de hafızanın manifestoya
    nasıl sızdığını anlayabilirsiniz.
25. 67950 1:08 - 1:11
    Bu noktada, Hafıza Monitörü ve
    Yığın İzleyicisi gibi sağlanmış
26. 71090 1:11 - 1:14
    olan araçların hafızanın SDK manifestosuna
    nasıl sızdığını anlamanız gerekir.
27. 73960 1:14 - 1:16
    Ancak nereden kaynaklandığını
    bilemeyebilirsiniz.
28. 75720 1:16 - 1:19
    Sızıntıdan kaçınmak için işte size
    bazı iyi çalışma yöntemleri.
29. 78880 1:19 - 1:21
    Kodunuz boyunca objelerinizin hayatını
    takip edin ve ihtiyacınız olmadığında
30. 81270 1:21 - 1:24
    kaynakları (referansları) temizleyin.
31. 84070 1:24 - 1:25
    Tamam, bir sonraki slayt
    gösteriminde bu sızıntıya
32. 85180 1:25 - 1:27
    neyin neden olabileceğiniz
    tanımlayacağız.