Berbagi teknologi

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

Ikhtisar alat yang terkait dengan pengumpulan dan analisis kinerja

Ada banyak alat untuk mengumpulkan, menganalisis, dan menampilkan data kinerja aplikasi seluler, yang secara kasar dapat dibagi ke dalam kategori berikut. Misalnya alat kinerja seluler yang dapat mengumpulkan berbagai indikator kinerja, perfdog, dan Solopi, di antaranya Solopi adalah sumber terbuka, dan pefdog adalah alat komersial. Alat yang dapat melakukan analisis kerusakan, seperti Firebase Crashlytics komersial dan alat Sentry sumber terbuka. Jika Anda perlu menganalisis data terkait jaringan, Anda dapat menggunakan Charles atau Wireshark. Selain itu, terdapat alat manajemen kinerja yang komprehensif, seperti Dynatrace. Secara umum, kemampuan, keakuratan, dan pengalaman pengguna alat komersial jelas lebih baik daripada alat sumber terbuka. Sebagai studi dan penelitian pribadi, saya hanya bisa memulai dari alat sumber terbuka. Oleh karena itu, saat menulis blog ini, kami juga akan menggunakan alat open source sebagai contoh.

Alat pengujian kinerja seluler：
PerfDog: Alat untuk memantau kinerja aplikasi, CPU, memori, konsumsi daya, dan data lainnya, mendukung pengujian kinerja dan pemantauan aplikasi seluler secara real-time.
Solopi: berfokus pada pengujian dan pemantauan kinerja aplikasi seluler, termasuk pemantauan frame rate, CPU, memori, dan indikator lainnya secara real-time.

Alat analisis kerusakan：
Firebase Crashlytics: Alat pelaporan dan analisis kerusakan canggih yang disediakan oleh Google yang dapat memantau kerusakan aplikasi secara real-time.
Penjaga: Alat pelacak kesalahan sumber terbuka yang mendukung berbagai platform, termasuk pelaporan kesalahan dan pemantauan kinerja aplikasi seluler.

Alat pengujian kinerja jaringan：
Charles Proxy: Alat proxy debugging jaringan yang menangkap dan menganalisis permintaan jaringan dan data respons untuk aplikasi seluler.
Wireshark: Alat analisis jaringan sumber terbuka yang mendukung penangkapan dan analisis paket jaringan aplikasi seluler.

alat APM(Manajemen Kinerja Aplikasi):
Dynatrace: Solusi pemantauan kinerja full-stack cloud-native yang mendukung pemantauan kinerja aplikasi seluler dan analisis pengalaman pengguna.

Metrik kinerja apa yang dikumpulkan dan bagaimana caranya

  Sebelum melakukan analisis kinerja, Anda harus memahami terlebih dahulu pengertian dari masing-masing indikator kinerja. Dengan mengambil contoh indikator kinerja yang dikumpulkan oleh Solopi, mari kita lihat indikator umum kinerja aplikasi seluler dan bagaimana indikator tersebut dapat dikumpulkan.

Kecepatan bingkai

Rumus untuk menghitung frame rate adalah:Kecepatan bingkai = jumlah bingkai yang diambil/periode waktu,Target frame rate untuk sebagian besar pengembang aplikasi dan game adalah60FPS( frame/detik), mengapa target frame rate 60FPS? Karena kecepatan refresh layar pada sebagian besar ponsel cerdas dan tablet modern adalah 60Hz, selama kecepatan bingkai mencapai 60FPS, yaitu jumlah bingkai yang diambil per detik adalah 60, efek visual pengguna akan lebih mulus dan tidak ada jeda. Minimum tidak boleh lebih rendah dari 30FPS. Hal ini karena monitor berulang kali menampilkan gambar dari frame sebelumnya sambil menunggu frame baru, sehingga menyebabkan gambar menjadi tidak mulus. Yang tinggi bisa mencapai 90FPS (misalnya untuk perangkat dengan refresh rate tinggi).

Cara mengumpulkan informasi kecepatan bingkai

  Ada dua cara untuk mengumpulkan frame rate. Salah satunya adalah dengan menggunakan kelas Choreographer untuk mengumpulkan statistik frame rate. Cara ini memerlukan penulisan kode dalam aplikasi dan hanya dapat mengumpulkan informasi frame rate aplikasi.Cara lainnya adalah dengan menggunakan alat gfxinfo. Mengambil Solopi sebagai contoh, waktu frame habis dalam 1 detik juga dihitung melalui informasi alat gfxinfo, dan frame rate sebenarnya disimpulkan. Oleh karena itu, ketika mendekati stasioner, sebagian dari frame rate mungkin ditampilkan secara tidak benar. Disarankan untuk melakukan pengujian kecepatan bingkai dalam skenario dinamis seperti menggeser atau berpindah halaman. Metode gfxinfo dapat mengumpulkan informasi frame rate semua aplikasi dan sangat cocok sebagai alat pengumpul data kinerja. Oleh karena itu, di sini kami juga fokus pada cara mengumpulkan informasi frame rate melalui gfxinfo.

Ada dua langkah utama untuk mengumpulkan informasi kecepatan bingkai.langkah pertama: Dapatkan informasi gfxinfo melalui perintah adb,Langkah 2 : Mengurai informasi dan menghitung informasi kecepatan bingkai. Isi informasi gfxinfo kurang lebih sebagai berikut:

Statistik sejak: Statistik waktu mulai, satuannya adalah nanodetik.
Total bingkai yang dirender: Jumlah total bingkai yang dirender.
Janky frame: Jumlah frame jank, yaitu jumlah frame yang melebihi 16 md (interval penyegaran 60 frame per detik).
Persentase frame jank: Rasio frame jank terhadap jumlah total frame.
Persentil ke-90: persentil ke-90, menunjukkan bahwa 90% frame memiliki waktu rendering di bawah nilai ini (dalam milidetik).
Persentil ke-95: persentil ke-95, menunjukkan bahwa 95% frame memiliki waktu rendering di bawah nilai ini (dalam milidetik).
Persentil ke-99: Persentil ke-99, menunjukkan bahwa 99% frame memiliki waktu rendering di bawah nilai ini (dalam milidetik).
Jumlah Vsync yang Terlewatkan: Jumlah sinkronisasi vertikal yang tidak disinkronkan, yaitu jumlah penurunan bingkai yang disebabkan oleh kegagalan rendering tepat waktu.
Angka Latensi masukan yang tinggi: Jumlah penundaan masukan yang tinggi menunjukkan jumlah penundaan yang disebabkan oleh terlalu lamanya waktu pemrosesan peristiwa masukan.
Jumlah thread UI Lambat: Berapa kali thread UI merespons dengan lambat, yaitu berapa kali thread UI membutuhkan waktu terlalu lama untuk diproses.

Mengambil Solopi sebagai contoh, kecepatan bingkai disimpulkan melalui waktu habis bingkai di informasi gfxinfo. Untuk kode proyek tertentu, Anda dapat melihat kode sumber solopi.

tingkat lag/jumlah lag

Jumlah pembekuan : Selama periode pengujian, jumlah periode selama frame rate terdeteksi lebih rendah dari ambang batas. Setiap kali frame rate turun di bawah ambang batas selama jangka waktu tertentu, hal ini dihitung sebagai stutter. Ambang batas di sini dapat disesuaikan. Misalnya, jika 60FPS lebih rendah dari kecepatan bingkai target, maka dapat dicatat sebagai pembekuan. Artinya, jika waktu rendering frame lebih besar dari 16 ms, maka dianggap macet.

tingkat keterlambatan : Persentase waktu pembekuan terhadap total waktu pengujian. Asumsikan bahwa dalam pengujian, aplikasi berjalan selama 120 detik, selama itu frame rate lebih rendah dari 16 FPS total 4 kali, dan total waktu jeda adalah 8 detik, maka: jumlah jeda: 4 kali. Tingkat kegagapan: 8/120*100%=6,7%. Pada gfxinfo diatas juga terdapat informasi data mengenai lag rate.

CPU/memori

  Mengambil solopi sebagai contoh, cpu mencakup persentase penggunaan CPU dari proses tempat aktivitas tingkat atas aplikasi berada dan persentase penggunaan CPU global untuk aplikasi proses tunggal, data ini mewakili penggunaan CPU dari aplikasi tersebut aplikasi proses multi-proses, data ini mewakili proses UI tingkat atas, ketika peralihan proses terjadi, Soloπ dapat secara otomatis beralih ke data proses baru.

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")

Waktu merespon

  Ambil contoh solopi, Berisi data waktu respons dan waktu penyegaran untuk klik aplikasi. Milik data dimensi aplikasi. Waktu dari klik pengguna hingga pertama kali sistem mengeluarkan pembaruan antarmuka adalah waktu respons, dan waktu hingga sistem berhenti menyegarkan antarmuka adalah waktu penyegaran. Logika penghitungan waktu respons adalah dengan membagi rekaman layar menjadi beberapa bingkai. Menurut situs resmi Solopi, secara otomatis mengenali bingkai awal dan bingkai akhir untuk menghitung waktu respons waktu respons tidak tepat. Misalnya, saat pengguna mengklik Mulai, saat Anda mengklik halaman aplikasi, waktu pengoperasian kecepatan tangan seseorang di tengah disertakan, dan bagian ini dihitung ke dalam waktu respons. Oleh karena itu, jika Anda ingin menghitung waktu respons halaman yang disiapkan, akan lebih akurat jika hanya merekam layar dan secara manual mengidentifikasi bingkai awal dan akhir halaman. Langkah-langkah spesifik untuk merekam bingkai layar adalah sebagai berikut:

Di atas adalah pemahaman tentang arti indikator kinerja umum dalam aplikasi seluler, serta petunjuk rinci tentang cara mengumpulkannya. Mengenai crash dan lain-lain, akan kami perkenalkan secara detail di blog berikutnya.