Application Performance: Adapting to Latency

En önemli performans konularından biri de uygulamamızın kötü bir network connection’dan iyi olana geçerken ya da tam tersi durumda nasıl davranacağıdır.

Request; cihazımından local bir baz istasyonuna ulaşmak için yapılır ki o da service provider’ın serverına route eder. Sonrasında o da bu provider için local bir data proxy’ye gidebilir. İnternete gitmeden ve ana data serverına erişmeden önce o da response’u decode edip, datayı fetch edecek geri gönderecek. ISP server ve son olarak da cihazımıza. Burada net bir şekilde anlaşılacağı üzere döngüde çok fazla parça var. Ve herhangi birinde, bi yerde bir bottleneck yaşanabilir.

Tüm bu aşamaları kontrol edemediğimiz için, yapılabilecek olan davranış uygulamamızın her bir connectionda nasıl davrandığını kontrol etmektir. Bu da 2 şeyden geçmektedir.

1. Hız ve Network hakkında bilgi almak
2. Uygulamamızı bad latency’de değişikliklere cevap verecek şekilde tasarlamak

Aşağıdaki kod parçasını kullanarak ne tip bir bağlantıda olduğumuzu öğrenebiliriz. Fakat gerçekte bu bize en iyi durum senaryosunu verir.

ConnectivityManager cm =(ConnectivityManager)getBaseContext().getSystemService(Context.CONNECTIVITY_SERVICE);

NetworkInfo activeNetwork = cm.getActiveNetworkInfo();

if(activeNetwork.getType() != ConnectivityManager.TYPE_WIFI){

  String typeName = activeNetwork.getSubtypeName();

  int type = activeNetwork.getSubtype();

  switch (type){

      // TelephonyManager.NETWORK_TYPE *enums

  }

}

Kullanıcı LTE’de bile olsa, data serverla ilgili bir yavaşlık sorunu olabilir. Daha kesin ama daha kompleks olan çözüm ise response’ları almak için geçen süreyi hesaplamaktır.

Mesela listview’deki tüm tumbnailler 128×128 px’se o zaman genel olarak size’o 1K olur diyebiliriz. Bu verinin network’de ne kadar sürede ineceği aslında bellidir. Zaman üzerinde bunların ort. gerçek maaliyetleri hesaplanabilir. Bu bilgiye sahip olduktan sonra, app’i nasıl tasarlayacağımıza karar verebiliriz.

Mesela, ekrandaki gibi 2 treshold, 3 aralık belirlenebiilir. Eğer latency 60 ms’den azsa en düşük treshold’da demektir. Prefetching konusunda daha agresif ama cacheleme için daha az agrasif bir tutum izlenebilir. Eğer bir sonraki tresholddaysa batching&caching konusuna daha çok dikkat etmek gerekir. Ama eğer son tresholddaysa, requestler daha sonra iyi bir bağlantıya geçilmek üzere ertelemek düşünülebilir. Yada ui yapısı değiştirilebilir. Herşey fetch edilmeyebilir.

Bir diğer gerçek de, bu tresholdlar tüm kullanıcılar için çalışmayacaktır.

Bir diğer çözüm, kullanıcı app’i kullanmadan connection teste tabi tutulabilir. Aşağıdaki iki tool’la yüksek latency durumunda app’inizin durumunu izleyebilirsiniz.

• Emulator Throttling
• AT&T’s Network Attenuator

Referans: