Xamarin.forms: [خطأ] InvalidOperationException في TypedBinding`2 [TSource، TProperty]. تطبيق

mfeingol إذا كنت قادرًا على تضييق نطاق هذا الأمر ، هل يمكنك من فضلك إرفاق مشروع صغير يوضح هذه المشكلة؟ شكر!

سأحاول القيام بذلك في نهاية هذا الأسبوع ، ولكن هذا النوع من الصعب إعادة إنتاجه عند الطلب. أي أدلة من جانبك ، بناءً على فهمك للكود؟

يبدو أن هذا مرتبط بربط XAML باستخدام نوع البيانات.

أنا أسافر الآن ، ولكن fwiw كان الحل المؤقت الخاص بي هو تعطيل الارتباطات المترجمة.

mfeingol حسنًا ، هذا يبدو صحيحًا. إذا سنحت لك فرصة ، فيرجى تقديم عينة من المشروع لمساعدتنا في تضييق نطاق المشكلة. شكر!

أرى هذه المشكلة نفسها على كل من iOS و Android. أنا لا أستخدم الارتباطات المترجمة.

مشكلة AppCenter:

TypedBinding 2[TSource,TProperty].Apply (System.Boolean fromTarget) TypedBinding 2 + PropertyChangedProxy [TSource، TProperty].b__16_0 ()
خيط + RunnableImplementor.Run ()
IRunnableInvoker.n_Run (System.IntPtr jnienv ، System.IntPtr native__this)
(طريقة الغلاف الديناميكي) System.Object.26 (intptr ، intptr)

مشروع نماذج Xamarin ، صفحة Xaml مع ViewModel - تحتوي الشبكة على ScrollView - ScrollView يحتوي على ملصقات. بسيط جدا.

samhouts : لقد إظهار المشكلة في نموذج التطبيق. ومع ذلك ، لديّ إعادة إنتاج بنسبة 100٪ في تطبيق الإنتاج الخاص بي.

هل يمكنني منح شخص ما في فريقك أذونات لمشروع Azure DevOps حتى يتمكن من إعادة إنتاج المشكلة؟

shneuvil في microsoft.com

أنت في: https://dev.azure.com/sideroads/Sideroads

خطوات Repro:

1. git checkout 6698-repro والإصدار. قد تحتاج إلى إضافة الدليل الخارجي إلى قائمة أدلة NuGet لالتقاط حزمة.
2. قم بتشغيل التطبيق وإنشاء رحلة جديدة من صفحة الرحلات. قم بتسمية الرحلة بشيء مثل "اختبار" واترك جميع الإعدادات الافتراضية باستثناء تحديد المغادرة والوصول والمطارات (مثل SEA و LAS).
3. اضغط على الرحلة لتحديدها.
4. من قائمة الهامبرغر ، انتقل إلى صفحة الطقس ، وتأكد من ظهور تقارير الطقس للمواقع ذات الصلة.
5. انتقل إلى الإعدادات ، وقم بتغيير مزود الطقس من NWS إلى HERE.
6. ارجع إلى صفحة الطقس. يجب أن ترى تحطمًا بسرعة كبيرة. يجب إعادة فتح التطبيق في صفحة الطقس ، وتحديث الطقس ، وإنشاء عطل آخر.

إذا لم تتمكن من إجراء مثل هذه الرحلة البسيطة لسبب ما ، فسوف أقوم بتصدير رحلة أكثر تعقيدًا لك مع المزيد من المواقع.

@ PureWeen : اسمحوا لي أن أعرف إذا كان هذا لا يعمل من أجلك.

mtirona : فاتني تعليقك سابقًا ، آسف. من الغريب أنك ترى هذا دون استخدام روابط مجمعة. لا أفترض أن لديك مشروع إعادة تشغيل بسيط يتسبب في حدوث الانهيار عند الطلب؟

mfeingol تظهر هذه المشكلة بشكل عشوائي داخل تطبيقنا. ليس لديّ وسيلة بسيطة لإعادة إنشائها عند الطلب - لدي مئات الأعطال في AppCenter لتوثيق المشكلة. سأكون ممتنًا لأي توجيهات حول كيفية منع المشكلة ...

mtirona : هل أنت متأكد بنسبة 100٪ أنك لا تستخدم x: DataType في أي مكان في XAML؟

mfeingol كان هناك x: DataType في الصفحات

أنا متأكد من خمسة وتسعة من أن هذا مرتبط بـ XamlC ، إلا إذا قمت بإنشاء TypedBindings في التعليمات البرمجية الخاصة بك (تلك _ فقط_ التي تم إنشاؤها بواسطة مترجم Xaml)

ملاحظة جانبية: لقد كنت في Xamarin Forms 3.6 ، وقد قمت للتو بالتحديث إلى الإصدار 4.1. عند تشغيل تطبيقي لأول مرة ، رأيت على الفور هذا التعطل أثناء إضافة عناصر بسرعة إلى صفحة عرض قائمة مجمعة. لذلك لا تزال المشكلة موجودة مع 4.1.0.618606.

PureWeen : لقد قمت بتحديث خطوات repro أعلاه للإشارة إلى فرع يمكنك الخروج منه والذي يجب أن يعيد حل المشكلة على الفور.

mfeingol هل يمكنك القيام بذلك من أجلي؟

إذا لم تتمكن من إجراء مثل هذه الرحلة البسيطة لسبب ما ، فسوف أقوم بتصدير رحلة أكثر تعقيدًا لك مع المزيد من المواقع.

لقد جربت خطواتك ولم يتحطم شيء من أجلي

حسنًا ، mfeingol لست متأكدًا من كيفية أو سبب

يستخدم TypedBindings WeakReference إلى BindableObject ، لذلك إذا كان الشيء الوحيد الذي يشير إلى BindableObject ، فسوف يفقد هذا المرجع.

ها هو الرمز الذي يتعطل
ج #
إذا (! _weakTarget.TryGetTarget (خارج الهدف))
رمي InvalidOperationException () الجديد ؛

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;

وإذا فعلت ذلك فلن يحدث الانهيار.

تفكيري هو أنه بطريقة ما تصل بياناتك إلى مكان يكون فيه الشيء الوحيد الذي يشير إلى مثيل LocationDayWeatherViewModel المرتبط بـ ViewCell هو TypeBinding وهذا كل شيء. ما زلت لم أتتبع ما إذا كان هذا استثناءً من جانبنا ضدك. هل يمكنك التأكد من أنك تحتفظ بمرجع إلى جميع LocationDayWeatherViewModel الذي تم إنشاؤه والمرتبط بـ ListView؟

شكرا للنظر في هذا! لقد كان من الصعب جدًا إعادة إنتاج هذه المشكلة خارج التطبيق الكامل ، لذا فمن المنطقي أنها ستكون شيئًا يتضمن مراجع ضعيفة. أتساءل عما إذا كانت إضافة ضغط الذاكرة إلى نموذج أبسط قد يؤدي إلى نفس المشكلة.

على أي حال ، ستكون المرة الوحيدة التي لا يتم فيها الإشارة إلى مثيل LocationDayWeatherViewModel بواسطة نموذج العرض أثناء تحديث يوم الطقس ، حيث يمسح الرمز مجموعة ObservableCollection المقيدة للعناصر قبل إدراج عناصر جديدة. يحدث هذا في عمق ExpandableGroupCollectionViewModel.Refresh في حالة رغبتك في تعيين بت في الثانية.

ومع ذلك ، أعتقد أن مسح مجموعة ObservableCollection المقيدة يجب أن تكون عملية آمنة ، وليس من الواضح بالنسبة لي سبب استخدام ارتباطات XF لمراجع ضعيفة. يبدو أن هذا النوع من السباق سيكون بالضبط.

جانبا: حاولت نسخ العناصر الموجودة في this في قائمة مؤقتة قبل المقاصة في Refresh ، ولكن من المدهش أن هذا لا يبدو أنه يعمل على حل المشكلة. لقد أشرت إلى القائمة الموجودة في نهاية الطريقة للتأكد من أن GC لم تقم بإيقافها أيضًا. أعتقد أن هذا سيكون منطقيًا إذا كان XF يحاول استخدام الربط القديم "لاحقًا" ، ويقترح أنه لا توجد طريقة جيدة لتطبيق ما لتثبيت المراجع المرتبطة. لكن ربما أكون قد أسيء فهم الأشياء.

(ونعم ، رمز الطقس / الموسع خارج عن السيطرة قليلاً. أتمنى أن يكون لدى XF عنصر تحكم المتوسع الأصلي ...)

أعتقد أن إضافة ضغط الذاكرة أو مجرد الاتصال بـ GC.Collect قد يعيد إنشاء المشكلة في مشروع أصغر. قد يحدث ذلك أيضًا بسبب تنظيم OnPropertyChanged في TypedBinding إلى مؤشر ترابط واجهة المستخدم

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

لذا وبوضوح أفكر في ما يمكن أن يحدث

PropertyChanged قائمة الانتظار على UI Thread
واضح
GC
WeakReference يفقد المرجع
PropertyChanged يحل الآن ويطرح استثناءً

ربما يتعلق الأمر بهذه المشكلة؟
https://github.com/xamarin/xamarin-android/issues/2049

قد يكون لدى StephaneDelcroix بعض الأفكار الإضافية في هذه المرحلة :-)

كان لدي القليل من وقت الفراغ الليلة الماضية ، وحاولت إضافة GC.Collect() بعد المكالمة إلى Clear() في نسبي المبسط. لسوء الحظ ، لم أتمكن من إعادة إنتاج المشكلة بهذه الطريقة.

هل انتظرت النهائيات المعلقة؟

نحن نفعل ذلك على هذا النحو في اختباراتنا فقط لنكون متأكدين تمامًا
https://github.com/xamarin/Xamarin.Forms/blob/a76db1407a76fccbf487425db1bca5d15f925127/Xamarin.Forms.Controls.Issues/Xamarin.Forms.Controls.Issues.Shared/Helpers/GarbageColcsion#

هذه حقا دعوة جيدة. لكن للأسف ، حتى بعد ذلك ، لا يؤدي Clear() إلى حدوث إعادة تعيين.

لذا أخذ خطوة للوراء ... كيف يجب أن يعمل هذا؟ إذا كان الربط يحتوي على مرجع ضعيف ، فيمكن أن يكون هذا الكائن بحكم التعريف GC. هذا شيء ، حسنًا ، يمكن أن يحدث ، ولا ينبغي أن يطرح XF استثناءً لا يمكن الوصول إليه. بدلاً من ذلك ، من المحتمل أن يتجاهل إشعار PropertyChanged ويثق في أن التطبيق يعرف ما يفعله. أعني ، ماذا يمكنها أن تفعل أيضًا؟

هل يمكنك إرفاق repro الذي تستخدمه لمحاولة إعادة إنشائه؟

سوف أرفق الرمز الليلة. إنه في الأساس repro داخل التطبيق الذي رأيته بالفعل ، تم استخراجه في تطبيق مستقل. لكني لم أر المشكلة في داخلها بعد.

TypedBindingCrashes.zip

@ PureWeen : أي شيء آخر يمكنني القيام به للمساعدة في تشخيص هذا؟

mfeingol ليس في الوقت الحالي ما لم تحصل على أي أفكار حول كيفية إعادة طرح التطبيق المستقل. من الصعب بعض الشيء تقليله في الأكبر ، لذا سنكون أبطأ قليلاً في حل هذا.

هل من الممكن أن نفكر في هذا من خلال المفاهيم ، كما ذكرت في https://github.com/xamarin/Xamarin.Forms/issues/6698#issuecomment -519359760؟ أم لا تزال هناك قطع مفقودة حول سبب المشكلة بالفعل؟

لدي نفس المشكلة ولا يمكنني أيضًا إعادة إنتاج ذلك بسهولة) -:

ysmoradi : لا أعتقد أنك قادر على تحميل repro بسيط؟

من الصعب التكاثر حتى في تطبيق الإنتاج الخاص بي!

لديّ نسخة في الإنتاج أيضًا ، ولكن وفقًا لـ PureWeen من الصعب عليهم فهم المشكلة دون وصف أبسط. لقد حاولت وفشلت في إنتاج واحدة. :-(

أعتقد أنه من الجيد أن يكون لديك اسم الخاصية + اسم نوع العرض + اسم نوع سياق الربط في رسالة الاستثناء ، حتى نتمكن من الحصول على رؤى أفضل.

أواجه نفس المشكلة بالضبط ، iOS و Android ، باستخدام أشكال xamarin 4.2.0.709249.
لدي ListView باستخدام DataTemplate لتصور الكائنات المحددة في xaml الخاص بي.
لقد تم تعيين نوع البيانات على صفحة xaml ثم على صفحة مختلفة في قائمة بيانات listview.

لست مضطرًا إلى الاتصال بمسح أو استبدال أو أي شيء في القائمة التي ألزم بها ، يبدو أنه يكفي الاتصال بـ GC.Collect وانتظار طريقة أخرى لإعطائي الخطأ أعلاه. (إذا لم يكن لدي GC.Collect ، فإنه نادرًا ما يفشل ، ولكنه يحدث من حين لآخر ، حيث يتم تحميل المكالمة بنجاح ، لكنه يفشل عند التحديث.)

ومع ذلك ، فقد وجدت شيئًا مثيرًا للاهتمام ، إذا قمت بإزالة الربط بين طريقة العرض الخاصة بي. يكون مشغولًا في عرض القائمة. يزول تحديث الخطأ ، (لكن مؤشر التحديث يستمر في العمل بعد السحب للتحديث بالطبع).

أيضًا ، إذا قمت بإزالة نوع البيانات من صفحة المحتوى ، وقمت بتعيينه فقط على قالب البيانات ، فسيختفي الخطأ أيضًا ، ويمكنني استخدام الربط في قائمة العرض IsRefresing.

لتلخيص ما أحتاجه في تطبيق الإنتاج الخاص بي لإعادة الإنتاج:

1. قم بتعيين DataType في ContentPage
2. قم بتعيين الربط على IsRefreshing في ListView
3. احصل على مكالمة GC.Collect تليها انتظار Task.Delay (250) ؛ في الطريقة المرتبطة بـ RefreshCommand listview

shoyheim : هل لديك نسخة بسيطة يمكنك نشرها هنا؟

shoyheim : هل لديك نسخة بسيطة يمكنك نشرها هنا؟

mfeingol آسف ، لقد كنت أختبر /

shoyheim : هل سبق لك أن حظيت بأي حظ في هذا؟

تضمين التغريدة
لا آسف ، لقد حاولت ، ولكن كلما قمت بعمل نسخة بسيطة ، لا يمكنني جعلها تتعطل ، لكن تطبيق الإنتاج الخاص بي يستمر في الانهيار والتعطل.
الآن قمت بإزالة جميع الارتباطات المترجمة واستخدمت روابط وقت التشغيل في ملفات xaml الخاصة بي ، واختفت الأعطال.
لقد قضيت الكثير من الوقت في محاولة اكتشاف الخطأ الذي يحدث ، والشيء الوحيد الذي أتأكد منه هو أن هناك صلة بين استخدام ListView مع ربط على "isRefreshing" لإظهار متى يتم تحديث القائمة ، واستخدام الارتباطات المترجمة ... يبدو أيضًا أن الأعطال تحدث في وقت قريب من وقت جمع القمامة.

1- تغيير خاصية سياق الربط (عرض النموذج).
2- نحن ننظر إلى البوب ​​حتى يتم تدميره.
3- يتم استدعاء GC.

1. Binding.Apply يتم استدعاءه ويحاول الوصول إلى الكائنات المطلوبة التي اختفت لذا فإنه يرمي InvalidOperationException.
   قد تسأل لماذا يتم تنفيذ الخطوة 4 في وقت متأخر؟ لأنه تم استدعاؤه في Device.BeginInvokeOnMainThread ، وسيتم إضافة هذا الإجراء إلى نهاية قائمة قائمة انتظار إجراءات سلسلة الرسائل الرئيسية.
   لقد تمكنت من التعامل مع هذا الاستثناء من خلال توفير PlatformServices المخصصة لـ xf ولم يعد هناك أي عطل بعد الآن ، ولكنه يطرح استثناءً أكثر من 800 مرة! لجميع عمليات الربط المكتوبة تقريبًا للصفحة التالفة

ysmoradi : قضيت بعض الوقت في محاولة إعادة إنتاج خطواتك ، ولم أتمكن من إطلاق أي أعطال. لا أفترض أن لديك مشروع عينة.

لقد قلت من قبل أنه ليس لدي أي إعادة شراء بسيطة وأنه يحدث في تطبيق الإنتاج الخاص بي ، كما يحدث بشكل عشوائي.
في المرة الأولى التي بدأت فيها إنشاء الريبو ، لم أكن على دراية بالعديد من الأشياء ، لكن غدًا سأحاول إنشاء واحد آخر باستخدام افتراضاتي الجديدة.
نصائح أخرى قد تساعد: استنادًا إلى افتراضاتي ، يؤدي تمكين GC المتزامن إلى زيادة فرصة إعادة إنتاج الانهيار. لأنه يمكن أن يجمع الكائنات في سلسلة منفصلة. نحتاج أيضًا إلى تغيير خاصية نموذج العرض في سلسلة رسائل / مهمة منفصلة لأن Device.BeginInvokeOnMainThread يمرر الإجراء إلى نهاية قائمة انتظار سلاسل الرسائل الرئيسية فقط عندما يتم استدعاؤه في سلسلة رسائل أخرى غير السلسلة الرئيسية.
حاول مرة أخرى وأخبرني إذا وجدت شيئًا ، وسأحاول غدًا.

لدي GC متزامن ممكّن. باستخدام اقتراحاتك ، يقوم مقتطف الشفرة الذي أستخدمه بهذا:

            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 هي خاصية في الصفحة 1 ، يتم تنفيذها باستخدام BindableProperty. تستخدم الصفحة 1 الارتباطات المترجمة.

لم يحالفنا الحظ بعد.

الحصول على نفس المشكلة بشكل عشوائي هنا أيضًا في تطبيق الإنتاج الخاص بي. بعد المرور بالعملية الشاقة لإعداد x: نوع البيانات في كل مكان كما هو موصى به في إرشادات الأداء ، لا يمكنني القول إنني مسرور لإزالتها جميعًا بسبب هذه المشكلة.

سوف أقوم بتحديث هذا باستخدام تطبيق repro إذا كان بإمكاني إدارة تشغيل واحد.

ملاحظة: أشك في أن هذا مرتبط ، ولكن يبدو أنني بدأت في رؤية المشكلة فقط بعد أن بدأت أيضًا في استخدام التنسيقات المضغوطة. ربما صدفة لأن القضية عشوائية للغاية ، لكن من يدري.

لقد قمت للتو بتحديث تطبيقي إلى MVVM باستخدام الارتباطات المجمعة والحصول على نفس الخطأ الآن.
تشغيل أحدث Xamarin. النماذج: 4.2.0.848062

مع التكوين التالي:

ليس لديك أيضًا خطوات repro (هذا الإصدار من التطبيق في مرحلة تجريبية ليوم واحد ولدي بالفعل تقريرين عبر AppCenter حول هذا الموضوع).
يمكن مشاركة مستودع التطبيق ، ولكن بدون خطوات repro ، أعتقد أنه لن يساعد كثيرًا.

قد لا أفهم الصورة بأكملها ، لكن أليس الحل السهل لذلك هو ببساطة إلغاء التطبيق والعودة عندما يحصل الهدف على GCed ، كما هو الحال بالفعل بدون DO_NOT_CHECK_FOR_BINDING_REUSE في TypedBinding.cs؟ لا أرى كيف أن الرمي فكرة جيدة هنا.

fmanseau : لدي نفس الرأي. تضمين التغريدة

إذا كان ذلك مفيدًا أيضًا ، فيبدو أن هناك مشكلة متعلقة بهذا في repo لـ Prism تحتوي على خطوات إعادة بروز (تتطلب تطبيق Prism ، ولكن من السهل اتباع نمط مشابه بدونه)

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

StephaneDelcroix @ kingces95wachs
يبدو أنكم تقفون وراء تطبيق TypedBinding .

كما ترى في هذا الموضوع ، فإن العديد من المطورين هناك (بما فيهم أنا) يتعرضون للتعطل في تطبيقاتهم بين الحين والآخر بسبب InvalidOperationException طرحه TypedBinding .
يبدو أن samhouts محقة في افتراضها ، أنه بعد دخول GC وإزالة target من TypedBinding (كما هو الحال على الأرجح في تطبيقنا ، حيث لدينا ListView مع العديد من DataTemplates ) ، TypedBinding يرمي InvalidOperationException الذي لم يتم اكتشافه مطلقًا ويؤدي إلى تعطل التطبيق على Android (وربما أي نظام أساسي آخر ؟؟) مثله:

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]. تطبيق (نظام منطقي من الهدف)
TypedBinding`2 + PropertyChangedProxy [TSource، TProperty].b__16_0 ()
خيط + RunnableImplementor.Run ()
IRunnableInvoker.n_Run (System.IntPtr jnienv ، System.IntPtr native__this)
(طريقة الغلاف الديناميكي) Android.Runtime.DynamicMethodNameCounter.43 (intptr ، intptr)

