A legtöbbet kihozni az APK analizátorból

Wojtek Kaliciński

Follow

nov 23, 2016 – 6 min read

Az Android Studio egyik kedvenc legújabb kiegészítése az APK Analyzer, amelyet a felső menüben a Build → Analyze APK menüpont alatt találsz.

Pro-tipp: Az APK Analyzer segítségével megnyithatja és megvizsgálhatja bármely, a számítógépén lévő APK fájl tartalmát, akár a helyi Android Studio projektből épített, akár a build szerverről vagy más artifact tárolóból szerzett APK fájl tartalmát

. Nem kell, hogy az Android Studio-ban megnyitott projektből épüljön, és nincs szüksége az adott APK forráskódjára sem.

Megjegyzés: Az APK Analyzer legjobban a release buildekkel működik. Ha az alkalmazás debug buildjét kell elemeznie, győződjön meg róla, hogy olyan APK-t használ, amely nincs instrumentálva az azonnali futtatáshoz. Ennek megszerzéséhez használhatja a Build → Build APK parancsot. Az archívumban található instant-run.zip fájl jelenlétének ellenőrzésével láthatja, hogy megnyitott-e egy Instant Run instrumentált APK-t.

Az APK-elemző használata remek lehetőség az APK-fájlok körüljárására és a szerkezetük megismerésére, a fájl tartalmának ellenőrzésére a kiadás előtt, illetve néhány gyakori probléma, például az APK méretével és a DEX-szel kapcsolatos problémák elhárítására.

Az APK-elemző sok hasznos, felhasználható információt adhat az alkalmazás méretéről. A képernyő tetején láthatja a nyers fájlméretet, amely csak az APK lemezen lévő mérete. A Letöltési méret azt mutatja meg, hogy a Play Store által alkalmazott tömörítést figyelembe véve mennyi adatot fog felhasználni az alkalmazás letöltéséhez.

A fájlok és mappák listája a teljes méret szerint csökkenő sorrendben van rendezve. Ezáltal kiválóan alkalmas az APK méretoptimalizálás alacsonyan lógó gyümölcseinek azonosítására. Minden egyes alkalommal, amikor egy mappába fúródik, láthatja azokat az erőforrásokat és egyéb entitásokat, amelyek a legtöbb helyet foglalják az APK-ban.

Resources sorted in downending order according to size

Ebben a példában, amikor egy APK-t vizsgáltam a lehetséges méretcsökkentés szempontjából, azonnal észrevettem, hogy egy 3 képkockás PNG animáció az egyetlen legnagyobb dolog a rajzolható erőforrásaink között, a súlya 1 volt.5 MB, és ez csak az xxhdpi sűrűségű!

Mivel ezek a képek tökéletes jelölteknek tűnnek a vektorként való tárolásra, megkerestük az artwork forrásfájljait, és VectorDrawable-ként importáltuk őket az Android Studio 2.2 Vector Asset importáló eszközének új PSD-támogatásával.

Azzal, hogy ugyanezt a folyamatot elvégeztük a másik fennmaradó animációval (instruction_touch_*.png), és eltávolítottuk ezeket a PNG-fájlokat minden sűrűségben, több mint 5 MB-ot tudtunk megtakarítani. A visszafelé kompatibilitás fenntartása érdekében a VectorDrawableCompat-t használtuk a támogató könyvtárból.

A többi erőforrás mappát átnézve könnyű volt kiszúrni néhány tömörítetlen WAV fájlt, amelyeket OGG-vé lehetett konvertálni, ami még nagyobb megtakarítást jelentett anélkül, hogy egy sor kódhoz is hozzá kellett volna nyúlni.

Az APK egyéb mappáinak böngészése

A következő az ellenőrizendő dolgok listáján a lib/ mappa volt, amely az általunk támogatott három ABI natív könyvtárát tartalmazza.

A döntés az volt, hogy az APK splits támogatást használjuk a Gradle buildünkben, hogy az alkalmazás különálló verzióit hozzuk létre minden egyes ABI-hez.

