Bagikan melalui

Meningkatkan Xamarin.Forms Performa Aplikasi

  • Artikel

Evolve 2016: Mengoptimalkan Performa Aplikasi dengan Xamarin.Forms

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 perangkat. 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.

Ada banyak teknik untuk meningkatkan performa, dan performa Xamarin.Forms aplikasi yang dirasakan. Secara kolektif teknik ini dapat sangat mengurangi jumlah pekerjaan yang dilakukan oleh CPU, dan jumlah memori yang dikonsumsi oleh aplikasi.

Catatan

Sebelum membaca artikel ini, Anda harus terlebih dahulu membaca Performa Lintas Platform, yang membahas teknik khusus non-platform untuk meningkatkan penggunaan memori dan performa aplikasi yang dibangun menggunakan platform Xamarin.

Mengaktifkan pengkompilasi XAML

XAML dapat dikompilasi secara opsional langsung ke dalam bahasa perantara (IL) dengan kompilator XAML (XAMLC). XAMLC menawarkan sejumlah manfaat:

  • Ini melakukan pemeriksaan waktu kompilasi XAML, memberi tahu pengguna tentang kesalahan apa pun.
  • Ini menghapus beberapa waktu beban dan instansiasi untuk elemen XAML.
  • Ini membantu mengurangi ukuran file perakitan akhir dengan tidak lagi menyertakan file .xaml.

XAMLC diaktifkan secara default dalam solusi baru Xamarin.Forms . Namun, mungkin perlu diaktifkan dalam solusi yang lebih lama. Untuk informasi selengkapnya, lihat Mengkompilasi XAML.

Menggunakan pengikatan yang dikompilasi

Pengikatan yang dikompilasi meningkatkan performa pengikatan data dalam Xamarin.Forms aplikasi dengan menyelesaikan ekspresi pengikatan pada waktu kompilasi, bukan pada waktu proses dengan pantulan. Mengkompilasi ekspresi pengikatan menghasilkan kode yang dikompilasi yang biasanya menyelesaikan pengikatan 8-20 kali lebih cepat daripada menggunakan pengikatan klasik. Untuk informasi selengkapnya, lihat Pengikatan Terkompilasi.

Mengurangi pengikatan yang tidak perlu

Jangan gunakan pengikatan untuk konten yang dapat dengan mudah diatur secara statis. Tidak ada keuntungan dalam mengikat data yang tidak perlu terikat, karena pengikatan tidak hemat biaya. Misalnya, pengaturan Button.Text = "Accept" memiliki lebih sedikit overhead daripada mengikat Button.Text ke properti viewmodel string dengan nilai "Terima".

Menggunakan perender cepat

Perender cepat mengurangi inflasi dan biaya Xamarin.Forms rendering kontrol pada Android dengan meratakan hierarki kontrol asli yang dihasilkan. Ini semakin meningkatkan performa dengan membuat lebih sedikit objek, yang pada gilirannya menghasilkan pohon visual yang kurang kompleks, dan penggunaan memori yang lebih sedikit.

Dari Xamarin.Forms 4.0 dan seterusnya, semua aplikasi yang menargetkan FormsAppCompatActivity menggunakan perender cepat secara default. Untuk informasi selengkapnya, lihat Perender Cepat.

Mengaktifkan pelacakan startup di Android

Kompilasi Ahead of Time (AOT) di Android meminimalkan overhead startup aplikasi Just in Time (JIT) dan penggunaan memori, dengan biaya pembuatan APK yang jauh lebih besar. Alternatifnya adalah menggunakan pelacakan startup, yang menyediakan trade-off antara ukuran APK Android dan waktu startup, jika dibandingkan dengan kompilasi AOT konvensional.

Alih-alih mengkompilasi sebanyak mungkin aplikasi ke kode yang tidak dikelola, pelacakan startup hanya mengkompilasi serangkaian metode terkelola yang mewakili bagian paling mahal dari startup aplikasi dalam aplikasi kosong Xamarin.Forms . Pendekatan ini menghasilkan pengurangan ukuran APK, jika dibandingkan dengan kompilasi AOT konvensional, sambil tetap memberikan peningkatan startup serupa.

Mengaktifkan pemadatan tata letak

