Verstecke seltsame unerwünschte Xcode-Protokolle

Aufbauend auf dem Original Tweet von @rustyshelf und der illustrierten Antwort von iDevzilla ist hier eine Lösung, mit der das Rauschen des Simulators gedämpft wird, ohne die NSLog-Ausgabe des Geräts zu deaktivieren.

1. Setzen Sie unter Produkt> Schema> Schema bearbeiten ...> Ausführen (Debuggen) die Umgebungsvariable OS_ACTIVITY_MODE auf $ {DEBUG_ACTIVITY_MODE}.

2. Wechseln Sie zu Ihren Projekterstellungseinstellungen, und klicken Sie auf +, um eine benutzerdefinierte Einstellung mit dem Namen DEBUG_ACTIVITY_MODE hinzuzufügen. Erweitern Sie diese Einstellung und klicken Sie auf das + neben Debug, um einen plattformspezifischen Wert hinzuzufügen. Wählen Sie das Dropdown-Menü aus und ändern Sie es in "Beliebiger iOS-Simulator". Dann setzen Sie den Wert auf "disable", so dass es so aussieht:

OS_ACTIVITY_MODE hat bei mir nicht funktioniert , möglicherweise , weil ich disable als disabled getippt habe, aber ist das nicht natürlicher ?! ?), oder zumindest nicht viele Nachrichten verhindert. Hier ist der eigentliche Umgang mit den Umgebungsvariablen.

https://llvm.org/svn/llvm-project/lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp

lldb_private::Error
PlatformDarwin::LaunchProcess(lldb_private::ProcessLaunchInfo &launch_info) {
  // Starting in Fall 2016 OSes, NSLog messages only get mirrored to stderr
  // if the OS_ACTIVITY_DT_MODE environment variable is set.  (It doesn't
  // require any specific value; rather, it just needs to exist).
  // We will set it here as long as the IDE_DISABLED_OS_ACTIVITY_DT_MODE flag
  // is not set.  Xcode makes use of IDE_DISABLED_OS_ACTIVITY_DT_MODE to tell
  // LLDB *not* to muck with the OS_ACTIVITY_DT_MODE flag when they
  // specifically want it unset.
  const char *disable_env_var = "IDE_DISABLED_OS_ACTIVITY_DT_MODE";
  auto &env_vars = launch_info.GetEnvironmentEntries();
  if (!env_vars.ContainsEnvironmentVariable(disable_env_var)) {
    // We want to make sure that OS_ACTIVITY_DT_MODE is set so that
    // we get os_log and NSLog messages mirrored to the target process
    // stderr.
    if (!env_vars.ContainsEnvironmentVariable("OS_ACTIVITY_DT_MODE"))
      env_vars.AppendArgument(llvm::StringRef("OS_ACTIVITY_DT_MODE=enable"));
  }

  // Let our parent class do the real launching.
  return PlatformPOSIX::LaunchProcess(launch_info);
}

Wenn Sie OS_ACTIVITY_DT_MODE in den Umgebungsvariablen auf "NO" setzen (GUI-Methode in der Hauptantwort im Screenshot des Schemas erklärt), funktioniert dies für mich.

Soweit NSLog der Abladeplatz für Systemmeldungen, Fehler und Ihr eigenes Debugging ist: Ein realer Protokollierungsansatz ist wahrscheinlich sowieso erforderlich, z. https://github.com/fpillet/NSLogger .

ODER

Trinken Sie das neue Kool-Aid: http://asciiwwdc.com/2016/sessions/721https://developer.Apple.com/videos/play/wwdc2016/721/ Es ist nicht verwunderlich, dass es nach der Überarbeitung der gesamten Protokollierungs-API einige Probleme gibt.

NACHTRAG

Wie auch immer, NSLog ist nur eine Scheibe:

https://developer.Apple.com/library/content/releasenotes/Miscellaneous/RN-Foundation-OSX10.12/

NSLog/CFLog

NSLog ist jetzt in den meisten Fällen nur ein Shim für os_log.