الآن يسأل mfeingol بشكل معقول عن سبب وجود InvalidOperationException الذي يتسبب في هذا الانهيار بعد كل شيء. أعني أنه من الناحية المفاهيمية لم يكن مسموحًا بجمع الهدف من القمامة ، فلماذا تستخدم مرجعًا ضعيفًا؟

أنا نفسي مطور WPF منذ .NET 3.0 وأعلم أن الاستثناءات الملزمة لم تتسبب في حدوث عطل ، ولكن تم تسجيلها فقط.

لذا سؤالي:
هل هناك أي سبب وجيه يجعل TypedBinding يطرح استثناء ولا يتجاهل الهدف فقط إذا تم جمعه؟

أو ربما يجب على نظام الربط نفسه أن يلتقط جميع الاستثناءات الملزمة ويسمح لنا للمطورين بابتلاعها أو التصرف بشكل مناسب؟

هذا حقًا خطأ مهم لتطبيق الإنتاج الخاص بنا وإذا لزم الأمر ، سأقوم بإنشاء Xamarin وسيط إصدار نماذج لنا يعمل على إصلاح هذا. لكن من أجل ذلك أريد أن أعرف ما هي الآثار غير المرغوب فيها التي قد تحدث!

bruzkovsky - قد يكون هذا مفيدًا لك أيضًا

