Bagaimana untuk mengoptimumkan prestasi dalam sudut? Analisis ringkas kaedah pengesanan perubahan

sudutBagaimana untuk mengoptimumkan prestasi? Artikel berikut akan memberi anda pengenalan yang mendalam kepada penyelesaian pengoptimuman prestasi Angular - pengesanan perubahan Saya harap ia akan membantu anda!

sudut Pengoptimuman Prestasi - Pengesanan Perubahan

Untuk penerangan penunjuk prestasi bahagian hadapan, industri mempunyai Bercakap tentang perkataan sendiri, secara ringkasnya, ia berkaitan dengan prestasi skrin pertama dan kelancaran halaman. Kali ini, kami akan menganalisis pengoptimuman prestasi interaksi halaman dari perspektif kelancaran halaman. [Cadangan tutorial berkaitan: "tutorial sudut"]

Apakah kelancaran halaman?

Kefasihan halaman ditentukan oleh kadar bingkai FPS (Bingkai Sesaat - bilangan bingkai yang dihantar sesaat Secara umumnya, kadar penyegaran semula skrin pelayar arus perdana ialah 60Hz (dimuatkan semula 60 kali sesaat). . akan menjadi Bingkai jatuh dan gagap berlaku. 根因在于：浏览器中的 JavaScript 执行和页面渲染会相互阻塞.

Dalam devtools Chrome kita boleh laksanakan Cmd Shift P dan masukkan show fps untuk membuka panel fps dengan cepat, seperti yang ditunjukkan di bawah:

Dengan memerhati panel FPS , kita boleh memantau kelancaran halaman semasa dengan mudah

1 Faktor yang mempengaruhi prestasi halaman

Sama ada interaksi halaman adalah lancar bergantung pada sama ada respons halaman lancar dan Respon halaman pada asasnya ialah proses pemaparan semula perubahan status halaman ke halaman.

Proses respons halaman adalah kira-kira seperti berikut:

Secara amnya, Logik pemprosesan acara Pengendali Acara tidak mengambil terlalu banyak masa, jadi faktor utama yang mempengaruhi prestasi sudut ialah 异步事件触发 dan 变更检测. Secara amnya, logik pemprosesan acara Pengendali Acara tidak mengambil terlalu banyak masa, jadi faktor yang mempengaruhi prestasi Sudut terutamanya terletak pada pencetus peristiwa tak segerak dan pengesanan perubahan.

Untuk Angular, proses pemaparan halaman ialah proses pengesanan perubahan Dapat difahami bahawa pengesanan perubahan Angular mesti diselesaikan dalam masa 16.6ms untuk mengelakkan kehilangan bingkai halaman dan ketinggalan.

Prestasi respons halaman boleh dioptimumkan daripada tiga aspek berikut.

(1) Untuk peringkat peristiwa pencetus, anda boleh mengurangkan pencetus peristiwa tak segerak untuk mengurangkan bilangan keseluruhan pengesanan perubahan dan pemaparan semula;

(2) Untuk peringkat logik pelaksanaan Pengendali Peristiwa, masa pelaksanaan boleh dikurangkan dengan mengoptimumkan logik kod kompleks; anda boleh

Kurangkan bilangan pengesanan perubahan

dan pengiraan data templat untuk mengurangkan masa pemaparan; Untuk (2) Pengendali Acara, isu khusus perlu dianalisis secara terperinci tanpa perbincangan, terutamanya untuk ( 1) (3) Optimumkan

2 Pelan pengoptimuman

2.1 Kurangkan mencetuskan peristiwa tak segerak

Dalam mod pengesanan perubahan lalai Angular, peristiwa tak segerak akan mencetuskan pengesanan perubahan global Oleh itu, mengurangkan pencetus peristiwa tak segerak akan meningkatkan prestasi Angular.

Acara tak segerak termasuk acara Tugas Makro dan acara Tugas Mikro

Pengoptimuman peristiwa tak segerak adalah terutamanya untuk acara pemantauan dokumen. Contohnya, klik, naik tetikus, gerak tetikus... dan acara mendengar lain pada dokumen.

Mendengar adegan acara:

Renderer2.listen(dokumen, …)

fromEvent(document,…)

           document.addEventListener(…)

Acara mendengar DOM mesti dialih keluar apabila ia tidak diperlukan lagi.

Contoh: [pop] Perintah kotak gesaan

Senario penggunaan: menapis lajur jadual, mengklik tempat selain ikon atau menatal halaman, menyembunyikan kotak timbul penapis lajur

Pendekatan sebelumnya adalah untuk terus Memantau acara klik dan acara tatal dokumen dalam arahan pop mempunyai kelemahan bahawa kotak gesaan tidak dipaparkan, tetapi acara pemantauan masih wujud, yang sangat tidak munasabah.

Penyelesaian yang munasabah: Hanya dengar acara klik dan tatal apabila kotak gesaan dipaparkan dan alih keluar acara mendengar apabila ia disembunyikan.

Untuk acara mendengar DOM yang sering dicetuskan, anda boleh menggunakan pengendali rjx untuk mengoptimumkan acara. Untuk butiran, rujuk Rjx Operator. Gli RxJS.

2.2 Pengesanan Perubahan

Apakah pengesanan perubahan?

Untuk memahami pengesanan perubahan, kita boleh mencari jawapan daripada matlamat pengesanan perubahan. Matlamat pengesanan perubahan sudut adalah untuk memastikan model (kod TypeScript) dan templat (HTML) disegerakkan. Oleh itu, pengesanan perubahan boleh difahami sebagai: Semasa mengesan perubahan model, kemas kini templat ( DOM ) .

Apakah proses pengesanan perubahan?

Dengan melakukan pengesanan perubahan dalam pepohon komponen dalam susunan atas-bawah, iaitu pengesanan perubahan dilakukan pada komponen induk dahulu, dan kemudian pada komponen anak Komponen melakukan pengesanan perubahan. Mula-mula semak perubahan data komponen induk, dan kemudian kemas kini templat komponen induk Apabila mengemas kini templat, apabila menemui komponen anak, ia akan mengemas kini nilai yang terikat pada komponen anak, dan kemudian masukkan komponen anak untuk melihat sama ada komponen anak. indeks nilai input @Input telah berubah Jika ia berubah, tandakan subkomponen sebagai kotor, yang memerlukan pengesanan perubahan seterusnya Selepas menandakan subkomponen, teruskan mengemas kini templat di belakang subkomponen dalam komponen induk. Selepas semua templat komponen induk telah dikemas kini, buat perubahan pada pengesanan subkomponen.

2.2.1 Prinsip pengesanan perubahan sudut

Dalam mod lalai pengesanan perubahan lalai, prinsip peristiwa tak segerak yang mencetuskan pengesanan perubahan Angular ialah sudut memanggil ApplicationRef apabila memproses peristiwa tak segerak menggunakan Zone.js Kaedah tick() melakukan pengesanan perubahan daripada komponen akar kepada komponen anaknya. Semasa proses pemulaan aplikasi Sudut, zon (NgZone) dimulakan, dan kemudian semua logik dijalankan dalam objek _dalam objek.

Zone.js melaksanakan kelas berikut:

• Kelas zon, persekitaran pelaksanaan acara JavaScript Seperti urutan, mereka boleh membawa beberapa data dan mungkin mempunyai zon induk dan anak.
• Kelas ZoneTask, acara tak segerak yang dibungkus, tugasan ini mempunyai tiga subkelas:
• • MicroTask, dicipta oleh Promise.
  • MacroTask, dicipta oleh setTimeout dsb.
  • EventTask, dicipta oleh addEventListener dsb., seperti acara dom.
• Objek ZoneSpec, parameter yang disediakan kepadanya semasa mencipta ngZone, mempunyai tiga cangkuk yang boleh mencetuskan pengesanan:
• • onInvoke, panggil tertentu Cangkuk yang dicetuskan apabila fungsi panggil balik dipanggil.
  • onInvokeTask, cangkuk yang dicetuskan apabila ZoneTask dicetuskan, seperti apabila setTimeout tamat tempoh.
  • onHasTask, cangkuk yang dicetuskan apabila mengesan kehadiran atau ketiadaan ZoneTask (iaitu, dicetuskan untuk zon jadual pertama dan tugasan panggilan atau batal terakhir).
• Kelas ZoneDelegate, bertanggungjawab untuk memanggil cangkuk.

Prinsip proses pengesanan adalah kira-kira seperti berikut:

Operasi pengguna mencetuskan peristiwa tak segerak (seperti peristiwa dom, permintaan antara muka...)

= > Kelas ZoneTask mengendalikan acara. Kaedah runTask() zon dipanggil dalam fungsi invokeTask() Dalam kaedah runTask, zon memanggil cangkuk ZoneSpec melalui atribut contoh _zoneDelegate

=> Tiga cangkuk ZoneSpec (onInvokeTask, onInvoke, onHasTask) Dalam cangkuk, pemberitahuan zone.onMicrotaskEmpty.emit(null) dicetuskan melalui fungsi checkStable()

=> Komponen akar memanggil tick() selepas mendengar onMicrotaskEmpty, dan kaedah tick memanggil detectChanges()Mulakan pengesanan daripada komponen akar

=> ... >)refreshView()executeTemplate()Carta aliran prinsip pengesanan perubahan yang terperinci: executeTemplate