Nur macht es jetzt Sinn, die Quelle für die andere env-Variable anzugeben. Ziemlich unterschiedlich, diesmal von Apple Interna. Nicht sicher, warum sie sich überschneiden. [Falscher Kommentar zu NSLog entfernt]

[Geändert am 22. September]: Ich frage mich, was "release" und "stream" anders machen als "debug". Nicht genug Quelle.

https://github.com/macosforge/libdispatch/blob/8e63547ea4e5abbfe55c0c3064181c4950a791d3/src/voucher.c

e = getenv("OS_ACTIVITY_MODE");
if (e) {
    if (strcmp(e, "release") == 0) {
        mode = voucher_activity_mode_release;
    } else if (strcmp(e, "debug") == 0) {
        mode = voucher_activity_mode_debug;
    } else if (strcmp(e, "stream") == 0) {
        mode = voucher_activity_mode_stream;
    } else if (strcmp(e, "disable") == 0) {
        mode = voucher_activity_mode_disable;
    }
}

Ein Tweet hatte die Antwort für mich - https://Twitter.com/rustyshelf/status/775505191160328194

Setzen Sie in Ihrem Debug-Schema die Umgebungsvariable OS_ACTIVITY_MODE = disable, um zu verhindern, dass sich der Xcode 8 iOS Simulator wie verrückt anmeldet.

Es funktionierte.

Dies ist in Xcode Version 8.0 Beta 2 (8S162m) für mich immer noch nicht behoben und zusätzliche Protokolle werden auch in der Xcode-Konsole angezeigt

** EDIT 8/1/16: Dies wurde in den Versionshinweisen für Xcode 8 Beta 4 (8S188o) als ein noch bestehendes Problem bestätigt .

Bekannte Probleme in Xcode 8 Beta 4 - IDE

Debuggen

• Xcode Debug Console zeigt beim Debuggen von Anwendungen im Simulator eine zusätzliche Protokollierung von System-Frameworks an. (27331147, 26652255)

Voraussichtlich wird dies mit der Veröffentlichung von GM behoben. Bis dahin ist Geduld und zwar nicht ideal, aber ein Workaround, den ich benutze, ist unten ...

Ähnlich wie bei der vorherigen Antwort muss ich:

• meinen Druckprotokollen ein Sonderzeichen voranstellen (zB * oder ^ oder! etc etc)

• Verwenden Sie dann das Suchfeld unten rechts im Konsolenfenster, um meine Konsolenprotokolle zu filtern, indem Sie mein ausgewähltes Sonderzeichen eingeben, damit die Konsole meine Druckprotokolle wie vorgesehen anzeigt

Bitte finden Sie die folgenden Schritte.

1. Wählen Sie Produkt => Schema => Schema bearbeiten oder verwenden Sie die Tastenkombination: CMD + <
2. Wählen Sie die Option Run von der linken Seite aus.
3. Fügen Sie im Abschnitt Umgebungsvariablen die Variable hinzu. OS_ACTIVITY_MODE = disable

Weitere Informationen finden Sie in der unten stehenden GIF-Darstellung.

Meine Lösung besteht darin, den Debugger-Befehl und/oder Log Message in zu verwenden Haltepunkte.

Und ändern Sie die Ausgabe der Konsole von Alle Ausgabe zu Debugger-Ausgabe wie

In Ordung. Es scheint viel Aufregung um dieses zu geben, also gebe ich euch eine Möglichkeit, es ohne diesen Schema-Trick beizubehalten. Ich werde den iOS-Simulator speziell ansprechen, aber dies muss möglicherweise auch für den TV-Sim angewendet werden, der sich in einem anderen Verzeichnis befindet.

Das Problem, das all diese Dinge verursacht, sind Plists im Xcode-Verzeichnis. Es gibt einen Prozess, der beim Start mit configd_sim gestartet wird, der die Plists einliest und Debugging-Informationen ausgibt, wenn die Plists angeben, dass sie protokolliert werden sollen.

