Az Android Studio egy olyan hibakeresőt biztosít, amellyel többek között a következőket teheti:

  • Válasszon ki egy eszközt, amelyen az alkalmazást hibakeresni szeretné.
  • Töréspontok beállítása a Java, Kotlin és C/C++ kódban.
  • Változók vizsgálata és kifejezések kiértékelése futásidőben.

Ez az oldal a hibakereső alapvető műveleteire vonatkozó utasításokat tartalmazza. További dokumentációért lásd az IntelliJ IDEA debugging docs-t is.

Enable debugging

A debugging megkezdése előtt a következőképpen kell felkészülnie:

  • Engedélyezze a hibakeresést az eszközén:

    Ha emulátort használ, ez alapértelmezés szerint engedélyezve van. Csatlakoztatott eszköz esetén azonban engedélyeznie kell a hibakeresést az eszköz fejlesztői beállításaiban.

  • Futtasson hibakeresésre alkalmas buildváltozatot:

    Egy olyan buildváltozatot kell használnia, amely tartalmazza a debuggable true-t a buildkonfigurációban. Általában egyszerűen kiválaszthatja az alapértelmezett “debug” változatot, amely minden Android Studio projektben benne van (még ha nem is látható a build.gradle fájlban). De ha új build típusokat definiál, amelyeknek debuggolhatónak kell lenniük, akkor a build típushoz hozzá kell adni a `debuggable true`-t:

    android { buildTypes { customDebugType { debuggable true ... } }}

    Ez a tulajdonság a C/C++ kódot tartalmazó modulokra is vonatkozik. (A jniDebuggable tulajdonságot már nem használjuk.)

    Ha az alkalmazás olyan könyvtári modultól függ, amelyet szintén debuggolni szeretne, akkor azt a könyvtárat is debuggable true-vel kell csomagolni, hogy megtartsa a debug szimbólumait.Annak érdekében, hogy az alkalmazásprojekt debuggolható változatai megkapják egy könyvtári modul debuggolható változatát, győződjön meg róla, hogy a könyvtár nem alapértelmezett verzióit is közzéteszi.

Hibakeresés megkezdése

A hibakeresési munkamenetet a következőképpen indíthatja el:

  1. Állítson be néhány töréspontot az alkalmazás kódjában.
  2. Az eszköztáron válassza ki a céleszköz legördülő menüből az eszközt, amelyen az alkalmazást hibakeresni kívánja.

    Ha nincs beállítva semmilyen eszköz, akkor vagy USB-n keresztül kell csatlakoztatnia egy eszközt, vagy létre kell hoznia egy AVD-t az Android emulátor használatához.

  3. Az eszköztáron kattintson a Debug gombra.

    Ha megjelenik egy párbeszédpanel, amely megkérdezi, hogy “a futtatásról a hibakeresésre akar-e váltani”, az azt jelenti, hogy az alkalmazás már fut az eszközön, és a hibakeresés megkezdéséhez újra kell indítani. Ha inkább az alkalmazás ugyanazon példányát szeretné futtatni, kattintson a Debuggolás leállítása gombra, és helyette csatolja a hibakeresőt egy futó alkalmazáshoz.

    Egyébként az Android Studio elkészít egy APK-t, aláírja azt egy hibakeresési kulccsal, telepíti a kiválasztott eszközre, és futtatja azt. Ha C és C++ kódot ad a projekthez, az Android Studio a natív kód hibakereséséhez az LLDB hibakeresőt is futtatja a Debug ablakban.

  4. Ha a Debug ablak nincs megnyitva, válassza a View > Tool Windows > Debug (vagy kattintson a Debug gombra az eszközablak sávban), majd kattintson a Debugger fülre, ahogy az 1. ábrán látható.

    1. ábra. A Debugger ablak, amely az aktuális szálat és egy változó objektumfáját mutatja

A debugger csatlakoztatása egy futó alkalmazáshoz

