عرض مراجع كائن Flex

Question

لدي القليل من مشكلة تسرب الذاكرة في تطبيق Flex الخاص بي ، والنسخة القصيرة من سؤالي هي: هل هناك أي طريقة (في Acitonscript 3) للعثور على جميع الإشارات المباشرة إلى كائن معين؟

ما لدي هو عدد من المشاهدات مع نماذج العرض التقديمي وراء كل منها (باستخدام SWIZ). وجهات نظر الاهتمام هي أطفال tabnavigator ، لذلك عندما أغلق علامة التبويب ، تتم إزالة العرض من المسرح. عندما تتم إزالة العرض من المرحلة ، يقوم Swiz بتعيين مرجع النموذج في العرض إلى NULL ، كما ينبغي. أنا أيضا إزالة removeallchildren () من العرض.

ومع ذلك ، عند التنميط بالتطبيق ، عندما أقوم بذلك وأشغيل GC ، لا يتم تحرير عرض العرض ولا نموذج العرض التقديمي (على الرغم من أن كلاهما يضعان مراجعهما على بعضهما البعض على الفرق). يتم تحرير كائن نموذج واحد يستخدمه العرض (وليس مقدمًا ، رغم ذلك) ، لذلك ليس مكسورًا تمامًا.

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

هتافات.

Answer 1

على افتراض أنك تستخدم Flex Builder ، يمكنك تجربة Profiler. في تجربتي ، ليس من الجيد جدًا تحديد الأداء ، ولكنه كان مفيدًا للعثور على تسرب الذاكرة.

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

لا أعرف أي برامج تعليمية جيدة لـ FB Profiler ، لكن ربما سيساعد هذا في البدء.

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

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

أهم الأرقام هي "حالات تراكمية" و "مثيلات". الأول هو العدد الإجمالي للحالات التي تم إنشاؤها حتى الآن ؛ والثاني ، عدد الحالات المذكورة التي لا تزال على قيد الحياة. لذا ، فإن نقطة البداية الجيدة هي الحصول على تطبيقك إلى الحالة التي تشك في أن يتم إنشاء التسريبات. يجب أن ترى 1 لـ "مثيلات تراكمية" و "مثيلات".

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

الآن ، إذا انخفض عدد "الحالات" لك عرضه إلى 0 ، فلا يوجد تسرب هناك. إذا كنت تعتقد أن التطبيق يتسرب ، فحاول العثور على كائنات أخرى ربما لم يتم التخلص منها بشكل صحيح. إذا بقي العدد في 1 ، فهذا يعني أن وجهة نظرك قد تم تسريبها. الآن ، عليك أن تجد لماذا وأين.

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

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

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

أتمنى أن يساعدك هذا.

Answer 2

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

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

هجيت
Back2dos

Answer 3

أيضا استدلال مفيدة للعثور على تسرب الذاكرة: http://www.tikalk.com/flex/solving-memory-leaks-using-flash-builder-4-profiler