A következőkben gyorsan átnéztem az AndroidManifest.xml-t, és észrevettem, hogy a <application>-ből hiányzik az android:extractNativeLibs attribútum. Ennek az attribútumnak a hamisra állításával némi helyet takaríthatunk meg az eszközön, mivel megakadályozza a natív könyvtárak kimásolását az APK-ból a fájlrendszerbe. Az egyetlen követelmény, hogy a fájlok oldalra igazítva és tömörítetlenül legyenek tárolva az APK-n belül, amit az Android Gradle plugin 2.2.0+ verziójának új csomagolója támogat.

A teljes AndroidManifest.xml az APK Analyzerben megtekintve

Miután elvégeztem ezeket a módosításokat, kíváncsi voltam, hogy az alkalmazás új verziója hogyan viszonyul az előzőhöz. Ehhez megnéztem a forrást abból a git commitból, amellyel kezdtem, lefordítottam az APK-t, és elmentettem egy másik mappába. Ezután a Compare with… funkciót használtam, hogy megnézzem a régi és az új buildek közötti méretkülönbségeket.

APK összehasonlítás – a jobb felső sarokban lévő gombon keresztül érhető el

Az erőforrások és a natív könyvtárak terén sokat léptünk előre, összesen 17 MB-ot takarítottunk meg, nagyon kevés változtatással az alkalmazásban. Azonban azt látom, hogy a DEX méretünk visszafejlődött, a classes2.dex 400KB-val nőtt.

Debugging DEX issues

Ez esetben a különbség a függőségek újabb verziókra való frissítéséből és új könyvtárak hozzáadásából adódott. A Proguard és a Multidex már engedélyezve volt a buildjeinkhez, így nem sok mindent lehetett tenni a DEX méretünkkel kapcsolatban. Ennek ellenére az APK analizátor egy nagyszerű eszköz az ilyen beállításokkal kapcsolatos problémák hibakeresésére, különösen akkor, ha először engedélyezzük a Multidexet vagy a Proguardot a projektünkhöz.

Az osztályok tartalmának vizsgálata.dex

Ha bármelyik DEX-fájlra kattintasz, egy összefoglaló jelenik meg arról, hogy hány osztályt és metódust definiál, és összesen hány hivatkozást tartalmaz (a hivatkozások számítanak bele a 64K-os korlátba egyetlen DEX-fájlban). Ezen a példaképen az alkalmazás épp most éri el a korlátot, ami azt jelenti, hogy a MultiDexnek a közeljövőben külön fájlokra kell osztania az osztályokat.

A csomagok között lefelé haladva láthatja, hogy melyek használják fel az összes hivatkozást. Ebben az esetben láthatjuk, hogy a Support könyvtár és a Google Play Services a fő okozója ennek a helyzetnek:

Referenciák száma csomagonként

Mihelyt engedélyezte a MultiDexet és lefordította az alkalmazást, észrevehet egy második osztály2.dex fájl (és esetleg classes3.dex, és így tovább). Az Android gradle plugin MultiDex megoldása kitalálja, hogy mely osztályokra van szükség az alkalmazás indításához, és azokat az elsődleges classes.dex fájlba helyezi, de abban a ritka esetben, amikor ez nem működik, és ClassNotFoundException-t kap, az APK Analyzer segítségével megvizsgálhatja a DEX fájlokat, majd kikényszerítheti, hogy a hiányzó osztályok az elsődleges DEX fájlba kerüljenek.

A Proguard engedélyezése és az osztályok vagy metódusok reflexióval vagy XML elrendezésből történő használata esetén hasonló problémákkal fog találkozni. Az APK Analyzer segíthet a Proguard-konfiguráció helyes voltának ellenőrzésében, mivel könnyen ellenőrizheti, hogy a szükséges metódusok és osztályok jelen vannak-e az APK-ban, és hogy át vannak-e nevezve (obfuszkálva). Meggyőződhet arról is, hogy az eltüntetni kívánt osztályok valóban eltávolításra kerültek, és nem veszik el az értékes referenciamódszerek számát.

Kíváncsiak vagyunk, milyen egyéb felhasználási lehetőségeket talál az APK Analyzerre, és milyen egyéb funkciókat szeretne beépíteni az eszközbe!

Szólj hozzá!