Logcat — ano ito, antas ng pag-log at paggamit ng mga log

Ano ang Logcat sa Android

Logcat — ay isang system buffer ng Android kung saan ang lahat ng proseso (kabilang ang Linux kernel, system_server at mga application) ay nagsusulat ng mga mensahe sa isang tiyak na format. Ang tool na logcat, na bahagi ng Android SDK, ay nagbabasa ng buffer na ito at nagpapakita ng mga mensahe sa real-time. Simula sa Android 4.1 (API 16), ang pag-access sa Logcat ay limitado: ang mga application ay maaari lamang magbasa ng kanilang sariling mga log, at ang mga system log ay naa-access sa pamamagitan ng ADB na may debug access.

Bawat mensahe ng Logcat ay naglalaman ng limang field: petsa at oras, PID (identifier ng proseso), TID (identifier ng thread), antas ng pag-log, at tag. Ang format ay fixed at pareho para sa lahat ng bersyon ng Android. Ito ay nagpapahintulot sa paggamit ng grep, awk at sed utilities para sa pag-filter ng mga log sa CI/CD pipelines nang walang pag-asa sa IDE.

Ang mga log ay naka-store sa isang circular buffer na may fixed size: 256 KB para sa main, 256 KB para sa system, at 256 KB para sa events (Android 5+). Kapag napuno ang buffer, ang mga lumang mensahe ay tinatanggal. Maaaring baguhin ng developer ang laki ng buffer sa pamamagitan ng PROP logcat.size o sa mga setting ng developer ng device.

Antas ng log at tag: istraktura ng mensahe ng Logcat

Anim na antas ng pag-log ang tumutukoy sa kahalagahan ng mensahe. Gumagamit ang Android ng mga standard na antas na katulad ng iba pang platform, ngunit may sariling mga pangalan ng constant sa klase na Log. Ang pagpili ng tamang antas ay tumutulong sa epektibong pag-filter ng mga log at hindi paglubog ng mga kritikal na mensahe sa mga sekundaryo.

Mga tag: organisasyon ng mga mensahe ayon sa modyul

Tag — isang string hanggang 23 character na nagpapakilala sa pinagmulan ng mensahe. Inirerekomenda na gamitin ang pangalan ng klase o modyul bilang tag: MainActivity, AuthManager, NetworkModule. Ito ay nagpapahintulot sa pag-filter ng mga log ayon sa isang partikular na component ng application. Para sa pagkakapareho sa team, maaaring gumawa ng tag constants sa isang hiwalay na file o gamitin ang library na Timber na awtomatikong naglalagay ng tag batay sa pangalan ng klase.

Crash log at stack trace ng exception

Sa hindi nahawakang exception, ang Android mismo ay nagsusulat sa Logcat ng kumpletong stack trace na may indikasyon ng klase, method, linya ng code, at chain ng tawag. Ang crash log ay naglalaman ng uri ng exception (NullPointerException, RuntimeException), mensahe, at pagkakasunod-sunod ng mga tawag mula sa punto ng pag-crash hanggang sa entry point ng application. Para sa pagsusuri ng mga crash log mula sa mga device ng user, ginagamit ang Firebase Crashlytics na nagsi-sync ng stack trace sa obfuscation map (mapping.txt para sa Android).

Logcat sa Android Studio: interface, filter, at paghahanap

Android Studio ay nagbibigay ng graphical na interface ng Logcat, naa-access sa pamamagitan ng View → Tool Windows → Logcat (Alt + 6). Ang Logcat window ay nag-a-update sa real-time, nagpapakita ng lahat ng mensahe ng konektadong device, at nagpapahintulot sa pag-configure ng mga flexible na filter para ihiwalay ang kinakailangang impormasyon mula sa pangkalahatang daloy.

Pag-filter ayon sa antas at tag

Dropdown list Log Level ay nagsasala ng mga mensahe ayon sa minimum na antas: piliin ang WARN upang makita lamang ang mga babala at error, itinatago ang VERBOSE, DEBUG, at INFO. Ang field na Search ay nagpapahintulot sa paghahanap ayon sa teksto ng mensahe o tag — sumusuporta sa regex, na maginhawa para sa paghahanap ng mga mensahe ayon sa pattern.

Mga naka-save na filter

Saved Filters — isang malakas na feature ng Logcat sa Android Studio. Maaari kang lumikha ng filter na nagpapakita lamang ng mga mensahe na may tag ng iyong application (tag:MyApp) at antas na WARN+. Ang mga filter ay nai-save sa pagitan ng mga session at naa-access mula sa dropdown list. Para sa mga proyektong may maraming modyul, gumawa ng hiwalay na filter para sa bawat modyul.

# Halimbawang expression para sa pag-filter ng mga log ng application
tag:"MyApp" level:WARN # WARN+ lang para sa MyApp
package:"com.mycompany" # Lahat ng log ng package
-tag:"okhttp" # Ibukod ang mga log ng OkHttp

