Domyślnie wygląda na to, że logcat obcina każdy komunikat dziennika, który uzna za „za długi”. Dzieje się tak zarówno w środowisku Eclipse, jak i podczas uruchamiania programu logcat w wierszu poleceń przy użyciu adb -d logcat
i powoduje obcięcie niektórych ważnych komunikatów debugowania.
Czy istnieje sposób na zwiększenie maksymalnej długości ciągu obsługiwanego przez program logcat, aby przestał obcinać informacje debugowania? Z oficjalnej dokumentacji wynika, że może nie być, ale może logcat obsługuje dodatkowe opcje, o których tam nie wspomniano?
Odpowiedzi:
W logcat istnieje bufor o stałym rozmiarze dla dzienników binarnych (
/dev/log/events
), a ten limit wynosi 1024 bajty. W przypadku dzienników niebinarnych istnieje również ograniczenie:Zatem rzeczywisty rozmiar wiadomości dla dzienników binarnych i niebinarnych wynosi ~ 4076 bajtów. Interfejs programu rejestrującego jądro narzuca ten
LOGGER_ENTRY_MAX_PAYLOAD
limit.Źródła liblog (używane przez logcat) również mówią:
Polecam Ci nxlog narzędzie, które nie korzysta z pliku binarnego logcat, ale ze względu na ograniczenia w jądrze wątpię, że będzie rozwiązać problem. Niemniej jednak warto spróbować. (zastrzeżenie: jestem autorem).
źródło
LOGGER_ENTRY_MAX_PAYLOAD
została zmniejszona z 4076 do 4068 w nowszych wersjach Androida (patrz tutaj ).Ok, ciekawe. Byłem rozczarowany, widząc, że odpowiedź brzmiała: „naprawdę nie da się jej rozwinąć”. Moją początkową myślą było to, aby to rozbić, aby móc zobaczyć całość, więc tutaj podzielę się z wami, jak to robię (nie to, że to nic wymyślnego ani nie jest prawie wydajne, ale robi to w mgnieniu oka):
Edytowano, aby pokazać ostatni ciąg!
źródło
int chunkCount = sb.length() / 4000;
Wykorzystanieint chunkCount = sb.length() / 4000; if (chunkCount * 4000 < sb.length()) chunkCount++;
else { Log.v(TAG, sb); }
aby również wydrukować dziennik, gdy wiadomość jest <= 4000 znakówPodziel go rekurencyjnie na kilka części.
źródło
źródło
Oto kod, którego używam - obcina wiersze na granicy 4000, jednocześnie przerywając wiersz w nowych wierszach, a nie w środku wiersza. Ułatwia odczytanie pliku dziennika.
Stosowanie:
Realizacja:
źródło
Poniższy kod jest udoskonaleniem tego, co opublikował Mark Buikema. Zrywa ciąg w nowych wierszach. Przydatne do rejestrowania długich ciągów JSON.
źródło
źródło
nam tę logikę stronicowania
źródło
przedstawię własne podejście do rozwiązania Travisa,
skorzystać z faktu, że
Log.println()
zwraca liczbę zapisanych bajtów, aby uniknąć zakodowania na sztywno „4000”. następnie rekurencyjnie wywołaj swoją część wiadomości, której nie można było zarejestrować, dopóki nic nie zostanie.źródło
Jeśli Twój dziennik jest bardzo długi (np. Rejestrowanie całego zrzutu bazy danych w celu debugowania itp.), Może się zdarzyć, że logcat zapobiega nadmiernemu rejestrowaniu. Aby obejść ten problem, możesz dodać limit czasu co x milisekund.
Uważaj, używaj tego tylko do debugowania, ponieważ może to zatrzymać blokowanie głównego wątku.
źródło
Jak wspomniał @mhsmith,
LOGGER_ENTRY_MAX_PAYLOAD
w najnowszych wersjach Androida jest to 4068. Jeśli jednak użyjesz 4068 jako maksymalnej długości wiadomości we fragmentach kodu oferowanych w innych odpowiedziach, wiadomości zostaną obcięte. Dzieje się tak, ponieważ Android dodaje więcej znaków na początku i na końcu wiadomości, które również się liczą. Inne odpowiedzi wykorzystują limit 4000 jako obejście. Jednak w tym kodzie można naprawdę wykorzystać cały limit (kod generuje tag ze śladu stosu, aby pokazać nazwę klasy i numer linii, która wywołała dziennik, możesz to zmodyfikować):źródło
Nie znam żadnej opcji, aby zwiększyć długość logcat, ale możemy znaleźć różne dzienniki, takie jak dziennik główny, dziennik zdarzeń itp. Dziennik główny zwykle zawiera wszystko, co jego długość dochodzi do 4 MB .. Więc możesz odzyskać utracone dane w terminalu dziennika. Ścieżka to: \ data \ logger.
źródło
Chociaż inne dostarczone rozwiązania były pomocne, nie byłem z nich zadowolony, ponieważ nie obejmowały przypadków, w których dziennik jest dłuższy niż dwa razy dłuższy niż LOGGER_ENTRY_MAX_LEN wspomniany przez @ b0ti. Co więcej, nawet moje poniższe rozwiązanie nie jest idealne, ponieważ LOGGER_ENTRY_MAX_LEN nie jest pobierany dynamicznie. Jeśli ktoś zna sposób na to, chciałbym usłyszeć o tym w komentarzach! W każdym razie jest to rozwiązanie, którego teraz używam w swoim kodzie:
źródło