Xamarin.forms: [Bug] InvalidOperationException di TypedBinding`2 [TSource, TProperty] .Apply

@mfeingol Jika Anda dapat mempersempitnya, dapatkah Anda melampirkan proyek kecil yang menunjukkan masalah ini? Terima kasih!

Saya akan mencoba melakukannya akhir pekan ini, tetapi yang ini agak sulit untuk mereproduksi sesuai permintaan. Adakah petunjuk dari sisi Anda, berdasarkan pemahaman Anda tentang kode?

Sepertinya ini terkait dengan pengikatan XAML menggunakan DataType.

Saya sedang bepergian sekarang, tetapi solusi sementara saya adalah menonaktifkan pengikatan terkompilasi.

@mfeingol Oke, kedengarannya benar. Jika Anda mendapat kesempatan, berikan contoh proyek untuk membantu kami mempersempit masalah. Terima kasih!

Saya melihat masalah yang sama ini di iOS dan Android. Saya tidak menggunakan binding terkompilasi.

Masalah AppCenter:

TypedBinding 2[TSource,TProperty].Apply (System.Boolean fromTarget) TypedBinding 2 + PropertyChangedProxy [TSource, TProperty].b__16_0 ()
Thread + RunnableImplementor.Run ()
IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this)
(metode dinamis pembungkus) System.Object.26 (intptr, intptr)

Proyek bentuk Xamarin, halaman Xaml dengan ViewModel - Grid berisi ScrollView - ScrollView berisi label. Cukup mudah.

@samhouts : Saya telah mencoba yang terbaik, tetapi saya tidak dapat mereproduksi masalah di aplikasi sampel. Saya, bagaimanapun, memiliki 100% repro di aplikasi produksi saya.

Dapatkah saya memberi seseorang di tim Anda izin ke proyek Azure DevOps saya sehingga mereka dapat mereproduksi masalahnya?

shneuvil di microsoft.com

Anda berada di: https://dev.azure.com/sideroads/Sideroads

Langkah repro:

1. git checkout 6698-repro dan bangun. Anda mungkin perlu menambahkan direktori Eksternal ke daftar direktori NuGet Anda untuk mengambil paket.
2. Jalankan aplikasi dan buat perjalanan baru dari halaman perjalanan. Beri nama perjalanan dengan sesuatu seperti "Test" dan biarkan semua default kecuali menentukan keberangkatan dan kedatangan dan bandara (misalnya SEA dan LAS).
3. Ketuk perjalanan untuk memilihnya.
4. Dari menu hamburger, buka halaman cuaca, konfirmasi laporan cuaca muncul untuk lokasi yang relevan.
5. Buka pengaturan, ubah penyedia cuaca dari NWS ke SINI.
6. Kembali ke halaman cuaca. Anda akan melihat crash dengan cukup cepat. Memulai ulang aplikasi akan terbuka kembali di halaman cuaca, menyegarkan cuaca, dan menghasilkan crash lagi.

Jika karena alasan tertentu Anda tidak dapat melakukan repro dengan perjalanan sederhana seperti itu, saya akan mengekspor perjalanan yang lebih canggih untuk Anda dengan lebih banyak lokasi.

@PureWeen : beri tahu saya jika ini tidak berhasil untuk Anda.

@mtirona : Saya melewatkan komentar Anda sebelumnya, maaf. Aneh bahwa Anda melihat ini tanpa menggunakan binding terkompilasi. Saya kira Anda tidak memiliki proyek repro sederhana yang memicu crash sesuai permintaan?

@mfeingol Masalah ini muncul secara acak dalam aplikasi kita. Saya tidak memiliki yang sederhana untuk dibuat ulang sesuai permintaan - Saya memiliki ratusan crash di AppCenter yang mendokumentasikan masalah tersebut. Saya akan berterima kasih atas petunjuk apa pun tentang cara mencegah masalah ini ...

@mtirona : apakah Anda 100% yakin tidak menggunakan x: DataType di mana pun di XAML Anda?

@mfeingol Ada x: DataType pada halaman induk jadi saya telah melalui seluruh aplikasi dan membuat cabang di mana saya telah menghapus x: DataType. Saya sedang dalam proses untuk menguji QA kami di cabang ini untuk kerusakan untuk melihat apakah ini menyelesaikan masalah.

Saya yakin lima-sembilan bahwa ini terkait dengan XamlC, kecuali Anda membuat TypedBindings di kode Anda sendiri (yang _hanya_ dibuat oleh kompiler Xaml)

Catatan tambahan: Saya telah menggunakan Xamarin Forms 3.6, dan saya baru saja memperbarui ke versi 4.1 terbaru. Saat pertama kali menjalankan aplikasi saya, saya langsung melihat error ini saat menambahkan item dengan cepat ke halaman listview yang dikelompokkan. Jadi masalahnya masih ada dengan 4.1.0.618606.

@PureWeen : Saya telah memperbarui langkah-langkah repro di atas untuk merujuk ke cabang yang dapat Anda selesaikan yang seharusnya segera melaporkan masalah tersebut untuk Anda.

@mfeingol bisakah kamu melakukan ini untukku?

Jika karena alasan tertentu Anda tidak dapat melakukan repro dengan perjalanan sederhana seperti itu, saya akan mengekspor perjalanan yang lebih canggih untuk Anda dengan lebih banyak lokasi.

Saya mencoba langkah Anda dan tidak ada yang jatuh untuk saya

Baiklah, jadi @mfeingol Saya tidak yakin bagaimana atau mengapa data Anda berbaris menyebabkan masalah ini, tetapi inilah yang saya ketahui sejauh ini

TypedBindings menggunakan WeakReference ke BindableObject jadi jika itu satu-satunya referensi BindableObject maka referensi itu akan hilang.

Inilah kode yang macet
`` C #
if (! _weakTarget.TryGetTarget (out target))
melempar InvalidOperationException () baru;

If you look at the output of the application while it's running the exception always happens after a GC which makes sense why you are only seeing this after loading a larger data set.

As a test with the TypeBindings I created a nuget where it stores the source and target to a local variable just to see what would happen 

```C#
            _weakSource.SetTarget(source);
            _weakTarget.SetTarget(bindObj);
            _bindObj = bindObj;
            _source = source;
            ApplyCore(source, bindObj, targetProperty);
        }

        BindableObject _bindObj;
        object _source;

