Bagikan melalui

Performa Lintas Platform

  • Artikel

Performa aplikasi yang buruk menyajikan dirinya dalam banyak hal. Ini dapat membuat aplikasi tampak tidak responsif, dapat menyebabkan pengguliran lambat, dan dapat mengurangi masa pakai baterai. Namun, mengoptimalkan performa melibatkan lebih dari sekadar menerapkan kode yang efisien. Pengalaman pengguna tentang performa aplikasi juga harus dipertimbangkan. Misalnya, memastikan bahwa operasi dijalankan tanpa memblokir pengguna untuk melakukan aktivitas lain dapat membantu meningkatkan pengalaman pengguna.

Menggunakan Profiler

Saat mengembangkan aplikasi, penting untuk hanya mencoba mengoptimalkan kode setelah dibuat profilnya. Pembuatan profil adalah teknik untuk menentukan di mana pengoptimalan kode akan memiliki efek terbesar dalam mengurangi masalah performa. Profiler melacak penggunaan memori aplikasi, dan merekam waktu berjalan metode dalam aplikasi. Data ini membantu menavigasi melalui jalur eksekusi aplikasi, dan biaya eksekusi kode, sehingga peluang terbaik untuk pengoptimalan dapat ditemukan.

Xamarin Profiler akan mengukur, mengevaluasi, dan membantu menemukan masalah terkait performa dalam aplikasi. Ini dapat digunakan untuk membuat profil aplikasi Xamarin.iOS dan Xamarin.Android dari dalam Visual Studio untuk Mac atau Visual Studio. Untuk informasi selengkapnya tentang Xamarin Profiler, lihat Pengantar Xamarin Profiler.

Praktik terbaik berikut direkomendasikan saat membuat profil aplikasi:

  • Hindari membuat profil aplikasi dalam simulator, karena simulator dapat mendistorsi performa aplikasi.
  • Idealnya, pembuatan profil harus dilakukan pada berbagai perangkat, karena mengambil pengukuran performa pada satu perangkat tidak akan selalu menunjukkan karakteristik performa perangkat lain. Namun, minimal, pembuatan profil harus dilakukan pada perangkat yang memiliki spesifikasi terendah yang diantisipasi.
  • Tutup semua aplikasi lain untuk memastikan bahwa dampak penuh dari aplikasi yang sedang difilter sedang diukur, bukan aplikasi lain.

Rilis Sumber Daya IDisposable

Antarmuka IDisposable menyediakan mekanisme untuk merilis sumber daya. Ini menyediakan Dispose metode yang harus diimplementasikan untuk secara eksplisit merilis sumber daya. IDisposable bukan destruktor, dan hanya boleh diimplementasikan dalam keadaan berikut:

  • Ketika kelas memiliki sumber daya yang tidak dikelola. Sumber daya umum yang tidak terkelola yang memerlukan penghapusan mencakup file, aliran, dan koneksi jaringan.
  • Saat kelas memiliki sumber daya terkelola IDisposable .

Konsumen jenis kemudian dapat memanggil IDisposable.Dispose implementasi ke sumber daya gratis ketika instans tidak lagi diperlukan. Ada dua pendekatan untuk mencapai hal ini:

  • Dengan membungkus IDisposable objek dalam pernyataan using .
  • Dengan membungkus panggilan ke IDisposable.Dispose dalam try/finally blok.

Membungkus Objek IDisposable dalam menggunakan Pernyataan

Contoh kode berikut menunjukkan cara membungkus IDisposable objek dalam using pernyataan:

public void ReadText (string filename)
{
  ...
  string text;
  using (StreamReader reader = new StreamReader (filename)) {
    text = reader.ReadToEnd ();
  }
  ...
}

Kelas StreamReader mengimplementasikan IDisposable, dan using pernyataan menyediakan sintaks yang nyaman yang memanggil StreamReader.Dispose metode pada StreamReader objek sebelum keluar dari cakupan. using Dalam blok, StreamReader objek bersifat baca-saja dan tidak dapat ditetapkan ulang. Pernyataan ini using juga memastikan bahwa Dispose metode dipanggil bahkan jika terjadi pengecualian, karena kompilator mengimplementasikan bahasa perantara (IL) untuk blok/tryfinally.

Membungkus Panggilan ke IDisposable.Dispose dalam Blok Coba/Akhirnya

