MetricKit. Analisis kinerja aplikasi iOS

Mainan baru

Kami terus membiasakan diri dengan materi baru dari Apple yang disajikan di WWDC. Kali ini, pertimbangkan MetricKit , kerangka kerja yang sama sekali baru yang berfungsi sebagai alat untuk memantau kinerja aplikasi.

Semua orang tahu bahwa mengukur kinerja aplikasi selama pengembangan itu mudah. Xcode menunjukkan jumlah RAM yang digunakan dan beban prosesor, Anda dapat terhubung menggunakan Instrumen ke simulator atau perangkat yang sedang diuji dan bahkan menulis alat Anda sendiri (untuk rincian lebih lanjut, lihat artikel kami tentang paket alat kustom: bagian 1 / bagian 2 ). Memahami pentingnya penyetelan kinerja tidak memungkinkan Anda mengukur hampir semua yang dilakukan aplikasi. Tetapi segala sesuatunya menjadi lebih rumit ketika kita berbicara tentang AppStore, jika aplikasi yang dikembangkan ditujukan untuk pengguna nyata. Tidak peduli seberapa hati-hati Anda menguji aplikasi Anda, dalam kondisi nyata akan selalu ada banyak kejutan yang akan mempengaruhi kinerja dan pengalaman pengguna. Tentu saja, ada banyak alat untuk mengumpulkan berbagai parameter, tetapi sebagian besar dibatasi oleh iOS SDK , serta dampak pemantauan aktual terhadap perilaku aplikasi.

Tahun ini, Apple memutuskan untuk mengisi celah ini dan memberi pengembang alat yang membantu mereka mengumpulkan dan menganalisis metrik kinerja aplikasi di lingkungan dunia nyata. Mereka mengumumkan MetricKit (kerangka kerja yang menyediakan akses ke opsi yang disediakan OS) dari tab terpisah di penyelenggara Xcode 11, tempat Anda dapat menemukan pengaturan aplikasi. Kami akan berhenti sebentar di MetricKit, karena tampilan parameter dalam Xcode hanya akan berfungsi dengan aplikasi yang sudah diterbitkan di AppStore.

MXMetricManager

Arsitektur kerangka ini cukup sederhana dan mudah. Bagian pusat ditempati oleh kelas MXMetricManager , yang merupakan struktur elemen tunggal yang menyediakan pengembang dengan seperangkat besar kerangka API.

Secara umum, alur kerja terdiri dari 3 langkah utama:

1. Anda menginisialisasi MXMetricMnager dan menetapkan pengamat untuk itu.
2. Jika mau, Anda dapat menerapkan metrik Anda sendiri di aplikasi menggunakan API Signpost
3. Dan akhirnya, sekarang kita berurusan dengan data yang diterima dalam metode didReceivePayloads, yaitu kirim ke backend Anda untuk analisis lebih lanjut.

Parameter datang sebagai array contoh MXMetricPayload . Payload merangkum set metadata dan cap waktu. Muatan metrik adalah pembungkus sederhana untuk subklas MXMetric . Untuk setiap jenis parameter, ini terpisah.

Jenis metrik didokumentasikan dengan cukup baik oleh Apple, jadi jangan terlalu lama membahasnya. Namun, Anda harus berhenti memperhatikan satu hal menarik - MXMetric menyediakan API terbuka untuk membuat serialisasi dalam NSDictionary atau JSON, yang, menurut saya, agak tidak biasa.

Komponen internal MetricKit.

Di luar, MetricKit terlihat sangat sederhana. Tetapi selalu menarik untuk melihat bagaimana semuanya bekerja dari dalam. Pencelupan ke dalam sesuatu yang lebih dalam selalu merupakan intrik, jika Anda menghadapi tugas tertentu. Jadi saya memutuskan bahwa saya ingin memberikan parameter dengan tag MetricKit, dan kemudian meminta mereka untuk memberi saya metrik yang diperbarui kapan saja. Tentu saja, Anda dapat menggunakan ` Debug -> Simulate MetricKit Payloads` dalam Xcode, tetapi id tidak memungkinkan Anda untuk menampilkan data Anda sendiri. Benar, ini bukan tim yang sangat berguna, tetapi memberi Anda arahan dalam penelitian Anda, dan itu terlihat sangat lucu;)

Untuk memulai tugas, kita jelas membutuhkan MetricKit itu sendiri. Anda mungkin berpikir bahwa mendapatkan file biner untuk framework itu mudah, karena Xcode memperlihatkannya dalam daftar frameworks segera setelah Anda menambahkannya melalui dialog "link file binary to libraries". Ini adalah pemikiran yang sangat optimis. Karena jika Anda membuka MetricKit.framework , Anda akan melihat file MetricKit.tbd . Ukurannya hanya 4kb . Jelas, ini bukan yang kita cari.

Jadi apa yang sebenarnya terjadi di sini?

TBD adalah singkatan dari “rintisan dylib berbasis teks” dan sebenarnya adalah file YAML dengan deskripsi yang mengekspor karakter dylib dan jalur ke biner dylib. Menautkan ke file tbd mengurangi ukuran biner. Kemudian, saat runtime, biner dylib nyata akan diunduh dari OS di jalur yang ditentukan dalam file tbd. Seperti inilah tampilan file saat Anda membukanya di Xcode:



Menggunakan path dari file tbd, Anda dapat dengan mudah mendapatkan biner MetricKit untuk penelitian lebih lanjut, tetapi ada metode yang bahkan lebih sederhana.

Biner aplikasi kami berisi jalur ke setiap pustaka yang terhubung secara dinamis di bagian header Mach-O. Informasi ini mudah diambil menggunakan alat menggunakan flag -l.