Die Plisten befinden sich hier:

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Preferences/Logging/Subsystems

Wenn Sie mit einer Beta herumspielen, beachten Sie, dass das Verzeichnis anders ist.

In diesem Verzeichnis sehen Sie zahlreiche Plisten. Erstellen Sie nun Ihre Anwendung, führen Sie sie aus und beobachten Sie die Protokolle. Sie suchen nach dem Inhalt, unmittelbar gefolgt von dem Teilsystem : . Es ist der unmittelbar darauf folgende Name, der für die entsprechende problematische Liste steht.

Ändern Sie von dort aus entweder die Plist, um den Debugging-Schlüssel/Wert [Level] auszuschalten, der ein Wörterbuch mit dem Schlüssel/Wert "Enable" => "Default" ist, oder löschen Sie einfach die Plist. Beachten Sie, dass Sie als Root angemeldet sein müssen, um eine dieser Aktionen ausführen zu können, da sich diese in der Xcode-Anwendung befinden.

der Befehl plutil -p könnte auch für Sie von Nutzen sein. d.h.

plutil -p /Applications/Xcode.app/Contents/Developer/Platforms/AppleTVSimulator.platform/Developer/SDKs/AppleTVSimulator.sdk/System/Library/Preferences/Logging/Subsystems/com.Apple.BackBoardServices.fence.plist

Dies gab mir eine der problematischen Plisten, die enthielten:

{ "DEFAULT-OPTIONS" => { "Level" => { "Enable" => "Default" }}}

Viel Glück :]

Dies hängt mit einem bekannten Problem bei der Protokollierung zusammen, das in den Xcode 8 Beta-Versionshinweisen (wurde auch von einem Techniker bei WWDC befragt) gefunden wurde.

Beim Debuggen von WatchOS-Anwendungen im Watch-Simulator führt das Betriebssystem möglicherweise zu einer übermäßigen Anzahl nicht hilfreicher Protokollierungen. (26652255)

Derzeit ist keine Problemumgehung verfügbar. Sie müssen auf eine neue Version von Xcode warten.

EDIT 05.07.16: Dies soll ab Xcode 8 Beta 2 behoben sein:

Behoben in Xcode 8 Beta 2 - IDE

Debuggen

• Beim Debuggen einer App im Simulator werden Protokolle angezeigt. (26457535)

Xcode 8 Beta 2 Versionshinweise

Dies ist kein Problem mehr in xcode 8.1 (getestete Version 8.1 Beta (8T46g)) . Sie können die Umgebungsvariable OS_ACTIVITY_MODE aus Ihrem Schema entfernen.

https://developer.Apple.com/go/?id=xcode-8.1-beta-rn

Debuggen

• Xcode Debug Console zeigt keine zusätzliche Protokollierung von System-Frameworks mehr an, wenn Anwendungen im Simulator debuggt werden. (26652255, 27331147)

In Xcode 10 deaktiviert die Variable OS_ACTIVITY_MODE mit dem Wert disable (oder default) auch den Wert NSLog, egal was passiert.

Wenn Sie also das Konsolenrauschen, aber nicht Ihre eigenen Protokolle entfernen möchten, können Sie das gute alte printf("") anstelle des NSLog verwenden, da es nicht vom OS_ACTIVITY_MODE = disable betroffen ist.

Aber sehen Sie sich besser die neue os_log API an hier .

Diese Lösung hat bei mir funktioniert:

1. Führen Sie die App im Simulator aus
2. Öffnen Sie das Systemprotokoll (⌘ + /)

Dadurch werden alle Debug-Daten und auch Ihre NSLogs gelöscht.

So filtern Sie nur Ihre NSLog-Anweisungen:

1. Stellen Sie jedem ein Symbol voran, zum Beispiel: NSLog(@"^ Test Log")
2. Filtern Sie die Ergebnisse mithilfe des Suchfelds oben rechts, im obigen Fall "^"

Das sollten Sie bekommen: