-
Title:
04-07 Leaks_Continued_With_Heap_Viewer
-
Description:
04-07 Leaks_Continued_With_Heap_Viewer
-
Yığın izleyici kullanarak, ilk GC'den sonra
yalnızca 1.39 milyonun boş olduğunu
-
görüyoruz. Bu, çöp toplayıcısının
sızıntıdan dolayı çok fazla
-
hafızayı iyileştirediğini gösterebilir.
İkinci bir GC olayından sonra,
-
yığın izleyici sistemin, bu uygulama
için daha fazla hafızayı bölerek
-
daha geniş bellek parmak izi düzenlemesine
karar verdiğini göstermektedir.
-
Yığın boyutunu 32
megabyte'a çıkartarak, ki
-
20 megabyte'dan ilk GV'de daha yukarıdadır.
-
Bu sefer yığınımızda
12.9 megabyte'ımız var.
-
Bu noktada, sistem dramatik
olarak bu uygulamanın
-
daha geniş kapladığı alan
için bunu denkleştirir.
-
Genişleme tekrar ederse, bu uygulama
kazasına neden olabilir, eğer sistem
-
artık daha fazla uygulama
için hafıza dağıtamazsa.
-
O zaman unutmayın, hafıza sızıntısı
yavaş olur ve bunlar sinsidir ve
-
onaylamak için düzgün test
ortamı gerektirir ve bu zaman alır.
-
Aynı zamanda, bunun gibi bir modelin
hafızanın meşru kullanımını
-
temsil edebileceğini unutmayın.
-
Örneğin, geniş grafikler veya
fotoğrafları çalıştırmak
-
için dizayn edilmiş bir
uygulamanın olduğunu farzedin.
-
Paketleme servisi burada yavaş hafıza
sızıntısı için tetikte beklemektedir ancak
-
daima uygulamanızın çekirdek
işlevliğinin hafıza
-
sonuçlarına karşı topladığınız
verileri tartmaktadır.
-
Bu noktada, SD'de hafızanın manifestoya
nasıl sızdığını anlayabilirsiniz.
-
Bu noktada, Hafıza Monitörü ve
Yığın İzleyicisi gibi sağlanmış
-
olan araçların hafızanın SDK manifestosuna
nasıl sızdığını anlamanız gerekir.
-
Ancak nereden kaynaklandığını
bilemeyebilirsiniz.
-
Sızıntıdan kaçınmak için işte size
bazı iyi çalışma yöntemleri.
-
Kodunuz boyunca objelerinizin hayatını
takip edin ve ihtiyacınız olmadığında
-
kaynakları (referansları) temizleyin.
-
Tamam, bir sonraki slayt
gösteriminde bu sızıntıya
-
neyin neden olabileceğiniz
tanımlayacağız.