In C-derivativen Sprachen gibt es die Möglichkeit, bedingten Code für Debug und Runtime zu haben. Auf diese Weise gibt es keinen Overhead in der Laufzeit.
Wie würde ich das mit Java / Android und den Log.i-Anweisungen machen? Wenn ich nur einen konstanten globalen boolean debugOn verwende, der offensichtlich die redundanten Checks in der Laufzeit hinterlässt.
Was ist der beste Ansatz für bedingte Log-Anweisungen ?
Vielen Dank
BEARBEITEN:
Da es einige Kommentare gibt, die der angenommenen Antwort folgen, poste ich meine Schlussfolgerung hier ....
%Vor%... genau wie in xCode:)
Android Build System hat vor einiger Zeit eine Konstante BuildConfig.DEBUG zur Verfügung gestellt, also schlage ich vor sie zu benutzen und den Code so zu schreiben:
Es werden keine redundanten Prüfungen durchgeführt, da es eine Konstante ist. Dieser Code wird auch vom Compiler optimiert, aber Sie haben auch ProGuard zur Verfügung. Selbst wenn die Kontrollen vorhanden sind, sollten mögliche Auswirkungen auf die Leistung vernachlässigbar sein.
Dieser Ansatz hatte den Nachteil, dass Sie diese Konstante entweder manuell oder über eine benutzerdefinierte Regel in der Build-Datei selbst bearbeiten mussten. Jetzt wird dies jedoch automatisch vom Build-System übernommen, so dass Sie nichts selbst tun müssen.
Erstellen Sie Ihre eigene Log-Klasse, indem Sie die Log-Klasse erweitern, die statische Variable debugLevel darin erstellen, eigene Methoden und Bezeichnungen wie INFO, DEBUG usw. erstellen.
ändert jetzt den Wert von static varable debugLevel und spiegelt die gesamte Anwendung wider.
also keine Notwendigkeit für (Debug) überall.
Java hat keine C-ähnliche bedingte Kompilierung, es sei denn, Sie implementieren es selbst. (Es ist nicht so schwierig, aber IMO ist es nicht die Mühe wert.)
Ihre Möglichkeiten sind ziemlich begrenzt. Das Beste, was Sie tun können, ist teure Protokollierungsanweisungen in ein isLoggable zu packen.
Bei kurzen Log-Anweisungen ist es mehr Rauschen als es wert ist.
Bearbeiten Malcolm könnte Recht haben (obwohl ich mich wahrscheinlich immer noch nicht darum kümmern würde.)
Bearbeiten Der Vergleich mit einem statischen DEBUG ist immer noch im Byte-Code; ProGuard sollte die unnötige Verzweigung entfernen. Ohne ProGuard wäre es die JIT oder die Compiler-Implementierung.