Contoh kode berikut menunjukkan cara membungkus panggilan ke IDisposable.Dispose dalam try/finally blok:

public void ReadText (string filename)
{
  ...
  string text;
  StreamReader reader = null;
  try {
    reader = new StreamReader (filename);
    text = reader.ReadToEnd ();
  } finally {
    if (reader != null) {
      reader.Dispose ();
    }
  }
  ...
}

Kelas StreamReader mengimplementasikan IDisposable, dan finally blok memanggil metode untuk merilis StreamReader.Dispose sumber daya.

Untuk informasi selengkapnya, lihat Antarmuka IDisposable.

Berhenti berlangganan dari Peristiwa

Untuk mencegah kebocoran memori, peristiwa harus berhenti berlangganan sebelum objek pelanggan dibuang. Hingga peristiwa berhenti berlangganan, delegasi untuk peristiwa di objek penerbitan memiliki referensi ke delegasi yang merangkum penanganan aktivitas pelanggan. Selama objek penerbitan memegang referensi ini, pengumpulan sampah tidak akan mengklaim kembali memori objek pelanggan.

Contoh kode berikut menunjukkan cara berhenti berlangganan dari peristiwa:

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;
  }
}

Kelas Subscriber berhenti berlangganan dari peristiwa dalam metodenya Dispose .

Siklus referensi juga dapat terjadi saat menggunakan penanganan aktivitas dan sintaks lambda, karena ekspresi lambda dapat mereferensikan dan menjaga objek tetap hidup. Oleh karena itu, referensi ke metode anonim dapat disimpan di bidang dan digunakan untuk berhenti berlangganan dari peristiwa, seperti yang ditunjukkan dalam contoh kode berikut:

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;
  }
}

Bidang handler mempertahankan referensi ke metode anonim, dan digunakan untuk langganan peristiwa dan berhenti berlangganan.

Gunakan Referensi Lemah untuk Mencegah Objek Abadi

Catatan

Pengembang iOS harus meninjau dokumentasi tentang menghindari referensi melingkar di iOS untuk memastikan aplikasi mereka menggunakan memori secara efisien.

Tunda Biaya Pembuatan Objek

Inisialisasi malas dapat digunakan untuk menunda pembuatan objek sampai pertama kali digunakan. Teknik ini terutama digunakan untuk meningkatkan performa, menghindari komputasi, dan mengurangi persyaratan memori.

Pertimbangkan untuk menggunakan inisialisasi malas untuk objek yang mahal untuk dibuat dalam dua skenario ini:

  • Aplikasi mungkin tidak menggunakan objek .
  • Operasi mahal lainnya harus diselesaikan sebelum objek dibuat.

Kelas Lazy<T> ini digunakan untuk menentukan jenis yang diinisialisasi malas, seperti yang ditunjukkan dalam contoh kode berikut:

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)
{
  ...
}

Inisialisasi malas terjadi saat pertama kali Lazy<T>.Value properti diakses. Jenis yang dibungkus dibuat dan dikembalikan pada akses pertama, dan disimpan untuk akses di masa mendatang.

Untuk informasi selengkapnya tentang inisialisasi malas, lihat Inisialisasi Malas.

Menerapkan Operasi Asinkron

.NET menyediakan versi asinkron dari banyak API-nya. Tidak seperti API sinkron, API asinkron memastikan bahwa utas eksekusi aktif tidak pernah memblokir utas panggilan untuk waktu yang signifikan. Oleh karena itu, saat memanggil API dari utas UI, gunakan API asinkron jika tersedia. Ini akan membuat utas UI tidak diblokir, yang akan membantu meningkatkan pengalaman pengguna dengan aplikasi.

Selain itu, operasi jangka panjang harus dijalankan pada utas latar belakang, untuk menghindari pemblokiran utas UI. .NET menyediakan async kata kunci dan await yang memungkinkan penulisan kode asinkron yang menjalankan operasi jangka panjang pada utas latar belakang, dan mengakses hasilnya pada penyelesaian. Namun, sementara operasi jangka panjang dapat dijalankan secara asinkron dengan await kata kunci, ini tidak menjamin bahwa operasi akan berjalan pada utas latar belakang. Sebagai gantinya, ini dapat dicapai dengan meneruskan operasi jangka panjang ke Task.Run, seperti yang ditunjukkan dalam contoh kode berikut:

public class FaceDetection
{
  ...
  async void RecognizeFaceButtonClick(object sender, EventArgs e)
  {
    await Task.Run(() => RecognizeFace ());
    ...
  }

  async Task RecognizeFace()
  {
    ...
  }
}

Metode ini RecognizeFace dijalankan pada utas latar belakang, dengan RecognizeFaceButtonClick metode menunggu hingga RecognizeFace metode selesai sebelum melanjutkan.

Operasi yang berjalan lama juga harus mendukung pembatalan. Misalnya, melanjutkan operasi jangka panjang mungkin menjadi tidak perlu jika pengguna menavigasi dalam aplikasi. Pola untuk menerapkan pembatalan adalah sebagai berikut:

  • Buat CancellationTokenSource instans. Instans ini akan mengelola dan mengirim pemberitahuan pembatalan.
  • Teruskan CancellationTokenSource.Token nilai properti ke setiap tugas yang harus dapat dibatalkan.
  • Berikan mekanisme untuk setiap tugas untuk menanggapi pembatalan.
  • CancellationTokenSource.Cancel Panggil metode untuk memberikan pemberitahuan pembatalan.

Penting

Kelas CancellationTokenSource mengimplementasikan IDisposable antarmuka, sehingga CancellationTokenSource.Dispose metode harus dipanggil setelah CancellationTokenSource instans selesai.

Untuk informasi selengkapnya, lihat Gambaran Umum Dukungan Asinkron.

Menggunakan Pengumpul Sampah SGen

Bahasa terkelola seperti C# menggunakan pengumpulan sampah untuk mengklaim kembali memori yang dialokasikan untuk objek yang tidak lagi digunakan. Dua pengumpul sampah yang digunakan oleh platform Xamarin adalah:

  • SGen – Ini adalah pengumpul sampah generasi dan merupakan pengumpul sampah default di platform Xamarin.
  • Boehm - Ini adalah pengumpul sampah non-generasi yang konservatif. Ini adalah pengumpul sampah default yang digunakan untuk aplikasi Xamarin.iOS yang menggunakan API Klasik.

SGen menggunakan salah satu dari tiga timbunan untuk mengalokasikan ruang untuk objek:

  • Pembibitan – Di sinilah objek kecil baru dialokasikan. Ketika pembibitan kehabisan ruang, pengumpulan sampah kecil akan terjadi. Setiap objek langsung akan dipindahkan ke tumpukan utama.
  • Mayor Heap – Di sinilah objek jangka panjang disimpan. Jika tidak ada cukup memori dalam tumpukan utama, maka pengumpulan sampah utama akan terjadi. Jika pengumpulan sampah utama gagal membebaskan memori yang cukup maka SGen akan meminta lebih banyak memori kepada sistem.
  • Ruang Objek Besar - Di sinilah objek yang memerlukan lebih dari 8000 byte disimpan. Objek besar tidak akan dimulai di pembibitan, tetapi sebaliknya akan dialokasikan dalam timbunan ini.

Salah satu keunggulan SGen adalah waktu yang dibutuhkan untuk melakukan pengumpulan sampah kecil sebanding dengan jumlah objek langsung baru yang dibuat sejak pengumpulan sampah kecil terakhir. Ini akan mengurangi dampak pengumpulan sampah pada performa aplikasi, karena pengumpulan sampah kecil ini akan memakan waktu lebih sedikit daripada pengumpulan sampah utama. Pengumpulan sampah utama masih akan terjadi, tetapi kurang sering.

Pengumpul sampah SGen adalah default dalam Xamarin.iOS 9.2.1 dan yang lebih besar, dan oleh karena itu akan digunakan secara otomatis. Harap dicatat bahwa kemampuan untuk mengubah pengumpul sampah telah dihapus dari versi Visual Studio yang lebih baru. Untuk informasi selengkapnya, lihat Sistem Penghitungan Referensi Baru.

Mengurangi Tekanan pada Pengumpul Sampah

Ketika SGen memulai pengumpulan sampah, SGen akan menghentikan utas aplikasi saat mengklaim kembali memori. Saat memori diklaim kembali, aplikasi mungkin mengalami jeda singkat atau gagap di UI. Seberapa mudah jeda ini tergantung pada dua faktor:

  1. Frekuensi – Seberapa sering pengumpulan sampah terjadi. Frekuensi pengumpulan sampah akan meningkat karena lebih banyak memori dialokasikan di antara koleksi.
  2. Durasi – Berapa lama setiap pengumpulan sampah individu akan memakan waktu. Ini kira-kira sebanding dengan jumlah objek langsung yang dikumpulkan.

Secara kolektif ini berarti bahwa jika banyak objek dialokasikan tetapi tidak tetap hidup, akan ada banyak pengumpulan sampah pendek. Sebaliknya, jika objek baru dialokasikan secara perlahan dan objek tetap hidup, akan ada pengumpulan sampah yang lebih sedikit tetapi lebih lama.

Untuk mengurangi tekanan pada pengumpul sampah, ikuti panduan berikut:

  • Hindari pengumpulan sampah dalam perulangan yang ketat dengan menggunakan kumpulan objek. Ini sangat relevan untuk game, yang perlu menciptakan sebagian besar objek mereka terlebih dahulu.
  • Rilis sumber daya secara eksplisit seperti aliran, koneksi jaringan, blok memori besar, dan file setelah tidak lagi diperlukan. Untuk informasi selengkapnya, lihat Merilis Sumber Daya yang Dapat Diubah I.
  • Batalkan pendaftaran penanganan aktivitas setelah tidak lagi diperlukan, untuk membuat objek dapat dikumpulkan. Untuk informasi selengkapnya, lihat Berhenti berlangganan dari Peristiwa.

Mengurangi Ukuran Aplikasi

Penting untuk memahami proses kompilasi pada setiap platform, untuk memahami dari mana ukuran aplikasi yang dapat dieksekusi berasal:

  • Aplikasi iOS adalah ahead-of-time (AOT) yang dikompilasi ke bahasa assembly ARM. Kerangka kerja .NET disertakan, dengan kelas yang tidak digunakan dilucuti hanya jika opsi linker yang sesuai diaktifkan.
  • Aplikasi Android dikompilasi ke bahasa perantara (IL) dan dikemas dengan kompilasi MonoVM dan just-in-time (JIT). Kelas kerangka kerja yang tidak digunakan dilucuti hanya jika opsi linker yang sesuai diaktifkan.
  • Aplikasi Windows Telepon dikompilasi ke IL dan dijalankan oleh runtime bawaan.

Selain itu, jika aplikasi membuat penggunaan generik yang luas, ukuran akhir yang dapat dieksekusi akan lebih meningkat karena akan berisi versi asli yang dikompilasi dari kemungkinan generik.

Untuk membantu mengurangi ukuran aplikasi, platform Xamarin menyertakan linker sebagai bagian dari alat build. Secara default, linker dinonaktifkan, dan harus diaktifkan dalam opsi proyek untuk aplikasi. Pada waktu build, aplikasi akan melakukan analisis statis untuk menentukan jenis mana, dan anggota, yang benar-benar digunakan oleh aplikasi. Kemudian akan menghapus jenis dan metode yang tidak digunakan dari aplikasi.

Cuplikan layar berikut menunjukkan opsi linker di Visual Studio untuk Mac untuk proyek Xamarin.iOS:

Linker options for Xamarin.iOS

Cuplikan layar berikut menunjukkan opsi linker di Visual Studio untuk Mac untuk proyek Xamarin.Android:

Linker options for Xamarin.Android

Linker menyediakan tiga pengaturan berbeda untuk mengontrol perilakunya:

  • Jangan Tautkan – Tidak ada jenis dan metode yang tidak digunakan yang akan dihapus oleh linker. Untuk alasan performa, ini adalah pengaturan default untuk build debug.
  • Link Framework SDK/SDK Assembly Only – Pengaturan ini hanya akan mengurangi ukuran rakitan yang dikirim oleh Xamarin. Kode pengguna tidak akan terpengaruh.
  • Tautkan Semua Rakitan – Ini adalah pengoptimalan yang lebih agresif yang akan menargetkan rakitan SDK dan kode pengguna. Untuk pengikatan, ini akan menghapus bidang dukungan yang tidak digunakan dan membuat setiap instans (atau objek terikat) lebih ringan, mengkonsumsi lebih sedikit memori.

Tautan Semua Rakitan harus digunakan dengan hati-hati karena dapat merusak aplikasi dengan cara yang tidak terduga. Analisis statis yang dilakukan oleh linker mungkin tidak mengidentifikasi semua kode yang diperlukan dengan benar, yang mengakibatkan terlalu banyak kode dihapus dari aplikasi yang dikompilasi. Situasi ini akan memanifestasikan dirinya hanya pada runtime ketika aplikasi crash. Karena itu penting untuk menguji aplikasi secara menyeluruh setelah mengubah perilaku linker.

