Teknologian jakaminen

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Yleiskatsaus suorituskyvyn keräämiseen ja analysointiin liittyvistä työkaluista

Mobiilisovellusten suorituskykytietojen keräämiseen, analysoimiseen ja näyttämiseen on monia työkaluja, jotka voidaan karkeasti jakaa seuraaviin luokkiin. Esimerkiksi mobiili suorituskykytyökalut, jotka voivat kerätä useita suorituskykyindikaattoreita, perfdog ja Solopi, joista Solopi on avoimen lähdekoodin ja pefdog on kaupallinen työkalu. Työkaluja, jotka voivat suorittaa kaatumisanalyysin, kuten kaupallinen Firebase Crashlytics ja avoimen lähdekoodin Sentry-työkalu. Jos sinun on analysoitava verkkoon liittyviä tietoja, voit käyttää Charlesia tai Wiresharkia. Lisäksi tarjolla on kattavat suorituskyvyn hallintatyökalut, kuten Dynatrace. Yleisesti ottaen kaupallisten työkalujen ominaisuudet, tarkkuus ja käyttökokemus ovat ehdottomasti parempia kuin avoimen lähdekoodin työkalut Henkilökohtaiseen opiskeluun ja tutkimukseen ainoa tapa aloittaa on avoimen lähdekoodin työkaluista. Siksi tätä blogia kirjoittaessamme käytämme esimerkkeinä myös avoimen lähdekoodin työkaluja.

Mobiili suorituskyvyn testaustyökalu：
PerfDog: Työkalu sovellusten suorituskyvyn, suorittimen, muistin, virrankulutuksen ja muiden tietojen seurantaan, tukee suorituskyvyn testausta ja mobiilisovellusten reaaliaikaista seurantaa.
Solopi: keskittyy mobiilisovellusten suorituskyvyn testaamiseen ja seurantaan, mukaan lukien kuvanopeuden, prosessorin, muistin ja muiden indikaattoreiden reaaliaikainen seuranta.

Kaatumisanalyysityökalu：
Firebase Crashlytics: Googlen tarjoama tehokas kaatumisraportointi- ja -analyysityökalu, joka voi seurata sovellusten kaatumisia reaaliajassa.
Sentry: avoimen lähdekoodin virheseurantatyökalu, joka tukee useita alustoja, mukaan lukien virheraportointi ja mobiilisovellusten suorituskyvyn seuranta.

Verkon suorituskyvyn testaustyökalut：
Charles Proxy: Verkon vianetsintävälityspalvelintyökalu, joka kaappaa ja analysoi mobiilisovellusten verkkopyyntö- ja vastaustiedot.
Wireshark: avoimen lähdekoodin verkkoanalyysityökalu, joka tukee mobiilisovellusten verkkopakettien sieppaamista ja analysointia.

APM työkalut(Sovelluksen suorituskyvyn hallinta):
Dynatrace: Pilvipohjainen, täyden pinon suorituskyvyn seurantaratkaisu, joka tukee mobiilisovellusten suorituskyvyn seurantaa ja käyttökokemusten analysointia.

Mitä suorituskykymittareita kerätään ja miten

  Ennen suoritusanalyysin suorittamista sinun on ensin ymmärrettävä kunkin suoritusindikaattorin merkitys. Otetaan esimerkkinä Solopin keräämät suorituskykyindikaattorit, katsotaanpa yleisiä mobiilisovellusten suorituskyvyn indikaattoreita ja kuinka näitä indikaattoreita voidaan kerätä.

Ruudunpäivitysnopeus

Kuvataajuuden laskentakaava on:Kuvataajuus = piirrettyjen kehysten määrä/ajanjakso,Useimpien sovellusten ja pelien kehittäjien tavoitekehysnopeus on60 FPS( ruutua sekunnissa), miksi tavoitekuvanopeus on 60 FPS? Koska useimpien nykyaikaisten älypuhelimien ja tablettien näytön virkistystaajuus on 60 Hz, niin kauan kuin kuvataajuus saavuttaa 60 FPS, eli piirrettyjen ruutujen määrä sekunnissa on 60, käyttäjän visuaaliset tehosteet ovat tasaisempia eikä viivettä ole. Vähimmäisnopeus ei voi olla pienempi kuin 30 FPS Tämä johtuu siitä, että näyttö näyttää toistuvasti edellisen ruudun kuvan odottaessaan uutta kuvaa, jolloin kuva on epätasainen. Korkeat voivat saavuttaa 90 FPS (esimerkiksi laitteissa, joissa on korkea virkistystaajuus).