Dan jika saya melakukan itu maka kecelakaan itu tidak terjadi.

Pemikiran saya adalah bahwa entah bagaimana data Anda mencapai tempat di mana satu-satunya hal yang mereferensikan instance LocationDayWeatherViewModel yang terikat ke ViewCell adalah TypeBinding dan hanya itu. Saya masih belum cukup melacak apakah ini merupakan pengecualian di pihak kami vs Anda. Dapatkah Anda memastikan Anda mempertahankan referensi ke semua LocationDayWeatherViewModel yang dibuat yang terikat ke ListView?

Terima kasih telah melihat ini! Masalah ini cukup sulit direproduksi di luar aplikasi lengkap, jadi masuk akal jika ini melibatkan referensi yang lemah. Saya ingin tahu apakah menambahkan tekanan memori ke repro yang lebih sederhana dapat mengakibatkan masalah yang sama.

Bagaimanapun, satu-satunya saat instance LocationDayWeatherViewModel tidak akan direferensikan oleh viewmodel adalah selama penyegaran hari cuaca, di mana kode tersebut menghapus item yang terikat ObservableCollection sebelum memasukkan item baru. Ini terjadi jauh di dalam ExpandableGroupCollectionViewModel.Refresh jika Anda ingin menyetel bps.

Namun, saya berpikir bahwa membersihkan ObservableCollection terikat harus menjadi operasi yang aman, dan tidak jelas bagi saya mengapa pengikatan XF akan menggunakan ref yang lemah. Kedengarannya seperti perlombaan seperti ini.

