Turkish subtitles

← 04-02 Memory,_GC,_and_Performance

04-02 Memory,_GC,_and_Performance

Get Embed Code
13 Languages

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

  1. Şimdi tüm kodlarımız hızlı ve harika
    çalışıyor, o zaman sistemimizde
  2. performansı etkileyecek bellek hakkında
    biraz daha konuşalım.
  3. Donanıma yakın olduğu bilinen çoğu
    programlama dilleri veya tersine,
  4. yüksek performans, C,C++, ve
    Fortran, genellikle belleğin
  5. kendisini yöneten programlayıcılardır.
  6. Etkin olarak programlayıcılar
    bellek blokajının tahsis
  7. edilmesinden ve bazen ileride
    kullanmayı tamamladıklarında kaynağı
  8. serbest bırakmaktan sorumludurlar.
  9. Ne zaman ve ne kadar belleğin boşta tahsis
    edilmesini siz belirlediğiniz için, yönetme
  10. belleğinin toplam kalitesi sizin
    becerilerinize ve etkinliklerinize
  11. bağlıdır. Bu çok büyük sorumluluktur.
  12. Ve gerçek programlayıcılar her zaman
    bellek bölümlerinin ve bitlerinin
  13. tümünü takip edenler değillerdir.
  14. Bunu düşünün demek istiyorum,
    ürün geliştirme kirli ve çılgınca
  15. bir süreçtir ve çoğu zaman
    düzgünce serbest bırakılmadan sonuçlanır.
  16. Bu serbest bırakılmamış bellek bloku
    bellek sızıntısı olarak bilinmekte ve
  17. başka bir yerde daha iyi kullanabileceğiniz
    kabarıklık kaynağında bulunmaktadır,
  18. Bellek sızıntısının neden olduğu bu kaosu,
    stresi ve bazen büyük para
  19. kayıplarını azaltmak için yönetici bellek
    dilleri oluşturulur.
  20. Uygulamanın kendisi tarafından gerekli
    olmadığı zaman, bu dillerin çalışma süresi
  21. bellek tahsislerinin çalışma süreleri ve
    belleğin sisteme geri serbest bırakılması,
  22. bunlar programlayıcıdaki müdahalelerdir.
    Bu tür veya bir yönetici belleği
  23. ortamında iddia edilen tercihan bilim,
    çöp toplama
  24. olarak bilinmektedir, bu konsept 1959
    yılında John McCarthy tarafından
  25. lisp programlama dilinde problemleri
    çözmek için oluşturulmuştur.
  26. Çöp toplama olayının temel ilkeleri
    şöyle: bir numara, örneğin ileride
  27. ulaşılamayan bir programda veri objelerini
    bulma ve kod tarafından artık
  28. başvurulmayan herhangi bir bellek.
  29. İkinci sırada, bu objeler tarafından
    kullanılan kaynakların geri kazanılması.
  30. Teoride basit bir konsept ancak 2
    milyon kod çizginiz olduğunda ve tahsis
  31. değeri dört olduğunda oldukça
    karmaşık olmaktadır.
  32. Şimdi bunu düşünün, çöp toplama olayı
    gerçekten mükemmel olabilir, burada
  33. şu anda programınızda eğer 20,000
    tahsisiniz varsa demek istiyorum.
  34. Hangilerine artık ihtiyaç yok?
  35. Veya daha iyisi, kullanılmayan belleği
    boşaltmak için ne zaman çöp toplama
  36. olayını gerçekleştirmelisiniz?
  37. Aslında bunlar çok zor sorular ve iyi ki
    bunları geliştirmek için inovasyon
  38. değerinde 50 yıl geçirmişiz, bu nedenle
    Android Program Hatasında çöp
  39. tolayıcısının neden McCarthy'nin
    orijinal önerisine göre
  40. biraz daha gelişmiş sofistike
    olduğunu anlıyoruz.
  41. Mümkün olduğunca hızlı ve
    kesintisiz yapılmıştır.
  42. Etkili olarak, tahsis türüne ve ileriki
    GC olayları için sistemin ne kadar iyi
  43. tahsisleri organize ettiğine bağlı
    olarak android program hatalarındaki
  44. bellek yığınları aralıklara
    segmentlere ayrılırlar.
  45. Yeni bir obje tahsis edildiğinde,
    kullanmış olduğunuz android programlama
  46. hatasının sürümüne bağlı olarak
    hangi aralıkların yerleştirilmesi
  47. gerektiğiyle ilgili en iyi bu
    karekteristikler hesaba katılıyor.
  48. Ve işte önemli bir bölüm. Objelerin
  49. serbest kalması gibi her aralığın
    bir ayar boyutu var, biz kombine
  50. boyutları takip edeceğiz ve
    aralık büyüdükçe sistem gelecekteki
  51. tahsisler için belleği
    boşaltmak için çöp toplama
  52. olayını gerçekleştirmesi gerekecektir.
  53. Şimdi kullanmış olduğunuz Android
    program işleyişine bağlı olarak GC
  54. olayının farklı olarak davranmasına değer.
  55. Örneğin, Dalvik'te çoğu GC olayı
    dünya olaylarını durdurur, işlem
  56. tamamlanana kadar çalışan herhangi
    yönetici kodu duracaktır demektir.
  57. Ki bu, eğer GC'ler artık normal değilse
    veya zaman diliminizde önemli
  58. harcamalara neden olduğundan bir
    seferinde binlercesi oluyorsa
  59. çok problemle olabilirler.
  60. >> Ve açık olmak gerekirse, söylenen
    kesintileri azaltabilmek ve mümkün
  61. olduğunca hızlı bir şekilde bu olaylardan
    emin olmak için Android mühendisleri çok
  62. fazla zaman harcadılar. Kodunuzda hala
    bazı uygulama performans problemlerine
  63. neden olabilirler. İlk olarak, ne kadar
    verilen çerçevede
  64. uygulamanız GC yapmada zaman
    harcıyorsa,
  65. o kadar az 16 milisaniye
    engel oluşturma çerçevesinde
  66. tutmak için geri kalan
    mantığın ihtiyacı vardır.
  67. Eğer çok fazla GC'niz varsa veya her
    birisinden sonra oluşan uzun bir şey varsa,
  68. çerçeve işleme sürenizi 16 milisaniye
    engel oluşturma içerisine koyabilir ki bu
  69. görülebilir bağlanmaya veya kullanıcınız
    için saçmalıklara neden olabilecektir.
  70. İkinci olarak, kod akışınız GC'nin
    daha sık olmasına zorlayan bir tür
  71. olabilir veya bu normal süreden
    daha uzun sürdürebilir.
  72. Örneğin uzun süre çalışan döngü
    içerisinde büyük bir bölümdeki
  73. obje stoklarını tahsis ederseniz,
    sonra çok sayıda objeyle bellek
  74. yığıntınızı kirletirseniz, bu ilave
    bellek basıncından dolayı çok
  75. sayıda GC başlatarak hızlıca tüketirsiniz.
  76. Yönetici bellek ortamında
    olmamıza rağmen,
  77. bellek sızıntısı hala olabilir.
  78. Diğer diller kadar oluşturması
    kolay olmamalarına rağmen.
  79. GC olayı esnasında boşalamayacak
    objelerle sıcaklığınızı bu sızıntılar
  80. etkileyebilir, sonuç olarak düzenli
    bir moda dahilinde etkin birşekilde
  81. sahip olduğunuz kullanılabilir alan
    miktarını azaltarak ve daha fazla GC olayı
  82. başlatılmasını zorlayarak. İşte anlaşma,
    verilen çerçevede eğer GC miktarı
  83. olayını azaltmak istiyorsanız,
    uygulama bellek kullanımınızı
  84. iyileştirmeye odaklanmanız
    gerekmektedir, demek istiyorum.
  85. Kod perspektifince, problemlerin
    nereden geldiğini izleyerek bulmak
  86. zordur ancak iyi ki Android
    SDK emrinize hazır bir
  87. şekilde güç araç setine sahip.
  88. Haydi bir göz atalım.