Kuvanopeustietojen kerääminen

  Kuvataajuuden keräämiseen on kaksi tapaa. Yksi on käyttää Koreografi-luokkaa kuvanopeustilastojen keräämiseen. Tämä edellyttää koodin kirjoittamista sovelluksen sisällä, ja se voi kerätä vain sovelluksen kuvanopeustietoja.Toinen tapa on käyttää gfxinfo työkalu. Esimerkkinä Solopista lasketaan myös aikakatkaisukuvaaika 1 sekunnin sisällä gfxinfo-työkalun tietojen avulla ja päätellään todellinen kuvataajuus. Siksi, kun se on lähellä hiljaisuutta, osa kuvanopeudesta saattaa näkyä väärin. On suositeltavaa suorittaa kuvanopeuden testaus dynaamisissa skenaarioissa, kuten liukuessa tai sivun vaihtamisessa. gfxinfo-menetelmällä voidaan kerätä kuvanopeustietoja kaikista sovelluksista ja se soveltuu erittäin hyvin suorituskykytietojen keruutyökaluksi. Siksi tässä keskitymme myös kuvanopeustietojen keräämiseen gfxinfon kautta.

Kuvanopeustietojen keräämiseen on kaksi päävaihetta.Ensimmäinen askel: Hanki gfxinfo-tiedot adb-komennolla,Vaihe 2 : jäsentää tiedot ja laskea kuvanopeustiedot. gfxinfo-tietojen sisältö on suunnilleen seuraava:

Tilastot alkaen: Tilastot alkamisaika, yksikkö on nanosekuntia.
Renderöityjen kehysten kokonaismäärä: Renderöityjen kehysten kokonaismäärä.
Janky-kehykset: Janky-kehysten määrä, eli yli 16 ms:n kehysten määrä (päivitysväli 60 kuvaa sekunnissa).
Janky-kehysten prosenttiosuus: Hullujen kehysten suhde kehysten kokonaismäärään.
90. prosenttipiste: 90. prosenttipiste, mikä osoittaa, että 90 prosentilla kehyksistä renderöintiajat ovat tätä arvoa pienemmät (millisekunteina).
95. prosenttipiste: 95. prosenttipiste, mikä osoittaa, että 95 prosentilla kehyksistä renderöintiajat ovat tämän arvon alapuolella (millisekunteina).
99. prosenttipiste: 99. prosenttipiste, mikä osoittaa, että 99 %:lla kehyksistä renderöintiajat ovat tätä arvoa pienemmät (millisekunteina).
Numero Missed Vsync: Synkronoimattomien pystysynkronointien määrä, eli kehysten pudotusten määrä, joka johtuu siitä, että hahmonnus epäonnistui ajoissa.
Numero Suuri tuloviive: Suurten tuloviiveiden määrä ilmaisee liian pitkän syötetapahtuman käsittelyajan aiheuttamien viiveiden määrän.
Lukumäärä hidas käyttöliittymäsäike: kuinka monta kertaa käyttöliittymäsäie vastasi hitaasti, eli kuinka monta kertaa käyttöliittymän säiettä kesti liian kauan käsitellä.

Esimerkkinä Solopista kehysnopeus päätellään gfxinfo-tiedoissa olevan aikakatkaisukehyksen avulla. Tietyn projektin koodia varten voit tarkastella solopin lähdekoodia.

viivenopeus / viiveiden määrä

