قراءة بلغات أخرى: الإنجليزية البرتغالية 中文

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

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

المشكلة

إذا كنت تريد اتباع المثال، فابدأ باستنساخ هذا المستودع: https://github.com/flounder4130/debugger-example

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

في تطبيق المثال الخاص بنا، يحدث العطل عند النقر فوق الزر الزر N. ومع ذلك، ليس من السهل العثور على الكود المسؤول عن هذا الإجراء:

دعونا نرى كيف يمكننا استخدام مصحح الأخطاء للعثور عليه.

نقاط توقف الطريقة

تتمثل ميزة نقاط توقف الطريقة على نقاط توقف الأسطر في أنه يمكن استخدامها في التسلسلات الهرمية الكاملة للفئات. كيف يكون هذا مفيدًا في حالتنا؟

إذا نظرت إلى مثال المشروع، سترى أن جميع فئات الإجراءات مشتقة من واجهة الإجراء بطريقة واحدة: الأداء ().

سيؤدي تعيين نقطة توقف للطريقة على طريقة الواجهة هذه إلى تعليق التطبيق في كل مرة يتم فيها استدعاء إحدى الطرق المشتقة. لتعيين نقطة توقف للطريقة، انقر فوق السطر الذي يعلن عن الطريقة.

ابدأ جلسة تصحيح الأخطاء وانقر فوق الزر N. تم تعليق التطبيق على ActionImpl14. الآن نعرف أين يوجد الكود المقابل لهذا الزر.

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

وقفة التطبيق

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

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

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

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

نصيحة: لمزيد من النصائح والحيل مع برنامج الإيقاف المؤقت راجع تصحيح الأخطاء بدون نقاط توقف وDebugger.godMode()

مقالب الموضوع

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

انقر فوق الزر الزر N. أثناء تعطل التطبيق، انتقل إلى IntelliJ IDEA. من القائمة الرئيسية، اختر تشغيل | إجراءات التصحيح | الحصول على تفريغ الموضوع.

استكشف المواضيع المتوفرة على اليسار، وفي AWT-EventQueue ستشاهد سبب المشكلة.

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

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

فهم المشكلة

بغض النظر عن تقنية التصحيح، وصلنا إلى ActionImpl14. في هذه الفئة، كان شخص ما ينوي القيام بالعمل في موضوع منفصل، لكنه خلط بين Thread.start() و Thread.run()، الذي يقوم بتشغيل التعليمات البرمجية في نفس الموضوع مثل رمز الاستدعاء.

يحذرنا المحلل الثابت لـ IntelliJ IDEA من هذا الأمر في وقت التصميم:

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

HotSwap

الآن بعد أن اكتشفنا سبب الخطأ، دعونا نصحح المشكلة.

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

فلنفعل ذلك بالطريقة الذكية. أولاً، قم بإصلاح الكود باستخدام الإصلاح السريع المقترح:

بعد أن يصبح الكود جاهزًا، انقر فوق تشغيل | إجراءات التصحيح | إعادة تحميل الفئات التي تم تغييرها. يظهر بالون يؤكد وصول الرمز الجديد إلى الجهاز الافتراضي.

دعنا نعود إلى التطبيق ونتحقق. النقر على الزر N لم يعد يؤدي إلى تعطل التطبيق.

نصيحة: ضع في اعتبارك أن HotSwap له حدوده. إذا كنت مهتمًا بإمكانيات HotSwap الموسعة، فقد يكون من الجيد إلقاء نظرة على الأدوات المتقدمة مثل DCEVM أو JRebel

ملخص

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

آمل أن تجد التقنيات الموضحة مفيدة. اسمحوا لي أن أعرف ما هو رأيك!

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

• Debugger.godMode() – اختراق تطبيق JVM باستخدام المصحح
• استكشاف أخطاء مصحح الأخطاء البطيء وإصلاحها
• ما الخطأ في createDirectories()؟ - دليل لملف تعريف وحدة المعالجة المركزية
• تصحيح الأخطاء بدون نقاط توقف

ترقبوا المزيد!