APK-analysaattorin hyödyntäminen

Wojtek Kaliciński

Follow

23. marraskuuta, 2016 – 6 min luettu

Yksi suosikkini viimeaikaisista lisäyksistä Android Studioon on APK Analyzer, joka löytyy ylävalikosta kohdasta Build → Analyze APK.

Pro-vinkki: voit myös vetää ja pudottaa APK-tiedostoja editoriin avataksesi ne

APK Analyzerin avulla voit avata ja tutkia minkä tahansa tietokoneellasi olevan APK-tiedoston sisällön, joka on joko rakennettu paikallisesta Android Studio -projektistasi tai hankittu rakennuspalvelimelta tai muusta artefaktivarastosta. Sitä ei tarvitse rakentaa mistään Android Studiossa avoinna olevasta projektista, etkä tarvitse kyseisen APK-tiedoston lähdekoodia.

Huomautus: APK Analyzer toimii parhaiten julkaisuversioiden kanssa. Jos haluat analysoida sovelluksesi debug-buildin, varmista, että käytät APK:ta, jota ei ole instrumentoitu Instant Runia varten. Voit hankkia sen Build → Build APKkomennolla. Voit nähdä, oletko avannut Instant Run -instrumentoidun APK:n tarkistamalla, että arkiston sisällä on instant-run.zip-tiedosto.

APK-analysaattorin käyttäminen on hyvä tapa penkoa APK-tiedostoja ja tutustua niiden rakenteeseen, tarkistaa tiedostojen sisältö ennen julkaisua tai vianmääritykseen joissakin yleisissä ongelmissa, mukaan lukien APK:n koko- ja DEX-ongelmat.

APK-analysaattorista saat paljon hyödyllistä, käyttökelpoista tietoa sovelluksen koosta. Näytön yläreunassa näkyy Raw File Size, joka on vain APK:n koko levyllä. Latauskoko näyttää arvion siitä, kuinka paljon dataa käytetään sovelluksesi lataamiseen, kun otetaan huomioon Play-kaupan soveltama pakkaus.

Luettelo tiedostoista ja kansioista on lajiteltu kokonaiskoon mukaan alenevaan järjestykseen. Tämän ansiosta se sopii erinomaisesti APK-koon optimoinnin matalalla roikkuvien hedelmien tunnistamiseen. Joka kerta kun porautuu kansioon, näkee resurssit ja muut kokonaisuudet, jotka vievät eniten tilaa APK:ssa.

Resurssit lajiteltuna alenevaan järjestykseen koon mukaan

Tässä esimerkissä tutkiessani APK:ta mahdollisten koon pienentämismahdollisuuksien etsimistä havaitsin saman tien, että 3-kehyksinen PNG-animaatio on piirtokelpoisten resurssiemme yksittäinen isoin yksittäinen olio, painaen 1:llä.5 Mt, ja se on vain xxhdpi-tiheydellä!

Koska nämä kuvat näyttävät täydellisiltä ehdokkailta vektoreina tallentamiseen, löysimme taideteoksen lähdetiedostot ja toimme ne VectorDrawables-tiedostoina käyttäen Android Studion 2.2:n Vector Asset -tuontityökalun uutta PSD-tukea.

Käymällä läpi saman prosessin toiselle jäljelle jääneelle animaatiolle (ohje_kosketus_s*.png) ja poistamalla nämä PNG-tiedostot kaikilla tiheyksillä pystyimme säästämään yli viisi Mt. Yhteensopivuuden säilyttämiseksi taaksepäin käytimme tukikirjastosta löytyvää VectorDrawableCompat-tiedostoa.

Katsellessamme muita resurssikansioita oli helppo havaita joitakin pakkaamattomia WAV-tiedostoja, jotka voitiin muuntaa OGG:ksi, mikä merkitsi vieläkin suurempaa säästöä ilman, että jouduttiin koskemaan koodiriviinkään.

Apk:n muiden kansioiden selaaminen

Seuraavana tarkistettavien asioiden listalla oli lib/-kansio, joka sisältää natiivit kirjastot kolmelle tukemallemme ABI:lle.

Päätöksemme oli käyttää APK splits -tukea Gradle-rakennuksessamme luodaksemme sovelluksesta erilliset versiot kullekin ABI:lle.

