1. Pengenalan
Dengan perkembangan pesat IoT baru-baru ini, peranti pintar dengan pelbagai bentuk dan saiz permukaan telah dikeluarkan satu demi satu. Aliran ini berpotensi mengubah cara pengguna berinteraksi dengan apl mudah alih. Untuk lebih spesifik, pengguna kini boleh secara kolaboratif menggunakan permukaan berbilang peranti untuk berinteraksi dengan apl mudah alih, dan bukannya terhad kepada satu peranti pada satu masa. Paradigma baru sebegini dipanggil pengkomputeran pelbagai permukaan, dan ia boleh memberikan pengguna pengalaman pengguna baharu (UX) untuk kegunaan berbilang peranti. Contohnya, skrin apl YouTube terdiri daripada antara muka pengguna (UI) video yang menunjukkan aliran video dan UI senarai yang menunjukkan senarai video berkaitan. Jika kedua-dua elemen UI ini boleh dipaparkan pada peranti yang berbeza, pengguna boleh menonton video pada skrin penuh sambil menyemak imbas senarai video berkaitan dengan mudah pada masa yang sama.
Terdapat beberapa penyelesaian untuk membolehkan pengkomputeran berbilang permukaan, termasuk peringkat aplikasi and peringkat sistem pendekatan. Pendekatan peringkat apl ialah menggunakan apl tersuai yang dibangunkan untuk pengkomputeran berbilang permukaan, seperti penstriman video lancar merentas peranti (cth, Netflix) dan pengeditan dokumen kolaboratif berbilang pengguna (cth, Dokumen Google). Namun, pendekatan ini memerlukan banyak usaha kejuruteraan untuk membangunkan aplikasi tersuai sedemikian, jadi hanya sebilangan kecil aplikasi berbilang permukaan tersedia secara komersial pada masa ini. Sebaliknya, pendekatan peringkat sistem adalah untuk mereka bentuk semula platform mudah alih sedia ada khusus untuk persekitaran berbilang peranti. Sebagai contoh, kedua-dua FLUID [1] dan PRUID [2] ialah platform mudah alih berasaskan Android yang menyokong pengkomputeran berbilang permukaan dengan mengedarkan elemen UI bagi satu apl merentasi berbilang peranti. Sebagai contoh lain, FLUID-XP [3] melanjutkan lagi FLUID untuk mengedarkan elemen UI walaupun merentasi platform heterogen (cth, antara Android dan iOS). Walau bagaimanapun, pendekatan ini secara asasnya memerlukan pengubahsuaian yang ketara pada bahagian teras dalaman platform mudah alih seperti pengurusan UI dan pemaparan, menjadikannya sukar untuk menggunakan platform mudah alih baharu pada peranti pengguna secara praktikal. Ini kerana syarikat industri mudah alih yang menerajui pasaran platform mudah alih semasa, seperti Google dan Apple, cenderung keberatan untuk membuat pengubahsuaian yang ketara pada bahagian teras platform mudah alih mereka untuk mengekalkan kestabilan produk.
Untuk mengatasi kelemahan mereka, kertas kerja ini mencadangkan UI-Scissor, rangka kerja peringkat apl baharu yang secara automatik mengubah apl lama sedia ada yang dibina untuk satu peranti kepada apl berbilang permukaan. UI-Scissor boleh memanjangkan fungsi apl untuk membolehkan apl mudah alih individu mengedarkan elemen UI mereka merentas peranti, membolehkan penggunaan berbilang permukaan yang fleksibel untuk pengguna. Pelanjutan sedemikian dicapai dengan menggunakan logik kod yang diperlukan untuk pengedaran UI kepada apl mudah alih individu, oleh itu pendekatan kami tidak memerlukan pengubahsuaian pada platform mudah alih sedia ada dan tiada usaha kejuruteraan yang penting untuk pembangun apl membangunkan apl berbilang permukaan. Tambahan pula, UI-Scissor bertujuan untuk mencapai keperluan reka bentuk berikut. i) Ketelusan aplikasi: Transformasi apl hendaklah dilakukan secara telus mengikut gelagat apl mudah alih. Iaitu, transformasi tidak seharusnya mengganggu atau memesongkan gelagat apl secara tidak sengaja. Untuk melakukan ini, UI-Scissor direka bentuk untuk meminimumkan kesan transformasi aplikasi dengan menyediakan kebanyakan fungsi teras sebagai perkhidmatan latar belakang yang berasingan dan memasukkan hanya antara muka komunikasi yang minimum ke dalam aplikasi mudah alih. ii) Keserasian merentas platform: Apl mudah alih yang ditukar seharusnya dapat mengedarkan elemen UI merentas berbilang peranti heterogen dalam cara agnostik platform. Untuk tujuan ini, UI-Scissor mengubah UI apl mudah alih (iaitu, UI asli) kepada UI web yang sesuai yang boleh berjalan pada platform mudah alih yang berbeza apabila melaksanakan pengedaran UI.
2. Latar belakang
Untuk meneroka secara konkrit transformasi apl untuk pengedaran UI, kami menyasarkan apl Android dengan antara muka pengguna grafik (GUI). Skrin apl individu terdiri daripada koleksi elemen UI (cth, butang, teks). Dari perspektif pengguna, elemen UI ialah unit terkecil yang boleh digunakan oleh pengguna berinteraksi dalam apl. Untuk mewakili elemen UI ini, subsistem UI Android mempunyai dua jenis objek UI: widget and susun atur, yang diuruskan dalam struktur pokok yang dikenali sebagai pokok UI. Widget berfungsi sebagai nod daun dalam pepohon UI, mewakili komponen grafik yang dipetakan pada setiap elemen UI pada skrin apl. Sebaliknya, reka letak bertindak sebagai nod perantaraan dalam pepohon UI, berfungsi sebagai bekas yang menentukan kedudukan nod anaknya pada skrin. Dalam proses pemaparan UI Android, reka letak terlebih dahulu menentukan kedudukan setiap widget. Kemudian, widget ditarik ke kedudukan yang ditetapkan dengan menggunakan keadaan grafik masing-masing (cth, teks, warna, imej, dll.). Selepas itu, elemen UI yang dipaparkan pada skrin apl boleh selalu dikemas kini oleh acara luaran seperti input pengguna atau data rangkaian masuk. Contohnya, apabila pengguna menekan butang UI dalam apl mudah alih, input pengguna dihantar ke bahagian logik apl (iaitu, pendengar acara). Apabila memproses input pengguna, bahagian logik apl boleh mengubah suai keadaan grafik widget tertentu dengan menggunakan fungsi setempatnya, menghasilkan kemas kini elemen UI yang sepadan. Untuk mendayakan pengedaran UI kepada berbilang peranti, UI-Scissor perlu memastikan proses pengendalian pemaparan dan kemas kini UI boleh disokong dengan lancar dalam persekitaran berbilang peranti.
3. Reka Bentuk Sistem
Kami mempersembahkan UI-Scissor, rangka kerja berbilang peranti baharu yang memperluaskan fungsi apl untuk membolehkan apl mudah alih mengedarkan elemen UI mereka ke peranti jauh. Sambungan sedemikian dicapai dengan menambahkan lapisan baharu secara automatik pada apl mudah alih melalui instrumentasi kod, yang boleh meminimumkan beban kejuruteraan pada pembangun apl.
3.1 Aliran Kerja
Seperti yang ditunjukkan dalam Rajah 1, UI-Scissor menyokong pengkomputeran berbilang permukaan untuk aplikasi mudah alih melalui ? and talian fasa.
Fasa luar talian. Pembangun apl mengubah apl mudah alih warisannya, yang pada mulanya dibangunkan untuk persekitaran peranti tunggal, kepada apl berbilang permukaan baharu dengan menggunakan pengubah Apl. Pengubah apl ialah alat pengarangan yang disediakan oleh UI-Scissor dan memasukkan kod tambahan (dipanggil lapisan pengedaran UI) ke dalam apl sedia ada. Sebagai output, pembangun boleh memperoleh fail pakej apl berbilang permukaan (iaitu, APK) dan mengeluarkannya ke pasaran apl seperti Google Play. Kemudian, Pengguna Akhir boleh memuat turun dan memasang apl berbilang permukaan dengan mudah untuk menjalankan apl berbilang permukaan pada peranti hos mereka.
Fasa dalam talian. Pada peranti hos, apl berbilang permukaan (dipanggil apl hos) mampu mengedarkan elemen UInya kepada peranti jauh (peranti tetamu) melalui tiga sub-langkah. i) Berpasangan: Sebelum menjalankan apl hos, pengguna akhir terlebih dahulu perlu mendaftarkan peranti tetamu yang dipercayai dengan pengurus UI Jauh. Pengurus UI jauh ialah perkhidmatan latar belakang yang disediakan oleh UI-Scissor dan secara automatik mewujudkan sambungan rangkaian dengan peranti berdaftar apabila ia mengesan bahawa peranti itu berada berdekatan. Selepas itu, apl hos boleh berinteraksi dengan lancar dengan peranti berdaftar melalui pengurus UI Jauh. ii) Pengagihan UI: Lapisan pengedaran UI yang disuntik ke dalam apl hos menyediakan antara muka intuitif untuk pengedaran UI terpilih. Pengguna boleh mengaktifkan antara muka ini dengan mengetik berbilang jari dan memilih elemen UI yang diingini. Atas permintaan pengguna, lapisan pengedaran UI mengekstrak UI yang dipilih daripada pepohon UI apl hos dan menghantarnya ke peranti tetamu. Di sisi tetamu, bekas UI, yang beroperasi sebagai perkhidmatan latar belakang, memaparkan UI yang diedarkan melalui pemaparan tempatan (yang kami panggil UI tetamu). iii) Interaksi UI: Selepas pengedaran UI, UI-Scissor membolehkan pengguna berinteraksi dengan apl hos melalui UI hos dan tetamu dengan cara yang sama seolah-olah semua UI berada pada peranti yang sama. Contohnya, jika pengguna menyentuh butang yang diedarkan kepada peranti tetamu, peristiwa input dimajukan ke bahagian hos dan dikendalikan oleh logik apl hos dengan sewajarnya. Jika perlu, apl hos boleh mengemas kini beberapa keadaan UI tetamu.
3.2 Reka Bentuk Ciri Utama
UI-Scissor menyediakan beberapa ciri utama seperti berikut.
Transformasi apl. Pengubah apl meluaskan fungsi apl dengan memasukkan kod tambahan untuk pengedaran UI ke dalam fail APK apl mudah alih. Pertimbangan reka bentuk yang penting ialah menentukan logik kod yang sesuai untuk disuntik. Daripada menyuntik semua fungsi untuk pengkomputeran berbilang permukaan terus ke dalam apl mudah alih, yang boleh membawa kepada kerumitan dan kesan sampingan yang tidak dijangka, UI-Scissor meminimumkan volum kod yang disuntik. Ia menyokong fungsi teras dengan menyediakan perkhidmatan latar belakang yang berasingan (pengurus UI Jauh) dan hanya menyuntik antara muka minimum (lapisan pengedaran UI) ke dalam apl mudah alih untuk berinteraksi dengan perkhidmatan. Reka bentuk ini mengurangkan kemungkinan kesan sampingan. Pengubah apl dilaksanakan menggunakan Jelaga [4], perpustakaan analisis statik sumber terbuka.
Pengedaran UI merentas platform. Dalam UI-Scissor, pengedaran UI dimulakan apabila pengguna selesai memilih elemen UI yang dikehendaki. Mula-mula, lapisan pengedaran UI mengekstrak keadaan grafik UI yang dipilih daripada pepohon UI apl hos dan menghantarnya ke bahagian tetamu melalui pengurus UI Jauh. Keadaan grafik ini menunjukkan data penting untuk pemaparan UI, yang merangkumi bukan sahaja sifat umum (cth, jenis UI, lebar, tinggi, pengecam) tetapi juga sifat khusus untuk jenis UI (cth, kandungan, saiz fon untuk UI teks). Pada peranti tetamu, bekas UI menyahkod keadaan grafik yang diterima dan membina semula UI yang diedarkan. Di sini, satu isu penting ialah cabaran heterogeniti peranti. Dalam persekitaran berbilang peranti biasa, banyak peranti mungkin beroperasi pada pelbagai platform mudah alih seperti Android, iOS dan sebagainya. Berkenaan arah aliran ini, penciptaan UI apl hos (dirujuk sebagai UI asli) mungkin tidak dapat dilaksanakan jika hos & peranti tetamu adalah berdasarkan platform yang berbeza. Ini kerana platform yang berbeza secara dalaman adalah berdasarkan set arahan, fungsi API dan mekanisme pemaparan yang berbeza. Untuk menangani masalah ini, kami mereka bentuk bekas UI untuk menjana UI web daripada keadaan grafik UI asli. Pada asasnya, UI web dibina dengan bahasa pengaturcaraan web seperti HTML dan Javascript, jadi ia mempunyai kemudahalihan tinggi yang membolehkan UI web yang sama berfungsi pada pelbagai peranti. Untuk memanfaatkan kelebihan UI web, bekas UI secara dalaman mengekalkan jadual pemetaan antara UI asli dan UI web, yang membantu menjana UI web yang diperlukan dengan keadaan grafik UI asli yang diedarkan. Apabila keadaan grafik dihantar dari bahagian hos, bekas UI mula-mula mengenal pasti jenis setiap UI asli. Kemudian, ia berjaya mencipta UI web yang sesuai dengan keadaan grafik yang diterima dengan merujuk kepada jadual pemetaan mengikut jenis UI. Kami melaksanakan bekas UI menggunakan React Native [5] berasaskan Javascript, yang merupakan alat pembangunan mudah alih merentas platform.
Penyegerakan keadaan UI. Pada asasnya, apl mudah alih mengemas kini elemen UI dengan memanggil fungsi setempat, membayangkan bahawa UI yang diedarkan juga memerlukan kemas kini apabila fungsi setempatnya digunakan untuk pengkomputeran berbilang permukaan. Pengubah apl menyuntik Kod penyegerakan UI ke lokasi di mana fungsi setempat elemen UI dipanggil, memastikan pengkomputeran berbilang permukaan yang betul. Kod yang disuntik meminta lapisan pengedaran UI untuk mengubah suai keadaan grafik UI tetamu seolah-olah fungsi setempat digunakan pada bahagian tetamu. Selepas pelaksanaan, lapisan pengedaran UI menyemak sama ada elemen UI yang terlibat dalam panggilan fungsi diedarkan dan jika ya, hantarkan keadaan grafik yang diubah suai kepada peranti tetamu untuk kemas kini bekas UI. Satu cabaran ialah menentukan keadaan grafik yang diubah suai oleh fungsi yang digunakan. Walaupun fungsi UI dalam API Android didokumentasikan dengan baik untuk kesannya pada keadaan grafik, fungsi UI tersuai yang ditakrifkan oleh pembangun apl tidak diketahui dan khusus apl. Pengubah apl menangani perkara ini dengan menggunakan analisis hierarki kelas (CHA) untuk mengenal pasti keadaan grafik yang diubah suai oleh setiap fungsi UI tersuai sebelum instrumentasi kod. CHA menjana graf panggilan, memautkan tapak panggilan ke fungsi kelas yang mungkin. Ini membolehkan pengubah Apl mengenal pasti fungsi yang digunakan oleh fungsi UI tersuai, menganalisis kesannya pada keadaan grafik dan membimbing lapisan pengedaran UI dalam mengemas kini keadaan yang berkaitan pada tetamu.
Perbincangan mengenai penggunaan UI-Scissor. Untuk menskalakan penggunaan UI-Scissor, kami mencadangkan model yang mana pelayan (cth, pelayan pasaran aplikasi atau pelayan UI-Scissor khusus) mengendalikan transformasi aplikasi untuk pengkomputeran berbilang permukaan. Pembangun apl boleh menyerahkan fail APK mereka ke pelayan untuk menambah ciri berbilang permukaan. Pelayan mengubah fail APK dan menyediakan pembangun dengan versi yang diubah suai untuk dikeluarkan di pasaran aplikasi. Pengguna kemudian boleh memuat turun apl berbilang permukaan ini daripada pasaran apl seperti yang mereka lakukan dengan apl lama biasa. Ambil perhatian bahawa proses transformasi aplikasi ini hampir tidak memberi kesan kepada prestasi pelayan, biasanya mengambil masa beberapa minit sahaja, seperti yang ditunjukkan dalam Sekt. 4.
4. Penilaian
Kami membangunkan UI-Scissor untuk menunjukkan pengedaran UI terpilih yang lancar merentas peranti. Penilaian kami menggunakan pelaksanaan kami berdasarkan Android 11 dan React Native 0.69. Kami menggunakan dua peranti komersial sebenar (Google Pixel 5 dan 4a) dan satu peranti iOS maya (iPhone 14) yang dicontohi pada MacBook Air. Semua peranti disambungkan ke pusat akses Wi-Fi yang sama dengan daya pemprosesan 433 Mbps dan masa pergi balik (RTT) dengan purata 3.43 ms.
Ujian liputan. Untuk meneroka sejauh mana UI-Scissor menyokong potensi kes penggunaan berbilang permukaan, kami melanjutkan sepuluh apl lama yang dimuat turun daripada Google Play. Selepas itu, kami melancarkan setiap apl pada Google Pixel 5 (peranti hos) dan mengedarkan beberapa elemen UI kepada dua jenis peranti tetamu: satu peranti Android yang serupa dengan bahagian hos tetapi model berbeza (iaitu, Google Pixel 4a) dan satu lagi menjadi emulator iPhone 14. Ambil perhatian bahawa emulator sudah cukup untuk menunjukkan bahawa UI-Scissor boleh menyokong pengedaran UI untuk peranti berasaskan iOS kerana ia mempunyai susunan perisian yang sama seperti peranti iPhone sebenar. Jadual 1 memaparkan senarai kes penggunaan yang menggunakan apl lama. Kami mengesahkan bahawa UI-Scissor membolehkan tujuh apl berjaya beroperasi pada berbilang peranti. Terutamanya, walaupun dalam persekitaran heterogen dengan iPhone 14 sebagai peranti tetamu, apl lama melakukan pengkomputeran berbilang permukaan dengan lancar. Ini kerana UI-Scissor boleh membina semula elemen UI web yang betul pada sisi tetamu, menggunakan keadaan grafik elemen UI asli apl lama.
Sebaliknya, UI-Scissor tidak boleh menyokong tiga apl—Yanolja, Messenger dan Free Fire—atas sebab yang berbeza. Pertama, walaupun rangka kerja kami mencapai transformasi apl untuk Yanolja, apl ini gagal melepasi proses pengesahan tandatangan, menyebabkan apl itu ranap. Ini kerana kami menggunakan kunci tandatangan yang tidak sah semasa membungkus semula apl ini semasa percubaan kami. Ini membayangkan isu sedemikian tidak akan berlaku apabila pembangun apl dengan kunci tandatangan yang betul menggunakan UI-Scissor. Sementara itu, UI-Scissor tidak dapat menjalankan transformasi apl walaupun untuk Messenger dan Free Fire. Ini kerana mereka memanfaatkan rangka kerja UI pihak ketiga (cth, React Native atau Unity) yang mengurus semua objek UI melalui struktur data dalaman sambil tidak membenarkan UI-Scissor mengakses UI. Walau bagaimanapun, ini bukanlah had yang teruk untuk menghalang kebolehgunaan UI-Scissor, memandangkan kelaziman rangka kerja UI pihak ketiga tersebut. Kami menganalisis 50 apl lama dengan muat turun terkumpul tertinggi daripada Google Play dan mendapati 13 daripada apl ini menggunakan rangka kerja pihak ketiga. Ini menunjukkan bahawa UI-Scissor masih boleh menyokong kebanyakan apl, merangkumi 74% daripada apl yang kami periksa.
Overhed transformasi apl. Jadual 1 menunjukkan overhed transformasi apl, termasuk 'Masa transformasi' dan 'saiz APK'. UI-Scissor boleh menambah keupayaan pengedaran UI dalam masa kurang daripada lima minit, dengan saiz APK meningkat di bawah 10% selepas transformasi. Overhed masa/ruang minimum terhasil daripada reka bentuk UI-Scissor, meminimumkan kod yang disuntik dalam apl lama. Terutamanya, saiz APK apl kamera berkurangan sebanyak 16% disebabkan oleh pengalihan keluar logik kod yang tidak diperlukan oleh Soot semasa transformasi apl.
masa pengedaran UI. Untuk menilai prestasi UI-Scissor dalam mengedarkan UI kepada peranti tetamu, kami mengukur masa pengedaran UI untuk setiap senario kes penggunaan. Masa ini ditakrifkan sebagai perbezaan antara masa pengguna mencetuskan pengedaran UI dan masa skrin peranti tetamu dikemas kini kali terakhir. Rajah 2 memecahkan masa pengedaran UI untuk tujuh apl lama. Kalkulator and Nota mempunyai masa pengedaran UI kurang daripada 250 ms, sesuai untuk kegunaan interaktif. Walau bagaimanapun, apl lain mempamerkan masa yang lebih lama, antara 507 ms hingga 633 ms, terutamanya disebabkan oleh masa pemaparan yang panjang. Ini kerana UI apl ini mengandungi imej berkod Base64. Data ini diketahui menyebabkan overhed pemaparan tinggi dalam React Native yang digunakan oleh bekas UI [6]. Untuk memperincikannya, kami mengukur masa pengedaran UI untuk lima jenis UI yang berbeza, seperti yang ditunjukkan dalam Rajah 3. Ia mendedahkan bahawa hanya UI imej yang mengalami masa pemaparan yang tinggi, manakala selebihnya diedarkan dengan cepat dengan pemaparan pendek. Walau bagaimanapun, pengedaran UI ialah overhed satu pukulan untuk menyokong senario berbilang permukaan dan overhed untuk pemaparan imej boleh dikurangkan dengan menggunakan pengoptimuman yang disediakan oleh React Native, seperti ciri modul asli. Menggunakan pengoptimuman ini ditinggalkan untuk kerja masa hadapan.
masa tindak balas UI. Kami mengukur masa tindak balas UI untuk mengemas kini lima jenis UI tetamu. Masa tindak balas UI ditakrifkan sebagai perbezaan masa dari masa pengguna memberikan input sentuhan pada skrin tetamu hingga apabila skrin tetamu menunjukkan hasil input sentuhan melalui setiap UI tetamu. Seperti yang ditunjukkan dalam Rajah 4, bekas UI mengambil masa kira-kira 153ms untuk memproses input pengguna, overhed yang wujud yang disebabkan oleh Native React. UI-Scissor mengendalikan operasi kemas kini UI dengan cekap, menghasilkan masa tindak balas antara 267ms hingga 321ms—sederhana untuk kegunaan interaktif. Ambil perhatian bahawa masa pemaparan untuk kemas kini UI adalah lebih kecil daripada pengedaran UI kerana React Native mencipta struktur data baharu (iaitu, pepohon DOM maya) untuk pemaparan pada pengedaran UI, tetapi semasa kemas kini UI, ia hanya mengubah suai beberapa keadaan grafik bagi yang dijana sebelum ini. struktur data dan menggunakannya semula untuk rendering.
5. Kesimpulan
Kertas kerja ini membentangkan UI-Scissor, rangka kerja baru yang mengubah apl satu peranti secara automatik menjadi apl berbilang permukaan. Rangka kerja kami menyediakan i) alat pengarangan yang menambah apl lama sedia ada dengan ciri pengedaran UI dan ii) perkhidmatan yang membantu pengkomputeran pelbagai permukaan. Kami menjangkakan UI-Scissor boleh mempercepatkan pembangunan apl berbilang permukaan, memberikan pengalaman pengguna baharu.
Penghargaan
Kerja ini disokong oleh geran NRF (NRF-2021R1F1A1063785).
Rujukan
[1] S. Oh, A. Kim, S. Lee, K. Lee, D.R. Jeong, I. Shin, and S.Y. Ko, “FLUID: Flexible User Interface Distribution for Ubiquitous Multi-Device Interaction,” MobiCom, vol.23, no.4, pp.25-29, 2019.
CrossRef
[2] M. Cui, M. Lv, Q. He, C. Zhang, C. Gu, T. Yang, and N. Guan, “Pruid: Practical user interface distribution for multi-surface computing,” DAC, pp.679-684, 2021.
CrossRef
[3] S. Lee, H. Lee, H. Kim, S. Lee, J.W. Choi, Y. Lee, S. Lee, A. Kim, J.Y. Song, S. Oh, S.Y. Ko, and I. Shin, “FLUID-XP: Flexible User Interface Distribution for Cross-Platform Experience,” MobiCom, pp.762-774, 2021.
CrossRef
[4] Sable Research Group, “Soot - a java optimization framework.” https://github.com/Sable/soot.
[5] Meta platforms, Inc., “React native - learn once, write anywhere.” https://reactnative.dev.
[6] Stack Overflow, “React native image loading is too slow.” https://stackoverflow.com/questions/65727698/react-native-image-loading-is-too-slow.