Pemadatan tata letak menghapus tata letak tertentu dari pohon visual, dalam upaya untuk meningkatkan performa penyajian halaman. Manfaat performa yang diberikan ini bervariasi tergantung pada kompleksitas halaman, versi sistem operasi yang digunakan, dan perangkat tempat aplikasi berjalan. Namun, perolehan performa terbesar akan terlihat pada perangkat yang lebih lama. Untuk informasi selengkapnya, lihat Pemadatan Tata Letak.

Pilih tata letak yang benar

Tata letak yang mampu menampilkan beberapa anak, tetapi hanya memiliki satu anak, sia-sia. Misalnya, contoh kode berikut menunjukkan StackLayout dengan satu anak:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="DisplayImage.HomePage">
    <StackLayout>
        <Image Source="waterfront.jpg" />
    </StackLayout>
</ContentPage>

Ini boros dan StackLayout elemen harus dihapus, seperti yang ditunjukkan dalam contoh kode berikut:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="DisplayImage.HomePage">
    <Image Source="waterfront.jpg" />
</ContentPage>

Selain itu, jangan mencoba mereproduksi tampilan tata letak tertentu dengan menggunakan kombinasi tata letak lain, karena ini menghasilkan perhitungan tata letak yang tidak perlu dilakukan. Misalnya, jangan mencoba mereproduksi Grid tata letak dengan menggunakan kombinasi StackLayout instans. Contoh kode berikut menunjukkan contoh praktik buruk ini:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="Details.HomePage"
             Padding="0,20,0,0">
    <StackLayout>
        <StackLayout Orientation="Horizontal">
            <Label Text="Name:" />
            <Entry Placeholder="Enter your name" />
        </StackLayout>
        <StackLayout Orientation="Horizontal">
            <Label Text="Age:" />
            <Entry Placeholder="Enter your age" />
        </StackLayout>
        <StackLayout Orientation="Horizontal">
            <Label Text="Occupation:" />
            <Entry Placeholder="Enter your occupation" />
        </StackLayout>
        <StackLayout Orientation="Horizontal">
            <Label Text="Address:" />
            <Entry Placeholder="Enter your address" />
        </StackLayout>
    </StackLayout>
</ContentPage>

Ini boros karena perhitungan tata letak yang tidak perlu dilakukan. Sebaliknya, tata letak yang diinginkan dapat dicapai dengan lebih baik menggunakan , seperti yang Gridditunjukkan dalam contoh kode berikut:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="Details.HomePage"
             Padding="0,20,0,0">
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="100" />
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition Height="30" />
            <RowDefinition Height="30" />
            <RowDefinition Height="30" />
            <RowDefinition Height="30" />
        </Grid.RowDefinitions>
        <Label Text="Name:" />
        <Entry Grid.Column="1" Placeholder="Enter your name" />
        <Label Grid.Row="1" Text="Age:" />
        <Entry Grid.Row="1" Grid.Column="1" Placeholder="Enter your age" />
        <Label Grid.Row="2" Text="Occupation:" />
        <Entry Grid.Row="2" Grid.Column="1" Placeholder="Enter your occupation" />
        <Label Grid.Row="3" Text="Address:" />
        <Entry Grid.Row="3" Grid.Column="1" Placeholder="Enter your address" />
    </Grid>
</ContentPage>

Optimalkan performa tata letak

Untuk mendapatkan performa tata letak terbaik, ikuti panduan berikut:

  • Kurangi kedalaman hierarki tata letak dengan menentukan Margin nilai properti, memungkinkan pembuatan tata letak dengan tampilan pembungkusan yang lebih sedikit. Untuk informasi selengkapnya, lihat Margin dan Padding.
  • Saat menggunakan Grid, cobalah untuk memastikan bahwa baris dan kolom sesederh mungkin diatur ke Auto ukuran. Setiap baris atau kolom berukuran otomatis akan menyebabkan mesin tata letak melakukan perhitungan tata letak tambahan. Sebagai gantinya, gunakan baris dan kolom ukuran tetap jika memungkinkan. Atau, atur baris dan kolom untuk menempati jumlah ruang yang proporsional dengan GridUnitType.Star nilai enumerasi, asalkan pohon induk mengikuti panduan tata letak ini.
  • Jangan atur VerticalOptions properti dan HorizontalOptions tata letak kecuali diperlukan. Nilai default dan LayoutOptions.FillAndExpand memungkinkan pengoptimalan LayoutOptions.Fill tata letak terbaik. Mengubah properti ini memiliki biaya dan mengonsumsi memori, bahkan saat mengaturnya ke nilai default.
  • Hindari menggunakan RelativeLayout jika memungkinkan. Ini akan mengakibatkan CPU harus melakukan lebih banyak pekerjaan secara signifikan.
  • Saat menggunakan AbsoluteLayout, hindari menggunakan AbsoluteLayout.AutoSize properti jika memungkinkan.
  • Saat menggunakan StackLayout, pastikan hanya satu anak yang diatur ke LayoutOptions.Expands. Properti ini memastikan bahwa anak yang ditentukan akan menempati ruang terbesar yang StackLayout dapat diberikan kepadanya, dan boros untuk melakukan perhitungan ini lebih dari sekali.
  • Hindari memanggil salah satu metode Layout kelas, karena mengakibatkan perhitungan tata letak yang mahal dilakukan. Sebaliknya, kemungkinan perilaku tata letak yang diinginkan dapat diperoleh dengan mengatur TranslationX properti dan TranslationY . Atau, subkelas Layout<View> kelas untuk mencapai perilaku tata letak yang diinginkan.
  • Jangan memperbarui instans apa pun Label lebih sering daripada yang diperlukan, karena perubahan ukuran label dapat mengakibatkan seluruh tata letak layar dihitung ulang.
  • Jangan atur Label.VerticalTextAlignment properti kecuali diperlukan.
  • Atur LineBreakMode instans apa pun Label ke NoWrap jika memungkinkan.

Menggunakan pemrograman asinkron

Respons keseluruhan aplikasi Anda dapat ditingkatkan, dan hambatan performa sering dihindari, dengan menggunakan pemrograman asinkron. Di .NET, Pola Asinkron Berbasis Tugas (TAP) adalah pola desain yang direkomendasikan untuk operasi asinkron. Namun, penggunaan TAP yang salah dapat mengakibatkan aplikasi yang tidak format. Oleh karena itu, panduan berikut harus diikuti saat menggunakan TAP.

Fundamental

  • Pahami siklus hidup tugas, yang diwakili oleh TaskStatus enumerasi. Untuk informasi selengkapnya, lihat Arti status TaskStatus dan Tugas.

  • Task.WhenAll Gunakan metode untuk secara asinkron menunggu beberapa operasi asinkron selesai, daripada satu await per satu serangkaian operasi asinkron. Untuk informasi selengkapnya, lihat Task.WhenAll.

  • Task.WhenAny Gunakan metode untuk secara asinkron menunggu salah satu dari beberapa operasi asinkron selesai. Untuk informasi selengkapnya, lihat Task.WhenAny.

  • Task.Delay Gunakan metode untuk menghasilkan Task objek yang selesai setelah waktu yang ditentukan. Ini berguna untuk skenario seperti polling untuk data, dan menunda penanganan input pengguna untuk waktu yang telah ditentukan. Untuk informasi selengkapnya, lihat Task.Delay.

  • Jalankan operasi CPU sinkron intensif pada kumpulan utas dengan Task.Run metode . Metode ini adalah pintasan untuk TaskFactory.StartNew metode , dengan kumpulan argumen yang paling optimal. Untuk informasi selengkapnya, lihat Task.Run.

  • Hindari mencoba membuat konstruktor asinkron. Sebagai gantinya, gunakan peristiwa siklus hidup atau logika inisialisasi terpisah untuk menginisialisasi apa pun dengan benar await . Untuk informasi selengkapnya, lihat Konstruktor Asinkron di blog.stephencleary.com.

  • Gunakan pola tugas malas untuk menghindari menunggu operasi asinkron selesai selama startup aplikasi. Untuk informasi selengkapnya, lihat AsyncLazy.

  • Buat pembungkus tugas untuk operasi asinkron yang ada, yang tidak menggunakan TAP, dengan membuat TaskCompletionSource<T> objek. Objek-objek ini mendapatkan manfaat dari kemampuan pemrogramanTask, dan memungkinkan Anda mengontrol masa pakai dan penyelesaian .Task Untuk informasi selengkapnya, lihat Sifat TaskCompletionSource.

  • Task Mengembalikan objek, alih-alih mengembalikan objek yang ditungguTask, ketika tidak perlu memproses hasil operasi asinkron. Ini lebih berkinerja karena lebih sedikit pengalihan konteks yang dilakukan.

  • Gunakan pustaka Aliran Data Pustaka Paralel Tugas (TPL) dalam skenario seperti memproses data saat tersedia, atau ketika Anda memiliki beberapa operasi yang harus berkomunikasi satu sama lain secara asinkron. Untuk informasi selengkapnya, lihat Aliran Data (Pustaka Paralel Tugas).