Katsoin seuraavaksi nopeasti AndroidManifest.xml:n läpi ja huomasin, että <application>:sta puuttuu attribuutti android:extractNativeLibs. Asettamalla tämän attribuutin arvoksi false voidaan säästää tilaa laitteessa, sillä se estää natiivikirjastojen kopioimisen ulos APK:sta tiedostojärjestelmään. Ainoa vaatimus on, että tiedostot on kohdistettu sivuille ja tallennettu pakkaamattomina APK:n sisälle, mitä tuetaan Android Gradle -lisäosan versiossa 2.2.0+ olevalla uudella pakkaajalla.

Täydellinen AndroidManifest.xml, sellaisena kuin se on katsottuna APK Analyzerissa

Tehdessäni nämä muutokset olin utelias näkemään, miten sovelluksen uusi versio vertautuu aiempaan. Sitä varten tarkistin lähdekoodin siitä git-commitista, josta aloitin, käänsin APK:n ja tallensin sen toiseen kansioon. Sitten käytin Compare with… -toimintoa nähdäkseni erittelyn kokoeroista vanhan ja uuden buildin välillä.

APK-vertailu – pääset siihen oikeassa yläkulmassa olevan painikkeen kautta

Kehitimme resursseja ja natiivi-kirjastoja paljon, ja säästimme kaikkiaan 17 Mt hyvin pienillä muutoksilla sovelluksessa. Näen kuitenkin, että DEX-kokomme taantui, sillä classes2.dex kasvoi 400KB:lla.

DEX-ongelmien vianmääritys

Tässä tapauksessa ero tuli riippuvuuksiemme päivittämisestä uudempiin versioihin ja uusien kirjastojen lisäämisestä. Proguard ja Multidex olivat jo käytössä rakennuksissamme, joten DEX-kokomme suhteen ei ole paljoa tehtävissä. Silti APK-analysaattori on loistava työkalu debuggaamaan mahdollisia ongelmia tässä kokoonpanossa, varsinkin kun otat Multidexin tai Proguardin käyttöön projektissasi ensimmäistä kertaa.

Luokkien sisällön tutkiminen.dex

Kun napsautat mitä tahansa DEX-tiedostoa, näet yhteenvedon siitä, kuinka monta luokkaa ja metodia se määrittelee ja kuinka monta viittausta se sisältää yhteensä (viittaukset lasketaan yhden DEX-tiedoston 64K-rajaan). Tässä esimerkin kuvakaappauksessa sovellus on juuri saavuttamassa rajan, mikä tarkoittaa, että se tarvitsee MultiDexiä jakamaan luokat erillisiin tiedostoihin lähitulevaisuudessa.

Voit porautua paketteihin nähdäksesi, mitkä niistä käyttävät kaikki viittaukset. Tässä tapauksessa näemme, että Tukikirjasto ja Google Play Services ovat tärkeimmät syyt tähän tilanteeseen:

Viittausten määrä pakettia kohti

Kun olet ottanut MultiDexin käyttöön ja kääntänyt sovelluksen, huomaat, että toinen luokka2.dex-tiedosto (ja mahdollisesti classes3.dex ja niin edelleen). Android gradle -lisäosan MultiDex-ratkaisu selvittää, mitä luokkia tarvitaan sovelluksen käynnistämiseen, ja laittaa ne ensisijaiseen classes.dex-tiedostoon, mutta siinä harvinaisessa tapauksessa, että se ei toimi ja saat ClassNotFoundException-ilmoituksen, voit käyttää APK Analyzeria DEX-tiedostojen tarkasteluun ja pakottaa puuttuvat luokat ensisijaiseen DEX-tiedostoon.

Kohtaat samankaltaisia ongelmia ottaessasi Proguardin käyttöön ja käyttäessäsi luokkia tai metodeja heijastuksen avulla tai XML-layouteista. APK-analysaattori voi auttaa sinua tarkistamaan, että Proguard-konfiguraatiosi on oikea, sillä sen avulla voit helposti tarkistaa, ovatko tarvitsemasi metodit ja luokat läsnä APK:ssa ja onko ne nimetty uudelleen (obfuscated). Voit myös varmistaa, että luokat, jotka haluat poistaa, on todella poistettu, eivätkä ne vie kallisarvoista referenssimenetelmälukua.

Olemme uteliaita kuulemaan, mitä muita käyttötarkoituksia löydät APK-analysaattorille ja mitä muita ominaisuuksia haluaisit integroitavan työkaluun!

Jätä kommentti