Permudahkan proses:

Cetuskan peristiwa tak segerak

=> ZoneTask mengendalikan acara

=> daripada ZoneSpec Trigger onMicrotaskEmpty notification

=> Komponen akar menerima pemberitahuan onMicrotaskEmpty, melaksanakan tick(), dan mula mengesan dan mengemas kini dom

Seperti yang dapat dilihat daripada kod di atas, 当微任务为空的时候才会触发变更检测.

Carta alir prinsip pengesanan perubahan mudah:

Analisis kod sumber sudut Rujukan Zone.js blog.

2.2.2 Pelan pengoptimuman pengesanan perubahan

1) Gunakan mod OnPush

Prinsip: Kurangkan satu pengesanan perubahan yang memakan masa.

Perbezaan antara mod OnPush dan mod Lalai ialah: acara mendengar DOM, acara pemasa dan janji tidak akan mencetuskan pengesanan perubahan. Status komponen dalam mod Lalai sentiasa SemakSentiasa, yang bermaksud bahawa komponen mesti diuji setiap kitaran pengesanan.

Dalam mod OnPush: Situasi berikut akan mencetuskan pengesanan perubahan

S1 Rujukan @Input bagi komponen berubah.

S2 peristiwa terikat DOM bagi komponen, termasuk peristiwa terikat DOM bagi subkomponennya, seperti klik, serahkan, tetikus ke bawah. @HostListener()

Nota:

Acara DOM yang didengar melalui renderer2.listen() tidak akan mencetuskan pengesanan perubahan

Begitu juga kaedah mendengar asli melalui dom.addEventListener() Akan mencetuskan pengesanan perubahan

S3, Acara langganan boleh diperhatikan dan menetapkan paip Async pada masa yang sama.

S4 Gunakan kaedah berikut untuk mencetuskan pengesanan perubahan secara manual:

ChangeDetectorRef.detectChanges(): Pencetus pengesanan perubahan untuk komponen semasa dan bukan OnPush subkomponen.

ChangeDetectorRef.markForCheck(): Tandai paparan semasa dan semua nenek moyangnya sebagai kotor, dan pengesanan akan dicetuskan dalam kitaran pengesanan seterusnya.

ApplicationRef.tick(): Pengesanan perubahan tidak akan dicetuskan

2) Gunakan NgZone.runOutsideAngular()

Prinsip: Kurangkan bilangan pengesanan perubahan

Adakah pemantauan acara DOM Global ditulis dalam panggilan balik kaedah NgZone.runOutsideAngular() tidak akan mencetuskan pengesanan perubahan Angular. Jika komponen semasa belum dikemas kini, anda boleh melaksanakan cangkuk detectChanges() ChangeDetectorRef dalam fungsi panggil balik untuk mencetuskan pengesanan perubahan komponen semasa secara manual.

Contoh: komponen ikon dinamik app-icon-react

2.2.3 Kaedah nyahpepijat

Kaedah 1: Boleh dikawal dalam pelayar Taiwan, gunakan pemalam Angular DevTools untuk melihat acara DOM tertentu, status pengesanan sudut:

Kaedah 2: Anda boleh terus memasukkan: ng.profiler. timeChangeDetection() dalam konsol untuk melihat masa Pengesanan, dengan cara ini anda boleh melihat masa pengesanan global. Blog rujukanMemprofilkan Pengesanan Perubahan Sudut

2.3 Pengoptimuman Templat (HTML)

2.3.1 Kurangkan DOM Rendering: ngFor plus trackBy

Menggunakan atribut trackBy *ngFor, Angular hanya menukar dan memaparkan semula entri yang diubah tanpa perlu memuat semula keseluruhan senarai entri.

Contohnya: senario pengisihan jadual. Jika trackBy ditambahkan pada ngFor, hanya elemen dom baris akan dialihkan apabila jadual dipaparkan Jika trackBy tidak ditambahkan, elemen dom jadual sedia ada akan dipadamkan dahulu, dan kemudian elemen dom baris akan ditambah. Jelas sekali prestasi menggerakkan elemen dom sahaja akan menjadi lebih baik.

2.3.2 Jangan gunakan fungsi dalam ungkapan templat

Jangan gunakan panggilan fungsi dalam ungkapan templat Sudut Anda boleh menggunakan paip sebaliknya, atau anda boleh menggunakan pembolehubah selepas pengiraan manual. Apabila fungsi digunakan dalam templat, tidak kira sama ada nilai telah berubah atau tidak, fungsi akan dilaksanakan setiap kali pengesanan perubahan dilakukan, yang akan menjejaskan prestasi.

Senario untuk menggunakan fungsi dalam templat:

2.3.3 Kurangkan penggunaan ngFor

Menggunakan ngFor akan menjejaskan prestasi apabila jumlah data adalah besar.

Contoh:

Gunakan ngFor:

Tidak menggunakan ngFor: prestasi meningkat kira-kira 10 kali

Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila lawati: Video Pengaturcaraan! !

Atas ialah kandungan terperinci Bagaimana untuk mengoptimumkan prestasi dalam sudut? Analisis ringkas kaedah pengesanan perubahan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!