Log Level sa pag-develop ng aplikasyon: ano ito, mga uri ng antas at configuration

Ano ang Log Level?

Log Level — ay isang katangian ng bawat log message na tumutukoy sa kahalagahan at pagka-apura ng pagproseso nito. Ang mga modernong platform na iOS at Android ay sumusuporta sa isang pinag-isang iskala ng 6–7 antas: mula sa pinaka-detalyado (Verbose/Trace) hanggang sa kritikal (Error/Assert). Ang pagpili ng antas ay tumutukoy kung ang mensahe ay isusulat sa log sa kasalukuyang configuration ng aplikasyon.

Ang konsepto ng Log Level ay batay sa prinsipyo ng piramide ng kritikalidad: kung mas mataas ang antas, mas kaunting mensahe ang ipinapakita dito. Ayon sa datos ng Semaphore CI, 2024, sa isang production application ang distribusyon ay ganito: Info — 60% ng mensahe, Warn — 25%, Error — 10%, Debug — 5%. Ang mga mensaheng Verbose ay dapat na ganap na i-disable sa produksyon.

Bawat platform ay nagpapatupad ng Log Level sa pamamagitan ng sarili nitong API. Ang Android ay gumagamit ng android.util.Log na may mga metodong v(), d(), i(), w(), e(). Apple — OSLog na may mga antas na default, info, debug, error, fault. Ang mga library tulad ng Timber at CocoaLumberjack ay nagtatayo ng karagdagang functionality sa ibabaw ng mga standard na API na ito.

Ayon sa datos ng Google I/O 2023, ang maling pagpili ng Log Level ay sanhi ng 40% ng mga problema sa performance sa produksyon. Iniiwan ng mga developer ang Debug log sa release build, na nagiging sanhi ng labis na pagsulat sa disk at pinabilis na pag-discharge ng baterya.

Mga uri ng antas ng logging: mula Verbose hanggang Assert

Verbose (TRACE) — ang pinaka-detalyadong antas, na para lamang sa pag-develop. Sa antas na ito, lahat ng intermediate na kalkulasyon, pag-ulit ng loop, resulta ng bawat hakbang ng algorithm ay ipinapakita. Sa Android, ang antas na ito ay katumbas ng Log.v(), sa iOS — OSLog na may uri na debug (bago ang iOS 14 ay ginamit ang os_trace).

Debug — mga mensahe ng debugging na kapaki-pakinabang sa pag-develop at pag-test. Naglalaman ng impormasyon tungkol sa estado ng mahahalagang object, resulta ng SQL query, parameter ng API call. Hindi tulad ng Verbose, ang Debug message ay nakaayos at semantically makabuluhan. Sa iOS, ang antas na ito ay katumbas ng OSLogType.debug.

Info — mga impormatibong mensahe tungkol sa normal na kaganapan ng aplikasyon: initialization ng SDK, matagumpay na awtorisasyon, pagbubukas ng screen, pagtanggap ng datos mula sa server. Ang Info message ay hindi dapat maglaman ng personal na datos ng mga user at dapat na ligtas para sa pagsusuri sa produksyon. Sa iOS ay ginagamit ang OSLogType.info, sa Android — Log.i().

Warn — mga babala tungkol sa potensyal na problema. Ang aplikasyon ay patuloy na gumagana, ngunit ang sitwasyon ay nangangailangan ng atensyon: laki ng cache malapit sa limitasyon, lumang bersyon ng API, mabagal na tugon ng network, pagsubok muli ng koneksyon. Sa Android — Log.w(), sa iOS — OSLogType.default (para sa mga babala).

Error — mga kritikal na error kung saan ang aplikasyon ay hindi magawa ang hiniling na operasyon, ngunit patuloy na gumagana: bigong kahilingan sa API, pagkawala ng koneksyon, error sa pagsulat sa database, kawalan ng pahintulot. Sa iOS para sa error ay ginagamit ang OSLogType.error, sa Android — Log.e().