Ha az alkalmazás már fut az eszközön, a debuggerelést az alkalmazás újraindítása nélkül is elindíthatja az alábbiak szerint:

  1. Kattintson a Hibakereső csatlakoztatása az Android folyamathoz gombra.
  2. A Folyamat kiválasztása párbeszédpanelen válassza ki azt a folyamatot, amelyhez a hibakeresőt csatolni kívánja.

    Ha emulátort vagy rootolt eszközt használ, bejelölheti az Összes folyamat megjelenítése lehetőséget, hogy az összes folyamatot lássa.

    A Use Android Debugger Settings from legördülő menüből kiválaszthat egy meglévő futtatási/hibakereső konfigurációt. (C és C++ kód esetén ez lehetővé teszi, hogy egy meglévő konfigurációban újra felhasználja az LLDB indítási parancsait, az LLDB utólagos csatolási parancsait és a szimbólumkönyvtárakat.) Ha nincs meglévő futtatási/hibakereső konfiguráció, válassza az Új létrehozása lehetőséget. Ez a kiválasztás bekapcsolja a Debug Type (Hibakeresési típus) legördülő menüt, ahol más hibakeresési típust választhat. Alapértelmezés szerint az Android Studio az Auto debug típus segítségével választja ki a legjobb hibakeresési lehetőséget aszerint, hogy a projekt Java vagy C/C++ kódot tartalmaz.

  3. Kattintson az OK gombra.

    Megjelenik a Debug ablak.

Megjegyzés: Az Android Studio debugger és a szemétgyűjtő lazán integrált. Az Android virtuális gépe garantálja, hogy a debugger által ismert objektumok nem kerülnek szemétgyűjtésre, amíg a debugger meg nem szakítja a kapcsolatot. Ez azt eredményezheti, hogy az objektumok idővel felhalmozódnak, amíg a hibakereső csatlakoztatva van. Ha például a hibakereső lát egy futó szálat, a hozzá tartozó Thread objektumot a hibakereső kapcsolat megszakításáig nem gyűjti be a szemétbe, még akkor sem, ha a szál már befejeződött.

A hibakereső típusának módosítása

Miatt a Java/Kotlin kód és a C/C++ kód hibakereséséhez különböző hibakereső eszközökre van szükség, azAndroid Studio hibakereső lehetővé teszi, hogy kiválassza, melyik hibakereső típust kívánja használni. Alapértelmezés szerint az Android Studi a projektben észlelt nyelvek alapján dönti el, hogy melyik debuggert használja (azAuto debugger típusnál). A hibakereső azonban kézzel is kiválasztható a hibakereső konfigurációban (kattintson a Futtatás > EditConfigurations gombra) vagy a Futtatás > Attach debugger to Androidprocess gombra kattintva megjelenő párbeszédpanelen.

A rendelkezésre álló hibakeresési típusok a következők:

Auto Válassza ezt a hibakeresési típust, ha azt szeretné, hogy az Android Studio automatikusan válassza ki a legjobb lehetőséget a hibakeresés alatt álló kódhoz. Ha például C vagy C++ kód van a projektben, az Android Studio automatikusan a Dual hibakeresési típust használja. Ellenkező esetben az Android Studio a Java hibakeresési típust használja. Java Válassza ezt a hibakeresési típust, ha csak Java vagy Kotlin nyelven írt kódot szeretne hibakeresni – a Java hibakereső figyelmen kívül hagyja a natív kódban beállított töréspontokat vagy megfigyeléseket. Natív (csak C/C++ kóddal elérhető) Válassza ezt a hibakeresési típust, ha csak az LLDB-t szeretné használni a kód hibakereséséhez. Ha ezt a hibakeresési típust használja, a Java hibakeresési munkamenet nézet nem érhető el. Alapértelmezés szerint az LLDB csak a natív kódot vizsgálja, és figyelmen kívül hagyja a töréspontokat a Java kódban. Ha a Java kódját is hibakeresésre szeretné használni, akkor az Auto vagy a Dual hibakeresési típusra kell váltania.

