Return to Video

04-02 Memory,_GC,_and_Performance

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

Turkish subtitles

Revisions Compare revisions