Jika pengujian memang mengungkapkan bahwa linker telah salah menghapus kelas atau metode dimungkinkan untuk menandai jenis atau metode yang tidak direferensikan secara statis tetapi diperlukan oleh aplikasi dengan menggunakan salah satu atribut berikut:

  • Xamarin.iOS.Foundation.PreserveAttribute – Atribut ini untuk proyek Xamarin.iOS.
  • Android.Runtime.PreserveAttribute – Atribut ini untuk proyek Xamarin.Android.

Misalnya, mungkin perlu untuk mempertahankan konstruktor default jenis yang secara dinamis dibuat. Selain itu, penggunaan serialisasi XML mungkin mengharuskan properti jenis dipertahankan.

Untuk informasi selengkapnya, lihat Linker untuk iOS dan Linker untuk Android.

Teknik Pengurangan Ukuran Tambahan

Ada berbagai arsitektur CPU yang mendukung perangkat seluler. Oleh karena itu, Xamarin.iOS dan Xamarin.Android menghasilkan biner lemak yang berisi versi aplikasi yang dikompilasi untuk setiap arsitektur CPU. Ini memastikan bahwa aplikasi seluler dapat berjalan pada perangkat terlepas dari arsitektur CPU.

Langkah-langkah berikut dapat digunakan untuk mengurangi ukuran aplikasi yang dapat dieksekusi lebih lanjut:

  • Pastikan bahwa build Rilis diproduksi.
  • Kurangi jumlah arsitektur yang dibangun aplikasi, untuk menghindari biner FAT yang diproduksi.
  • Pastikan bahwa pengkompilasi LLVM sedang digunakan, untuk menghasilkan executable yang lebih dioptimalkan.
  • Kurangi ukuran kode terkelola aplikasi. Ini dapat dicapai dengan mengaktifkan linker di setiap perakitan (Tautkan Semua untuk proyek iOS, dan Tautkan semua rakitan untuk proyek Android).

Aplikasi Android juga dapat dibagi menjadi APK terpisah untuk setiap ABI ("arsitektur"). Pelajari lebih lanjut di posting blog ini: Cara Menjaga Ukuran Aplikasi Android Anda Tidak Berfungsi.

Optimalkan Sumber Daya Gambar

Gambar adalah beberapa sumber daya termahal yang digunakan aplikasi, dan sering ditangkap pada resolusi tinggi. Meskipun ini menciptakan gambar yang cerah penuh detail, aplikasi yang menampilkan gambar tersebut biasanya memerlukan lebih banyak penggunaan CPU untuk mendekode gambar dan lebih banyak memori untuk menyimpan gambar yang didekodekan. Menyia-nyiakan untuk mendekode gambar resolusi tinggi dalam memori ketika akan diturunkan skalanya ke ukuran yang lebih kecil untuk tampilan. Sebagai gantinya, kurangi penggunaan CPU dan jejak memori dengan membuat beberapa versi resolusi gambar tersimpan yang mendekati ukuran tampilan yang diprediksi. Misalnya, gambar yang ditampilkan dalam tampilan daftar kemungkinan besar akan menjadi resolusi yang lebih rendah daripada gambar yang ditampilkan di layar penuh. Selain itu, versi penurunan skala gambar resolusi tinggi dapat dimuat untuk menampilkannya secara efisien dengan dampak memori minimal. Untuk informasi selengkapnya, lihat Memuat Bitmap Besar Secara Efisien.

Terlepas dari resolusi gambar, menampilkan sumber daya gambar dapat sangat meningkatkan jejak memori aplikasi. Oleh karena itu, mereka hanya boleh dibuat ketika diperlukan dan harus dirilis segera setelah aplikasi tidak lagi memerlukannya.

Mengurangi Periode Aktivasi Aplikasi

Semua aplikasi memiliki periode aktivasi, yang merupakan waktu antara ketika aplikasi dimulai dan ketika aplikasi siap digunakan. Periode aktivasi ini memberi pengguna kesan pertama mereka tentang aplikasi, sehingga penting untuk mengurangi periode aktivasi dan persepsi pengguna tentangnya, agar mereka mendapatkan kesan pertama yang menguntungkan dari aplikasi.