علاوة على ذلك ، StephaneDelcroix @ kingces95wachs ، يمكنني رؤية العلم
DO_NOT_CHECK_FOR_BINDING_REUSE
ما هذا بالضبط؟

أرغب في تجميع نماذج Xamarin مع تعيين DO_NOT_CHECK_FOR_BINDING_REUSE على true للتخلص من هذا الخطأ.
ولكن ما هي عملية التفكير وراء ذلك؟ يجب أن يكون هناك سبب وجيه لوجود هذا العلم ، أليس كذلك؟

لقد حدث هذا لي في ContentPage بسيط مع ListView و DataTemplateSelector.
هل هناك أي تحديث حول هذه المشكلة؟
كيف يوصى حاليًا باستخدام الارتباطات المترجمة إذا كانت هذه المشكلة مفتوحة ؟؟
https://docs.microsoft.com/es-es/xamarin/xamarin-forms/app-fundamentals/data-binding/compiled-bindings

mrjavicho : هل هناك فرصة لنشر مشروع بسيط يعيد إنتاج المشكلة باستمرار؟

تمكنت من إعادة إنتاج المشكلة بشكل متكرر مع هذه العينة.
https://github.com/usausa/TypedBindingIssue

قم بتشغيل التطبيق وانقر فوق الزر اختبار.
أيضًا ، إذا قمت بإزالة التعليق في MainPage.Cleanup () ، فلن تحدث المشكلة.

هذا هو تتبع المكدس الذي أراه باستخدام كودusausa . لا يمكنني معرفة ما إذا كانت نفس المشكلة المذكورة أعلاه ، لكنها بالتأكيد مشكلة:

    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

ريبرو على الفور! أول ما لاحظته هو أن الانهيار يحدث في أوقات عشوائية تمامًا ، وأحيانًا يضغط على الزر عدة مرات وينتظر ، لذلك قمت بتعديله قليلاً لجعله يتعطل عاجلاً (باستمرار بعد 29 عنصرًا):

فقط قم برفع حدث الكمبيوتر الشخصي 80 مرة مثل هذا:
c# for (var i = 0; i < 80; i++) RaisePropertyChanged(nameof(Entity));

يؤدي هذا إلى جدولة المزيد من الأحداث للمرسل ، مما يزيد من معدل الفشل.

عند تعطيل تجميع XAML للفئتين View1 و View2 ، فسيكون هناك NullReferenceException طرحه في BindingExpression.cs:

لا يزال البحث عن حل بسيط ...