Platformlar Arası Performans
Kötü uygulama performansı birçok şekilde kendini gösterir. Bir uygulamanın yanıt vermemeye başlamasına neden olabilir, yavaş kaydırmaya neden olabilir ve pil ömrünü azaltabilir. Ancak performansı iyileştirmek, yalnızca verimli kod uygulamaktan fazlasını içerir. Kullanıcının uygulama performansı deneyimi de dikkate alınmalıdır. Örneğin, işlemlerin kullanıcının diğer etkinlikleri gerçekleştirmesini engellemeden yürütülmesini sağlamak, kullanıcının deneyimini geliştirmeye yardımcı olabilir.
Profil Oluşturucu'ları kullanma
Uygulama geliştirirken, kodu yalnızca profili oluşturulduktan sonra iyileştirmeyi denemeniz önemlidir. Profil oluşturma, kod iyileştirmelerinin performans sorunlarını azaltmada en büyük etkiye sahip olacağı yeri belirlemeye yönelik bir tekniktir. Profil oluşturucu uygulamanın bellek kullanımını izler ve uygulamadaki yöntemlerin çalışma süresini kaydeder. Bu veriler uygulamanın yürütme yollarında ve kodun yürütme maliyetinde gezinmeye yardımcı olur, böylece en iyi duruma getirme fırsatları bulunabilir.
Xamarin Profiler bir uygulamadaki performansla ilgili sorunları ölçer, değerlendirir ve bulmaya yardımcı olur. Xamarin.iOS ve Xamarin.Android uygulamalarının profilini Mac için Visual Studio veya Visual Studio'dan almak için kullanılabilir. Xamarin Profiler hakkında daha fazla bilgi için bkz . Xamarin Profiler'a giriş.
Bir uygulama profili oluşturulurken aşağıdaki en iyi yöntemler önerilir:
- Simülatör uygulama performansını çarpıtabileceği için simülatörde bir uygulamanın profilini oluşturmaktan kaçının.
- İdeal olarak, profil oluşturmanın çeşitli cihazlarda gerçekleştirilmesi gerekir çünkü bir cihazda performans ölçümleri almak her zaman diğer cihazların performans özelliklerini göstermez. Ancak, en azından en düşük tahmin edilen belirtime sahip bir cihazda profil oluşturma gerçekleştirilmelidir.
- Profili oluşturulan uygulamanın diğer uygulamalar yerine tam etkisinin ölçülmesini sağlamak için diğer tüm uygulamaları kapatın.
IDisposable Kaynaklarını Serbest Bırakma
IDisposable
Arabirim, kaynakları serbest bırakmak için bir mekanizma sağlar. Kaynakları açıkça serbest bırakmak için uygulanması gereken bir Dispose
yöntem sağlar. IDisposable
bir yıkıcı değildir ve yalnızca aşağıdaki durumlarda uygulanmalıdır:
- Sınıfı yönetilmeyen kaynaklara sahip olduğunda. Yayımlama gerektiren tipik yönetilmeyen kaynaklar dosyalar, akışlar ve ağ bağlantılarıdır.
- Sınıfı yönetilen kaynaklara
IDisposable
sahip olduğunda.
Tür tüketicileri daha sonra örnek artık gerekli olmadığında serbest kaynaklar için uygulamayı çağırabilir IDisposable.Dispose
. Bunu başarmak için iki yaklaşım vardır:
- Nesneyi bir
using
deyimineIDisposable
sarmalayarak. - Çağrısı
IDisposable.Dispose
birtry
/finally
blok içinde kaydırarak.
Bir using Deyiminde IDisposable Nesnesini Sarmalama
Aşağıdaki kod örneği, deyiminde using
bir IDisposable
nesnenin nasıl sarma yapılacağını gösterir:
public void ReadText (string filename)
{
...
string text;
using (StreamReader reader = new StreamReader (filename)) {
text = reader.ReadToEnd ();
}
...
}
StreamReader
sınıfı uygular IDisposable
ve using
deyimi, kapsamın dışına çıkmadan önce nesnede StreamReader
yöntemini çağıran StreamReader.Dispose
kullanışlı bir söz dizimi sağlar. Bloğun StreamReader
içinde using
nesne salt okunurdur ve yeniden atanamaz. deyimiusing
, derleyici bir blok için ara dili (IL) uyguladığındantry
/finally
, bir özel durum ortaya çıksa bile yönteminin çağrılmasını da sağlar.Dispose
Try/Finally Bloğunda IDisposable.Dispose Çağrısı Sarmalama
Aşağıdaki kod örneğinde çağrısının IDisposable.Dispose
bir try
/finally
blokta nasıl kaydırılır gösterilmektedir:
public void ReadText (string filename)
{
...
string text;
StreamReader reader = null;
try {
reader = new StreamReader (filename);
text = reader.ReadToEnd ();
} finally {
if (reader != null) {
reader.Dispose ();
}
}
...
}
StreamReader
sınıfı uygular IDisposable
ve finally
bloğu kaynağı serbest bırakmak için yöntemini çağırırStreamReader.Dispose
.
Daha fazla bilgi için bkz . IDisposable Arabirimi.
Olaylar aboneliğini kaldırma
Bellek sızıntılarını önlemek için abone nesnesi atılmadan önce olayların aboneliği kaldırılmalıdır. Olayın aboneliği kaldırılana kadar, yayımlama nesnesindeki olayın temsilcisinin abonenin olay işleyicisini kapsülleyen temsilciye bir başvurusu vardır. Yayımlama nesnesi bu başvuruyu barındırdığı sürece, atık toplama abone nesnesi belleğini geri kazanmaz.
Aşağıdaki kod örneği, bir olayın aboneliğini kaldırma işlemini gösterir:
public class Publisher
{
public event EventHandler MyEvent;
public void OnMyEventFires ()
{
if (MyEvent != null) {
MyEvent (this, EventArgs.Empty);
}
}
}
public class Subscriber : IDisposable
{
readonly Publisher publisher;
public Subscriber (Publisher publish)
{
publisher = publish;
publisher.MyEvent += OnMyEventFires;
}
void OnMyEventFires (object sender, EventArgs e)
{
Debug.WriteLine ("The publisher notified the subscriber of an event");
}
public void Dispose ()
{
publisher.MyEvent -= OnMyEventFires;
}
}
sınıfı, Subscriber
yönteminde olay aboneliğini Dispose
kaldırır.
Lambda ifadeleri nesnelere başvurabildiği ve nesneleri canlı tutabildiği için, başvuru döngüleri olay işleyicileri ve lambda söz dizimi kullanılırken de oluşabilir. Bu nedenle, aşağıdaki kod örneğinde gösterildiği gibi anonim yönteme başvuru bir alanda depolanabilir ve olay aboneliğini kaldırmak için kullanılabilir:
public class Subscriber : IDisposable
{
readonly Publisher publisher;
EventHandler handler;
public Subscriber (Publisher publish)
{
publisher = publish;
handler = (sender, e) => {
Debug.WriteLine ("The publisher notified the subscriber of an event");
};
publisher.MyEvent += handler;
}
public void Dispose ()
{
publisher.MyEvent -= handler;
}
}
alanı handler
, anonim yönteme başvuruyu korur ve olay aboneliği ve abonelikten çıkma için kullanılır.
Ölümsüz Nesneleri Önlemek için Zayıf Başvurular Kullanma
Not
iOS geliştiricileri, uygulamalarının belleği verimli bir şekilde kullandığından emin olmak için iOS'ta döngüsel başvurulardan kaçınma belgelerini gözden geçirmelidir.
Nesne Oluşturma Maliyetini Geciktirme
Yavaş başlatma, bir nesnenin oluşturulmasını ilk kullanılana kadar ertelemek için kullanılabilir. Bu teknik öncelikli olarak performansı geliştirmek, hesaplamayı önlemek ve bellek gereksinimlerini azaltmak için kullanılır.
Bu iki senaryoda oluşturulması pahalı olan nesneler için yavaş başlatma kullanmayı göz önünde bulundurun:
- Uygulama nesnesini kullanmayabilir.
- Nesne oluşturulmadan önce diğer pahalı işlemlerin tamamlanması gerekir.
sınıfı Lazy<T>
, aşağıdaki kod örneğinde gösterildiği gibi yavaş başlatılan bir tür tanımlamak için kullanılır:
void ProcessData(bool dataRequired = false)
{
Lazy<double> data = new Lazy<double>(() =>
{
return ParallelEnumerable.Range(0, 1000)
.Select(d => Compute(d))
.Aggregate((x, y) => x + y);
});
if (dataRequired)
{
if (data.Value > 90)
{
...
}
}
}
double Compute(double x)
{
...
}
Gecikmeli başlatma özelliğine ilk kez Lazy<T>.Value
erişildiğinde gerçekleşir. Sarmalanan tür oluşturulur ve ilk erişimde döndürülür ve gelecekteki tüm erişimler için depolanır.
Yavaş başlatma hakkında daha fazla bilgi için bkz . Gecikmeli Başlatma.
Zaman Uyumsuz İşlemler Uygulama
.NET, API'lerinin çoğunun zaman uyumsuz sürümlerini sağlar. Zaman uyumlu API'lerden farklı olarak, zaman uyumsuz API'ler etkin yürütme iş parçacığının çağıran iş parçacığını hiçbir zaman önemli bir süre engellememesini sağlar. Bu nedenle, UI iş parçacığından bir API çağırırken, kullanılabilir durumdaysa zaman uyumsuz API'yi kullanın. Bu, kullanıcı arabirimi iş parçacığının engelini kaldırmasını sağlar ve bu da kullanıcının uygulama deneyimini iyileştirmeye yardımcı olur.
Ayrıca, kullanıcı arabirimi iş parçacığının engellenmesini önlemek için uzun süre çalışan işlemler arka plan iş parçacığında yürütülmelidir. .NET, arka plan iş parçacığında async
uzun süre çalışan işlemleri yürüten ve tamamlandığında sonuçlara erişen zaman uyumsuz kodun yazılabilmesini sağlayan ve await
anahtar sözcüklerini sağlar. Ancak, uzun süre çalışan işlemler anahtar sözcüğüyle await
zaman uyumsuz olarak yürütülebilir, ancak bu işlemin arka plan iş parçacığında çalışacağını garanti etmez. Bunun yerine, bu, aşağıdaki kod örneğinde gösterildiği gibi uzun süre çalışan işlemi öğesine Task.Run
geçirerek gerçekleştirilebilir:
public class FaceDetection
{
...
async void RecognizeFaceButtonClick(object sender, EventArgs e)
{
await Task.Run(() => RecognizeFace ());
...
}
async Task RecognizeFace()
{
...
}
}
RecognizeFace
yöntemi, RecognizeFaceButtonClick
devam etmeden önce yöntemi tamamlanana kadar RecognizeFace
bekleyen bir arka plan iş parçacığında yürütülür.
Uzun süre çalışan işlemler de iptali desteklemelidir. Örneğin, kullanıcı uygulama içinde gezinirse uzun süre çalışan bir işleme devam etmesi gereksiz hale gelebilir. İptal uygulama düzeni aşağıdaki gibidir:
- Örnek
CancellationTokenSource
oluşturma. Bu örnek iptal bildirimlerini yönetir ve gönderir. CancellationTokenSource.Token
Özellik değerini iptal edilebilir olması gereken her göreve geçirin.- her görevin iptale yanıt vermesi için bir mekanizma sağlayın.
CancellationTokenSource.Cancel
İptal bildirimi sağlamak için yöntemini çağırın.
Önemli
CancellationTokenSource
sınıfı arabirimini IDisposable
uygular ve bu nedenle CancellationTokenSource.Dispose
örnek ile tamamlandıktan sonra CancellationTokenSource
yöntemi çağrılmalıdır.
Daha fazla bilgi için bkz . Zaman Uyumsuz Desteğe Genel Bakış.
SGen Çöp Toplayıcısı'nı kullanma
C# gibi yönetilen diller, artık kullanılmayan nesnelere ayrılan belleği geri kazanmak için çöp toplamayı kullanır. Xamarin platformu tarafından kullanılan iki çöp toplayıcı şunlardır:
- SGen : Bu bir nesil çöp toplayıcıdır ve Xamarin platformunda varsayılan çöp toplayıcıdır.
- Boehm – Bu muhafazakar, nesilsel olmayan bir çöp toplayıcıdır. Klasik API'yi kullanan Xamarin.iOS uygulamaları için kullanılan varsayılan çöp toplayıcıdır.
SGen, nesnelere alan ayırmak için üç yığından birini kullanır:
- Kreş – Burası yeni küçük nesnelerin ayrıldığı yerdir. Kreşte yer bittiğinde küçük bir çöp toplama işlemi gerçekleşir. Tüm canlı nesneler ana yığına taşınır.
- Major Heap – Burası uzun süre çalışan nesnelerin tutulduğu yerdir. Ana yığında yeterli bellek yoksa, büyük bir çöp toplama gerçekleşir. Büyük bir çöp toplama işlemi yeterli belleği boşaltmazsa SGen sistemden daha fazla bellek ister.
- Büyük Nesne Alanı – 8000 bayttan fazla gerektiren nesnelerin tutulduğu yerdir. Büyük nesneler kreşte başlamaz, bunun yerine bu yığında ayrılır.
SGen'in avantajlarından biri, küçük bir çöp toplama işlemi gerçekleştirme süresinin, son küçük çöp toplama işleminden bu yana oluşturulan yeni canlı nesne sayısıyla orantılı olmasıdır. Bu küçük çöp toplama işlemleri büyük bir çöp toplamadan daha az zaman alacağı için bu, atık toplamanın bir uygulamanın performansı üzerindeki etkisini azaltır. Büyük çöp toplama işlemleri yine de gerçekleşir, ancak daha az sıklıkta gerçekleşir.
SGen çöp toplayıcısı, Xamarin.iOS 9.2.1 ve üzeri için varsayılan değerdir ve bu nedenle otomatik olarak kullanılır. Atık toplayıcıyı değiştirme özelliğinin Visual Studio'nun daha yeni sürümlerinden kaldırıldığını lütfen unutmayın. Daha fazla bilgi için bkz . Yeni Başvuru Sayma Sistemi.
Çöp Toplayıcı üzerindeki Baskıyı Azaltma
SGen bir çöp toplama başlattığında, bellek geri kazanılırken uygulamanın iş parçacıklarını durdurur. Bellek geri kazanılırken, uygulama kullanıcı arabiriminde kısa bir duraklama veya takılmayla karşılaşabilir. Bu duraklamanın ne kadar algılanabilir olduğu iki faktöre bağlıdır:
- Sıklık – Çöp toplamanın oluşma sıklığı. Koleksiyonlar arasında daha fazla bellek ayrıldığında atık toplama sıklığı artar.
- Süre – Her bir çöp toplama işleminin ne kadar süreceği. Bu, toplanan canlı nesne sayısıyla kabaca orantılıdır.
Toplu olarak bu, birçok nesne ayrılır ancak hayatta kalmazsa, çok sayıda kısa çöp toplaması olacağı anlamına gelir. Buna karşılık, yeni nesneler yavaş ayrılırsa ve nesneler canlı kalırsa, daha az ama daha uzun çöp toplamaları olur.
Çöp toplayıcı üzerindeki baskıyı azaltmak için şu yönergeleri izleyin:
- Nesne havuzlarını kullanarak sıkı döngülerde çöp toplamaktan kaçının. Bu özellikle nesnelerinin çoğunluğunu önceden oluşturması gereken oyunlar için geçerlidir.
- Artık gerekli olmadığında akışlar, ağ bağlantıları, büyük bellek blokları ve dosyalar gibi kaynakları açıkça serbest bırakın. Daha fazla bilgi için bkz . Sürüm IDisposable Resources.
- Nesneleri toplanabilir hale getirmek için artık gerekli olmayan olay işleyicilerinin kaydını kaldırın. Daha fazla bilgi için bkz . Olaylar aboneliğini kaldırma.
Uygulamanın Boyutunu Küçültme
Bir uygulamanın yürütülebilir boyutunun nereden geldiğini anlamak için her platformdaki derleme işlemini anlamak önemlidir:
- iOS uygulamaları ARM derleme diline derlenmiş, önceden (AOT) olarak derlenmiştir. .NET çerçevesi dahil edilir ve kullanılmayan sınıflar yalnızca uygun bağlayıcı seçeneği etkinleştirildiğinde çıkarılır.
- Android uygulamaları ara dile (IL) derlenir ve MonoVM ve tam zamanında (JIT) derleme ile paketlenir. Kullanılmayan çerçeve sınıfları yalnızca uygun bağlayıcı seçeneği etkinse çıkarılır.
- Windows Telefon uygulamaları IL'de derlenir ve yerleşik çalışma zamanı tarafından yürütülür.
Buna ek olarak, bir uygulama genel özellikleri kapsamlı bir şekilde kullanırsa, genel olasılıkların yerel olarak derlenmiş sürümlerini içereceğinden son yürütülebilir boyut daha da artar.
Xamarin platformu, uygulamaların boyutunu azaltmaya yardımcı olmak için derleme araçlarının bir parçası olarak bir bağlayıcı içerir. Bağlayıcı varsayılan olarak devre dışıdır ve uygulamanın proje seçeneklerinde etkinleştirilmelidir. Derleme zamanında, uygulama tarafından gerçekte hangi türlerin ve üyelerin kullanıldığını belirlemek için uygulamanın statik analizini gerçekleştirir. Daha sonra kullanılmayan türleri ve yöntemleri uygulamadan kaldırır.
Aşağıdaki ekran görüntüsünde Xamarin.iOS projesi için Mac için Visual Studio bağlayıcı seçenekleri gösterilmektedir:
Aşağıdaki ekran görüntüsünde, Xamarin.Android projesi için Mac için Visual Studio bağlayıcı seçenekleri gösterilmektedir:
Bağlayıcı, davranışını denetlemek için üç farklı ayar sağlar:
- Bağlama – Bağlayıcı tarafından kullanılmayan türler ve yöntemler kaldırılmaz. Performans nedenleriyle, hata ayıklama derlemeleri için varsayılan ayar budur.
- Yalnızca Bağlantı Çerçevesi SDK'ları/SDK Derlemeleri – Bu ayar yalnızca Xamarin tarafından gönderilen derlemelerin boyutunu küçültür. Kullanıcı kodu etkilenmez.
- Tüm Derlemeleri Bağla – Bu, SDK derlemelerini ve kullanıcı kodunu hedefleyecek daha agresif bir iyileştirmedir. Bağlamalar için bu işlem kullanılmayan yedekleme alanlarını kaldırır ve her örneği (veya ilişkili nesneleri) daha hafif hale getirir ve daha az bellek kullanır.
Tüm Bütünleştirilmiş Kodları Bağla, uygulamayı beklenmeyen yollarla boza kadar dikkatli kullanılmalıdır. Bağlayıcı tarafından gerçekleştirilen statik analiz, gerekli olan tüm kodu doğru şekilde tanımlamayabilir ve bu da derlenen uygulamadan çok fazla kodun kaldırılmasına neden olabilir. Bu durum yalnızca uygulama kilitlendiğinde çalışma zamanında kendini gösterir. Bu nedenle bağlayıcı davranışını değiştirdikten sonra bir uygulamayı kapsamlı bir şekilde test etmek önemlidir.
Test, bağlayıcının bir sınıfı veya yöntemi yanlış kaldırdığını gösterirse, statik olarak başvurulmayan ancak uygulama tarafından gerekli kılınan türleri veya yöntemleri aşağıdaki özniteliklerden birini kullanarak işaretlemek mümkündür:
Xamarin.iOS.Foundation.PreserveAttribute
– Bu öznitelik Xamarin.iOS projelerine yöneliktir.Android.Runtime.PreserveAttribute
– Bu öznitelik Xamarin.Android projeleri içindir.
Örneğin, dinamik olarak örneklenmiş türlerin varsayılan oluşturucularını korumak gerekebilir. Ayrıca, XML serileştirmenin kullanılması, türlerin özelliklerinin korunmasını gerektirebilir.
Daha fazla bilgi için bkz . iOS için Bağlayıcı ve Android için Bağlayıcı.
Ek Boyut Küçültme Teknikleri
Mobil cihazları destekleyen çok çeşitli CPU mimarileri vardır. Bu nedenle, Xamarin.iOS ve Xamarin.Android, her CPU mimarisi için uygulamanın derlenmiş bir sürümünü içeren yağ ikilileri üretir. Bu, cpu mimarisinden bağımsız olarak bir mobil uygulamanın cihazda çalışmasını sağlar.
Uygulamanın yürütülebilir boyutunu daha da küçültmek için aşağıdaki adımlar kullanılabilir:
- Yayın derlemesi üretildiğinden emin olun.
- FAT ikili dosyasının üretilmesinden kaçınmak için uygulamanın oluşturulduğu mimari sayısını azaltın.
- Daha iyileştirilmiş bir yürütülebilir dosya oluşturmak için LLVM derleyicisinin kullanıldığından emin olun.
- Uygulamanın yönetilen kod boyutunu küçültün. Bu, bağlayıcıyı her derlemede etkinleştirerek gerçekleştirilebilir (iOS projeleri için Tümünü Bağla ve Android projeleri için tüm derlemeleri bağla).
Android uygulamaları, her ABI ("mimari") için ayrı bir APK'ya da ayrılabilir. Bu blog gönderisinde daha fazla bilgi edinin: Android Uygulamanızın Boyutunu Küçültme.
Görüntü Kaynaklarını İyileştirme
Görüntüler, uygulamaların kullandığı en pahalı kaynaklardan bazılarıdır ve genellikle yüksek çözünürlüklerde yakalanır. Bu, ayrıntılarla dolu canlı görüntüler oluştururken, bu tür görüntüleri görüntüleyen uygulamalar genellikle görüntünün kodunu çözmek için daha fazla CPU kullanımı ve kodu çözülen görüntüyü depolamak için daha fazla bellek gerektirir. Görüntü için daha küçük bir boyuta ölçeklendirilecek yüksek çözünürlüklü bir görüntünün kodunun bellekte çözülmesi boşa harcanır. Bunun yerine, depolanmış görüntülerin tahmin edilen görüntü boyutlarına yakın birden çok çözünürlük sürümü oluşturarak CPU kullanımını ve bellek ayak izini azaltın. Örneğin, liste görünümünde görüntülenen bir görüntünün büyük olasılıkla tam ekranda görüntülenen görüntüden daha düşük bir çözünürlükte olması gerekir. Buna ek olarak, yüksek çözünürlüklü görüntülerin ölçeği azaltılmış sürümleri en düşük bellek etkisiyle verimli bir şekilde görüntülemek için yüklenebilir. Daha fazla bilgi için bkz . Büyük Bit Eşlemleri Verimli Bir Şekilde Yükleme.
Görüntü çözünürlüğünden bağımsız olarak, görüntü kaynaklarını görüntülemek uygulamanın bellek ayak izini büyük ölçüde artırabilir. Bu nedenle, bunlar yalnızca gerekli olduğunda oluşturulmalı ve uygulama artık bunları gerektirmediği anda serbest bırakılmalıdır.
Uygulama Etkinleştirme Süresini Azaltma
Tüm uygulamaların bir etkinleştirme süresi vardır. Bu süre, uygulamanın ne zaman başlatıldığıyla uygulamanın kullanıma hazır olduğu zaman arasındaki süredir. Bu etkinleştirme dönemi, kullanıcılara uygulamayla ilgili ilk izlenimlerini sağlar ve bu nedenle uygulamayla ilgili olumlu bir ilk izlenim elde edebilmeleri için etkinleştirme süresini ve kullanıcının bu konudaki algısını azaltmak önemlidir.
Bir uygulama ilk kullanıcı arabirimini görüntülemeden önce, kullanıcıya uygulamanın başlatıldığını belirten bir giriş ekranı sağlamalıdır. Uygulama ilk kullanıcı arabirimini hızlı bir şekilde görüntüleyemiyorsa, uygulamanın yanıt vermediğinden emin olmak için, kullanıcıya etkinleştirme dönemi boyunca ilerleme durumunu bildirmek için giriş ekranı kullanılmalıdır. Bu güvence bir ilerleme çubuğu veya benzer bir denetim olabilir.
Etkinleştirme döneminde, uygulamalar genellikle kaynakların yüklenmesini ve işlenmesini içeren etkinleştirme mantığını yürütür. Gerekli kaynakların uzaktan alınmak yerine uygulama içinde paketlenmesini sağlayarak etkinleştirme süresi azaltılabilir. Örneğin, bazı durumlarda etkinleştirme döneminde yerel olarak depolanan yer tutucu verileri yüklemek uygun olabilir. Ardından, ilk kullanıcı arabirimi görüntülendiğinde ve kullanıcı uygulamayla etkileşime geçtikten sonra yer tutucu veriler uzak bir kaynaktan aşamalı olarak değiştirilebilir. Buna ek olarak, uygulamanın etkinleştirme mantığı yalnızca kullanıcının uygulamayı kullanmaya başlamasına izin vermek için gereken işleri gerçekleştirmelidir. Bu, derlemeler ilk kez kullanıldıklarında yüklendiğinden ek derlemelerin yüklenmesini geciktirmesi durumunda yardımcı olabilir.
Web Hizmeti İletişimini Azaltma
Bir uygulamadan web hizmetine Bağlan uygulama performansını etkileyebilir. Örneğin, ağ bant genişliğinin daha fazla kullanılması, cihazın pil kullanımının artmasına neden olur. Ayrıca, kullanıcılar uygulamayı bant genişliği sınırlı bir ortamda kullanıyor olabilir. Bu nedenle, bir uygulama ile web hizmeti arasındaki bant genişliği kullanımını sınırlamak mantıklıdır.
Bir uygulamanın bant genişliği kullanımını azaltmaya yönelik yaklaşımlardan biri, verileri ağ üzerinden aktarmadan önce sıkıştırmaktır. Ancak sıkıştırma işleminden gelen ek CPU kullanımı, pil kullanımının artmasına da neden olabilir. Bu nedenle, sıkıştırılmış verilerin ağ üzerinden taşınıp taşınmayacağına karar vermeden önce bu denge dikkatli bir şekilde değerlendirilmelidir.
Dikkate alınması gereken bir diğer sorun da bir uygulama ile web hizmeti arasında taşınan verilerin biçimidir. İki birincil biçim Genişletilebilir biçimlendirme dili (XML) ve JavaScript Nesne Gösterimi (JSON) biçimindedir. XML, çok sayıda biçimlendirme karakteri içerdiğinden görece büyük veri yükleri üreten metin tabanlı bir veri değişim biçimidir. JSON, veri gönderirken ve alırken bant genişliği gereksinimlerini azaltan, kompakt veri yükleri üreten metin tabanlı bir veri değişim biçimidir. Bu nedenle, JSON genellikle mobil uygulamalar için tercih edilen biçimdir.
Bir uygulama ile web hizmeti arasında veri aktarırken veri aktarım nesnelerinin (DTO) kullanılması önerilir. DTO, ağ üzerinden aktarmak için bir veri kümesi içerir. DTO'lar kullanılarak, tek bir uzaktan aramada daha fazla veri iletilebilir ve bu da uygulama tarafından yapılan uzak çağrıların sayısını azaltmaya yardımcı olabilir. Genellikle, daha büyük bir veri yükü taşıyan uzaktan arama, yalnızca küçük bir veri yükü taşıyan bir çağrıyla benzer bir süre alır.
Web hizmetinden alınan veriler yerel olarak önbelleğe alınmalıdır ve önbelleğe alınan veriler tekrar tekrar web hizmetinden alınmak yerine kullanılır. Ancak, bu yaklaşımı benimserken, web hizmetinde değişirse yerel önbellekteki verileri güncelleştirmek için uygun bir önbelleğe alma stratejisi de uygulanmalıdır.
Özet
Bu makalede, Xamarin platformu kullanılarak oluşturulan uygulamaların performansını artırmaya yönelik teknikler açıklanmış ve ele alınmaktadır. Bu teknikler toplu olarak bir CPU tarafından gerçekleştirilen çalışma miktarını ve bir uygulama tarafından kullanılan bellek miktarını büyük ölçüde azaltabilir.