Sebelum aplikasi menampilkan UI awalnya, aplikasi harus menyediakan layar splash untuk menunjukkan kepada pengguna bahwa aplikasi dimulai. Jika aplikasi tidak dapat dengan cepat menampilkan UI awalnya, layar splash harus digunakan untuk memberi tahu pengguna tentang kemajuan melalui periode aktivasi, untuk menawarkan jaminan bahwa aplikasi belum menggantung. Jaminan ini bisa menjadi bilah kemajuan, atau kontrol serupa.

Selama periode aktivasi, aplikasi menjalankan logika aktivasi, yang sering mencakup pemuatan dan pemrosesan sumber daya. Periode aktivasi dapat dikurangi dengan memastikan bahwa sumber daya yang diperlukan dikemas dalam aplikasi, alih-alih diambil dari jarak jauh. Misalnya, dalam beberapa keadaan mungkin sesuai selama periode aktivasi untuk memuat data tempat penampung yang disimpan secara lokal. Kemudian, setelah antarmuka pengguna awal ditampilkan, dan pengguna dapat berinteraksi dengan aplikasi, data tempat penampung dapat diganti secara progresif dari sumber jarak jauh. Selain itu, logika aktivasi aplikasi hanya boleh melakukan pekerjaan yang diperlukan untuk memungkinkan pengguna mulai menggunakan aplikasi. Ini dapat membantu jika menunda pemuatan rakitan tambahan, assembly dimuat saat pertama kali digunakan.

Mengurangi Komunikasi Layanan Web

Koneksi ke layanan web dari aplikasi dapat berdampak pada performa aplikasi. Misalnya, peningkatan penggunaan bandwidth jaringan akan mengakibatkan peningkatan penggunaan baterai perangkat. Selain itu, pengguna mungkin menggunakan aplikasi di lingkungan terbatas bandwidth. Oleh karena itu, masuk akal untuk membatasi pemanfaatan bandwidth antara aplikasi dan layanan web.

Salah satu pendekatan untuk mengurangi pemanfaatan bandwidth aplikasi adalah dengan mengompresi data sebelum mentransfernya melalui jaringan. Namun, penggunaan CPU tambahan dari proses pemadatan juga dapat mengakibatkan peningkatan penggunaan baterai. Oleh karena itu, tradeoff ini harus dievaluasi dengan hati-hati sebelum memutuskan apakah akan memindahkan data terkompresi melalui jaringan.

Masalah lain yang perlu dipertimbangkan adalah format data yang berpindah antara aplikasi dan layanan web. Dua format utama adalah Extensible Markup Language (XML) dan JavaScript Object Notation (JSON). XML adalah format pertukaran data berbasis teks yang menghasilkan payload data yang relatif besar, karena berisi sejumlah besar karakter pemformatan. JSON adalah format pertukaran data berbasis teks yang menghasilkan payload data ringkas, yang menghasilkan pengurangan persyaratan bandwidth saat mengirim data dan menerima data. Oleh karena itu, JSON sering kali merupakan format yang disukai untuk aplikasi seluler.

Disarankan untuk menggunakan objek transfer data (DTO) saat mentransfer data antara aplikasi dan layanan web. DTO berisi sekumpulan data untuk ditransfer di seluruh jaringan. Dengan menggunakan DTO, lebih banyak data dapat ditransmisikan dalam satu panggilan jarak jauh, yang dapat membantu mengurangi jumlah panggilan jarak jauh yang dilakukan oleh aplikasi. Umumnya, panggilan jarak jauh yang membawa payload data yang lebih besar membutuhkan waktu yang sama sebagai panggilan yang hanya membawa payload data kecil.

Data yang diambil dari layanan web harus di-cache secara lokal, dengan data yang di-cache digunakan daripada berulang kali diambil dari layanan web. Namun, saat mengadopsi pendekatan ini, strategi penembolokan yang sesuai juga harus diterapkan untuk memperbarui data di cache lokal jika berubah di layanan web.

Ringkasan

Artikel ini menjelaskan dan membahas teknik untuk meningkatkan performa aplikasi yang dibangun menggunakan platform Xamarin. Secara kolektif teknik ini dapat sangat mengurangi jumlah pekerjaan yang dilakukan oleh CPU, dan jumlah memori yang dikonsumsi oleh aplikasi.