UI

  • Panggil api versi asinkron, jika tersedia. Ini akan membuat utas UI tidak diblokir, yang akan membantu meningkatkan pengalaman pengguna dengan aplikasi.

  • Perbarui elemen UI dengan data dari operasi asinkron pada utas UI, untuk menghindari pengecualian yang dilemparkan. Namun, pembaruan pada ListView.ItemsSource properti akan secara otomatis dinamai ke utas UI. Untuk informasi tentang menentukan apakah kode berjalan pada utas UI, lihat Xamarin.Essentials: MainThread.

    Penting

    Setiap properti kontrol yang diperbarui melalui pengikatan data akan secara otomatis di-marshal ke utas UI.

Penanganan kesalahan

  • Pelajari tentang penanganan pengecualian asinkron. Pengecualian yang tidak tertangani yang dilemparkan oleh kode yang berjalan secara asinkron disebarkan kembali ke utas panggilan, kecuali dalam skenario tertentu. Untuk informasi selengkapnya, lihat Penanganan pengecualian (Pustaka Paralel Tugas).
  • Hindari membuat async void metode, dan sebagai gantinya membuat async Task metode. Ini memungkinkan penanganan kesalahan, komposabilitas, dan kemampuan uji yang lebih mudah. Pengecualian untuk pedoman ini adalah penanganan aktivitas asinkron, yang harus mengembalikan void. Untuk informasi selengkapnya, lihat Menghindari Async Void.
  • Jangan mencampur pemblokiran dan kode asinkron dengan memanggil Task.Waitmetode , Task.Result, atau GetAwaiter().GetResult , karena dapat mengakibatkan kebuntuan terjadi. Namun, jika pedoman ini harus dilanggar, pendekatan yang disukai adalah memanggil GetAwaiter().GetResult metode karena mempertahankan pengecualian tugas. Untuk informasi selengkapnya, lihat Asinkron Semua Cara dan Penanganan Pengecualian Tugas di .NET 4.5.
  • ConfigureAwait Gunakan metode jika memungkinkan, untuk membuat kode bebas konteks. Kode bebas konteks memiliki performa yang lebih baik untuk aplikasi seluler dan merupakan teknik yang berguna untuk menghindari kebuntuan saat bekerja dengan basis kode asinkron sebagian. Untuk informasi selengkapnya, lihat Mengonfigurasi Konteks.
  • Gunakan tugas kelanjutan untuk fungsionalitas seperti menangani pengecualian yang dilemparkan oleh operasi asinkron sebelumnya, dan membatalkan kelanjutan baik sebelum dimulai atau saat dijalankan. Untuk informasi selengkapnya, lihat Menautkan Tugas dengan Menggunakan Tugas Berkelanjutan.
  • Gunakan implementasi asinkron ICommand saat operasi asinkron dipanggil dari ICommand. Ini memastikan bahwa setiap pengecualian dalam logika perintah asinkron dapat ditangani. Untuk informasi selengkapnya, lihat Pemrograman Asinkron: Pola untuk Aplikasi MVVM Asinkron: Perintah.

Pilih kontainer injeksi dependensi dengan hati-hati

Kontainer injeksi dependensi memperkenalkan batasan performa tambahan ke dalam aplikasi seluler. Mendaftarkan dan menyelesaikan jenis dengan kontainer memiliki biaya performa karena penggunaan refleksi kontainer untuk membuat setiap jenis, terutama jika dependensi sedang direkonstruksi untuk setiap navigasi halaman di aplikasi. Jika ada banyak atau dependensi mendalam, biaya pembuatan dapat meningkat secara signifikan. Selain itu, pendaftaran jenis, yang biasanya terjadi selama startup aplikasi, dapat berdampak nyata pada waktu startup, tergantung pada kontainer yang digunakan.