Selain: Saya mencoba menyalin item di this ke dalam daftar sementara sebelum membersihkan di Refresh , tetapi yang mengejutkan, itu tampaknya tidak menyelesaikan masalah. Saya mereferensikan daftar di akhir metode untuk memastikan GC tidak melakukannya juga. Saya kira ini akan masuk akal jika XF mencoba menggunakan pengikatan basi "nanti", dan ini akan menyarankan bahwa tidak ada cara yang baik bagi aplikasi untuk menstabilkan referensi terikat. Tapi saya mungkin salah paham.

(Dan ya, kode cuaca / expander agak di luar kendali. Saya berharap XF memiliki kontrol Expander asli ...)

Saya pikir menambahkan tekanan memori atau hanya memanggil GC.Collect mungkin menciptakan kembali masalah tersebut pada proyek yang lebih kecil. Mungkin juga terjadi karena OnPropertyChanged on TypedBinding diatur ke UI Thread

https://github.com/xamarin/Xamarin.Forms/blob/7cc9a282bdeb76405c793574ebe0d096072f4228/Xamarin.Forms.Core/TypedBinding.cs#L275

Jadi dengan jelas saya berpikir apa yang mungkin terjadi

PropertyChanged antrian di UI Thread
Bersih
GC
WeakReference kehilangan referensi
PropertyChanged sekarang menyelesaikan dan melontarkan pengecualian

Mungkin ada hubungannya dengan masalah ini?
https://github.com/xamarin/xamarin-android/issues/2049

@StephaneDelcroix mungkin memiliki beberapa wawasan tambahan saat ini :-)

Saya memiliki sedikit waktu luang tadi malam, dan saya mencoba menambahkan GC.Collect() setelah panggilan ke Clear() dalam repro saya yang disederhanakan. Sayangnya saya tidak dapat mereproduksi masalah seperti itu.

Apakah Anda menunggu finalisator yang tertunda?

Kami melakukannya seperti ini dalam pengujian kami hanya untuk memastikannya
https://github.com/xamarin/Xamarin.Forms/blob/a76db1407a76fccbf487425db1bca5d15f925127/Xamarin.Forms.Controls.Issues/Xamarin.Forms.Controls.Issues.Shared/Helpers/GarbageCollectionL9

Itu panggilan yang sangat bagus. Tapi sayangnya, bahkan setelah itu, Clear() tidak memicu repro.

Jadi mengambil langkah mundur ... bagaimana ini bekerja? Jika binding memiliki referensi yang lemah, maka menurut definisi objek tersebut dapat di-GC. Jadi itu adalah sesuatu yang, yah, bisa terjadi, dan XF seharusnya tidak memberikan pengecualian yang tidak tertandingi. Alih-alih, itu mungkin harus mengabaikan pemberitahuan PropertyChanged dan percaya aplikasi tahu apa yang dilakukannya. Maksud saya, apa lagi yang bisa dilakukannya?

Dapatkah Anda melampirkan repro yang Anda gunakan untuk mencoba dan membuat ulang?

Saya akan melampirkan kodenya malam ini. Ini pada dasarnya adalah repro dalam aplikasi yang telah Anda lihat, diekstrak menjadi aplikasi mandiri. Tapi saya belum melihat masalah repro di dalamnya.

TypedBindingCrashes.zip

@ PureWeen : ada hal lain yang dapat saya lakukan untuk membantu mendiagnosis ini?

@mfeingol tidak sekarang kecuali Anda mendapatkan ide bagaimana melakukan repro dengan aplikasi mandiri. Agak sulit untuk menguranginya menjadi yang lebih besar jadi kami akan sedikit lebih lambat dengan menyelesaikan yang satu ini.