Berikut ini adalah output untuk proyek uji yang saya buat:

→ otool -l ./Metrics | grep -i metrickit name /System/Library/Frameworks/MetricKit.framework/MetricKit (offset 24) 

Anda dapat melihat jalur yang sama yang kita lihat sebelumnya di file tbd. Memiliki file kerangka biner, Anda dapat melihat elemen internalnya. Untuk ini, saya biasanya menggunakan Hopper Disassemble . Ini adalah alat yang mudah digunakan, tetapi sangat ampuh untuk mempelajari file biner dengan cermat.

Segera setelah file biner MetricKit terbuka, buka Tab 'Proc.' dan perluas daftar 'Tag'. Di sini Anda dapat melihat semua karakter yang diekspor. Memilih salah satu dari mereka (misalnya, MXMetricManager), kita akan melihat semua metodenya dan, setelah memilih metode, kita akan melihat isinya di sisi kanan:



Saat melihat daftar metode MXMetricManager [ https://gist.github.com/deszip/88a258ae21d33dc75d7cbac9569c6ec1 ], sangat mudah untuk melihat metode _checkAndDeliverMetricReports. Ini sepertinya adalah apa yang perlu dipanggil untuk mendapatkan MetricKit untuk menyampaikan pembaruan kepada pelanggan.

Sayangnya, upaya untuk memanggilnya tidak mengarah ke panggilan ke pelanggan, yang mungkin berarti bahwa parameter ini tidak akan dikirimkan. Mempertimbangkan implementasi metode ini, kami mencatat beberapa hal menarik: ini menyebutkan isi dari direktori / Library / Caches / MetricKit / Reports.

Dia kemudian mencoba membuka zip instance MXMetricPayload untuk setiap item pada disk. Dan akhirnya, iterates lebih dari pelanggan terdaftar dan memanggil metode didReceive dengan daftar data.

Masalahnya mungkin adalah bahwa tidak ada data di / Library / Caches / MetricKit / Reports , tetapi kita tahu bahwa kita membutuhkan beberapa contoh MXMetricPayload yang diarsipkan. Jadi, mari kita buat dan letakkan di disk sebelum memanggil ' _checkAndDeliverMetricReports '. Sekali lagi, rencananya adalah membuat instance MXMetricPayload, lalu membuat dan menambahkan segala jenis MXMetric ke dalamnya, dan kemudian mengarsipkan instance data ke disk. Setelah semua, panggil metode ' _checkAndDeliverMetricReports ', ini akan menyebabkan memanggil pelanggan kami dengan rintisan sebagai argumen.

Melihat melalui dokumen Apple tentang muatan dan metrik, Anda mungkin memperhatikan bahwa mereka tidak memiliki inisialisasi publik, dan sebagian besar properti hanya baca-saja. Jadi, bagaimana mungkin untuk membuat kelas?

Kembali ke Hopper lagi untuk melihat daftar metode MXMetricPayload :



Di sini Anda dapat melihat inisialisasi dan metode untuk menetapkan parameter. Memanggil metode pribadi mudah menggunakan kelas NSInvocation dan metode 'performSelector' karena sifat dinamis dari Objective-C.

Sebagai contoh, kami akan membuat metrik untuk CPU dan menambahkannya ke payload. Dengan menggunakan tautan ini, Anda dapat menemukan fragmen kode lengkap: [ https://gist.github.com/deszip/a0cf877b07cc2877129e0aaef2fed1e4 ].

Dan akhirnya, kami mengarsipkan semua yang kami buat dan menulis data ke direktori / Library / Caches / MetricKit / Reports .

Sekarang saatnya memanggil metode ' _checkAndDeliverMetricReports ', yang pada akhirnya akan mengarah pada panggilan ke pelanggan. Kali ini kami meneruskan data dengan muatan paypal sebagai argumen sebagai argumen.

Dari mana metrik berasal

Mendapatkan laporan cukup mudah diimplementasikan melalui MetricKit , tetapi Anda mungkin tertarik mempelajari bagaimana laporan muncul di direktori app / Library . Begini caranya.

Menggali di dalam binary MetricKit, saya perhatikan metode ini: '_createXPCConnection'. Memeriksa implementasinya mengklarifikasi situasi - ia membangun NSXPCConnection untuk layanan dengan nama com.apple.metrickit.xpc dan dua antarmuka MXXPCServer dan MXXPCClient untuk sisi klien dan server. Jika Anda melihat deskripsi protokol:

Kesimpulan

MetricKit adalah alat yang unik dan sangat diperlukan untuk menjaga kinerja aplikasi Anda dalam kondisi nyata dalam produksi.

Sayangnya, saat ini tidak memungkinkan untuk melihat antarmuka pengguna 'Metrik' di Xcode, kecuali yang ditunjukkan saat demo di sesi WWDC.



Ini bisa menjadi alat yang tak ternilai untuk membawa pengalaman pengguna ke tingkat berikutnya dengan menghilangkan masalah kinerja dalam kode Anda.

Salah satu kelemahan yang saya lihat sekarang di alat ini adalah kurangnya detail untuk setiap jenis: hanya pemisahan yang merupakan versi aplikasi, dan Anda tidak dapat melihat metrik apa pun untuk grup perangkat / versi OS / wilayah tertentu, dll.

Tetapi, tentu saja, selalu ada peluang untuk mengirim data kepada diri Anda untuk diproses lebih lanjut bersama dengan informasi penting yang Anda butuhkan. Anda dapat melampirkannya pada tugas di pelacak bug Anda dan banyak lagi. Di AppSpector, tim kami bekerja untuk memperluas fungsionalitas alat pemantauan kinerja menggunakan data yang diperoleh dari MetricKit .

Tetap up to date!