Sebagai alternatif, injeksi dependensi dapat dibuat lebih berkinerja dengan menerapkannya secara manual menggunakan pabrik.

Membuat aplikasi Shell

Xamarin.Forms Aplikasi Shell memberikan pengalaman navigasi berpendapat berdasarkan flyout dan tab. Jika pengalaman pengguna aplikasi Anda dapat diimplementasikan dengan Shell, akan bermanfaat untuk melakukannya. Aplikasi Shell membantu menghindari pengalaman startup yang buruk, karena halaman dibuat sesuai permintaan sebagai respons terhadap navigasi daripada saat startup aplikasi, yang terjadi dengan aplikasi yang menggunakan 'TabbedPage'. Untuk informasi selengkapnya, lihat Xamarin.Forms Shell.

Gunakan CollectionView alih-alih ListView

CollectionView adalah tampilan untuk menyajikan daftar data menggunakan spesifikasi tata letak yang berbeda. Ini memberikan alternatif yang lebih fleksibel, dan berkinerja untuk ListView. Untuk informasi selengkapnya, lihat Xamarin.Forms CollectionView.

Optimalkan performa ListView

Saat menggunakan ListView, ada sejumlah pengalaman pengguna yang harus dioptimalkan:

  • Inisialisasi – interval waktu dimulai saat kontrol dibuat, dan berakhir saat item ditampilkan di layar.
  • Menggulir – kemampuan untuk menggulir daftar dan memastikan bahwa UI tidak tertinggal dari gerakan sentuh.
  • Interaksi untuk menambahkan, menghapus, dan memilih item.

ListView Kontrol memerlukan aplikasi untuk menyediakan data dan templat sel. Bagaimana hal ini dicapai akan berdampak besar pada performa kontrol. Untuk informasi selengkapnya, lihat ListView Performance.

Mengoptimalkan sumber daya 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. Misalnya, jika aplikasi menampilkan gambar dengan membaca datanya dari aliran, pastikan aliran dibuat hanya saat diperlukan, dan pastikan bahwa aliran dirilis saat tidak lagi diperlukan. Ini dapat dicapai dengan membuat aliran saat halaman dibuat, atau ketika Page.Appearing peristiwa diaktifkan, lalu membuang aliran saat Page.Disappearing peristiwa terjadi.

Saat mengunduh gambar untuk ditampilkan dengan ImageSource.FromUri metode , cache gambar yang diunduh dengan memastikan bahwa UriImageSource.CachingEnabled properti diatur ke true. Untuk informasi selengkapnya, lihat Bekerja dengan Gambar.

Untuk informasi selengkapnya, lihat Mengoptimalkan Sumber Daya Gambar.

Mengurangi ukuran pohon visual

Mengurangi jumlah elemen pada halaman akan membuat halaman dirender lebih cepat. Ada dua teknik utama untuk mencapai hal ini. Yang pertama adalah menyembunyikan elemen yang tidak terlihat. Properti IsVisible dari setiap elemen menentukan apakah elemen harus menjadi bagian dari pohon visual atau tidak. Oleh karena itu, jika elemen tidak terlihat karena disembunyikan di belakang elemen lain, hapus elemen atau atur propertinya IsVisible ke false.

Teknik kedua adalah menghapus elemen yang tidak perlu. Misalnya, contoh kode berikut menunjukkan tata letak halaman yang berisi beberapa Label objek:

<StackLayout>
    <StackLayout Padding="20,20,0,0">
        <Label Text="Hello" />
    </StackLayout>
    <StackLayout Padding="20,20,0,0">
        <Label Text="Welcome to the App!" />
    </StackLayout>
    <StackLayout Padding="20,20,0,0">
        <Label Text="Downloading Data..." />
    </StackLayout>
</StackLayout>

Tata letak halaman yang sama dapat dipertahankan dengan jumlah elemen yang dikurangi, seperti yang ditunjukkan dalam contoh kode berikut:

<StackLayout Padding="20,35,20,20" Spacing="25">
  <Label Text="Hello" />
  <Label Text="Welcome to the App!" />
  <Label Text="Downloading Data..." />
</StackLayout>

Mengurangi ukuran kamus sumber daya aplikasi