Apakah mungkin kita dapat memikirkan hal ini secara konseptual, seperti yang saya sebutkan di https://github.com/xamarin/Xamarin.Forms/issues/6698#issuecomment -519359760? Atau apakah masih ada bagian yang hilang tentang apa yang sebenarnya menyebabkan masalah?

Saya memiliki masalah yang sama dan saya juga tidak dapat mereproduksi dengan mudah) -:

@ysmoradi : Saya kira Anda tidak dapat mengupload repro sederhana?

Sulit untuk mereproduksi bahkan dalam aplikasi produksi saya!

Saya juga memiliki repro dalam produksi, tetapi menurut @PureWeen , sulit bagi mereka untuk memahami masalah tanpa repro yang lebih sederhana. Saya sudah mencoba dan gagal membuatnya. :-(

Saya pikir itu ide yang baik untuk memiliki nama properti + nama tipe tampilan + nama tipe konteks yang mengikat dalam pesan pengecualian, sehingga kita dapat memiliki wawasan yang lebih baik.

Saya mengalami masalah yang sama persis, iOS dan Android, menggunakan formulir xamarin 4.2.0.709249.
Saya memiliki ListView menggunakan DataTemplate untuk memvisualisasikan objek, yang ditentukan dalam xaml saya.
Saya memiliki DataType yang ditetapkan pada halaman xaml dan kemudian yang berbeda pada datatemplate listview.

Saya tidak perlu memanggil clear atau replace atau anyting pada daftar yang saya ikat, tampaknya sudah cukup untuk memanggil GC.Collect dan menunggu metode lain untuk memberi saya kesalahan di atas. (Jika saya tidak memiliki panggilan GC.Collect, ini sangat jarang gagal, tetapi sesekali terjadi, dengan panggilan tersebut berhasil dimuat, tetapi gagal saat memuat ulang.)

Namun, saya menemukan sesuatu yang menarik, jika saya menghapus ikatan saya antara viewModel.IsBusy saya ke listview.IsRefreshing kesalahan hilang, (tetapi indikator penyegaran terus berjalan setelah tarik untuk menyegarkan tentu saja).

Juga, jika saya menghapus tipe data pada halaman konten, dan hanya mengaturnya pada templat data, kesalahan juga hilang, dan saya dapat menggunakan pengikatan pada listview IsRefresing.

Untuk meringkas apa yang saya perlukan di aplikasi produksi saya untuk mereproduksi:

1. Setel DataType di ContentPage
2. Setel Binding pada IsRefreshing di ListView
3. Lakukan panggilan GC.Collect diikuti dengan menunggu Task.Delay (250); dalam metode yang terikat ke RefreshCommand listview

@shoyheim : apakah Anda memiliki repro sederhana yang dapat Anda posting di sini?

@shoyheim : apakah Anda memiliki repro sederhana yang dapat Anda posting di sini?

@mfeingol Maaf, saya telah menguji /

@shoyheim : apakah Anda pernah beruntung dengan ini?

@jamur_kejang
Tidak, maaf, saya sudah mencoba, tetapi setiap kali saya membuat repro sederhana, saya tidak dapat membuatnya mogok, tetapi aplikasi produksi saya terus mogok dan mogok.
Sekarang saya menghapus semua pengikatan terkompilasi saya dan hanya menggunakan pengikatan runtime di file xaml saya, dan crash telah menghilang.
Saya telah menghabiskan banyak waktu untuk mencoba mencari tahu apa yang salah, dan satu-satunya hal yang saya yakin adalah bahwa ada hubungan antara menggunakan ListView dengan pengikatan pada "isRefreshing" untuk menunjukkan saat daftar menyegarkan, dan menggunakan pengikatan terkompilasi ... tampaknya juga error terjadi di sekitar waktu pengumpulan sampah.

1- Properti konteks pengikatan (model tampilan) diubah.
2- Kami menampilkan pop sehingga hancur.
3- GC dipanggil.

1. Binding.Apply dipanggil dan mencoba mendapatkan akses objek yang diperlukan yang sudah tidak ada sehingga melontarkan InvalidOperationException.
   Anda mungkin bertanya mengapa langkah 4 dilakukan sangat terlambat? Karena dipanggil di Device.BeginInvokeOnMainThread, dan tindakan semacam itu akan ditambahkan ke akhir daftar antrean tindakan utas utama.
   Saya bisa menangani pengecualian itu dengan menyediakan PlatformServices kustom ke xf dan tidak ada lagi crash, tetapi pengecualian itu muncul lebih dari 800 kali! Untuk hampir semua jenis penjilidan halaman hancur

@ysmoradi : Saya menghabiskan beberapa waktu mencoba mereproduksi langkah Anda, dan saya tidak dapat memicu

Saya telah mengatakan sebelumnya bahwa saya tidak memiliki repo sederhana dan itu terjadi di aplikasi produksi saya, dan itu juga terjadi secara acak.
Pertama kali saya mulai membuat repo, saya tidak mengetahui banyak hal, tetapi besok saya akan mencoba membuat yang lain menggunakan asumsi baru saya.
Kiat lain yang mungkin membantu: Berdasarkan asumsi saya, memiliki GC yang bersamaan memungkinkan hasil menjadi peningkatan peluang untuk mereproduksi kerusakan. Karena dapat mengumpulkan objek pada utas terpisah. Kita juga perlu mengubah properti model tampilan pada utas / tugas terpisah karena Device.BeginInvokeOnMainThread meneruskan tindakan ke akhir antrian utas utama hanya ketika dipanggil di utas selain utas utama.
Coba lagi dan beri tahu saya jika Anda menemukan sesuatu, dan saya akan mencobanya besok.

Saya mengaktifkan GC serentak. Dengan menggunakan saran Anda, cuplikan kode yang saya gunakan melakukan ini:

            Page1 page = new Page1();
            await this.Navigation.PushModalAsync(page);
            await Task.Run(() => { page.TXT = "Foo"; });
            await this.Navigation.PopModalAsync();

            GC.Collect();
            GC.WaitForPendingFinalizers();

            GC.Collect();
            GC.WaitForPendingFinalizers();

TXT adalah properti di Page1, diimplementasikan menggunakan BindableProperty. Halaman1 menggunakan binding terkompilasi.

Masih belum berhasil.

Mendapatkan masalah yang sama secara acak di sini juga di aplikasi produksi saya. Setelah melalui proses yang membosankan dari pengaturan x: Jenis data di mana-mana seperti yang direkomendasikan dalam pedoman kinerja, saya tidak dapat mengatakan bahwa saya sangat senang harus menghapus semuanya karena masalah ini.

Saya akan memperbarui ini dengan aplikasi repro jika saya bisa membuatnya berfungsi.

Catatan: Saya ragu ini terkait, tetapi tampaknya saya baru mulai melihat masalah setelah saya juga mulai menggunakan tata letak terkompresi. Mungkin kebetulan karena masalahnya sangat acak, tapi siapa tahu.

Baru saja memperbarui aplikasi saya ke MVVM dengan binding terkompilasi dan mendapatkan kesalahan yang sama sekarang.
Menjalankan Xamarin.Forms terbaru: 4.2.0.848062

Dengan konfigurasi berikut:

Juga tidak memiliki langkah repro (versi aplikasi ini dalam versi beta untuk satu hari dan saya sudah memiliki dua laporan melalui AppCenter tentang itu).
Dapat membagikan repositori aplikasi, tetapi tanpa langkah repro, saya rasa itu tidak akan banyak membantu.

Saya mungkin tidak memahami keseluruhan gambar, tetapi bukankah solusi mudah untuk ini hanyalah dengan Unapply dan kembali ketika target mendapat GC, seperti itu sudah terjadi tanpa DO_NOT_CHECK_FOR_BINDING_REUSE yang ditentukan di TypedBinding.cs? Saya tidak melihat bagaimana melempar adalah ide yang bagus di sini.

@fmanseau : Saya memiliki pandangan yang sama. @ PureWeen?

Juga jika itu membantu, masalah yang terkait dengan ini di repo Prism tampaknya memiliki langkah-langkah repro (ini membutuhkan aplikasi Prism, tetapi mungkin mudah untuk mengikuti pola serupa tanpa).

https://github.com/PrismLibrary/Prism/issues/1688

@Sthaneelix @ kingces95 @wach
Kalian tampaknya berada di belakang implementasi TypedBinding .

Seperti yang Anda lihat di utas ini, banyak pengembang di luar sana (termasuk saya) yang aplikasinya mogok sesekali karena InvalidOperationException dilempar oleh TypedBinding .
Tampaknya @samhouts benar dalam asumsinya, bahwa setelah GC memulai dan menghapus target dari TypedBinding (seperti yang sangat mungkin terjadi di aplikasi kami, di mana kami memiliki ListView dengan banyak kompleks DataTemplates ), TypedBinding melempar InvalidOperationException yang tidak pernah tertangkap dan menyebabkan aplikasi crash di Android (dan berpotensi pada platform lain ??) seperti ini:

TypedBinding 2[TSource,TProperty].Apply (System.Boolean fromTarget) System.InvalidOperationException: Operation is not valid due to the current state of the object. Stack traces TypedBinding 2 [TSource, TProperty] .Apply (System.Boolean fromTarget)
TypedBinding`2 + PropertyChangedProxy [TSource, TProperty].b__16_0 ()
Thread + RunnableImplementor.Run ()
IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this)
(wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.43 (intptr, intptr)

Sekarang @mfeingol cukup bertanya mengapa ada InvalidOperationException yang menyebabkan crash ini. Maksud saya, secara konseptual tidak boleh ada target menjadi sampah yang dikumpulkan, mengapa menggunakan referensi yang lemah?

Saya sendiri adalah pengembang WPF sejak .NET 3.0 dan tahu bahwa pengecualian yang mengikat tidak pernah menyebabkan crash, tetapi hanya dicatat.

Jadi pertanyaan saya:
Adakah alasan yang tepat mengapa TypedBinding membuat pengecualian dan tidak mengabaikan target jika dikumpulkan?

Atau mungkin sistem pengikatan itu sendiri harus menangkap semua pengecualian pengikatan dan memungkinkan kami para pengembang untuk menelannya atau bereaksi dengan tepat?

Ini benar-benar bug penting untuk aplikasi produksi kami dan jika diperlukan, saya akan membuat rilis perantara Xamarin.Forms untuk kami yang memperbaikinya. Tetapi untuk itu saya ingin tahu apa efek yang tidak diinginkan dari hal ini!

@bruzkovsky - ini mungkin menarik bagi Anda juga

Selain itu, @StephaneDelcroix @ kingces95 @wachs , saya dapat melihat sebuah bendera
DO_NOT_CHECK_FOR_BINDING_REUSE
Sebenarnya untuk apa ini?

Saya sangat ingin mengkompilasi Xamarin.Forms dengan DO_NOT_CHECK_FOR_BINDING_REUSE disetel ke true untuk menghilangkan bug ini.
Tapi bagaimana proses berpikir di baliknya? Pasti ada alasan bagus untuk menghadirkan bendera ini, bukan?

Ini baru saja terjadi pada saya di ContentPage sederhana dengan ListView dan DataTemplateSelector.
Apakah ada pembaruan tentang masalah ini?
Kenapa saat ini disarankan untuk menggunakan binding terkompilasi jika masalah ini terbuka ??
https://docs.microsoft.com/es-es/xamarin/xamarin-forms/app-fundamentals/data-binding/compiled-bindings

@mrjavicho :

Saya dapat sering mereproduksi masalah dengan sampel ini.
https://github.com/usausa/TypedBindingIssue

Jalankan aplikasi dan klik tombol Test.
Selain itu, jika Anda menghapus komentar di MainPage.Cleanup (), masalah tidak akan terjadi.

Berikut jejak tumpukan yang saya lihat menggunakan kode @usausa . Tidak tahu apakah itu masalah yang sama seperti di atas, tetapi ini jelas merupakan masalah:

    0x16 in Xamarin.Forms.Internals.TypedBinding<TypedBindingIssueApp.View1ViewModel,string>.Apply at D:\a\1\s\Xamarin.Forms.Core\TypedBinding.cs:99,5  C#  Annotated Frame
    0x7 in Xamarin.Forms.Internals.TypedBinding<TypedBindingIssueApp.View1ViewModel,string>.PropertyChangedProxy.<OnPropertyChanged>b__16_0 at D:\a\1\s\Xamarin.Forms.Core\TypedBinding.cs:277,31   C#  Annotated Frame
    0x29 in Xamarin.Forms.DispatcherExtensions.Dispatch at D:\a\1\s\Xamarin.Forms.Core\DispatcherExtensions.cs:53,6 C#  Annotated Frame
    0x3F in Xamarin.Forms.Internals.TypedBinding<TypedBindingIssueApp.View1ViewModel,string>.PropertyChangedProxy.OnPropertyChanged at D:\a\1\s\Xamarin.Forms.Core\TypedBinding.cs:277,5    C#  Annotated Frame
    0x15 in Xamarin.Forms.BindingExpression.WeakPropertyChangedProxy.OnPropertyChanged at D:\a\1\s\Xamarin.Forms.Core\BindingExpression.cs:645,6    C#  Annotated Frame
>   0x14 in TypedBindingIssueApp.NotificationObject.RaisePropertyChanged at C:\Operations\Build\External\TypedBindingIssue\TypedBindingIssueApp\TypedBindingIssueApp\NotificationObject.cs:13,13    C#  Symbols loaded.
    0x5D in TypedBindingIssueApp.LongLifecycleModel.Next at C:\Operations\Build\External\TypedBindingIssue\TypedBindingIssueApp\TypedBindingIssueApp\LongLifecycleModel.cs:19,13    C#  Symbols loaded.
    0x2A in TypedBindingIssueApp.MainPage.Button_OnClicked at C:\Operations\Build\External\TypedBindingIssue\TypedBindingIssueApp\TypedBindingIssueApp\MainPage.xaml.cs:29,17   C#  Symbols loaded.
    0x6 in System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1092,17   C#  Annotated Frame
    0x73 in System.Threading.ExecutionContext.RunInternal at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:968,17   C#  Annotated Frame
    0x4 in System.Threading.ExecutionContext.Run at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:910,13    C#  Annotated Frame
    0x32 in System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1073,25 C#  Annotated Frame
    0x6 in System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation.<>c.<.cctor>b__7_0 at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:379,78  C#  Annotated Frame
    0xC in Android.App.SyncContext. C#  Annotated Frame

Repro sudah tepat! Hal pertama yang saya perhatikan adalah bahwa crash terjadi pada waktu yang benar-benar acak, kadang-kadang menekan tombol beberapa kali dan menunggu, jadi saya mengubahnya sedikit untuk membuatnya crash lebih cepat (secara konsisten setelah 29 entitas):

Naikkan saja acara PC 80 kali seperti ini:
c# for (var i = 0; i < 80; i++) RaisePropertyChanged(nameof(Entity));

Ini menjadwalkan lebih banyak acara ke petugas operator, yang meningkatkan tingkat kegagalan.

Ketika menonaktifkan kompilasi XAML untuk kelas View1 dan View2 , maka ada NullReferenceException dilemparkan di BindingExpression.cs:

Masih mencari solusi sederhana ...