Assert (WTF) — ang pinakamataas na antas, na nagpapahiwatig ng sitwasyong “hindi ito maaaring mangyari”. Ginagamit para sa pag-log ng mga bug na lumalabag sa mga pangunahing invariant ng sistema. Sa Android, ang Assert message ay hindi ipinapakita sa release build bilang default. Sa iOS, ang WTF (What a Terrible Failure) ay pinoproseso sa pamamagitan ng OSLogType.fault.

Paggamit ng Log Level sa Android

Android Log API — ang built-in na mekanismo ng logging mula sa package na android.util.Log. Nagbibigay ng 6 na static na metodo: Log.v(), Log.d(), Log.i(), Log.w(), Log.e() at Log.wtf(). Bawat metodo ay tumatanggap ng tag (string na nagpapakilala sa pinagmulan) at msg (teksto ng mensahe).

class UserRepository {
    companion object {
        private val TAG = "UserRepo"
    }

    suspend fun loadUser(id: String): User {
        Log.d(TAG, "Naglo-load ng user na may id: $id")

        return try {
            val response = api.fetchUser(id)
            Log.i(TAG, "Matagumpay na na-load ang user")
            response.toUser()
        } catch (e: Exception) {
            Log.e(TAG, "Hindi na-load ang user: ${e.message}")
            throw e
        }
    }
}

Pag-filter ayon sa antas sa Android Logcat ay ginagawa sa pamamagitan ng ADB: adb logcat *:E ay magpapakita lamang ng Error message. Sa production build, lahat ng tawag sa Log.v() at Log.d() ay tinatanggal ng ProGuard/R8 kapag naka-enable ang minification. Ang Log.i(), Log.w() at Log.e() ay nananatili, kaya mahalaga na huwag maglabas ng sensitibong datos sa pamamagitan ng mga metodong ito.

Para sa custom na pag-filter sa runtime, ang Android ay nagbibigay ng Log.isLoggable(tag, level) — isang metodo na sumusuri kung ang tinukoy na antas ay naka-enable para sa isang partikular na tag. Ito ay nagpapahintulot ng dynamic na pag-enable ng detalyadong logging para sa isang partikular na module nang hindi na kailangang i-rebuild ang aplikasyon.

Paggamit ng Log Level sa iOS at macOS

OSLog — ang pinag-isang sistema ng logging ng Apple, na pumalit sa deprecated na NSLog. Ang OSLog ay nagbibigay ng 5 antas: debug, info, default (notice), error at fault. Ang pangunahing bentahe ay nakabalangkas na logging na may suporta para sa mga naka-format na string at dynamic na pag-filter sa pamamagitan ng console.

import OSLog

let logger = Logger(
    subsystem: "com.example.app",
    category: "network"
)

func fetchData(from url: URL) {
    logger.debug("Starting request to \(url.absoluteString)")

    do {
        let data = try Data(contentsOf: url)
        logger.info("Received \(data.count) bytes")
    } catch {
        logger.error("Request failed: \(error.localizedDescription)")
    }
}

Sistema ng pag-filter ng OSLog ay gumagana sa antas ng operating system. Ang Debug message ay isinusulat lamang kapag nakakonekta ang debugger o kapag naka-enable ang argumentong -com.apple.CoreData.Logging.debug 1. Ang Info message ay kinokolekta sa memorya ng device (hanggang 512 KB) at accessible sa pamamagitan ng Console.app. Ang Error at fault ay isinusulat palagi at available para sa pagkolekta sa pamamagitan ng crash-reporting system.

Mahalagang katangian ng OSLog: mga naka-format na string na may placeholder. Sa halip na string interpolation ng Swift (na palaging kinakalkula, anuman ang antas), ang OSLog ay gumagamit ng os_log format na may %{public}@ at %{private}@ para sa paghihiwalay ng sensitibong datos. Ang private parameter ay naka-mask sa production log.

Produksyon vs Debug: paano i-configure ang pag-filter ng antas

