從vue遷移到react

by Gupta Garuda

通過古普塔·歌魯達(Gupta Garuda)

從AngularJS遷移到React-您如何衡量性能提升？ (Migrating from AngularJS to React — how do you measure your performance gains?)

Are you looking into migrating a large AngularJS single page application to React? If so, you may be wondering what sort of performance gains you are going to get with React and how the code will morph (with state management libraries Redux or Mobx).

您是否正在考慮將大型AngularJS單頁應用程序遷移到React？如果是這樣，您可能想知道React將帶來什么樣的性能提升以及代碼將如何變形(使用狀態管理庫Redux或Mobx)。

In this post, I’ll try to answer some of these questions, and give you a lot of data you can use to make more informed decisions.

在本文中，我將嘗試回答其中的一些問題，并為您提供大量可用于做出更明智決策的數據。

First, I will go over the performance and memory profiles of various UI scenarios implemented using AngularJS, React/Redux and React/Mobx. We will compare and contrast the performance of these frameworks on measures like script execution time, frames per sec, and usedJSHeapSize for each scenario.

首先，我將介紹使用AngularJS，React / Redux和React / Mobx實現的各種UI場景的性能和內存配置文件。我們將在每種情況下在腳本執行時間，每秒幀數和usedJSHeapSize等指標上比較和對比這些框架的性能。

I provided the links to the test pages and source code so you can try out those scenarios and can review the code to get a feel for constructs that React (with Redux or Mobx) will bring to the table.

我提供了指向測試頁面和源代碼的鏈接，因此您可以嘗試這些場景并可以查看代碼，以使React(帶有Redux或Mobx)將帶到表中的構造有個感覺。

性能測試設置 (Performance test setup)

To evaluate the performance of AngularJS and React, I created a benchmark application, a stock ticker dashboard. This application shows a list of stocks and has some controls to automate UI test actions. For each stock, the application shows the ticker symbol, company name, sector name, current price, volume and simple moving averages (10 days, 50 days and 200 days), and a visual indicator showing whether the price went up or down. The test dataset consists of 5000 stock tickers and is loaded during the page load via a script tag.

為了評估AngularJS和React的性能，我創建了一個基準應用程序，一個股票行情顯示板。該應用程序顯示了股票列表，并具有一些控件來自動執行UI測試操作。對于每只股票，應用程序均顯示股票代碼，公司名稱，行業名稱，當前價格，交易量和簡單移動平均線(10天，50天和200天)，以及直觀的指示器，顯示價格是漲還是跌。測試數據集由5000個股票行情自動收錄器組成，并在頁面加載期間通過腳本標簽加載。

I created three versions of this application using AngularJS, React/Redux, and React/Mobx. This enables us to easily compare the performance metrics for each scenario across the frameworks.

我使用AngularJS，React / Redux和React / Mobx創建了該應用程序的三個版本。這使我們能夠輕松比較跨框架的每個方案的性能指標。

測試方案 (Test Scenarios)

Switching views
切換檢視

We navigate through a list of 5000 stock tickers showing 150 tickers at a time every 0.5sec. This scenario measures how quickly the framework can update the view when the visible collection data model changes.
我們瀏覽5000個股票行情清單，每0.5秒一次顯示150個股票行情。此方案測量可見集合數據模型更改時框架更新視圖的速度。

Real world use-case: route changes, paging through a listview, virtual scroll, and so on.
現實中的用例：路由更改，通過列表視圖進行分頁，虛擬滾動等。
Adding tickers
添加股票行情

We add 50 tickers to the visible collection every 100ms until we show the entire collection of 5000 tickers. This scenario measures how quickly the framework can create new items. Showing 5000 tickers is not a realistic scenario, but we can visualize the limits where things will fall apart with each framework.
我們每100ms向可見的集合中添加50個標記，直到顯示5000個標記的整個集合。此方案測量框架可以多快地創建新項目。顯示5000個報價不是現實的情況，但是我們可以可視化每個框架將崩潰的限制。

