In anderen Sprachen lesen: Englisch Español 中文
Es gibt viele Debugger-Tutorials, in denen Sie lernen, wie Sie Zeilenhaltepunkte festlegen, Werte protokollieren oder Ausdrücke auswerten. Während dieses Wissen allein viele Tools zum Debuggen Ihrer Anwendung bereitstellt, können reale Szenarien etwas komplexer sein und einen fortgeschritteneren Ansatz erfordern.
In diesem Artikel erfahren Sie, wie Sie ohne große Designkenntnisse Codes finden, die ein Einfrieren der Benutzeroberfläche verursachen, und fehlerhafte Codes in Echtzeit beheben.
Wenn Sie folgen möchten, klonen Sie zunächst dieses Repository: https://github.com/flounder4130/debugger-example
Angenommen, Sie haben eine komplexe Anwendung, die abstürzt, wenn Sie eine Aktion ausführen. Sie wissen, wie Sie den Fehler reproduzieren können, aber die Schwierigkeit besteht darin, dass Sie nicht wissen, welcher Teil des Codes für diese Funktionalität verantwortlich ist.
In unserer Beispiel-App tritt der Ruhezustand ein, wenn Sie auf die Schaltfläche N klicken. Allerdings ist es nicht so einfach, den für diese Aktion verantwortlichen Code zu finden:
Mal sehen, wie wir den Debugger verwenden können, um es zu finden.
Der Vorteil von Methoden-Breakpoints gegenüber Zeilen-Breakpoints besteht darin, dass sie über gesamte Klassenhierarchien hinweg verwendet werden können. Wie nützlich ist das in unserem Fall?
Wenn Sie sich das Beispielprojekt ansehen, werden Sie feststellen, dass alle Aktionsklassen mit einer einzigen Methode von der Action-Schnittstelle abgeleitet werden: perform().
Durch das Festlegen eines Methodenhaltepunkts für diese Schnittstellenmethode wird die Anwendung immer dann angehalten, wenn eine der abgeleiteten Methoden aufgerufen wird. Um einen Methodenhaltepunkt festzulegen, klicken Sie auf die Zeile, die die Methode deklariert.
Starten Sie die Debugger-Sitzung und klicken Sie auf Schaltfläche N. Die Anwendung wird in ActionImpl14 angehalten. Jetzt wissen wir, wo sich der Code befindet, der dieser Schaltfläche entspricht.
Obwohl wir uns in diesem Artikel auf die Fehlersuche konzentrieren, kann diese Technik auch viel Zeit sparen, wenn Sie verstehen möchten, wie etwas in einer großen Codebasis funktioniert.
Der Ansatz mit Methodensperrpunkten funktioniert gut, basiert jedoch auf der Annahme, dass wir etwas über die übergeordnete Schnittstelle wissen. Was ist, wenn diese Annahme falsch ist oder wir diesen Ansatz aus einem anderen Grund nicht verwenden können?
Nun, wir können das auch ohne Haltepunkte machen. Klicken Sie auf Schaltfläche N und gehen Sie bei gesperrter Anwendung zu IntelliJ IDEA. Wählen Sie im Hauptmenü Ausführen | Debugging-Aktionen | Programm pausieren.
Die Anwendung wird angehalten, sodass wir den aktuellen Status der Threads auf der Registerkarte Threads & Variablen überprüfen können. Dadurch erhalten wir einen Überblick darüber, was die Anwendung gerade tut. Da es gesperrt ist, können wir die Sperrmethode identifizieren und sie auf den Ort des Anrufs zurückführen.
Dieser Ansatz hat einige Vorteile gegenüber einem traditionelleren Thread-Dump, auf die wir in Kürze eingehen werden. Es stellt beispielsweise auf komfortable Weise Informationen zu Variablen bereit und ermöglicht die Steuerung der weiteren Programmausführung.
Hinweis: Weitere Tipps und Tricks mit Programm anhalten finden Sie unter Debug ohne Haltepunkte und Debugger.godMode().
Schließlich können wir einen Thread-Dump verwenden, der nicht unbedingt eine Debugger-Funktion ist. Es ist unabhängig davon verfügbar, ob Sie den Debugger verwenden oder nicht.
Klicken Sie auf die Schaltfläche N. Gehen Sie zu IntelliJ IDEA, während die Anwendung gesperrt ist. Wählen Sie im Hauptmenü Ausführen | Debugging-Aktionen | Thread-Dump abrufen.
Schauen Sie sich die verfügbaren Threads auf der linken Seite an und unter AWT-EventQueue sehen Sie, was das Problem verursacht.
Der Nachteil von Thread-Dumps besteht darin, dass sie nur eine Momentaufnahme des Programmstatus zum Zeitpunkt der Erstellung liefern. Sie können Thread-Dumps nicht verwenden, um Variablen zu untersuchen oder die Programmausführung zu steuern.
In unserem Beispiel müssen wir nicht auf einen Thread-Dump zurückgreifen. Ich möchte diese Technik jedoch dennoch erwähnen, da sie in anderen Fällen nützlich sein kann, beispielsweise wenn Sie versuchen, eine Anwendung zu debuggen, die ohne den Debug-Agenten gestartet wurde.
Unabhängig von der Debugging-Technik kommen wir zu ActionImpl14. In dieser Klasse wollte jemand die Arbeit in einem separaten Thread erledigen, verwechselte jedoch Thread.start() mit Thread.run(), wodurch der Code im selben Thread wie der aufrufende Code ausgeführt wird.
Der statische Analysator von IntelliJ IDEA warnt uns sogar zur Entwurfszeit davor:
Eine Methode, die schwere Arbeit ausführt (oder in diesem Fall viel Schlaf), wird im UI-Thread aufgerufen und blockiert ihn, bis die Methode abgeschlossen ist. Aus diesem Grund können wir in der Benutzeroberfläche einige Zeit lang nichts tun, nachdem wir auf Schaltfläche N geklickt haben.
Da wir nun die Ursache des Fehlers entdeckt haben, können wir das Problem beheben.
Wir könnten das Programm stoppen, den Code neu kompilieren und ihn dann erneut ausführen. Allerdings ist es nicht immer praktisch, die gesamte Anwendung nur für eine kleine Änderung neu zu falten.
Lassen Sie uns dies auf intelligente Weise tun. Korrigieren Sie zunächst den Code mit dem vorgeschlagenen Quick-Fix:
Sobald der Code fertig ist, klicken Sie auf Ausführen | Debugging-Aktionen | Geänderte Klassen neu laden. Es erscheint eine Meldung, die bestätigt, dass der neue Code die VM erreicht hat.
Gehen wir zurück zur App und überprüfen es. Durch Klicken auf die Schaltfläche N stürzt die App nicht mehr ab.
Tipp: Denken Sie daran, dass HotSwap seine Grenzen hat. Wenn Sie an den erweiterten Funktionen von HotSwap interessiert sind, ist es möglicherweise eine gute Idee, einen Blick auf erweiterte Tools wie DCEVM oder JRebel zu werfen.
Mithilfe unserer Überlegungen und einiger Debugger-Funktionen konnten wir den Code finden, der das Einfrieren der Benutzeroberfläche in unserem Projekt verursacht hat. Anschließend korrigieren wir den Code, ohne Zeit mit der Neukompilierung und Neubereitstellung zu verschwenden, was in realen Projekten zeitaufwändig sein kann.
Ich hoffe, dass Sie die beschriebenen Techniken nützlich finden. Teilen Sie mir Ihre Meinung mit!
Wenn Sie an weiteren Artikeln zum Thema Debuggen und Profiling interessiert sind, schauen Sie sich einige meiner anderen Artikel an:
Das obige ist der detaillierte Inhalt vonDebuggen inaktiver Anwendungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