Sumber daya apa pun yang digunakan di seluruh aplikasi harus disimpan dalam kamus sumber daya aplikasi untuk menghindari duplikasi. Ini akan membantu mengurangi jumlah XAML yang harus diurai di seluruh aplikasi. Contoh kode berikut menunjukkan HeadingLabelStyle sumber daya, yang digunakan di seluruh aplikasi, dan sebagainya didefinisikan dalam kamus sumber daya aplikasi:

<Application xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="Resources.App">
     <Application.Resources>
         <ResourceDictionary>
            <Style x:Key="HeadingLabelStyle" TargetType="Label">
                <Setter Property="HorizontalOptions" Value="Center" />
                <Setter Property="FontSize" Value="Large" />
                <Setter Property="TextColor" Value="Red" />
            </Style>
         </ResourceDictionary>
     </Application.Resources>
</Application>

Namun, XAML yang khusus untuk halaman tidak boleh disertakan dalam kamus sumber daya aplikasi, karena sumber daya kemudian akan diuraikan pada startup aplikasi alih-alih ketika diperlukan oleh halaman. Jika sumber daya digunakan oleh halaman yang bukan halaman startup, sumber daya harus ditempatkan di kamus sumber daya untuk halaman tersebut, oleh karena itu membantu mengurangi XAML yang diurai saat aplikasi dimulai. Contoh kode berikut menunjukkan HeadingLabelStyle sumber daya, yang hanya ada di satu halaman, dan sebagainya ditentukan dalam kamus sumber daya halaman:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="Test.HomePage"
             Padding="0,20,0,0">
    <ContentPage.Resources>
        <ResourceDictionary>
          <Style x:Key="HeadingLabelStyle" TargetType="Label">
              <Setter Property="HorizontalOptions" Value="Center" />
              <Setter Property="FontSize" Value="Large" />
              <Setter Property="TextColor" Value="Red" />
          </Style>
        </ResourceDictionary>
    </ContentPage.Resources>
    ...
</ContentPage>

Untuk informasi selengkapnya tentang sumber daya aplikasi, lihat Gaya XAML.

Menggunakan pola perender kustom

Sebagian besar Xamarin.Forms kelas perender mengekspos OnElementChanged metode , yang dipanggil ketika Xamarin.Forms kontrol kustom dibuat untuk merender kontrol asli yang sesuai. Kelas perender kustom, di setiap proyek platform, lalu ambil alih metode ini untuk membuat instans dan menyesuaikan kontrol asli. Metode SetNativeControl ini digunakan untuk membuat instans kontrol asli, dan metode ini juga akan menetapkan referensi kontrol ke Control properti .

Namun, dalam beberapa keadaan OnElementChanged metode dapat dipanggil beberapa kali. Oleh karena itu, untuk mencegah kebocoran memori, yang dapat berdampak pada performa, perawatan harus dilakukan saat membuat instans kontrol asli baru. Pendekatan yang digunakan saat membuat instans kontrol asli baru dalam perender kustom diperlihatkan dalam contoh kode berikut:

protected override void OnElementChanged (ElementChangedEventArgs<NativeListView> e)
{
  base.OnElementChanged (e);

  if (e.OldElement != null)
  {
    // Unsubscribe from event handlers and cleanup any resources
  }

  if (e.NewElement != null)
  {
    if (Control == null)
    {
      // Instantiate the native control with the SetNativeControl method
    }
    // Configure the control and subscribe to event handlers
  }
}

Kontrol asli baru hanya boleh dibuat sekali, ketika Control properti adalah null. Selain itu, kontrol hanya boleh dibuat, dikonfigurasi, dan penanganan aktivitas berlangganan saat perender kustom dilampirkan ke elemen baru Xamarin.Forms . Demikian pula, setiap penanganan aktivitas yang berlangganan hanya boleh dihentikan langganannya dari saat elemen perender dilampirkan ke perubahan. Mengadopsi pendekatan ini akan membantu menciptakan perender kustom yang berkinerja efisien yang tidak menderita kebocoran memori.

Penting

Metode SetNativeControl hanya boleh dipanggil jika e.NewElement properti bukan null, dan Control propertinya adalah null.

Untuk informasi selengkapnya tentang perender kustom, lihat Menyesuaikan Kontrol di Setiap Platform.