A natív hibakeresés csak a következő követelményeknek megfelelő eszközökön működik:

  • A készülék támogatja a run-as-t.

    Az eszköz run-as támogatásának ellenőrzéséhez futtassa a következő parancsot az eszközéhez csatlakoztatott ADB héjon:

    run-as your-package-name pwd

    A your-package-name helyébe az alkalmazás csomagneve lép. Ha az eszköz támogatja a run-as-t, a parancsnak hiba nélkül kell visszatérnie.

  • Az eszközön engedélyezve van a ptrace.

    Az ptrace engedélyezésének ellenőrzéséhez futtassa a következő parancsot az eszközéhez csatlakoztatott ADB shell-en:

    sysctl kernel.yama.ptrace_scope

    Ha a ptrace engedélyezve van, a parancs a 0 értéket vagy egy unknown key hibát ír ki. Ha a ptrace nincs engedélyezve, akkor a parancs a 0-től eltérő értéket fog kiírni.

Kettős (csak C/C++ kóddal elérhető) Válassza ezt a hibakeresési típust, ha a Java és a natív kód hibakeresése között szeretne váltani. Az Android Studio mind a Java debuggert, mind az LLDB-t az alkalmazás folyamatához csatolja, egyet a Java debuggerhez, egyet pedig az LLDB-hez, így az alkalmazás újraindítása vagy a debugkonfiguráció módosítása nélkül ellenőrizheti a töréspontokat mind a Java, mind a natív kódban.

A 2. ábrán vegye észre a Debug ablak címétől jobbra lévő két fület. Mivel az alkalmazás Java és C++ kódot is tartalmaz, az egyik fül a natív kód hibakeresésére, a másik pedig a Java kód hibakeresésére szolgál, ahogy azt a -java jelzi.

2. ábra. A natív kód hibakeresésére szolgáló lap és a Java kód hibakeresésére szolgáló lap

Megjegyzés: Ha olyan natív kódot hibakeres, amelyet a fordító optimalizált, a következő figyelmeztető üzenetet kaphatja: This function was compiled with optimizations enabled. Some debugger features may not be available. Az optimalizálási zászlók, például a -O zászlók használatakor a fordító módosításokat hajt végre a lefordított kódon, hogy az hatékonyabban fusson. Ez azt eredményezheti, hogy a hibakereső váratlan vagy helytelen információkat jelent, mivel a hibakereső nehezen tudja az optimalizált lefordított kódot visszavezetni az eredeti forráskódhoz. Ezért a natív kód hibakeresése közben tiltsa le a fordítóoptimalizálást.

A rendszernapló használata

A rendszernapló az alkalmazás hibakeresése közben megjeleníti a rendszerüzeneteket. Ezek az üzenetek tartalmazzákaz eszközön futó alkalmazásoktól származó információkat. Ha a rendszernaplót szeretné használni az alkalmazás hibakereséséhez, győződjön meg róla, hogy a kódja naplóüzeneteket ír, és kiírja a kivételek stacktrace-ét, amíg az alkalmazás a fejlesztési fázisban van.

Naplóüzenetek írása a kódban

Ha naplóüzeneteket szeretne írni a kódjában, használja a Log osztályt. A naplóüzenetek segítenek megérteni a végrehajtási folyamatot azáltal, hogy összegyűjtik a rendszer hibakijelzéseit, miközben interakcióba lépsz az alkalmazásoddal. A naplóüzenetekből megtudhatod, hogy az alkalmazásod melyik része sikertelen volt. A naplózással kapcsolatos további információkért lásd: Naplók írása és megtekintése.

A következő példa azt mutatja, hogyan adhat naplóüzeneteket annak meghatározására, hogy a korábbi állapotinformációk rendelkezésre állnak-e a tevékenység indításakor:

A fejlesztés során a kódja elkaphat kivételeket is, és a stack trace-t a rendszernaplóba írhatja:

Megjegyzés: Távolítsa el a hibakeresési naplóüzeneteket és a stack trace nyomtatási hívásokat a kódjából, amikor készen áll az alkalmazás közzétételére. Ezt egy DEBUGflag beállításával és a debug naplóüzenetek feltételes utasításokon belüli elhelyezésével teheti meg.

A rendszernapló megtekintése

A debug és egyéb rendszerüzeneteket a Logcat ablakban megtekintheti és szűrheti. Például láthatja a szemétgyűjtéskor megjelenő üzeneteket, vagy azokat az üzeneteket, amelyeket a Log osztállyal ad hozzá az alkalmazásához.

A logcat használatához indítsa el a hibakeresést, és válassza az alsó eszköztár Logcat lapját a 3. ábrán látható módon.

3. ábra. Logcat ablak szűrőbeállításokkal

A logcat és szűrési lehetőségeinek leírását lásd: Naplók írása és megtekintése a Logcat segítségével.

Munka töréspontokkal

Az Android Studio többféle töréspontot támogat, amelyek különböző hibakeresési műveleteket váltanak ki. A leggyakoribb típus a sor megszakítási pont, amely megállítja az alkalmazás végrehajtását egy megadott kódsoron. Szüneteltetés közben megvizsgálhatja a változókat, kiértékelheti a kifejezéseket, majd soronként folytathatja a végrehajtást a futási hibák okainak megállapítása érdekében.

A sormegszakítási pont hozzáadásához a következőképpen járjon el:

  1. Keresze meg a kód azon sorát, ahol szüneteltetni szeretné a végrehajtást, majd vagy kattintson a bal oldali ereszre a kódsor mentén, vagy helyezze a caretet a sorra, és nyomja le a Control+F8 (Macen a Command+F8) billentyűkombinációt.
  2. Ha az alkalmazás már fut, nem kell frissítenie azt a megállási pont hozzáadásához – csak kattintson a Attach debugger to Android proccess gombra. Ellenkező esetben indítsa el a hibakeresést a Debug gombra kattintva.

3. ábra. Egy piros pont jelenik meg a vonal mellett, ha töréspontot állít be

Amikor a kód végrehajtása eléri a töréspontot,az Android Studio szünetelteti az alkalmazás végrehajtását. Ezután a Hibakereső lap eszközeivel azonosíthatja az alkalmazás állapotát:

  • Az objektumfa vizsgálatához egy változót bontson ki a Változók nézetben. Ha a Változók nézet nem látható, kattintson a Változók nézet visszaállítása gombra.

  • A kifejezés kiértékeléséhez az aktuális végrehajtási ponton kattintson a Kifejezés kiértékelése gombra.

  • A kód következő sorára való továbblépéshez (módszer megadása nélkül) kattintson a Step Over gombra.

  • A metódushíváson belüli első sorra való továbblépéshez kattintson a Step Into .

  • Az aktuális metóduson kívüli következő sorra való továbblépéshez kattintson a Step Out .

  • Az alkalmazás normál folytatásához kattintson a Resume Program gombra.

Ha a projektje natív kódot használ, az Auto debug típus alapértelmezés szerint a Java debuggert és az LLDB-t is két különálló folyamatként csatolja az alkalmazáshoz, így az alkalmazás újraindítása vagy a beállítások módosítása nélkül válthat a Java és a C/C++ töréspontok vizsgálata között.

Megjegyzés: Ahhoz, hogy az Android Studio a C vagy C++ kódban lévő töréspontokat érzékelje, az LLDB-t támogató debug típust kell használnia, például az Auto, Native vagy Dual típusokat. Az Android Studio által használt hibakeresési típus megváltoztatható a hibakeresési konfiguráció szerkesztésével. Ha többet szeretne megtudni a különböző hibakeresési típusokról, olvassa el az egyéb hibakeresési típusok használatáról szóló részt.

Amikor az Android Studio telepíti az alkalmazást a célkészülékre, a hibakeresési ablak minden hibakeresési folyamathoz egy lap vagy hibakeresési munkamenet nézettel nyílik meg, ahogy a 4. ábrán látható.

4. ábra. Natív kód hibakeresése az LLDB használatával

  1. Az Android Studio átvált a <a te modulod> lapra, amikor az LLDB hibakereső töréspontot talál a C/C++ kódodban. A Frames, Variables és Watches panelek is elérhetőek, és pontosan úgy működnek, mintha Java kódot hibakeresne. Bár a Szálak ablaktábla nem érhető el az LLDB munkamenet nézetben, a Frames ablaktábla legördülő listájával elérheti az alkalmazás folyamatait. Ezekről a panelekről többet megtudhat az ablakkeretek hibakereséséről és a változók vizsgálatáról szóló szakaszokban.

    Megjegyzés: A natív kódban lévő töréspont vizsgálata közben az Android rendszer felfüggeszti az alkalmazás Java bytecode-ját futtató virtuális gépet. Ez azt jelenti, hogy a natív kódban lévő töréspont vizsgálata közben nem tud interakcióba lépni a Java debuggerrel, illetve nem tud állapotinformációkat lekérni a Java debugger munkamenetéből.

  2. Az Android Studio átvált a <az ön modulja>-java lapra, amikor a Java debugger töréspontot talál a Java kódjában.
  3. Az LLDB-vel végzett hibakeresés során az LLDB munkamenet nézetben az LLDB terminál segítségével parancssori opciókat adhat át az LLDB-nek. Ha vannak bizonyos parancsai, amelyeket szeretne, hogy az LLDB minden alkalommal futtasson le, amikor elkezdi az alkalmazás hibakeresését, akár közvetlenül a hibakeresőnek az alkalmazás folyamatához való csatlakozása előtt, akár közvetlenül azután, akkor ezeket a parancsokat hozzáadhatja a hibakeresési konfigurációjához.

A C/C++ kód hibakeresése során speciális megszakítási pontokat, úgynevezett watchpointokat is beállíthat, amelyek felfüggeszthetik az alkalmazás folyamatát, amikor az alkalmazás interakcióba lép egy adott memóriablokkal. Ha többet szeretne megtudni, olvassa el a figyelési pontok hozzáadásáról szóló részt.

Töréspontok megtekintése és konfigurálása

Az összes töréspont megtekintéséhez és a töréspont-beállítások konfigurálásához kattintson a Töréspontok megtekintése gombra a Debug ablak bal oldalán. Megjelenik a Töréspontok ablak az 5. ábrán látható módon.

5. ábra. A Töréspontok ablak felsorolja az összes aktuális töréspontot, és tartalmazza az egyes töréspontok viselkedési beállításait

A Töréspontok ablakban a bal oldali listából engedélyezheti vagy letilthatja az egyes töréspontokat. Ha egy töréspont ki van kapcsolva, az Android Studio nem állítja meg az alkalmazást, amikor az adott törésponthoz ér. Válasszon ki egy töréspontot a listából a beállításainak konfigurálásához. Beállíthatja, hogy egy töréspont először le legyen tiltva, és egy másik töréspont elérését követően a rendszer engedélyezze azt. Azt is beállíthatja, hogy a töréspontot ki kell-e kapcsolni, miután azt elérte. Bármely kivételhez megállási pontot állíthat be, ha a megállási pontok listájában kiválasztja a Kivétel megállási pontok lehetőséget.

Debug ablak keretei

A Debugger ablakban a Keretek ablaktábla lehetővé teszi, hogy megvizsgálja azt a veremkeretet, amely az aktuális megállási pont elérését okozta. Így navigálhat és vizsgálhatja a veremkeretet, valamint ellenőrizheti az Android-alkalmazás szálainak listáját is. Egy szál kiválasztásához használja a szálválasztó legördülő menüpontot, és tekintse meg annak veremkeretét. A keretben lévő elemekre kattintva megnyílik a forrás a szerkesztőben. Testreszabhatja a szálak megjelenítését és exportálhatja a veremkeretet is, ahogyan azt az Ablakkeretek útmutatóban tárgyaltuk.

Változók vizsgálata

A Debugger ablakban a Változók ablaktábla lehetővé teszi a változók vizsgálatát, amikor a rendszer megállítja az alkalmazást egy törésponton, és kiválaszt egy keretet a Keretek ablaktáblából. A Változók ablaktábla segítségével ad-hoc kifejezéseket is kiértékelhet a kiválasztott keretben rendelkezésre álló statikus módszerek és/vagy változók segítségével.

A Megfigyelések ablaktábla hasonló funkciókat biztosít, azzal a különbséggel, hogy a Megfigyelések ablaktáblához hozzáadott kifejezések a hibakeresési munkamenetek között is megmaradnak. Olyan változókhoz és mezőkhöz érdemes megfigyeléseket hozzáadni, amelyekhez gyakran hozzáfér, vagy amelyek az aktuális hibakeresési munkamenet szempontjából hasznos állapotot biztosítanak. A Változók és a Megfigyelések panelek az 5. ábrán látható módon jelennek meg.

Ha változót vagy kifejezést szeretne hozzáadni a Megfigyelések listához, kövesse a következő lépéseket:

  1. Kezdje meg a hibakeresést.
  2. A Figyelések ablaktáblán kattintson a Hozzáadás gombra.
  3. A megjelenő szövegmezőbe írja be a megfigyelni kívánt változó vagy kifejezés nevét, majd nyomja le az Enter billentyűt.

Ha el szeretne távolítani egy elemet a Megfigyelések listából, jelölje ki az elemet, majd kattintson az Eltávolítás gombra.

A Megfigyelések listában lévő elemeket átrendezheti, ha kijelöl egy elemet, majd a Felfelé vagy a Lefelé gombra kattint.

6. ábra. A változók és a megfigyelések ablaktáblák a Debugger ablakban

Megfigyelési pontok hozzáadása

A C/C++ kód hibakeresése során speciális típusú megszakítási pontokat, úgynevezett megfigyelési pontokat állíthat be, amelyek felfüggeszthetik az alkalmazás folyamatát, amikor az alkalmazás kölcsönhatásba lép egy adott memóriablokkal. Ha például két mutatót állít be egy memóriablokkhoz, és ehhez rendel egy megfigyelési pontot, akkor bármelyik mutató használata az adott memóriablokk eléréséhez kiváltja a megfigyelési pontot.

Az Android Studio-ban futás közben létrehozhat megfigyelési pontot egy adott változó kiválasztásával, de az LLDB a megfigyelési pontot csak ahhoz a memóriablokkhoz rendeli hozzá, amelyet a rendszer az adott változóhoz rendel, magához a változóhoz nem. Ez eltér a változó hozzáadásától a Figyelempontok ablaktáblához, amely lehetővé teszi egy változó értékének megfigyelését, de nem teszi lehetővé az alkalmazás folyamatának felfüggesztését, amikor a rendszer kiolvassa vagy megváltoztatja a változó értékét a memóriában.

Megjegyzés: Amikor az alkalmazásfolyamata kilép egy függvényből, és a rendszer felszabadítja a helyi változókat a memóriából, újra hozzá kell rendelnie az ezekhez a változókhoz létrehozott megfigyelési pontokat.

A megfigyelési pont beállításához a következő követelményeknek kell megfelelnie:

  • A fizikai céleszköz vagy emulátor x86 vagy x86_64 CPU-t használ. Ha az eszköz ARM CPU-t használ, akkor a változó memóriában lévő címének határát 32 bites processzorok esetén 4 bájtra, 64 bites processzorok esetén 8 bájtra kell igazítania. A változót a natív kódban a változó lassításában a __attribute__((aligned(num_bytes))) megadásával tudja igazítani, az alábbiak szerint:
    // For a 64-bit ARM processorint my_counter __attribute__((aligned(8)));
  • Három vagy annál kevesebb figyelési pontot már hozzárendelt. Az Android Studio csak legfeljebb négy figyelési pontot támogat x86 vagy x86_64 céleszközökön. Más eszközök kevesebb megfigyelési pontot támogathatnak.

Megjegyzés: 32 bites ARM ABI-vel rendelkező alkalmazás hibakeresése esetén a megfigyelési pont hozzáadása vagy a kódon belüli változók felett való lebegés az értékeik vizsgálatához összeomlást okozhat. Megoldásként kérjük, hogy 64 bites ARM, x86 vagy x86_64 binárisokkal végezzen hibakeresést. Ez a probléma egy következő Android Studio kiadásban javításra kerül.