Real world use-case: Pinterest style infinite scroll where new UI elements are added to the DOM as the user scrolls.
現實中的用例：Pinterest樣式的無限滾動，其中在用戶滾動時將新的UI元素添加到DOM。
Quick Updates on Price/Volume
價格/數量快速更新

We render 1500 tickers and start updating price/volume data for random tickers once every 10ms. This scenario measures how quickly frameworks can apply the partial updates to the UI.
我們渲染1500個股票，并開始每10ms更新一次隨機股票的價格/交易量數據。此方案測量框架可以多快將部分更新應用于UI。

Real world use-case: updates to presence indicators, likes, retweets, claps, stock prices, and so on.
現實世界的用例：狀態指示器的更新，如贊，轉發，拍手，股票價格等。
Removing tickers
刪除股票行情

We will first add all 5000 tickers and then start removing 50 tickers from the visible collection once every 100ms.
我們將首先添加所有5000個股票，然后開始每100ms從可見集合中刪除50個股票。

鏈接到測試頁和源 (Links to test pages and source)

All the examples are written in Typescript and the compilation/bundling is done using Webpack. The Readme page for source URL lists the instructions to build and run the applications.

所有示例均以Typescript編寫，并且使用Webpack進行了編譯/捆綁。源URL的自述頁面列出了構建和運行應用程序的說明。

AngularJS — https://guptag.github.io/js-frameworks/AngularJS/examples/angularjs-perf-test/index.html (Source)
AngularJS- https ://guptag.github.io/js-frameworks/AngularJS/examples/angularjs-perf-test/index.html( 源 )
React/Redux — https://guptag.github.io/js-frameworks/Redux/examples/redux-perf-test/index.html
React / Redux- https: //guptag.github.io/js-frameworks/Redux/examples/redux-perf-test/index.html

(
(

Source)
來源 )
React/Mobx — https://guptag.github.io/js-frameworks/Mobx/examples/mobx-perf-test/index.html
React / Mobx- https: //guptag.github.io/js-frameworks/Mobx/examples/mobx-perf-test/index.html

(
(

Source)
來源 )

在我們開始之前... (Before we start…)

All the below metrics are measured on Win10/Intel Xeon E5 @ 2.4GHz, 6 core, 32GB desktop with Chrome browser v60. The numbers will change on different machines/browsers.
以下所有指標均在Win10 / Intel Xeon E5 @ 2.4GHz，6核，32GB臺式機和Chrome瀏覽器v60上進行測量。數字將在不同的機器/瀏覽器上改變。
To see the accurate heap memory data on the test pages, open Chrome with ‘--enable-precise-memory-info’ flag.
要在測試頁上查看準確的堆內存數據，請使用' --enable-precise-memory-info '標志打開Chrome。
React is a library rather than a full-fledged framework like AngularJS. In this post, I used the term framework for simplicity.
React是一個庫，而不是像AngularJS這樣的成熟框架。在本文中，為簡單起見，我使用了術語框架。
Test pages show live JavaScript heap size as Memory.
測試頁將實時JavaScript堆大小顯示為“內存”。

About javascript heap size: In Chrome TaskManager,
關于javascript堆大小：在Chrome TaskManager中，

In Chrome TaskManager, “The Memory column represents native memory. DOM nodes are stored in native memory. If this value is increasing, DOM nodes are getting created. The JavaScript Memory column represents the JS heap. This column contains two values. The value you’re interested in is the live number (the number in parentheses). The live number represents how much memory the reachable objects on your page are using. If this number is increasing, either new objects are being created, or the existing objects are growing. From Fix Memory Issues by Kayce Basques
在Chrome TaskManager中，“ 內存列代表本機內存。 DOM節點存儲在本機內存中。 如果此值增加，則將創建DOM節點。 JavaScript內存列代表JS堆。 此列包含兩個值。 您感興趣的值是實時數字(括號中的數字)。 實時數字表示頁面上的可訪問對象正在使用的內存量。 如果此數目增加，則說明正在創建新對象，或者現有對象正在增加 。凱西·巴斯克(Kayce Basques)的修復內存問題

About Frames per second:
關于每秒幀數：