Pag-export at pagsusuri

Ang mga log ng Logcat ay maaaring i-export sa isang text file sa pamamagitan ng icon na Save to File. Ito ay kapaki-pakinabang para sa pag-attach sa mga ticket sa Jira o pagsusuri ng mahabang session. Ang na-export na log ay maaaring buksan sa anumang text editor at ilapat ang grep para sa paghahanap ng mga pattern. Para sa naka-format na view, gamitin ang utility na logcat-color.

ADB logcat: command sa terminal para sa advanced na trabaho

ADB logcat — console version ng Logcat, naa-access sa pamamagitan ng Android Debug Bridge. Ang pangunahing bentahe nito ay ang kakayahang tumakbo sa CI servers, sa automation scripts, at sa mga device na walang Android Studio. Sinusuportahan ng ADB logcat ang lahat ng parehong filter gaya ng GUI, ngunit may flexibility ng command line.

Mga pangunahing command

Ang command na adb logcat na walang argumento ay nagpapakita ng buong buffer sa real-time. Upang huminto, gamitin ang Ctrl+C. Ang flag na -c ay nag-clear ng buffer bago magsimula ng recording — ito ay maginhawa kapag kailangan mong ihiwalay ang mga log ng kasalukuyang test mula sa mga nakaraang mensahe. Ang flag na -b ay pumipili ng uri ng buffer: main, system, events, crash (Android 12+).

# I-clear ang buffer at simulan ang pag-record ng log na may tag na MyApp
adb logcat -c
adb logcat MyApp:D *:S

# I-save ang mga log sa file
adb logcat -d > logcat_dump.txt

# Pag-filter ayon sa PID ng proseso
adb logcat --pid=12345

Pag-filter gamit ang grep at awk

Ang kumbinasyon ng ADB sa unix utilities ay nagbibigay ng maximum na flexibility. Halimbawa, ang filter na "*:S TAG:D" ay nagpapakita lamang ng mga mensahe na may tag na TAG ng antas na DEBUG at mas mataas, itinatago ang lahat ng iba. Upang makita lamang ang Exception, gamitin ang grep -i exception. Para sa pagsusuri ng dalas ng error, ilapat ang sort | uniq -c sa column ng tag.

Logcat sa CI/CD

Sa CI servers, ginagamit ang Logcat para sa pagtitipon ng diagnostics habang tumatakbo ang UI tests. Karaniwang pipeline: bago simulan ang mga test, ang buffer ay nililinis; pagkatapos ng execution ng mga test, ang dump ng mga log ay nai-save bilang build artifact. Kung ang test ay nabigo, batay sa mga log ay maaaring matukoy kung ang kabiguan ay sanhi ng ANR, hindi nahawakang exception, o network timeout.

Pag-log sa code: Log.d, Log.e at Timber

Ang klase na android.util.Log — built-in na API para sa pagsusulat ng mga mensahe sa Logcat. Ang Log.v, Log.d, Log.i, Log.w, Log.e at Log.wtf ay tumatanggap ng tag (string) at mensahe (string) o mensahe + Throwable. Para sa pag-format ng mga mensahe, gamitin ang String.format o Kotlin String templates — iwasan ang concatenation ng string na lumilikha ng karagdagang object sa heap.

Ang library na Timber

Timber — sikat na library ni Jake Wharton na nag-aalis ng mga kakulangan ng built-in na Log API. Awtomatikong naglalagay ang Timber ng tag batay sa pangalan ng klase na tumawag sa pag-log at hindi nangangailangan ng pagpapasa ng tag sa bawat tawag. Sinusuportahan din ng Timber ang conditional logging: sa Release build, ang mga tawag na Timber.v at Timber.d ay maaaring i-disable ng isang linya sa Application.onCreate.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Built-in na Log API
        Log.d("MainActivity", "onCreate called")

        // Timber — awtomatikong tag batay sa pangalan ng klase
        Timber.d("onCreate called")
    }

    private fun loadData() {
        try {
            val result = fetchFromNetwork()
            Timber.i("Data loaded: $result")
        } catch (e: IOException) {
            Timber.e(e, "Failed to load data")
        }
    }
}

Conditional logging para sa Release

Sa Release build, inirerekomenda na i-disable ang VERBOSE at DEBUG log upang mabawasan ang load sa Logcat buffer at maiwasan ang pagtagas ng sensitibong impormasyon. Nilulutas ng Timber ang gawaing ito sa pamamagitan ng PlantingTree: sa Debug flavor ay itinanim ang DebugTree (nagla-log ng lahat), sa Release — CrashReportingTree (nagla-log lamang ng ERROR sa pamamagitan ng Crashlytics). Ang built-in na Log API ay hindi sumusuporta sa conditional logging — ang developer ay kailangang balutin ang bawat tawag sa if (BuildConfig.DEBUG).