"Programcı": Ctrip mobil terminal kullanıcı arayüzü arayüzü performans optimizasyonu uygulaması
Sonuç olarak yazar, UI optimizasyonu, ağ optimizasyonu, iletişim veri formatı aktarım optimizasyonu, bellek optimizasyonu, başlangıç zamanı optimizasyonu, Hibrit çerçeve optimizasyonu ve React Native optimizasyonu perspektiflerinden ayrıntılı bir geliştirme gerçekleştirdi. Bu makale ilk bölümdür: UI optimizasyonu.Diğer bölümler "Programmer" dergisinin Aralık sayısında yayınlanacaktır. Ayrıntılar için lütfen 2016 "Programmer" a abone olun.
UI donmasının ilkesi ve nedeni
İnsan beyninin ve gözlerinin aslında bir resmin sürekliliğinde bir sınırı vardır.Örneğin, bir film izlediğimizde resmin doğal olarak tutarlı olduğunu ve kare hızının genellikle 24 fps olduğunu hissediyoruz; o zaman elbette cep telefonu kullanmanın da ekran işlemlerinin sürekliliğini algılaması gerekiyor ( Özellikle animasyon geçişi), bu nedenle cep telefonları alanında, Android / iOS basitçe bu pürüzsüz kare hızının 60 fps olmasını şart koşuyor.
Yukarıdaki arka plana dayalı olarak, Uygulama geliştirmemizin kare hızı performans hedefi, 60 fps'yi (16 ms / kare) korumaktır, yani Uygulama performansını optimize ettiğimizde aşağıdaki yönergeleri izlemeliyiz:
Tüm CPU ve GPU hesaplamalarının, çizim, oluşturma ve diğer işlemlerin her kare için 16 ms içinde işlendiğinden emin olmaya çalışın, aksi takdirde kare kaybı ve donma sorunlarına neden olur.
Yukarıdaki kekemelik prensibine dayanarak, kekemeliğin gerçekte nicelleştirilebileceğini biliyoruz.Her seferinde başarılı bir şekilde işlenip işlenemeyeceği çok önemli bir konu, yani bir işlemin 16 ms'de tamamlanıp tamamlanamayacağı, kekemelik performans sorununu doğrudan belirler.
UI donmasının yaygın nedenleri aşağıdaki gibidir:
-
Ana iş parçacığı, kullanıcı arayüzünü engelleyen zaman alıcı bir işlem yapar;
-
Animasyonun aynı anda birden çok kez yürütülmesi, GPU ve CPU'nun aşırı çekilmesine neden olur;
-
Görüntü aşırı çizim GPU ve CPU'da aşırı çekmeye yol açar;
-
Yerleşim çizimi ve metin hesaplama gibi sık yapılan işlemler, Görünümün yeniden işlenmesine neden olur;
-
Sık nesne oluşturma ve yok etme;
-
Aşırı karmaşık iş mantığı, zaman alan işlevler.
Ctrip Uygulamasının çeşitli UI arayüzlerinin optimizasyonu ile ilgili olarak, sorunu esas olarak yukarıda belirtilen UI gecikmesinin nedenlerine dayanarak çözdük, kare hızını iyileştirmeye, yerleştirme düzeni seviyesini azaltmaya ve nesne oluşturmayı azaltmaya odaklanıyoruz. Ctrip otelleri ve uçak biletlerinin ana işlem arayüzleri nispeten karmaşıktır. İş mantığı işlevi ne kadar karmaşıksa, performans sorunlarına sahip olma olasılığı o kadar yüksektir.Bu nedenle, genellikle karmaşık düzen, fazla çizim, zaman alan UI Thread işlevi, yavaş içerik yükleme, arayüz yeniden düzen (Layout) ve birçok GC zamanı gibi sorunlarla karşılaşır. Her sürümün yinelemeli geliştirme sürecinde, esas olarak platformu Android ve iOS olarak ayırıyor ve kullanıcı arayüzünü platform özellikleri açısından hedefli bir şekilde optimize ediyoruz.
Ctrip Uygulaması Android UI optimizasyon önlemleri
Android platformu, temelde Düzen düzeyini optimize ederek kullanıcı arayüzünü optimize eder: düzeyleri düşürür ve gereksiz yeniden Düzen ve Ölçümü önler, arabirim ekranını hızlandırır ve sistem GC'lerinin sayısını azaltır.
GPU Aşırı Çekmeyi Optimize Edin
"GPU Overdraw'ı Göster" geliştirici seçeneği aracılığıyla, inceleme arayüzünün aşırı çekme durumu görüntülenebilir. Optimizasyon karmaşık değildir Basamaklı düzende fazlalık arka plan ayarlarını ve resim kontrollerini kaldırarak, ön plan içeriği olduğunda arka plan görüntülenmez, arayüz arka planı Aktivite temasında tanımlanır ve Drawable'ın karmaşık Shape kullanımı temelde ortadan kaldırılabilir. Çizin, GPU ve CPU israfını azaltın.
UI performansının optimizasyonumuz, geliştirici seçeneklerinde ve ayarlarda GPU aşırı çekme aracı aracılığıyla analiz edilir. > geliştirici seçeneği- > GPU aşırı çiziminde hata ayıklayın (farklı cihazların farklı yerleri veya adları olabilir) ve hata ayıklamayı açtıktan sonra aşağıdaki şekil 1'i görebilirsiniz (Ctrip'in mevcut arayüzünün aşırı çizimini analiz edin)
Şekil 1 Ctrip otel listesi Overdraw
Tablo 1 Renk fazlalık diyagramı
Açtıktan sonra, uygulama arayüzünde hata ayıklamak istediğimiz çeşitli renkteki alanları görebileceğiniz ve belirli anlamın yukarıdaki tabloda gösterildiği görülebilir.
Aşırı çizim, ekranın bir pikselinde birden çok kez çizmeyi ifade ettiğinden (örneğin, arka plan rengi bir kez metin olduğunda iki kez arka plan rengine sahip bir TextView çizilecektir; burada vurgulanması gereken, Aktivite tarafından belirlenen Tema temasının arka planının sayılmamasıdır. Aşırı çizim seviyesi), bu nedenle en ideal olanı bir kez çizmektir, ki bu mavi (tabii ki bu birçok muhteşem arayüzde gerçekçi değildir, bu nedenle herkesin bir derecesi vardır. Performans optimizasyonu standart gereksinimleri geliştiriyoruz: kırmızı alan uzun vadeli olamaz Ekranın üçte birini aşmaya devam edin), bu nedenle düzeni düzeyini optimize etmek, gereksiz arka planları azaltmak, geçici olarak görüntülenmeyen Görünümü GÖRÜNMEZ yerine GONE olarak ayarlamak ve Görünüm'ün onDraw yöntemi ayarını özelleştirmek gibi bu renk dağılımına dayalı olarak kodu optimize etmemiz gerekir. Canvas.clipRect, çizim alanını belirtir veya en iyileştirmek için canvas.quickreject aracılığıyla çizim alanını azaltır.
Yukarıdaki Şekil 1'de gösterildiği gibi, otel listemizin ListView listesi öğesi optimize edildikten sonra, temelde yeşildir ve optimizasyondan önce çoğu kırmızıdır.
Düzen seviyesini optimize edin
UI düzeni iç içe yerleştirme seviyeleri ne kadar fazla olursa, ölçüm ve düzen süresi buna göre artacak ve temel çerçevenin donanım listesini oluşturma süresi buna göre artacaktır. Tarihsel nedenlerden dolayı, bazen mizanpajın okunabilirliğini artırmak için, basit mizanpajlarla elde edilebilecek işlevleri elde etmek için farklı üst düzey mizanpajları iç içe yerleştireceğiz ve bazen yalnızca test aşamasında kullanılacak mizanpajlar ekleyeceğiz. Yararsız seviyeleri silerek veya tüm yerleşimi dönüştürerek düzen düzeyini azaltın. Düzen düzeyini azaltmak için LinerLayout'u değiştirmek için RealtiveLayout kullanın; ek olarak, bazı ekran hatası arabirimi, yükleme komut kutusu arabirimi vb. Gibi genel düzen performansını optimize etmek için Merge etiketini veya ViewStub etiketini kullanın, görüntülenmesine gerek yoktur Bu düzenler, performansı artırmak için ViewStub etiketlerini kullanabilir.
Spesifik optimizasyon çalışması yaparken, sistemin UI seviyesini analiz etmek için HirectViewer, UI Automator için Dump UI Hierarchy ve sistemle birlikte gelen diğer araçları kullanırız.Benzer analiz sonucu aşağıdaki Şekil 2'de gösterilmiştir:
Şekil 2 UI Automator için Ctrip ana sayfası Dökümü UI Hiyerarşisi
Yukarıdaki Şekil 2'de gösterildiği gibi, mevcut arayüz Görünümünün oluşturma iç içe geçme seviyesini analiz edebilirsiniz.Genel olarak, 11 seviyeyi aşması tavsiye edilmez. 11 seviyeyi aşarsa, düzen optimizasyonunun gerekli olduğunu gösterir.Örneğin, o sırada gereksiz üst düzeni ve ViewStub'ı azaltmak gibi mekanizmaları benimsedik. En iyi hale getirmek için.
Arayüz yüklemesini hızlandırın
Mizanpaj düzeyini XML Mizanpaj dosyası perspektifinden düşürmenin yanı sıra, mizanpaj, aynı zamanda, mizanpajı önceden yükleyerek, yani gerçek görüntüleme süresini azaltmak için iş parçacığında gerekli bazı şişirme yaparak başlatılır. Bazı karmaşık düzenler için, özellikle liste kontrollerinde şişirmenin neden olduğu performans kaybını azaltmak için kendi View nesnesi yeniden kullanım havuzumuzu da oluşturacağız.
TraceView aracını ana iş parçacığının ve diğer zaman alan iş parçacıklarının zaman alıcı işlemlerini bulmak ve bunları optimize etmek ve ana iş parçacığının GC duraklamasını azaltmak için kullanabilirsiniz. Paralel GC'de bile, yığın kilitlenecek ve ana iş parçacığı bellek ayırmayı isterse askıya alınacak, bu nedenle özellikle onDraw gibi işlevlerde ana iş parçacığında daha fazla nesne ve daha büyük nesne ayırmaktan kaçınmaya çalışın. Askıya alınan süreyi azaltmak için. Ek olarak, ListView, ScrollView ve diğer kontrollerin EdgeEffect etkisini kaldırarak bellek tahsisini azaltabilir ve kontrolün oluşturulma süresini hızlandırabilirsiniz.
Yerel önbelleği kullanarak, ana arabirim son verileri önbelleğe alır ve artımlı güncelleme ve silme işlemleriyle, veriler sunucuyla senkronize edilebilir, böylece yerel veriler, ağın verileri geri getirmesini beklemeden doğrudan görüntülenebilir.
Gereksiz veri protokol alanlarını azaltın, ad uzunluğunu vb. Azaltın ve sıkıştırma yapın. İletim ve analiz süresini hızlandırmak için verileri sayfalara da yükleyebilirsiniz. Veriler ne kadar büyük olursa, iletim ve ayrıştırma süresi o kadar uzun olur ve o kadar çok bellek nesnesi tahsis edilir.
İş parçacığının önceliğine dikkat edin Daha fazla CPU zamanı alan işlevler için, iş parçacığının önceliğini de belirlemelisiniz.
Özel kontroller yeniden yerleşimi engeller
ListView kaydırma, reklam animasyonu değişiklikleri vb. Sürecinde, resimler ve metin değişmiştir ve genellikle tüm arayüzün yeniden düzenlendiği ve bu da performansı etkilediği bulunmuştur. Özellikle düzen karmaşık olduğunda, ölçüm süreci zaman alıcıdır ve bariz bir gecikmeye neden olur. Örneğin, TextView ve ImageView gibi temelde boyut olarak sabitlenmiş kontroller ve düzenler için bu, gereksiz kayıptır. Optimizasyon önlemleri alarak, requestLayout ve onSizeChanged yöntemlerini engellemek, geçersiz kılmak ve boyut değişmezse isteği engellemek için özel kontroller kullanırız. ViewPager gibi reklam afişleri için, önbelleğe alınan alt Görünümlerin sayısını reklam sayısına göre ayarlayabilirsiniz.
Sistem GC sürelerini azaltın
Android'de GC, performans gecikmesine neden olur ve optimize edilmesi gerekir. Görüntü belleğinin neden olduğu GC optimizasyonuna ek olarak aşağıdakileri de yaptık:
Nesne tahsisini azaltın ve gereksiz nesne tahsisini bulun.Örneğin, ambalajsız tipler kullanılabildiğinde, Otomatik Kutudan kaçınmak için paketleme türleri kullanılır. > Kutudan çıkarma işlemi, aynı anda çok sayıda nesne dizgisinin + işaret işlemini önler.Eğer iş parçacığı güvenliğinin neden olduğu sorunları dikkate almıyorsanız, dize işlemlerini gerçekleştirmek için StringBuffer yerine StringBuilder kullanın. Handler.post (Runnable r) sıklıkla kullanılır.
Nesnelerin yeniden kullanımı, sıklıkla tahsis edilen nesneler için bir yeniden kullanım havuzunun kullanılmasını gerektirir.
Yararsız nesnelere, özellikle büyük nesnelere ve koleksiyon nesnelerine ilişkin referansları mümkün olan en kısa sürede bırakın ve bunları "As" olarak ayarlayarak zamanında geri çağırın.
Sızıntıyı önlemek için, en temel dosyalara, akışlara, veritabanlarına, ağ erişimine, vb. Ek olarak, kendinizin Kaydı kaldırarak kaydettiğiniz bazı olayları kapatmayı ve statik değişkenleri ve tekilleri mümkün olduğunca az kullanmayı unutmamalısınız. Ek olarak, sistem tarafından sağlanan Android Lint statik tarama aracı, Thread'ın neden olduğu benzer İşleyici sızıntılarını ve bellek sızıntılarını önceden analiz edebilir.
Sonlandırma yönteminin kullanımını kontrol edin ve yüksek frekans işlevinde sonlandırmayı yeniden yazan sınıfı kullanın; bu, GC yükünü artıracak ve performans farkını birkaç kez yaratacaktır.
Makul bir kap seçin ve performansa öncelik verin.
Diziler, artık konteyner kullanmaya alışkın olsak bile, konteynerlerin sık kullanımının gizli performans tehlikelerine dikkat etmeliyiz: ilki genişletme maliyeti ve HashMap'i genişletirken yeniden Hashing maliyeti nispeten büyük. İkincisi, bellek ek yüküdür. HashMap, ek Map.Entry nesne tahsisi gerektirir, ek bellek gerektirir ve daha fazla bellek parçalanmasına eğilimlidir. SparseArray ve ArrayList, bellek açısından daha fazla avantaja sahiptir. Yine çapraz geçiştir.ArryList gibi RandomAccess arayüzünü uygulayan konteynerlerin geçişi için foreach döngüsü kullanılmamalıdır. Mobil cihazlarda, numaralandırmayı kullanmaktan kaçınmaya çalışın ve bunları açık anlamlara sahip özel int sabitleriyle değiştirin.
İzleme ve ince ayar yapmak için araçları kullanın: Sayfa kaydırma işlemi sırasında, bellek dalgalanmalarını ve GC koşullarını görüntülemek için Android Studio ile birlikte gelen Bellek İzleme aracını kullanın. Ayrıca, bellek ayırmayı gözlemlemek ve analiz etmek ve birçok küçük nesne ayırma problemini bulmak için Ayırma İzleyici aracını da kullanabilirsiniz. Ve bir bellek sızıntısı sorunu olup olmadığı. Olağan geliştirme çalışmamızda bellek sızıntılarını izlemek için LeakCannary'yi de entegre ettik.
Bazı yuvarlak görüntülerin işlenmesi gibi arabirimde zaman alan donanım hızlandırma noktalarını bulmak için Trace For OpenGL aracını kullanın.
Diğer detayların optimizasyonu
TraceView aracı aracılığıyla, bazı banner carousel reklamlarının ve metin animasyonlarının görünür alandan çıktıktan sonra hala düzenli olarak yenilendiğini gördük, bu sadece güç tüketmekle kalmaz, aynı zamanda kare hızını da etkiler. Optimizasyon ölçüsü, görünür alandan çıktıktan sonra animasyon karuselini durdurmaktır.
Ara yazılımın kodu, üst düzey iş tarafı tarafından daha sık çağrılır ve daha yüksek frekanslı işlevlere sahip olma eğilimindedir ve ayrıca ayrıntılı sorunlara eğilimlidir. Sık sık nesne atamaya ek olarak, sınıf başlatma performansı, senkronizasyon kilidi ek yükü, arabirim çağrı süresi ve numaralandırma kullanımı gibi sorunlar da göz ardı edilemeyecek konulardır.
Ctrip Uygulaması iOS UI optimizasyon önlemleri
İOS platformu ayrıca, temelde sık nesne oluşturma, ayarlama, imha etme, düzen hesaplama, görüntü oluşturma ve sorunları analiz etmek ve bulmak için diğer perspektiflerden kaçınarak GPU ve CPU kaynak tüketim mekanizmalarını azaltarak kullanıcı arayüzünü optimize eder. CPU ve GPU'nun kaynak tüketimini gerçek zamanlı olarak görmek için Cihazların GPU Sürücüsü ön ayarlarını kullanırız. Bu ön ayarda, doku sayısı, CA gönderme sıklığı, GPU tüketimi gibi ekranla ilgili neredeyse tüm verileri ve konumlandırma arayüzündeki sorunun nedeni görüntüleyebilirsiniz.
Nesne oluşturmayı ve nesne yok etmeyi optimize edin
Nesnelerin oluşturulması bellek ayıracak, öznitelikleri ayarlayacak ve hatta daha fazla CPU kaynağı tüketen dosyaları okuyacaktır. Performansı optimize etmek için ağır nesneler yerine hafif nesneler kullanmayı deneyin. Örneğin, CALayer, UIView'den çok daha hafiftir, bu nedenle dokunma olaylarına yanıt veren kontrollere gerek yoktur ve CALayer ekranı daha uygundur. Nesne UI işlemlerini içermiyorsa, onu oluşturmak için arka plan iş parçacığına koymayı deneyin.
Nesnelerin yok edilmesi çok fazla kaynak tüketmese de, birikim göz ardı edilemez. Genellikle bir konteyner sınıfı çok sayıda nesneyi tuttuğunda, yok edildiğinde kaynak tüketimi çok açıktır. Benzer şekilde, nesne serbest bırakılacak arka plan iş parçacığına yerleştirilebilirse, arka plan iş parçacığına geçin. İşte küçük bir ipucu: bloktaki nesneyi yakalayın ve ardından derleyici uyarılarını önlemek için rasgele bir mesaj göndermek için arka plan kuyruğuna atın ve nesne arka plan iş parçacığında yok edilebilir.
Sık nesne ayarlamalarından kaçının
Nesnelerin ayarlanması genellikle CPU kaynaklarının tüketildiği yerdir. Özellikle CALayer'dan bahsedeyim: CALayer içinde özniteliklere sahip değil. Öznitelik yöntemini çağırırken, çalışma zamanı resolverInstanceMethod aracılığıyla geçici olarak nesneye bir yöntem ekler ve ilgili öznitelik değerini dahili bir Sözlüğe kaydeder ve ayrıca temsilciyi bilgilendirir. , Animasyonlar vb. Oluşturmak çok yoğun kaynak gerektirir. UIView'ın görüntüyle ilgili özellikleri (çerçeve / sınırlar / dönüşüm gibi) aslında CALayer özelliklerinden eşlenir, bu nedenle UIView'un bu özelliklerini ayarlarken, tüketilen kaynaklar genel özelliklerden çok daha büyüktür. Bunun için uygulamanızda gereksiz nitelik değişikliklerini en aza indirmelisiniz.
Görünüm seviyesi ayarlandığında, UIView ve CALayer arasında birçok yöntem çağrısı ve bildirim olacaktır, bu nedenle performansı optimize ederken kod açısından optimize ederiz, yani görünüm seviyesini ayarlamaktan, görünüm eklemek ve kaldırmaktan kaçınmaya çalışıyoruz.
TableView kontrol optimizasyonu
Büyük bir Uygulama için, birçok yerin tamamlamak için TableView denetimini kullanması gerekir, bu nedenle hedeflenen TableView optimizasyonu bir kilit noktadır.
Ağ listesi verileri elde edildiğinde, arka plan iş parçacığındaki her bir hücre için gerekli olan verileri hesaplayacağız ve bunları bir yerleşim nesnesi olan CellLayout içinde kapsülleyeceğiz. CellLayout, tüm metnin CoreText mizanpaj sonuçlarını, Hücredeki her kontrolün yüksekliğini, Hücrenin toplam yüksekliğini vb. İçerir. Her CellLayout fazla bellek kaplamaz, bu nedenle üretildiğinde, tümü daha sonra diğer modüller ve yerler tarafından kullanılmak üzere bellekte önbelleğe alınabilir. Bunun avantajı, TableView her yükseklik fonksiyonunu talep ettiğinde herhangi bir ekstra hesaplama tüketmemesidir; CellLayout Hücrenin içine ayarlandığında, Hücre içindeki düzeni hesaplamaya gerek yoktur. Normal TableView için, düzen sonucunu arka planda önceden hesaplamak çok önemli bir performans optimizasyon noktasıdır, çünkü heightForRowAtIndexPath: en sık çağrılan yöntemdir.
TableView için, Cell içeriğinin ekran dışında oluşturulması büyük bir GPU tüketimine neden olacaktır. Geçmişten gelen miras nedeniyle, birçok Katman'ın yuvarlatılmış köşe özelliği kolaylık, hız ve basitlik için kullanıldı. Bu listeyi düşük performanslı bir cihazda (iPad 3 gibi) hızlıca kaydırabilir ve listede büyük bir kart olmasa da bunu hissedebilirsiniz. Duraklat, ancak genel ortalama kare hızı düştü. Enstrümanlar ile görüntülerken, GPU'nun tam kapasitede çalıştığını ancak CPU'nun nispeten boşta olduğunu görebilirsiniz. TableView'in ekran dışı görüntülemesini önlemek için, sonraki optimizasyon sürecinde Layer border, corner, shadow, mask ve diğer teknolojileri kullanmaktan kaçınmaya çalışıyoruz, ancak ilgili içeriği önceden arka planda çizmeye çalışıyoruz, yani talep üzerine asenkron olarak çiziyoruz. Otel ve uçak bileti listesinin performans gereksinimlerini iyileştirmek için karmaşık arayüz gereksinimlerinin performans darboğazıyla karşılaşıldığında asenkron çizim teknolojisi kullanılmaktadır.
Ek olarak, liste kontrolünün birleşik optimizasyonunun bir noktası, kayma sırasında talep üzerine yüklemektir.Bu, talep üzerine çok sayıda resim yüklendiğinde etkilidir.Önceden asenkron yüklemeyi gerçekleştirmek için SDWebImage kullandık. Yukarıdaki optimizasyon noktalarına ek olarak, diğer iyi bilinen optimizasyon noktaları şunlardır:
-
Hücreleri yeniden kullanmak için reuseIdentifier'ı doğru şekilde kullanın;
-
Hücrenin kendisi de dahil olmak üzere tüm görünümü opak yapmaya çalışın;
-
Daha az şeffaf katman kullanmaya veya hiç kullanmamaya çalışın;
-
Hücrede görüntülenen içerik Web'den geliyorsa, istek sonucunu önbelleğe almak için zaman uyumsuz yüklemeyi kullanın;
-
Alt görüntüleme sayısını azaltın;
-
Hücreye dinamik olarak bir Görünüm eklemek için addView'ı olabildiğince az kullanmaya çalışın. Bunu başlangıçta ekleyebilir ve ardından gösterilip gösterilmeyeceğini kontrol etmek için gizle kullanabilirsiniz.
Resim kontrollerinin optimizasyonu
Ctrip App, görüntüleri yüklemek için SDWebImage'ı yeni kullanmaya başladı.O zamanlar az sayıda performans sorunu olacağı ve bazı yerlerin ihtiyaçları karşılayamayacağı profil aracı ile analiz edildi, bu yüzden kendimiz daha yüksek performanslı bir görüntü yükleme kütüphanesi uyguladık. Basit bir tek görüntüyü gösterirken, UIView.layer.contents kullanmak yeterlidir.Ek kaynak tüketimi getirmek için UIImageView kullanmaya gerek yoktur, bu nedenle setImageWithURL gibi yöntemler CALayer'a eklenir. Ek olarak, görüntü kod çözme gibi işlemler, toplam Uygulama iş parçacığı sayısını kontrol eden YYDispatchQueuePool aracılığıyla yönetilir.
Grafik çizim optimizasyonu hakkında
Bir UIButton için bir arka plan resmi ayarladığımızda, arka plan resmini işlemek için birçok seçenek olduğunu herkes bilir.Örneğin, onu doğrudan tam boyutlu bir resimle ayarlayabilir, ayrıca yeniden boyutlandırılabilir resimler kullanabilir veya CALayer, CoreGraphics ve hatta OpenGL kullanarak çizim yapabilirsiniz. Elbette, farklı şemaların farklı kodlama karmaşıklığı ve performansı vardır. Farklı grafik oluşturma şemalarının performansıyla ilgili olarak şunları görebilirsiniz: iOS için Tasarım: Grafik Performansı.
Kısacası, önceden oluşturulmuş resimleri kullanmak daha hızlı olacaktır çünkü programda bir görüntü oluşturup üzerine çeşitli şekiller çizmeye gerek yoktur (Ekran Dışı Rendering). Ancak dezavantajı, bu görüntü kaynaklarını paketin boyutunu artırmaya ihtiyaç duyan bir kod paketinde paketlemeniz gerektiğidir. Bu nedenle, yeniden boyutlandırılabilir görüntüler harika bir seçimdir: tam boyutlu bir görüntüye ihtiyacınız yoktur, iOS'un görüntünün uzatılabilir kısımlarını sizin için çizmesine izin verin, böylece görüntünün boyutunu küçültün ve farklı boyutlar için farklı kontroller hazırlamanıza gerek yok Resmin boyutu. Örneğin, iki düğmenin farklı boyutları vardır, ancak arka plan görüntü stilleri aynıdır Yalnızca karşılık gelen stilin yeniden boyutlandırılabilir bir görüntüsünü hazırlamanız ve ardından iki düğmenin arka plan görüntülerini ayarlarken bunları genişletmeniz gerekir.
Grafik animasyon hakkında
Grafik performansının kullanıcı deneyimi üzerinde doğrudan bir etkisi vardır .. Instruments'daki Temel Animasyon aracı, fiziksel makinedeki grafik performansını ölçmek ve uygulamanın grafik performansını görünümün yenileme hızı ile değerlendirmek için kullanılır. Örneğin, karmaşık bir liste kaydırıldığında, yenileme hızı, kullanıcıları yeterince pürüzsüz hissettirmek için 60 fps'ye yaklaşmaya çalışmalıdır.Bu şekilden, çalışma döngüsünün en uzun yanıt süresinin 16 milisaniye olması gerektiği hesaplanabilir.
Aletlerin Temel Animasyon aracını başlattıktan sonra, Renk Karıştırılmış Katmanlar'ı bulabilirsiniz. Aletler, fiziksel makinede harmanlanmış Katmanlı Katmanı (kırmızı ile işaretlenmiş) görüntüleyebilir. Karıştırılmış Katman, bu Katmanların şeffaf olması ve sistemin işliyor olmasıdır Bu görünümlerde, pikselin gerçek rengi, görünümden sonra hesaplanabilir ve alttaki görünüm harmanlanır.Böyle çok sayıda karıştırılmış katman varsa, aşağıdaki şekilde gösterildiği gibi, kaydırma listesi kesinlikle düzgün olmayacaktır:
Harmanlanmış katman sorununu çözmek de çok basittir.Kırmızı alan görünümünün opak özelliğini kontrol edin ve bunu EVET olarak ayarlamayı unutmayın; backgroundColor özniteliğinin net olup olmadığını kontrol edin.Arka plan rengi net bir renkse, optimizasyonun gerekli olduğunu gösteren grafik performansının düşmanıdır.
Yukarıdaki şekilde sarı ile işaretlenen katman, katmanın yakınlaştırılmış resimleri göstermesidir.Bu resimler ağ üzerinden indirilirse program belirli bir çizim boyutuna güncellenerek çözülebilir. Bazı sistemlerde, Gezinme Çubuğu ve Araç Çubuğunun arka plan resimleri uzatılmış (Uzatılmış) resimlerdir, bunlar da sarı olarak ifade edilir, bu normaldir ve genellikle değiştirilmesi gerekmez. Bu tür bir sorunun genellikle performans üzerinde çok az etkisi vardır, ancak kenarda bulanıklaşabilir.
Makul konuları kullanın
GCD çok kullanışlı olduğundan, onu kontrol etmezseniz, alt iş parçacığına atılması gereken işlemlerin çoğu doğrudan genel kuyruğa eklenir ve bu da iki soruna neden olur:
Giderek daha fazla alt iş parçacığı açılır ve iş parçacığı ek yükü daha belirgin hale gelir. İş parçacığının belirli bir miktarda bellek alanı kaplaması gerektiğinden (varsayılan olarak, ana iş parçacığı 1M, alt iş parçacığı ise 512KB kaplar);
Çoklu okuma durumunda, ağ geri aramalarının zamanlama sorunları, veri işlemenin dağınık olmasına ve bulunmasının zor olmasına neden olur.
Bu amaçla, bazı temel ilkeler belirledik:
UI işlemleri ve DataSource işlemleri ana iş parçacığında olmalıdır;
DB işlemleri, günlük kayıtları ve ağ geri aramalarının tümü kendi sabit iş parçacıkları içindedir;
Farklı işletmeler kuyruklar oluşturarak veri tutarlılığını sağlayabilir. Örneğin, otel listesinin veri yüklenmesi, uçak bileti veri listesinin yüklenmesi vb.
Makul iş parçacığı tahsisi, nihai amaç, ana iş parçacığının, tüm Uygulamanın alt iş parçacığı sayısını makul bir aralıkta kontrol ederken mümkün olduğunca az UI dışı işlemi gerçekleştirmesini sağlamaktır.
Veri yapısının makul kullanımı
Farklı iş senaryolarına göre uygun veri yapısını seçin.Veri miktarı büyük olmadığında görünmeyebilir, ancak depoladığınız veri miktarı büyükse ve veri yapısı daha karmaşıksa, bu sizi etkileyebilir Programın performansı için, daha sık kullanılan veri yapısı dizidir ve arama süresi karmaşıklığı o (n) 'dir. Bir öğeyi hızlı bir şekilde bulmak istiyorsanız, bunun yerine harita veri yapısını kullanmanız önerilir.
Yükleme Görünümlerini yeniden kullanma ve geciktirme
Daha fazla alt görünüm, sistemin daha fazla işleme uygulaması anlamına geliyorsa, bu da sistemin daha fazla CPU ve bellek tüketimi anlamına geliyorsa, bu özellikle UIScrollView'da iç içe çok sayıda görünüme sahip uygulamalar için geçerlidir.
Burada optimizasyon püf noktamız, UITableView ve UICollectionView işlemlerini taklit etmektir: tüm alt görünümleri aynı anda oluşturmanıza gerek yoktur, gerektiğinde bunları oluşturabilirsiniz.Misyonlarını tamamladıklarında, onları yeniden kullanılabilir bir sıraya koyun, yani kendiniz uygulayın. View nesne havuzunu yeniden kullanma teknolojisi ile, görünümlerinizi yalnızca kaydırma gerçekleştiğinde oluşturmanız gerekir, bu da ekonomik olmayan bellek tahsisini önler ve böylece APP bellek tahsisinden tasarruf sağlar. Nesne havuzu yeniden kullanım teknolojisi ve gecikmeli yükleme hakkında, otel odası türü listeleri gibi hizmetlerin bölümlere ayrılmış gecikmeli yüklenmesi gibi APP'nin birçok iş senaryosu için geçerlidir.
sonuç olarak
Android ve iOS platformları, Android stüdyosu ve xcode kendi UI performans analiz araçlarına sahiptir, Android'de HirectView, TraceView ve diğer araçlar vardır, xcode'da Aletler (Çekirdek Animasyon) ve diğer araçlar vardır ve son olarak yukarıdaki çoklu araçları ve işbirliği yapmak için teknik araçları kullanırız, Ctrip Uygulaması Her arayüzün performansı büyük ölçüde iyileştirildi, ortalama kare hızı% 25'ten fazla arttı ve arayüz yükleme süresi% 20'den fazla arttı.
Mobil teknolojinin sürekli olgunlaşması ve gelişmesi ve çeşitli şirketlerin işlerinin olgun ve istikrarlı gelişimi ile, APP performans optimizasyonu, kullanıcı deneyimini iyileştirmek amacıyla büyük şirketlerin önemli bir endişesi haline geldi. Ve performans optimizasyonu, günlük geliştirme çalışmalarımızda devam edebilecek pratik bir sürekli geliştirme konusudur, yani cep telefonu modellerinin artan parçalanması, program işlevlerinin karmaşıklığı ve çeşitliliği ile performans ayarlamasının sonu yoktur. Sürekli optimizasyondan, çok fazla optimizasyon deneyimi biriktirmiş olsak da, Android platformunun bir bölümünde, Ctrip APP'nin alt uç düşük yapılandırmalı modellerdeki performansı hala iyimser değil. Bin millik yolculuk tek bir adımla başlar ve bir karınca yuvasında bin millik toprak dolgusu yok edilir.Binlerce mil uzakta olmak istiyorsanız bir sonraki aşamaya geçmeniz gerekir.Ardından, daha detaylı optimizasyon çözümleri ile kullanıcı deneyimini geliştirmek için çok çalışmaya devam edeceğiz.
Gelecekte, daha önce biriktirdiğimiz geçmiş optimizasyon deneyimine dayanarak, sorun olgusunu gözlemlemekten nedenini analiz etmeye, izleme, niceliksel hedefler belirleme, optimizasyon planları yürütme, sonuç verilerini doğrulamaya ve yeni sorunları gözlemlemeye geri dönmeye kadar kapalı bir performans optimizasyon deneyimi döngüsü oluşturacağız. Her bir kapalı döngü problemin sadece bir kısmını çözebilir.Silikon birikimi olmayan bir adım yoktur. Dere birikimi olmayan nehir yoktur. Sadece ince optimizasyon noktalarını sürekli olarak kavrayarak ve "kemirmeye" devam ederek iyi bir yukarı doğru spiral sonucu elde edebiliriz.
Yazar hakkında: Ctrip'in Ar-Ge müdürü Nan Zhiwen, Uygulamanın genel teknik çerçevesinin mimari geliştirme ve uygulamasından sorumluydu ve şimdi otel işinin yinelemeli güncellemesinden ve Uygulama mimarisi ve performansının optimizasyonundan sorumlu. Alibaba ve Giant Network'te art arda çalıştı.
Mobil geliştirmeyle ilgili en son bilgi ve teknolojiler hakkında bilgi edinmek için lütfen mobilehub genel WeChat hesabını (ID: mobilehub) takip edin.
