最佳化啟動效能

提高啟動效能通常是效能最佳化中最具價值的方面之一。您的應用程式啟動需要多長時間?在應用程式載入時,它是否會鎖定裝置或使用者的瀏覽器?這會讓使用者擔心您的應用程式崩潰或其他問題。良好的使用者體驗包括確保應用程式快速載入。本文提供了有關編寫新應用程式和將應用程式從其他平臺移植到 Web 的效能提示和建議。

快速非同步載入

無論平臺如何,儘快啟動始終是一個好主意。由於這是一個普遍問題,因此我們在這裡不會過多關注它。相反,我們將關注構建 Web 應用程式時一個更重要的問題:儘可能非同步啟動。這意味著不要在應用程式主執行緒上的單個事件處理程式中執行所有啟動程式碼。

相反,建立一個 Web 工作執行緒,在後臺執行緒中儘可能多地執行操作(例如,獲取和處理資料)。將任務委派給 Web 工作執行緒可以釋放主執行緒來執行需要它的任務,例如使用者事件和渲染 UI。反過來,主執行緒事件應包含許多小型任務,也稱為 微任務,而不是更大的、更耗時的任務。

非同步載入有助於防止頁面和使用者介面看起來(或實際變得)無響應。透過最大程度地減少單個載入任務所需的時間,應用程式的 事件迴圈 將在啟動時繼續迴圈。這將防止應用程式、瀏覽器和/或裝置看起來凍結。

在最壞的情況下,阻塞主執行緒會導致使用者解除安裝您的應用程式;例如,如果某人錯誤地啟動了您的應用程式,並且他們無法阻止關閉應用程式,他們可能會採取措施以防止這種情況再次發生。

有志者事竟成…

第一次就用“正確”的方式編寫所有內容比事後為了效能(和無障礙性)而進行改造要容易得多。從頭開始時,使適當的程式碼塊非同步意味著不需要改造。所有純啟動計算都應在後臺執行緒中執行,同時儘可能縮短主執行緒事件的執行時間。不要包含進度指示器以讓使用者知道正在發生什麼以及他們需要等待多長時間,而是讓進度條變得不必要。

另一方面,將現有應用程式移植到 Web 可能具有挑戰性。原生應用程式不需要以非同步方式編寫,因為作業系統通常會為您處理載入。源應用程式可能有一個主迴圈,可以輕鬆地使其非同步執行(透過分別執行每個主迴圈迭代);啟動通常只是一個連續的、單塊的過程,它可能會定期更新進度計。

雖然您可以使用 Web 工作執行緒 非同步執行非常大、持續時間長的 JavaScript 程式碼塊,但有一個很大的警告:Web 工作執行緒無法直接操作 DOM,並且對 window 物件的方法和屬性的訪問有限,包括對 WebGL 的訪問。這意味著,除非您能夠輕鬆地將啟動過程中的“純計算”塊提取到工作執行緒中,否則您最終將不得不將大部分或全部啟動程式碼執行在主執行緒上。

但是,即使像這樣的程式碼也可以透過一些工作來實現非同步。

實現非同步

以下是一些關於如何構建啟動過程以使其儘可能非同步(無論是新應用程式還是移植應用程式)的建議。

  • 在 Web 應用程式需要的指令碼標記上使用 deferasync 屬性。這允許 HTML 解析器繼續處理文件,而不是必須等到指令碼下載並執行完畢才能繼續。
  • 如果您需要解碼資產檔案(例如,解碼 JPEG 檔案並將其轉換為 WebGL 稍後使用的原始紋理資料),那麼在工作執行緒中進行解碼非常有用。
  • 在處理瀏覽器支援的資料(例如,解碼影像資料)時,請使用瀏覽器或裝置內建的解碼器,而不是自己編寫或使用原始程式碼庫中的解碼器。提供的解碼器幾乎肯定快得多,並且可以減少應用程式的大小。此外,瀏覽器可能會自動並行化這些解碼器。
  • 任何可以並行執行的資料處理都應該並行執行。不要依次處理一批資料;儘可能同時處理所有資料!
  • 不要在啟動 HTML 檔案中包含不參與 關鍵渲染路徑 的指令碼或樣式表。僅在需要時載入它們。
  • 減小 JavaScript 檔案的大小。嘗試將檔案的縮小版本傳送到瀏覽器,並使用 Gzip 或 Brotli 等壓縮方式。
  • 儘可能利用資源提示(如預連線或預載入)來指示瀏覽器哪些檔案對您的應用程式更重要。

您能夠非同步執行的操作越多,您的應用程式就能更好地利用多核處理器。

移植問題

完成初始載入後,應用程式的主程式碼開始執行,您的應用程式可能必須是單執行緒的,尤其是如果它是一個移植應用程式。為了幫助主程式碼的啟動過程,最重要的是將程式碼重構為小塊。然後可以將這些小塊在多個對應用程式主迴圈的呼叫中交錯執行(以便主執行緒能夠處理輸入等)。

Emscripten 提供了一個 API 來幫助進行這種重構;例如,您可以使用 emscripten_push_main_loop_blocker() 來建立一個函式,該函式將在允許主執行緒繼續之前執行。透過建立一個要按順序呼叫的函式佇列,您可以更容易地管理執行程式碼塊而不阻塞主執行緒。

但是,這仍然存在一個問題,即必須重構現有的程式碼才能以這種方式工作。這可能需要一些時間。

我應該多非同步?

您的網站越快變得可用,響應使用者輸入的速度越快,它看起來就會越好。一個在內容首次出現之前需要 1 或 2 秒的網站通常被認為是快速的;如果您習慣於網站需要 3 或 4 秒,那麼 7 或 8 秒就會感覺很長。

在響應能力方面,使用者不會注意到 50 毫秒或更短的延遲。任何超過 200 毫秒的延遲,使用者都會感覺到您的網站很遲鈍。在努力提高應用程式的載入速度和響應能力時,請記住,許多使用者可能擁有比您更舊、更慢的計算機,他們可能會遇到比您更長的延遲!

其他建議

除了非同步之外,還有其他一些事情可以幫助您提高應用程式的啟動時間。以下是一些方法。

下載時間

請記住使用者下載應用程式資料需要多長時間。如果您的應用程式非常受歡迎,或者必須頻繁地重新下載內容,那麼您應該嘗試使用盡可能快的託管伺服器。始終 壓縮 您的資料以使其儘可能小。

資料大小

盡力最佳化資料的大小;更小級別檔案比更大的檔案下載速度更快,處理速度也更快。

主觀因素

在啟動過程中,您能做任何事情來幫助使用者保持參與度,這將有助於使時間看起來過得更快。顯示一個模擬啟動畫面可以提高 感知效能。對於大型網站,您能做任何事情來幫助使用者感覺您的應用程式正在做些什麼,而不是靜靜地停在那裡,這將有所幫助。

另請參閱