Jäätymien määrä : Testijakson aikana niiden jaksojen määrä, joiden aikana kuvanopeuden havaitaan olevan kynnystä alhaisempi. Aina kun kuvataajuus putoaa kynnyksen alapuolelle joksikin aikaa, se lasketaan pätkiksi. Tässä olevaa kynnystä voidaan mukauttaa, jos se on esimerkiksi 60 FPS pienempi kuin tavoitekuvanopeus, se voidaan tallentaa pysäytyksenä. Eli jos kehyksen renderöintiaika on yli 16 ms, se lasketaan jumissa.

viiveaste : Pakastusajan prosenttiosuus kokonaistestiajasta. Oletetaan, että testissä sovellus oli käynnissä 120 sekuntia, jonka aikana kehysnopeus oli alle 16 FPS yhteensä 4 kertaa ja kokonaisviiveaika oli 8 sekuntia, sitten: viiveiden määrä: 4 kertaa. Änkytysaste: 8/120*100 %=6,7 %. Yllä olevassa gfxinfossa on myös datatietoja viivenopeudesta.

prosessori/muisti

  Esimerkkinä solopi sisältää prosessorin käyttöprosentin prosessista, jossa sovelluksen huipputason toiminta sijaitsee, ja yhden prosessin sovellusten prosessorin käyttöprosentin usean prosessin prosessisovellukset, nämä tiedot edustavat huipputason CPU-käyttöä, kun prosessin vaihto tapahtuu, Soloπ voi vaihtaa automaattisesti uuteen prosessitietoon.

import subprocess
 
def get_memory_info(pid):
    try:
        # Run adb shell command to read /proc/<pid>/statm
        command = f"adb shell cat /proc/{pid}/statm"
        result = subprocess.check_output(command, shell=True)
        statm_data = result.decode('utf-8').strip().split()
        
        # Parse statm data
        size, resident, shared, text, lib, data, dt = map(int, statm_data)
        
        memory_info = {
            'size': size,         # total program size (pages)
            'resident': resident, # resident set size (pages)
            'shared': shared,     # shared pages (pages)
            'text': text,         # text (code) size (pages)
            'lib': lib,           # library (unused since Linux 2.6; always 0)
            'data': data,         # data + stack (pages)
            'dt': dt              # dirty pages (unused since Linux 2.6; always 0)
        }
        
        return memory_info
    except subprocess.CalledProcessError as e:
        print(f"Error executing command: {e}")
        return None
    except Exception as e:
        print(f"Error: {e}")
        return None
 
# Replace with your application's PID
pid = '12345'
memory_info = get_memory_info(pid)
if memory_info:
    print(f"Memory info for PID {pid}:")
    print(f"Size: {memory_info['size']} pages")
    print(f"Resident set size (RSS): {memory_info['resident']} pages")
    print(f"Shared pages: {memory_info['shared']} pages")
    print(f"Text (code) size: {memory_info['text']} pages")
    print(f"Data + stack size: {memory_info['data']} pages")

Vasteaika

  Otetaan esimerkkinä Solopi, Sisältää vasteaika- ja päivitysaikatiedot sovelluksen napsautuksista. Kuuluu sovelluksen ulottuvuustietoihin. Aika käyttäjän napsautuksesta siihen, että järjestelmä julkaisee ensimmäisen käyttöliittymäpäivityksen, on vasteaika, ja aika, jonka jälkeen järjestelmä lopettaa käyttöliittymän päivittämisen, on päivitysaika. Vasteajan laskemisen logiikka on tallentaa näyttö kehyksiin ei ole oikein. Esimerkiksi kun käyttäjä napsauttaa aloituspainiketta, kun napsautat sovellussivua, jonkun keskellä olevan käden nopeus lasketaan mukaan, ja tämä osa lasketaan vasteaikaan. Siksi, jos haluat laskea valmistetun sivun vasteajan, on tarkempaa tallentaa vain näyttö ja tunnistaa manuaalisesti sivun alku- ja loppukehys. Tarkat vaiheet näyttöruutujen tallentamiseen ovat seuraavat:

Yllä oleva on käsitys yleisten suoritusindikaattoreiden merkityksestä mobiilisovelluksissa sekä yksityiskohtaiset ohjeet niiden keräämiseen. Mitä tulee kaatumiseen jne., esittelemme sen yksityiskohtaisesti seuraavassa blogissa.