Most devices today refresh their screens 60 times a second. If there’s an animation or transition running, or the user is scrolling the pages, the browser needs to match the device’s refresh rate and put up one new picture, or frame, for each of those screen refreshes. Each of those frames has a budget of just over 16ms (1 second / 60 = 16.66ms). In reality, however, the browser has housekeeping work to do, so all of your work needs to be completed inside 10ms. When you fail to meet this budget, the frame rate drops, and the content judders on screen. This is often referred to as jank, and it negatively impacts the user’s experience. From Rendering Performance by Paul Lewis
如今，大多數設備每秒刷新屏幕60次。 如果正在運行動畫或過渡，或者用戶正在滾動頁面，則瀏覽器需要匹配設備的刷新率，并為每個屏幕刷新放置一張新圖片或一幀。 這些幀中的每個幀的預算剛好超過16毫秒(1秒/ 60 = 16.66毫秒)。 但是，實際上，瀏覽器需要執行客房整理工作，因此您的所有工作都需要在10毫秒內完成。 如果您無法滿足此預算，則幀速率會下降，并且內容閃爍。 這通常稱為垃圾郵件，會對用戶的體驗產生負面影響。 從保羅·劉易斯的渲染表現

DOM-AngularJS組件與React組件 (DOM - AngularJS Components vs. React Components)

AngularJS directives (or components) create an extra wrapper element around the template. For simple views, this is not an issue. However, in complex views containing a large number of directives (especially when they are repeated within ng-repeat), all the extra elements will add up to the total size of the DOM tree — potentially impacting memory, selector performance, and so on.

AngularJS指令(或組件)在模板周圍創建了一個額外的包裝器元素。對于簡單的視圖，這不是問題。但是，在包含大量指令的復雜視圖中(尤其是在ng-repeat中重復執行這些指令時)，所有額外的元素加起來將達到DOM樹的總大小-可能會影響內存，選擇器性能等。

Although you can set ‘replace=true’ property to disable rendering the wrapper element, it causes a bunch of issues and is currently marked as deprecated.

盡管您可以設置'replace = true'屬性以禁用呈現wrapper元素，但它會引起很多問題，并且當前標記為deprecated 。

Here is the rendered HTML for the ticker component in AngularJS:

這是AngularJS中股票行情顯示組件的渲染HTML：

Here is rendered HTML for the similar ticker component in React:

這是React中類似的代碼組件的呈現HTML：

In our specific example, AngularJS created an additional 1400 DOM nodes compared to React for rendering the same number of tickers (200).

在我們的特定示例中，與React相比，AngularJS創建了額外的1400個DOM節點來渲染相同數量的代碼(200個)。

方案1-切換視圖 (Scenario 1 — Switching Views)

We navigate through a list of 5000 tickers showing 150 tickers at a time every 0.5sec.

我們瀏覽5000個滴答聲的列表，每0.5秒一次顯示150個滴答聲。

The below chart plots the script execution time for each refresh from Chrome’s performance timeline. AngularJS consistently took >200ms to delete the existing 150 tickers and to show the new ones. Whereas React/Redux did the same work within 90–100ms (half the time compared to ng1). The React/Mobx version took slightly more time than the Redux version, but not far from it.

下表繪制了Chrome性能時間軸上每次刷新的腳本執行時間。 AngularJS持續花費200毫秒以上的時間來刪除現有的150個股票并顯示新的股票。而React / Redux在90-100ms內完成了相同的工作(與ng1相比，時間縮短了一半)。 React / Mobx版本比Redux版本花費了更多時間，但相差不遠。

The below chart shows the frames per sec(fps) as the refresh happens. The Redux and Mobx versions stayed around 45fps whereas AngularJS stayed around 30 fps during the entire run.

下表顯示了刷新發生時的每秒幀數(fps)。在整個運行過程中，Redux和Mobx版本保持大約45 fps，而AngularJS保持大約30 fps。

內存和GC暫停 (Memory & GC pauses)

