前臺性能優化總結

場景

某天上完課，走在路上，忽然想起來，一個企業中，計算機量可能很大，500到2000左右。

分組時，可能會很耗時，前臺能不能承受的住。

模擬加了1000臺計算機，前臺直接炸，將近4秒才能出來，而且選擇的時候也很卡。

學習了不少數據量多時性能優化的方法，目前前臺通過一系列優化，能保證在Chrome瀏覽器環境、1000臺測試機的條件下，，2s內完成頁面渲染。

優化

組件介紹

前臺多選使用的是NZ爲咱們提供的多選框組件，該組件要求輸入信息必須知足必定格式。

/**
 * NZ 多選框
 * nz-checkbox-group
 * 數據格式規範
 */
export class NzCheckBoxSpec<T> {
    label: string;
    value: T;
    checked: boolean;
}

因此，計算機多選組件總體邏輯以下：

1. 獲取外部傳入的計算機列表(考慮到默認選中的問題)。
2. 從後臺查詢全部的計算機列表。
3. 根據全部計算機構造NZ多選框組件的輸入，checked一項根據當前遍歷的計算機是否在傳入的計算機列表中判斷。

性能問題

看着問題不大：

this.hostService.getAllHosts().subscribe((hosts) => {
    this.hostListValues = [];
    // 使用主機信息構造多選框綁定數據
    hosts.forEach((host) => {
        this.hostListValues.push({
            label: host.name,
            value: host,
            checked: HostCheckboxComponent.existIn(host, this._hostList)
        });
    });
});

查閱相關資料，原來一直都用的有問題，forEach雖然很好使，可是是性能最低的一種循環。

性能測試

我親自寫測試代碼測試三種循環方式的性能(數據量2000，內部執行一樣業務操做)：

實驗次數 / 實驗方法	forEach	for of	for
1	654ms	524ms	517ms
2	604ms	571ms	563ms
3	550ms	506ms	508ms
4	621ms	495ms	522ms
5	506ms	562ms	470ms
平均時間	587ms	531.6ms	516ms

我這裏只是部分少許數據，結果具備隨機性，不具備廣泛性。

反正這裏我是總結出幾點：

1. 當數據量少的時候，我使用forEach，方便。
2. 當數據量大的時候，我是用for循環，性能略好。
3. 當須要在循環中return時，使用for of，方便。

學習過程當中還查到了Duff's Device，這是目前性能最好的循環方式。有人測試，Duff's Device須要達到30萬的數據量才能顯示其算法高效的性能。

組件的錯誤使用

最開始，組件是這樣使用的。

<app-host-checkbox [hostList]="hostGroup.hostList"
                   (hostCheck)="bindHostList($event)"></app-host-checkbox>

看着沒啥毛病啊，把計算機組的hostList傳進去，而後一個輸出事件，綁定hostCheck事件，當選中的計算機有改動的時候就調用bindHostList()方法。

bindHostList(hostList: Array<Host>): void {
    this.hostGroup.hostList = hostList;
}

注意看這張圖：

1. 頁面把hostGroup的hostList傳給組件。
2. 組件初始化，當用戶選擇的時候，再把選中的值回傳給hostGroup。
3. hostGroup的hostList變了，又傳給組件了。

因此，組件初始化執行了兩次，原本for循環就已經很耗時了，更況且執行兩次。以前測試數據少沒發現。

新建臨時變量，該變量只用於傳輸入的hostList。

總結

在校學習過的東西，咱們老是好久之後用到。

若是不是華軟項目，也用不到學過的計算機網絡，沒有大數據量，學的算法複雜度也用不上。

當編碼不是問題的時候，咱們開始考慮設計與用戶體驗。