Ha megfelel a fenti követelményeknek, a következőképpen adhat hozzá megfigyelési pontot:

  1. Mialatt az alkalmazás egy törésponton van felfüggesztve, navigáljon az LLDB munkamenet nézetben a Változók ablaktáblára.
  2. Kattintson a jobb gombbal egy olyan változóra, amely a nyomon követni kívánt memóriablokkot foglalja, és válassza a Figyelőpont hozzáadása parancsot. Megjelenik a 7. ábrán látható párbeszédpanel a megfigyelési pont konfigurálásához.

    7. ábra. Megfigyelési pont hozzáadása egy változóhoz a memóriában

  3. Konfigurálja a megfigyelési pontot a következő beállításokkal:
    • Engedélyezve: Ezt az opciót letilthatja, ha azt szeretné, hogy az Android Studio egyelőre figyelmen kívül hagyja a megfigyelési pontot. Az Android Studio továbbra is elmenti a figyelési pontot, így később a hibakeresési munkamenetben elérheti azt.
    • Felfüggeszteni: Alapértelmezés szerint az Android rendszer felfüggeszti az alkalmazás folyamatát, amikor az hozzáfér egy megfigyelési ponthoz rendelt memóriablokkhoz. Ha nem szeretné ezt a viselkedést, törölheti a jelölőnégyzetet – ez további lehetőségeket tár fel, amelyekkel testre szabhatja a viselkedést, amikor a rendszer kölcsönhatásba lép a megfigyelési pontjával: Log message to console (Üzenet naplózása a konzolra) és Remove when hit (Eltávolítás ütközéskor).
    • Hozzáférés típusa: Válassza ki, hogy az alkalmazás akkor indítsa-e el a megfigyelési pontját, amikor megpróbál olvasni vagy írni a rendszer által a változónak kiosztott memóriablokkba. Ha a figyelési pontot olvasáskor vagy íráskor szeretné elindítani, válassza a Bármelyik lehetőséget.
  4. Kattintson a Kész gombra.

Az összes megfigyelési pont megtekintéséhez és a megfigyelési pont beállításainak konfigurálásához kattintson a Megszakítási pontok megtekintése gombra a hibakeresési ablak bal oldalán. Megjelenik a Töréspontok párbeszédpanel a 8. ábrán látható módon.

8. ábra. A Töréspontok párbeszédpanel felsorolja az aktuális megfigyelési pontokat, és tartalmazza az egyes megfigyelési pontok viselkedési beállításait

Miután hozzáadta a megfigyelési pontot, kattintson a Program folytatása gombra a Debug ablak bal oldalán az alkalmazás folyamatának folytatásához. Alapértelmezés szerint, ha az alkalmazás olyan memóriablokkhoz próbál hozzáférni, amelyhez megfigyelési pontot állított be, az Android rendszer felfüggeszti az alkalmazás folyamatát, és egy megfigyelési pont ikon jelenik meg az alkalmazás által utoljára végrehajtott kódsor mellett, amint az a 9. ábrán látható.

9. ábra. Az Android Studio jelzi az alkalmazás által közvetlenül a figyelési pont kiváltása előtt végrehajtott kódsort

Erőforrásértékek megjelenítési formátumának megtekintése és módosítása

A hibakeresési módban megtekintheti az erőforrásértékeket, és más megjelenítési formátumot választhat a Java-kódban lévő változókhoz. A Változók lap megjelenítésével és egy keret kijelölésével tegye a következőket:

  1. A Változók listában kattintson a jobb gombbal bárhol egy erőforrássorra a legördülő lista megjelenítéséhez.
  2. A legördülő listában válassza a Nézet mint lehetőséget, és válassza ki a használni kívánt formátumot.

    A rendelkezésre álló formátumok a kiválasztott erőforrás adattípusától függnek. A következő lehetőségek közül egy vagy több is megjelenhet:

    • Class: Az osztály definíciójának megjelenítése.
    • toString: String formátum megjelenítése.
    • Object: Az objektum (egy osztály példánya) definíciójának megjelenítése.
    • Tömb: Tömb formátumban történő megjelenítés.
    • Időbélyeg: A dátum és az idő megjelenítése a következőképpen: yyyy-mm-dd hh:mm:ss.
    • Auto: Az Android Studio az adattípus alapján választja ki a legjobb formátumot.
    • Bináris: Bináris érték megjelenítése nullákat és egyeseket használva.
    • MeasureSpec: A szülőből a kiválasztott gyermeknek átadott érték. Lásd MeasureSpec.
    • Hex: Hexadecimális értékként való megjelenítés.
    • Primitív: Megjelenítés numerikus értékként egy primitív adattípust használva.
    • Integer: Megjelenítés numerikus értékként a Integer típus szerint.

Egyéni formátumot (adattípus renderelőt) hozhat létre az alábbiak szerint:

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.