Pangunahing tuntunin — pinakamababang set ng antas sa produksyon: Info, Warn, Error, Assert. Ang Debug at Verbose ay dapat i-disable. Ang dahilan ay hindi gaanong seguridad kundi performance: bawat tawag sa log ay gumagamit ng oras ng CPU para sa pag-format ng string, kahit na hindi ipinapakita ang mensahe.

Tamad na pag-format ng string

Kritikal na optimisasyon — huwag gumamit ng string interpolation sa mga tawag sa log. Kung ang string ay binuo bago ang tawag sa log(), ang oras ng CPU ay nasasayang kahit na naka-disable ang antas. Gumamit ng tamad na pag-format sa pamamagitan ng lambda o guard condition.

Sa Android, ang metodo na Log.isLoggable() ay naglilingkod sa layuning ito, sa OSLog — native na suporta para sa mga naka-format na string na may placeholder. Ang Timber para sa Android ay lumulutas ng problema sa pamamagitan ng timber.log.Tree na may pagsusuri ng antas sa loob ng tree.

Dinamikong pagbabago ng antas habang tumatakbo

Remote Log Level — isang kasanayan kung saan ang antas ng logging ay kinokontrol mula sa server sa pamamagitan ng Firebase Remote Config o katulad na serbisyo. Kung may kumplikadong error na lumitaw sa produksyon, ang developer ay maaaring mag-enable ng Debug logging nang malayuan para sa isang partikular na module sa mga device ng napiling grupo ng mga user.

Ayon sa datos ng Firebase, 2024, ang kasanayang ito ay nagbabawas ng oras ng diagnosis ng mga bihirang bug ng 60% at nagbibigay-daan upang makakuha ng kumpletong larawan ng problema nang hindi nag-i-install ng debug build. Ang pangunahing limitasyon — ang log ay nag-a-activate lamang sa susunod na pagsisimula ng aplikasyon pagkatapos matanggap ang configuration.

Awtomatikong pag-filter ayon sa uri ng build

BuildConfig.DEBUG sa Android at #if DEBUG sa Swift — mga standard na mekanismo ng conditional compilation na nagdi-disable ng debugging level sa release build. Para sa malinis na arkitektura, inirerekomenda na ilipat ang pagpili ng Log Level sa DI container o logger factory, upang hindi mabigatan ang business logic ng mga conditional directive.

Pinakamahuhusay na kasanayan sa pagpili ng antas ng logging

Unang tuntunin — bawat tawag sa log ay dapat sumagot sa tanong na “sinu, ano, kailan”. Sino — component o module (tag sa Android, category sa iOS). Ano — partikular na kaganapan o pagbabago ng estado. Kailan — timestamp, na awtomatikong itinatakda ng sistema ng logging.

Ikalawang tuntunin — huwag mag-log ng sensitibong datos sa pamamagitan ng Info at mas mataas. Mga password, token, email, numero ng telepono, eksaktong geo-coordinate — ay mahigpit na ipinagbabawal sa anumang log na napupunta sa produksyon. Kung kinakailangan, gumamit ng pag-mask: “email: us***@example.com”.

Ikatlong tuntunin — ang antas na Warn ay zone ng responsibilidad ng developer, Error — ng team. Warn ay nangangahulugang “may potensyal na problema dito, bantayan”. Error — “may problema dito, ayusin”. Huwag gamitin ang Error para sa mga sitwasyong inaasahan at napangasiwaan (halimbawa, error sa API 404).

Ikaapat na tuntunin — pagkakapare-pareho. Ang buong proyekto ay dapat gumamit ng pare-parehong kombensyon sa pagpangalan ng tag at kategorya. Inirerekomenda ang ClassName.methodName para sa Android tag at module.subsystem para sa iOS category. Ito ay nagpapahintulot ng mabilis na pag-filter ng log ayon sa component.

Ikalimang tuntunin — subukan ang log. Sa unit test, suriin na sa partikular na senaryo ay tinatawag ang tamang Log Level. Para sa layuning ito, may mga mock logging library: Mockito para sa Android, Cuckoo para sa iOS. Ang pagsusuri ng antas sa pag-test ay pumipigil sa pagtagas ng debugging message sa produksyon.