The below chart shows the JavaScript heap size (‘usedJSHeapSize’) measured during the refresh. Both the AngularJS and Mobx versions showed a staircase pattern for the memory consumption, indicating that Chrome kicked in the GC to reclaim the memory. The Redux version is super consistent with its low memory profile all throughout the run.

下表顯示了刷新期間測量JavaScript堆大小(“ usedJSHeapSize”)。 AngularJS和Mobx版本都顯示了內存消耗的階梯模式，表明Chrome瀏覽器加入了GC以回收內存。在整個運行過程中，Redux版本與其低內存配置文件非常一致。

Let’s closely look into the timeline profiles for all the three versions.

讓我們仔細查看所有三個版本的時間線配置文件。

AngularJS execution caused several GC pauses as the ticker list gets refreshed. V8 tries to hide GC pauses by scheduling them during the unused chunks of idle times to improve the UI responsiveness. Contrary to this ideal behavior, GC pauses happened during the script execution contributing to the overall execution time.

隨著股票清單的刷新，AngularJS的執行導致了幾次GC暫停。 V8嘗試通過在未使用的空閑時間塊中安排GC暫停來隱藏GC暫停，以提高UI響應能力。與這種理想行為相反，GC暫停在腳本執行期間發生，這占了整個執行時間。

The Redux performance profile shows no GC pauses whatsoever during the script execution.

Redux性能配置文件顯示在腳本執行過程中，GC均未暫停。

The Mobx profile shows few GC pauses, but not as many as the AngularJS version.

Mobx配置文件顯示的GC暫停很少，但不如AngularJS版本那么多。

方案2-添加股票行情 (Scenario 2 — Adding Tickers)

We will add 50 tickers to the visible collection every 100ms until we show all the tickers. The result of showing all 5000 tickers is not a realistic scenario, but it would be interesting to see how each framework handles it.

我們將每100毫秒將50個股票添加到可見集合中，直到我們顯示所有股票。顯示所有5000個標記的結果不是現實的情況，但是看看每個框架如何處理它會很有趣。

The below chart plots the script execution time from Chrome’s performance timeline. In the case of AngularJS, the script execution time linearly increased as more and more tickers were added to the page. AngularJS took more time to add new tickers right from the start compared to the other versions.

下圖從Chrome的性能時間表繪制了腳本執行時間。對于AngularJS，隨著越來越多的代碼添加到頁面中，腳本執行時間線性增加。與其他版本相比，AngularJS從一開始就花費了更多時間來添加新的代碼。

Interestingly, the Redux and Mobx versions show impressive performance even towards the right side of the chart with thousands of tickers on the page. React’s virtual DOM diffing algorithm is showing its strength compared to AngularJS’s dirty checking.

有趣的是，Redux和Mobx版本甚至在圖表的右側也顯示了令人印象深刻的性能，頁面上有成千上萬的報價。與AngularJS的臟檢查相比，React的虛擬DOM差異算法正在展示其優勢。

With AngularJS, adding new items caused jank in the browser right from the start (red bars) and the number of frames per second dropped from 60 early on and never recovered (green area) during the entire add operation.

使用AngularJS，添加新項會從一開始就在瀏覽器中造成鋸齒(紅色條)，并且每秒幀數從60早就下降，并且在整個添加操作期間從未恢復(綠色區域)。

Redux created jank once early-on, but it is all clear until we crossed the halfway point of adding new tickers. FPS also nicely recovered to 60 in between the add operations.

Redux早些時候就創建了jank，但直到我們超過添加新的代碼的中間點時，一切都是清楚的。在添加操作之間，FPS也很好地恢復到60。

Mobx caused jank few times more times than Redux, but nowhere close to AngularJS.

Mobx造成jank的次數是Redux的幾倍，但遠不及AngularJS。

內存和GC事件 (Memory & GC events)

Redux consumed about half the heap size as AngularJS during the entire run. Mobx stayed in between.

在整個運行過程中，Redux消耗的堆大小約為AngularJS的一半。 Mobx停留在兩者之間。

Adding new tickers also triggered some GC pauses with AngularJS (almost once with every add operation). Redux triggered fewer GC pauses overall. Mobx started to trigger more GC pauses towards the end as we added more and more tickers to the list.

