Meituan Gıda Dağıtım Mobil Performans İzleme Sisteminin Uygulanması
Geliştirme, test etme ve lansman dönemine kadar, işlevsel gereksinimlerin birikmesi, personelin genişlemesi, proje gittikçe daha karmaşık hale geliyor ve yineleme döngüsü kısa, kullanıcılar çeşitli performans sorunlarını algılıyor, ancak mevcut Android Profil Oluşturma / Analiz aracında araç parçalanması var , Otomasyonsuz, dar kapsam ve diğer kusurlar, karşılaştığı sorunları tamamen çözmek imkansızdır.Meituan gıda dağıtım geliştirme ekibi için, gerçek performans verilerini otomatik olarak toplayabilen, insan gücünü serbest bırakabilen ve proaktif olarak önleyebilen böyle entegre bir araca ihtiyacı var. Mobil terminal performans izleme çözümü-Hertz'i geliştirdi.
Önsöz
Performans sorunları, Uygulama kullanıcılarının kaybına neden olan ana suçlulardan biridir. Uygulama performans sorunları arasında çökmeler, ağ isteği hataları veya zaman aşımları, yavaş yanıt hızı, liste kaydırma duraklamaları, büyük trafik, güç tüketimi vb. Yer alır. Cihaz donanımı ve yazılımının harici faktörleri dışında, Uygulamanın düşük performans göstermesinin birçok nedeni vardır. Bunun bir kısmı, geliştiriciler tarafından iş parçacığı, kilitler, sistem işlevleri, programlama paradigmaları ve veri yapılarının yanlış kullanımından kaynaklanıyor. En deneyimli programcılar bile geliştirme sırasında düşük performansa neden olan tüm "çukurlardan" kaçınamazlar.Bu nedenle, performans sorunlarını çözmenin anahtarı, bunların olabildiğince erken bulunup bulunamayacağıdır.
Meituan Waimai, uygulamadaki yaygın performans sorunlarını özetledi ve sektördeki WeChat ve 360 gibi performans izleme teknolojisinin ilkelerini öğrendikten sonra, bir dizi mobil terminal performans izleme çözümü-Hertz (Hertz) geliştirdi. Hertz'in amacı bu üç dönemin problemlerini çözmektir (Şekil 1'de gösterildiği gibi):
-
Geliştirme sırasında, performans anormalliklerini kontrol edin ve geliştiriciyi bilgilendirin;
-
Test süresi boyunca, performans testi raporları oluşturmak için mevcut test araçlarıyla birleştirin;
-
Çevrimiçi dönemde izleme platformu, çevrimiçi sorunları bulmak ve izlemek için performans verilerini raporlar.
Şekil 1 Hertz Design: Yazılım geliştirme yaşam döngüsünde karşılaşılan sorunları çözme
İzleme göstergeleri
Kullanıcıların algılayabileceği performans sorunları çok çeşitli olsa da, bunları yine de belirli izleme göstergelerine ayırabiliriz. Bu izleme göstergeleri şunları içerir: FPS, CPU kullanımı, bellek kullanımı, donmalar, sayfa yükleme süresi, ağ istek trafiği vb. Bunların arasında, FPS, CPU kullanımı, bellek kullanımı vb. Gibi bazı performans göstergelerinin elde edilmesi nispeten kolaydır ve donmalar, sayfa yükleme süresi, ağ istek trafiği vb. Gibi bazı performans göstergelerinin elde edilmesi kolay değildir.
Örneğin, iOS'ta şu şekilde FPS alabiliriz:
- (geçersiz) onay işareti: (CADisplayLink *) bağlantısı
{
NSTimeInterval deltaTime = link.timestamp-self.lastTime;
self.currentFPS = 1 / deltaTime;
self.lastTime = link.timestamp;
}
Android'de bellek kullanımını şu şekilde elde edebiliriz:
halka açık uzun süreli kullanımSize {
Runtime runtime = Runtime.getRuntime;
long totalSize = runtime.maxMemory > > 10;
this.memoryUsage = (runtime.totalMemory-runtime.freeMemory) > > 10;
this.memoryUsageRate = this.memoryUsage * 100 / totalSize;
}
Yukarıdaki örnek, FPS, bellek ve CPU göstergelerinin elde edilmesinin çok basit olduğunu, ancak anlamlı olması için diğer verilerle birleştirilmeleri gerektiğini göstermek içindir.Bu veriler, mevcut sayfa, geçerli Uygulama çalışma süresi veya donma meydana geldiğinde program yürütme yığını hakkında bilgileri içerir. Ve çalışan günlükler. Örneğin: CPU ve geçerli sayfa bilgileri, her sayfanın hesaplama karmaşıklığını değerlendirmek için birleştirilebilir; bellek ve Uygulama çalışma süresi, bellek sızıntısı olup olmadığını analiz etmek için bellek ve kullanım süresi arasındaki ilişkiyi gözlemlemek için birleştirilebilir; FPS ve kekemelik bilgileri, değerlendirmek için birleştirilebilir Bu sefer donma meydana geldiğinde Uygulamanın performansı ne ölçüde düştü?
Durak tespiti
Şu anda, genel mobil cihazların tümü çift arabellek + dikey senkronizasyon görüntüleme teknolojisini benimser. Genel ilke, görüntüleme sisteminin iki arabelleğe sahip olmasıdır. GPU, bir kareyi önceden oluşturacak ve video denetleyicisinin okuması için bir arabelleğe koyacaktır. Sonraki kare oluşturulduğunda, GPU doğrudan video denetleyicisinin işaretçisini ilk kareye yönlendirecektir. İki kap. Burada GPU, yeni bir çerçeve oluşturma ve arabellek güncellemesi gerçekleştirmeden önce ekranın VSync (dikey senkronizasyon) sinyalinin gönderilmesini bekleyecektir.
Çoğu cep telefonunun ekran yenileme hızı 60Hz'dir.Bu çerçevenin görevi 1000/60 = 16.67ms içinde tamamlanmazsa, çerçeve kaybı meydana gelir, kullanıcının donmayı hissetmesinin nedeni budur. Bu çerçevenin çizim görevi, CPU'nun çalışmasını ve GPU'nun çalışmasını içerir.Mpu, görüntü oluşturma, düzen hesaplama, resim kod çözme, metin çizimi vb. Gibi görüntülenen içeriğin hesaplanmasından sorumludur ve ardından CPU hesaplanan içeriği GPU'ya gönderir. GPU dönüştürme, birleştirme ve işleme gerçekleştirir.
UI çizimine ek olarak, sistem olayları, giriş olayları, program geri arama hizmetleri ve eklediğimiz diğer kodlar da ana iş parçacığında yürütülür.Ana iş parçacığına karmaşık kodlar eklendiğinde, bu kodlar ana iş parçacığını engelleyebilir. Tıklamalara, kayan olaylara yanıt vermek ve ana iş parçacığının UI çizim işlemlerini engellemek için bu, gecikmenin en yaygın nedenidir.
Ekran çizimi prensibini ve donma oluşumunun nedenlerini anladıktan sonra, FPS'yi algılayarak uygulamanın donup kalmadığını anlayabileceğinizi ve ayrıca mevcut sayfa çiziminin kalitesini ölçmek için sürekli bir FPS çerçevesinden kare kaybı oranını hesaplayabileceğinizi düşünmek kolaydır. . Ancak pratikte FPS'nin yenileme hızının çok hızlı olduğu ve titremeye meyilli olduğu, bu nedenle donmayı FPS ile doğrudan tespit etmenin daha zor olduğu bulunmuştur. Ana iş parçacığının mesaj döngüsünün yürütme süresini saptamak çok daha kolaydır ve bu, aynı zamanda endüstride sık sık kesintileri algılamak için kullanılan bir yöntemdir. Bu nedenle, Hertz'in pratikte kullandığı şey, ana iş parçacığının mesaj döngüsünün her yürütme zamanını tespit etmektir.Bu süre eşikten daha büyük olduğunda, durma olarak kaydedilir.
Şekil 2 Ana iş parçacığı her yürütüldüğünde mesaj döngüsü mantığının algılanması
Uygulamada, yeni bir sayfa açarken donma gibi bazı donmaların sürekliliğinin uzun sürdüğünü; bazı donmaların nispeten kısa bir süreklilik aldığını ancak liste kayarken kart gibi daha hızlı bir frekansa sahip olduğunu gördük. Duraklat. Bu nedenle, "kekemeliğin N kez T eşiğini aştığı" yargı stratejisini benimsiyoruz, yani bir zaman diliminde toplam kekemelik sayısı N'den büyük olduğunda toplama ve raporlama tetiklenir: Örneğin, kekemelik eşiği T = 2000 ms, kekemelik sayısı N = 1, uzun zaman alan bir donma olarak değerlendirilebilir; donma eşiği T = 300ms ve sıkışma sayısı N = 5 iken, daha hızlı bir donma olarak değerlendirilebilir.
Runnable loopRunnable = new Runnable {
@Override
public void run {
if (mStartedDetecting! isCatched) {
nowLaggyCount ++;
eğer (nowLaggyCount > = N) {
blockHandler.onBlockEvent;
isCatched = true;
...
}
}
}
};
public void onMainLoopFinish {
if (isCatched) {
blockHandler.onBlockFinishEvent (loopStartTime, loopEndTime);
}
resetStatus;
...
}
Kekemelik tespit edildiğinde, kekemeliğe neden olan problem nasıl bulunur? Donma meydana geldiğinde çağrı yığınını yakalayabilir ve programın günlüğünü çalıştırabilirseniz harika olmaz mıydı? Aslında, yığını yakalamak, gecikmeye neden olan "sorun kodunu" bulmamıza çok etkili bir şekilde yardımcı olabilir.
Pratikte, yığını alırken dikkat edilmesi gereken iki konu olduğunu gördük. Birincisi, stall'ın meydana geldiği anda olması gereken yığın yakalamanın zamanlamasıdır, sonra değil, aksi takdirde stall'a neden olan kod doğru bir şekilde yakalanamaz, bu nedenle stall alt thread'de bitmediğinde stall'ı yakalayacağız. Yığını al. İkinci soru, yığının nasıl sınıflandırılacağıdır. Caton yığınının sınıflandırması, Crash yığınınınkinden farklıdır. En içteki kodu sınıflandırmak açıkça uygunsuzdur çünkü dış katmandaki farklı iş mantığı kodları en içteki çağrı yığınında aynı olabilir. En dıştaki kodu sınıflandırmak da uygun değildir, çünkü en dıştaki kod iş mantığı kodu veya sistem çağrıları olabilir. Şu anda, Hertz'in yaklaşımı, en içteki sınıflandırma ilkesini takip etmek ve bazı basit kuralları eşleştirmek ve isabet kuralının sınıf adına göre sınıflandırmaktır.
veri izleme
Mobil kullanıcılar trafiğe karşı çok hassastır Meituan Waimai, zaman zaman kullanıcılardan kısa sürede çok fazla trafik tükettiğini söyleyen şikayetler almaktadır.Bu nedenle, kullanıcının trafik tüketimini uygulamada yerel olarak sayıp arka plana raporlayıp raporlayamayacağımızı düşünüyoruz. Bu istatistiğin her API için doğru olması gerekmez, toplam trafik tüketimini hesaplamak için kabaca sınıflandırılabilir.
Trafik istatistikleri boyutlarımız şunlardır: doğal gün + istek kaynağı + ağ türü. Sunucu tarafı trafik izleme ile neden istemcideki trafiği yerel olarak izlemem gerekiyor? Yerel trafik, Kullanıcı tarafından gönderilen tüm ağ isteklerini sayabilir ve bu sunucu tarafı izlemenin gerçekleştirilmesi zordur. Bir örnek, tüm ağ isteklerinin sunucu izlemesine bildirilmeyeceği; başka bir örnek, ağ nedenlerinden dolayı kullanıcıların yalnızca yukarı bağlantı trafiğini tüketebilmesi, ancak bu isteklerin sunucuya ulaşmamasıdır.
İOS'ta, trafik istatistiklerine ulaşmak için NSURLProtocol'u kaydederiz:
- (void) connectionDidFinishLoading: (NSURLConnection *) bağlantı
{
;
self.data = nil;
if (connection.originalRequest) {
WMNetworkUsageDataInfo * info =;
self.connectionEndTime =;
info.responseSize = self.responseDataLength;
info.requestSize = connection.originalRequest.HTTPBody.length;
info.contentType =;
;
;
}
}
Android'de, trafik istatistiklerine ulaşmak için ağ isteği API'lerine müdahale etmek için Aspectj tabanlı AOP kullanıyoruz:
@Pointcut ("target (java.net.URLConnection)" +
"! içinde (retrofit.appengine.UrlFetchClient)" +
"! (okio.Okio)! içinde (butterknife.internal.ButterKnifeProcessor)" +
"! (com.flurry.sdk.hb) içinde" +
"! (rx.internal.util.unsafe. *) içinde" +
"! (net.sf.cglib .. *) içinde" +
"! içinde (com.huawei.android .. *)" +
"! içinde (com.sankuai.android.nettraffic .. *)" +
"! içinde (roboguice .. *)" +
"! içinde (com.alipay.sdk .. *)")
korumalı void baseCondition {
}
@Pointcut ("çağrı (org.apache.http.HttpResponse org.apache.http.client.HttpClient.execute (org.apache.http.client.methods.HttpUriRequest))"
+ "hedef (org.apache.http.client.HttpClient)"
+ "değiştirgeler (istek)"
+ "! içinde (com.sankuai.android.nettraffic.factory .. *)"
+ "baseClientCondition"
)
void httpClientExecute (HttpUriRequest isteği) {
}
Toplam trafik tüketimi sayıldıktan sonra, konum sorunlarını kolaylaştırmak için trafiği kabaca sınıflandırmayı da umuyoruz. Önem verdiğimiz iki faktör var: Birincisi talebin kaynağı, yani trafik tüketiminin API isteklerinden mi, H5'ten mi yoksa CDN'den mi geldiği; ikincisi ağın türü, yani Wi-Fi, 4G veya 3G trafiğidir. Trafik kaynakları için öncelikle alan adına göre basit bir sınıflandırma yapıyoruz. Örnek olarak iOS'u ele alalım, örnek kod aşağıdaki gibidir:
- (NSString *) regApiHost {
_regApiHost? _regApiHost: @ "^ (. * \.)? (meituan \. com | maoyan \. com | dianping \. com | kuxun \. cn) $";
}
- (NSString *) regResHost {
_regResHost? _regResHost: @ "^ (. * \.)? (meituan \. net | dpfile \. com) $";
}
- (NSString *) regWebHost {
return _regWebHost? _regWebHost: @ "^ (. * \.)? (meituan \. com | maoyan \. com | dianping \. com | kuxun \. cn | meituan \. net | dpfile \ .com) $ ";
}
Ancak, bazı alan adları hem API hizmetlerini hem de Web hizmetlerini dağıtabilir. Bu tür alan adı için, iade edilen paketin MIMEType'ını doğrulayarak daha fazla ayrım yaparız. Örnek olarak iOS'u ele alalım, örnek kod aşağıdaki gibidir:
+ (BOOL) isPermissiveWebURL: (NSURL *) URL ve MIMEType: (NSString *) MIMEType
{
NSRegularExpression * permissiveHost =;
NSString * host = URL.host;
dönüş (|| || ||) (ana bilgisayar);
}
Sayfa hızı
Sayfa yükleme süresini ölçmek için iki sorunu çözmemiz gerekiyor. Birincisi, bir sayfanın yükleme süresinin nasıl ölçüleceği; ikincisi, olabildiğince az kod yazmadan veya yazmadan hız ölçümünün nasıl gerçekleştirileceği. Önce ilk soruya bakalım. Örnek olarak Android'i alın. Aktivitenin oluşturulması ve yüklenmesi sırasında, sayfa temasının ayarlanması, sayfa düzeninin başlatılması, resimlerin yüklenmesi, ağ verilerinin elde edilmesi veya veri tabanlarının okunması ve yazılması gibi birçok işlem gerçekleştirilir. Yukarıdaki işlemlerin herhangi birindeki performans sorunları, ekranın zamanında görüntülenmemesine neden olabilir ve kullanıcı deneyimini etkileyebilir. Hertz, bu olası işlemleri Şekil 3'te gösterilen hız ölçüm modelinde özetlemektedir.
Şekil 3 Hız ölçüm modeli
Bunlar arasında T1, sayfanın başlatıldığı andan ilk UI öğesinin görüntüsüne kadar geçen süreyi ifade eder Bu UI öğesi genellikle veri yüklendiğinde bekleyen animasyona atıfta bulunur. T2, ağ talebi zamanını ifade eder ve başlangıç noktası T1'in bitiş noktasından önce olabilir. T3, kullanıcı arayüzünü verilerle doldurma ve verileri yükledikten sonra yeniden oluşturma zamanıdır. T, tüm sayfanın başlatılmasından son UI çiziminin tamamlanmasına kadar geçen süredir.
İkinci soru için, noktaları her bir zaman noktasında gömmek için manuel olarak kod yazmanız gerekiyorsa, bu çok verimsizdir ve hataya açıktır. Bu nedenle Hertz, bir yapılandırma dosyası aracılığıyla her sayfaya karşılık gelen API'yi yapılandırır ve API isteklerinin temel sınıfındaki noktaları birleştirir. Elbette, bu çözümde, kancaların anahtar düğümlerindeki API çağrılarına gömülü kodun enjekte edilmesi gibi optimizasyon için yer vardır.
Ek olarak, başka bir soru, kullanıcı arayüzü oluşturmanın tamamlandığının nasıl belirleneceğidir? Android'de Hertz'in yaklaşımı, Activity'in rootView'ına bir FrameLayout eklemek ve bu FrameLayout'un dispatchDraw yöntemini çağırıp çağırmadığını izlemektir. Elbette, bu çözümün dezavantajı, birinci düzey Görünümün eklenmesinin daha derin yuvalama ile sonuçlanmasıdır.
@Override
korumalı void dispatchDraw (Canvas canvas) {
super.dispatchDraw (tuval);
if (! mIsComplete) {
mIsComplete = mCallback.onDrawEnd (this, mKey);
}
}
İOS'ta farklı bir yaklaşım benimsedik. Hertz, yapılandırma dosyasında son işleme sayfasının bir öğesinin etiketini belirtir ve ağ isteği başarılı olduktan sonra öğenin kök düğümün altında görünüp görünmediğini kontrol etmek için CADisplayLink'i açar.
- (geçersiz) onay işareti: (CADisplayLink *) bağlantısı
{
;
}
Tasarım paradigması
Tasarımın başlangıcında, SDK'nın ölçeklenebilirliği ve kullanım kolaylığı göz önünde bulundurularak birçok düşüncede bulunduk. SDK çerçevesi, bir bütün olarak üç katmana bölünmüş olan Şekil 4'te gösterilmektedir: en üst katman, ortam ve yapılandırma parametrelerinin yanı sıra çok az miktarda harici maruz kalma yöntemi sağlayan arayüz katmanıdır. İkinci katman, sayfa hızı ölçümü, donma algılaması ve parametre toplamanın tüm temel mantığını içeren iş katmanıdır. Üçüncü katman, iş katmanı tarafından üretilen verileri birleşik bir veri yapısında kapsülleyen ve bir adaptör aracılığıyla farklı çıktı kanallarına uyarlayan veri uyarlama katmanıdır.
Şekil 4 SDK mimari tasarımı
İlk düşüncemiz arayüzün kullanım kolaylığıdır Hertz, geliştirme, test etme ve çevrimiçi olmak üzere yerleşik üç çalışma moduna sahiptir. Geliştiricilerin yalnızca bir mod belirlemesi ve çalışmaya başlaması gerekir. Örnekleme frekansı, donma eşiği, raporlama kanalı anahtarı vb. Gibi SDK işlemi için gerekli parametreleri önceden ayarlayan çeşitli modlar ve indeks toplama, donma algılama, sayfa hızı ölçümü vb. Gibi mantık dahili olarak otomatik olarak yürütülür. Örnek olarak Android'i alın, örnek kod aşağıdaki gibidir:
final HertzConfiguration konfigürasyonu = new HertzConfiguration.Builder (bu)
.mode (HertzMode.HERTZ_MODE_DEBUG)
.appId (APP_ID)
.unionId (UNION_ID)
.inşa etmek;
Hertz.getInstance.init (yapılandırma);
İkincisi, SDK'nın ölçeklenebilirliğidir. Veri uyarlama katmanını örnek olarak ele alalım: Toplanan izleme verilerini farklı veri kanallarına uyarlayabilen şu anda beş yerleşik uyarlama kanalı bulunmaktadır. Seçilen çalışma moduna bağlı olarak veriler, test raporları oluşturmak için sunucu izleme kanalına uyarlanacak veya Uygulamada yalnızca günlük ve istemler yerel olarak çıkacaktır. Bu tasarımın bir avantajı, yeni bir veri çıkış kanalı eklemeniz gerekiyorsa, üst katmana bir durdurucu ekleyebilmeniz veya yalnızca küçük bir SDK kodunu değiştirerek bir bağdaştırıcı ekleyebilmenizdir. Benzer şekilde, performans elde etme modülünün tasarımı ve sayfa hızı ölçüm modülü de bu fikri takip eder.
Gerçek kullanım durumu
Hertz'e eriştikten sonra, Meituan Waimai başlangıçta performans sorunlarını keşfetme ve bulma yeteneğine sahiptir.Geliştirme, test ve çevrimiçi olmak üzere üç aşamadaki verilerle doğrulanmıştır ve ardından bunları ayrıntılı olarak paylaşacağız.
Geliştirme sırasında uygulama
Geliştirme döneminde Hertz'e erişim, çevrimdışı bir performans algılama aracını entegre etmeye eşdeğerdir.Bir anormallik algılandığında, verileri Şekil 5'te gösterildiği gibi doğrudan geliştiriciye geri besleyebilir.
Şekil 5 Örnek
Çalışma zamanında toplanan veriler günlüğe gönderilir ve geçerli FPS, CPU ve bellek gibi temel bilgileri görüntülemek için Uygulama sayfasına kayan bir katman eklenir. Bir durak tespit edilirse, bir komut istemi sayfası açılır ve mevcut yürütme yığınını listeler. Şu anda, donma tespitinin sonuçlarına göre, yığın günlüklerinin çoğu sorunlu kodu açıkça bulabilir.Koda baktığınız ve nedenini analiz ettiğiniz sürece, bu sorunlar kolayca optimize edilebilir.
Aşağıda, karmaşık UI başlatmanın neden olduğu bir duraklama örneği verilmiştir:
android.content.res.StringBlock.nativeGetString (Yerel Yöntem)
android.content.res.StringBlock.get (StringBlock.java:82)
android.content.res.XmlBlock $ Parser.getName (XmlBlock.java:175)
android.view.LayoutInflater.inflate (LayoutInflater.java:470)
android.view.LayoutInflater.inflate (LayoutInflater.java:420)
android.view.LayoutInflater.inflate (LayoutInflater.java:371)
com.sankuai.meituan.takeoutnew.controller.ui.PoiListAdapterController.getView (PoiListAdapterController.java:77)
com.sankuai.meituan.takeoutnew.adapter.PoiListAdapter.getView (PoiListAdapter.java:26)
android.widget.HeaderViewListAdapter.getView (HeaderViewListAdapter.java:220)
Aşağıda, bir dizeyi tersine ayrıştırmak için Gson kullanırken kekemeliğe bir örnek verilmiştir:
com.google.gson.Gson.toJson (Gson.java:519)
com.meituan.android.common.locate.util.GoogleJsonWrapper $ MyGson.toJson (GoogleJsonWrapper.java:236)
com.sankuai.meituan.location.collector.CollectorJson $ MyGson.toJson (CollectorJson.java:216)
com.sankuai.meituan.location.collector.CollectorFilter.saveCurrentData (CollectorFilter.java:67)
com.sankuai.meituan.location.collector.CollectorFilter.init (CollectorFilter.java:33)
com.sankuai.meituan.location.collector.CollectorFilter. < içinde > (CollectorFilter.java:27)
com.sankuai.meituan.location.collector.CollectorMsgHandler.recordGps (CollectorMsgHandler.java:134)
com.sankuai.meituan.location.collector.CollectorMsgHandler.getNewLocation (CollectorMsgHandler.java:81)
com.meituan.android.common.locate.LocatorMsgHandler $ 1.handleMessage (LocatorMsgHandler.java:29)
Aşağıda, ana iş parçacığının veritabanını okuyup yazmasının neden olduğu bir gecikme örneği verilmiştir:
android.database.sqlite.SQLiteConnection.executeForLastInsertedRowId (SQLiteConnection.java:782)
android.database.sqlite.SQLiteSession.executeForLastInsertedRowId (SQLiteSession.java:788)
android.database.sqlite.SQLiteStatement.executeInsert (SQLiteStatement.java:86)
de.greenrobot.dao.Abstractolated.executeInsert (Abstract Dao.java:306)
de.greenrobot.dao.Abstractolated.insert (Özet Dao.java:276)
com.sankuai.meituan.takeoutnew.db.dao.BaseAbstractYO.insert (BaseAbstract Dao.java:25)
com.sankuai.meituan.takeoutnew.log.LogDataUtil.insertIntoDb (LogDataUtil.java:243)
com.sankuai.meituan.takeoutnew.log.LogDataUtil.saveLogInfo (LogDataUtil.java:221)
com.sankuai.meituan.takeoutnew.log.LogDataUtil.saveLog (LogDataUtil.java:116)
com.sankuai.meituan.takeoutnew.log.LogDataUtil.saveLogInfo (LogDataUtil.java:112)
com.sankuai.meituan.takeoutnew.ui.page.main.order.OrderListFragment.onPageShown (OrderListFragment.java:306)
com.sankuai.meituan.takeoutnew.ui.page.main.order.OrderListFragment.init (OrderListFragment.java:151)
com.sankuai.meituan.takeoutnew.ui.page.main.order.OrderListFragment.onCreateView (OrderListFragment.java:81)
Bildirilen belirli sorunlara bakıldığında, günlüklerin çoğu sorunlu kodu açıkça bulabilir.Koda biraz bakıp nedenini analiz ettiğiniz sürece, bu sorunlar kolayca optimize edilebilir.
Test dönemi uygulaması
Geleneksel performans testleri çoğunlukla üçüncü taraf araçlara dayanır ve üretilen veriler, geliştirme tarafından ölçülen verilerden oldukça farklıdır.Ayrıca, bu testler genellikle yalnızca bazı gösterge verileri verir ve geliştiricilerin sorunu bulmalarına yardımcı olamaz. Test aşamasında performans verilerini toplamak için Hertz kullanıyoruz Test yöntemi manuel test, otomatik test veya Maymun testi olabilir. Performans verileri elde edildikten sonra, Şekil 6'da gösterildiği gibi komut dosyası işlendikten sonra basit bir test raporu verilecektir.
Şekil 6 Performans testi raporu
Elbette, bu test raporunun hala manuel olarak günlükleri dışa aktarması ve komut dosyalarını çalıştırması gerekiyor.Gelecekte, bu temelde bir dizi otomatik test aracı geliştireceğiz.
Operasyon ve bakım süresi uygulaması
Gecikme tespiti için, geliştirme ve test dönemlerinde hemen geliştiricilere geri bildirim sorunlarına ek olarak, veriler gri tonlamalı veya çevrimiçi çalışma sırasında da sunucuya yüklenecektir.Geçerli raporlama kanalı şirketin dahili CAT'idir. Yığının sınıflandırılması ve gösteriminin bilindik Crash izleme ile çok benzer olduğu görülebilir.Yukarıda bahsedilen sınıflandırma prensibine göre Caton yığını, oluşum sayısına göre düzenlenir ve versiyona, işletim sistemine ve cihaza göre filtrelenebilir. Geliştiricinin kullanım alışkanlıkları (Şekil 7'de gösterildiği gibi).
Şekil 7 Sıkışma algılama verilerinin düzenlenmesi
Trafik istatistikleri için, her gün sunucudaki tüm ağ kullanıcılarının trafik tüketim verilerini raporlayacağız ve tüm ağ trafiği tüketiminin ilk 100 kullanıcısını listeleyen bir rapor çıkaracağız. Bir anormallik bulunursa, hangi ağ talebinin anormal trafiğe neden olduğunu arka uç günlüğüne ve istemci tanılama günlüğüne göre daha fazla araştırabilirsiniz (bkz. Şekil 8).
Şekil 8 Trafik istatistikleri
Sayfa hızı ölçüm verileri ve FPS, CPU ve bellek gibi temel göstergeler için veriler ayrıca Uygulamanın genel performansını değerlendirmek için CAT'e rapor edilecektir (Şekil 9'da gösterildiği gibi).
Şekil 9 CAT izleme istatistikleri
sonuç olarak
Performans optimizasyonu, her olgun Uygulamanın ciddiye alması gereken bir konudur ve performans optimizasyonunun acı noktası genellikle sorunun zamanında bulunamaması veya problem bulunduğunda bulunamamasıdır. Meituan Waimai, performans optimizasyonunu yönlendirmek için izleme verilerini kullanır.Uygulamada, Uygulama performans izleme programı Hertz'i geliştirdi ve iyileştirdi ve izleme göstergeleri, takılma tespiti, trafik izleme ve sayfa hızı ölçümünde bazı keşif ve doğrulama çalışmaları yaptı.
Şu anda, Hertz'in izleme göstergeleri arasında FPS, CPU kullanımı, bellek kullanımı, donmalar, sayfa yükleme süresi, ağ istek trafiği vb. Yer alıyor ve güç tüketiminin izlenmesi, Uygulama soğuk başlatma ve İstisna, gelecekte izleme hedefine kademeli olarak eklenecek. . Performans izleme göstergeleri gelecekte birden fazla mevcut aracı yeniden kullanabilir ve bu temelde kademeli olarak gelişebilir.
Hertz'in kekemelik tespiti ve yığın yakalaması, geliştiricilerin performans sorunlarını bulmalarına çok etkili bir şekilde yardımcı olabilir, ancak mevcut kekemelik algılama stratejisi, optimizasyon için hala çok yer var. Örneğin, cihaza göre farklı eşikler ayarlanabilir ve uygulamanın çalışmasının farklı dönemlerinde farklı stratejiler ayarlanabilir. Yığının sınıflandırılmasına gelince, mevcut kurallar basitçe sınıf adının ön ekiyle eşleşmelidir.Daha doğru ve mantıklı bir şekilde nasıl sınıflandırılacağı da gelecekte daha fazla düşünmemiz gereken bir sorundur. Elbette, bu optimizasyonların desteklenmesi için daha fazla veri örneğine ihtiyaç vardır.
Gerçek zamanlı olarak görüntülenebilen ve aynı zamanda geçmiş raporlar aracılığıyla göz atılabilen bir Web sayfası gibi görsel ve kullanıcı dostu bir performans test aracı oluşturmak da çok önemlidir. Aynı zamanda Hertz, tasarımda otomatik test yöntemleriyle kolayca birleştirilebilir veya entegrasyon aşamasında otomatik olarak test raporları oluşturabilir, ancak bu konuda sadece bazı ön girişimlerde bulunduk. Performans verilerini doğru bir şekilde toplama yeteneğine sahip olduktan sonra, bunları test bağlantısı da dahil olmak üzere tüm geliştirme sürecine nasıl daha iyi uygulayacağımız hala uzun vadeli keşif ve pratik gerektirir.
Bu makale temel olarak Meituan Takeaway tarafından Hertz uygulamasında özetlenen bazı fikirleri ve uygulama yöntemlerini tanıtmaktadır ve Uygulama performansı izleme konusunda ele alınmayan birçok ilginç ve derinlemesine konu bulunmaktadır. Örneğin, performans izleme araçlarının ve araçların neden olduğu performans sorunları, performans optimizasyonu için belirli teknikler ve yöntemler ve anormal ekipman için bir izleme sistemi kurmak için performans verilerinin derinlemesine analizi, vb. Gelecekte, bu konularda daha fazla keşif, uygulama ve paylaşım da yapacağız.
Referans malzemeleri:
-
AndroidPerformanceMonitor;
-
Leakcanary;
-
Bekçi köpeği;
-
iOS Sistem Hizmetleri;
-
WeChat iOS Caton İzleme Sistemi.
Yazar hakkında: Meituan Dianping'de kıdemli Android Ar-Ge mühendisi olan Dong Shichao, Helsinki Teknoloji Üniversitesi'nden mezun oldu, 2014 yılında Meituan paket servisi olan müşteri Ar-Ge ekibine katıldı ve Meituan paket servisi olan Android istemcisinin iş gereksinimlerinin geliştirilmesinden sorumluydu, 22 yineleme ve pakete katıldı Müşterinin iş verileri, teknik veriler vb. Dahil iş destek çalışması. Bu makale orijinal bir CSDN makalesidir. Lütfen izinsiz yeniden yazdırmayın. Yeniden yazdırmanız veya bir makaleyi göndermeniz, bir makale göndermeniz veya makaleyi düzeltmeniz gerekiyorsa, lütfen mobile@csdn.net adresine e-posta gönderin.
Mobil geliştirmeyle ilgili en son bilgiler ve teknolojiler için lütfen mobilehub genel WeChat hesabını (ID: mobilehub) takip edin.
