Sorun Android ve java app'ler. Olay soyle gerceklesiyor:
Birinci sebep single threaded rendering. Android L'ye kadarki butun versiyonlarda, bir UI thread var. yani rendering single threaded. android rendering architecture en basta java'da baslamis (her OS firmasinin tarihinde boyle bir gerizekalilik ani var
managed dillerden gelen bir dingil "evet evet artik managed diller yeterince olgunlasti performans olarak problem yok UI'i managed dilde cizdirebiliriz problem olmaz" diyor ve bunu satiyor sonra koca bir firma bunu temizlemeye calisiyor. bkz Windows Vista reset, bkz Android) ve zamanla onemli bolumleri once native'e sonra da hwui uzerinden gpu'ya kaymis durumda. Lakin hwui bile henuz app'in Android View'lerini yarattigi ayni thread'de gl call'lari file ediyor.
Yani bir thread'de java view'lerin ondraw'lari traverse ediliyor. oralardan yine java'da display listler yaratiliyor, bunlar jni'dan native hwui'ye ulasiyor. hwui'de DisplayList'ten, OpenGlRenderer'a oradan opengl'e variyor. orada kullanilan gpu'nun driver'ina ve mimarisine bagli olarak da komutlar, tile-resolve'lar, fence'ler falan gibi senkronizasyon problemleri uzerinden en son ekran buffer'larina variyor.
Eger app developer o thread'de herhangi bir isi biraz uzatirsa frame kaciriyor.
Ikinci sebeb garbage collection. Eskiden java gc oldugu zaman butun dunyayi durduruyordu. ve herhangi bir alokasyon gc baslatabilir. bu onceden app'in orta yerinde 100 ms bloklanmak demekti. gingerbread'den beri "mostly concurrent" gc var ama o da 5 ms gibi beklemeler yaratabiliyor ki kotu zamanda gelen bir 5 ms size frame atlatabilir.
Dolayisiyla teorik olarak hic frame atlamayan android app'leri java'da yazilabilir. Ancak genelde pekcok app developer bu kadar hakim degil. Sonucta yaptigin cok masum gorunen kucucuk alokasyonlar bile GC baslatabilir. Bu olmasin diye bu geri zekali android'in "best practice"leri var. Bunlar "hic bisey aloke etme" "poollar yarat ordan kullan" "objeleri hep mutable yap recycle et" falan gibi seyler. Hani java kullanirkan bunlari dusunmek zorunda kalmamak avantajdi?
Iste o best practice'lerin birini kaciran her app her an frame atlayabilir. Ben bugune kadar elime alip 20 saniye icinde frame atlattiramadigim android cihaz gormedim.
Ayrica android codebase'de kod kalitesinin cok dusuk oldugu cok yer var. Bazi yerleri bildiin stajyere yazdirdiklarini dusunuyorum.
Tabi ilk versiyonlardan bugune coook cok gelismis. Ama yine de fluidity yonunden buyuk sorunlar var. L'de ayri render thread geliyor. Biraz daha iyilestirecektir.
GC icin'de ART'in Dalvik'i emekliye ayirmasi yardimci olabilir.
Butun bunlarin yaninda IOS ve Windows Mobile'in rendering stackleri defalarca daha ustun native stack'ler. IOS source'larini gormedim tabi ama windows grafik stack source'unu elbette gordum. ve Android'deki bazi production kodlari, windows da prototip branch'lerinde kod review'leri gecemez oyle soyliyim ben size.