添加新的代碼也觸發了AngularJS的GC暫停(每次添加操作幾乎都暫停了一次)。 Redux總體上觸發了較少的GC暫停。隨著我們在列表中添加越來越多的行情收錄器，Mobx開始在結尾處觸發更多的GC暫停。

方案3-快速更新價格/數量 (Scenario 3 — Quick Updates to Price/Volume)

This is the most common scenario in the real-time applications. Once the view is rendered, there will be a quick succession of updates coming into the application either via web-sockets, xhr calls, and so on. Imagine the use-cases like presence updates, stock price changes, likes/retweets/claps count changes, and more. Let’s see how each framework fares in this scenario.

這是實時應用程序中最常見的情況。呈現視圖后，將通過Web套接字，xhr調用等快速連續地將更新引入應用程序。想象一下用例，例如狀態更新，股價變化，點贊/轉發/拍張數量更改等。讓我們看看每種框架在這種情況下的表現。

All the below metrics are taken with 1500 tickers on the page and when price/volume changes are happening every 10ms.

以下所有指標都是在頁面上以1500個滴答作響的，并且每10毫秒發生一次價格/數量變化。

AngularJS again struggled to keep up with the updates happening in quick succession. Script execution for each update took about 35ms. Redux took 6ms to update the view. Mobx shines, updating the view within 2ms. Mobx’s derivation graph knows exactly which component to update based on which observable’s state is changed.

AngularJS再次努力跟上快速連續更新的步伐。每次更新的腳本執行大約需要35毫秒。 Redux用了6毫秒來更新視圖。 Mobx發光，在2ms內更新視圖。 Mobx的推導圖可根據更改的可觀察狀態準確地知道要更新的組件。

Here are the timeline profiles showing the script execution for each version.

以下是時間軸配置文件，顯示了每個版本的腳本執行情況。

FPS consistently stayed at 60 with Redux and Mobx, whereas it hovered a little below 30 with AngularJS.

Redux和Mobx的FPS始終保持在60，而AngularJS則保持在30以下。

方案4-刪除股票代碼 (Scenario 4 — Deleting Tickers)

We will add all 5000 tickers to the page and start removing 50 tickers from the visible collection every 100ms.

我們將向頁面添加所有5000個標記，并開始每100毫秒從可見集合中刪除50個標記。

The below images show the performance profile of the initial delete iterations. AngularJS is almost 4x slower compared to React versions. Redux and Mobx took a little more time in the initial iterations but settled between 50–70ms for each delete operation.

下圖顯示了初始刪除迭代的性能概況。與React版本相比，AngularJS幾乎慢了4倍。 Redux和Mobx在最初的迭代中花費了一些時間，但每次刪除操作的時間在50-70ms之間。

It’s pretty clear from all the above tests that React gives significant performance gains when compared with AngularJS.

從以上所有測試中可以很明顯地看出，與AngularJS相比，React可以顯著提高性能。

As the applications grow bigger and views get more complex, the runtime profile of the frameworks starts to differ in their various ways. Our objective was to replicate the scenarios we were targeting for, measure the performance/memory impact, and look at the pro/cons of the constructs with each framework.

隨著應用程序的增長和視圖的復雜化，框架的運行時配置文件開始以各種方式出現差異。我們的目標是復制我們要針對的場景，衡量性能/內存影響，并查看每個框架的構造的利弊。

Even with the most performant framework out there, we still need to apply a lot of discipline and follow the right patterns to make the applications scalable and performant.

即使有最高性能的框架，我們仍然需要運用大量的紀律并遵循正確的模式以使應用程序具有可擴展性和高性能。

I go over the core concepts, benefits, and gotchas of Redux and Mobx in a separate post.

我將在另一篇文章中介紹Redux和Mobx的核心概念，優勢和陷阱。

Thanks for reading. Hope this is helpful.

謝謝閱讀。希望這會有所幫助。

P.S. Thanks to Shyam Arjarapu and Adam Carr for reviewing this article.

PS感謝Shyam Arjarapu和Adam Carr審閱了本文。