作者 | 金盛杰(司旭)

一、背景

1.1 業務背景

支付寶卡包存放著用戶的會員卡和優惠券。無論是卡券cell，還是卡券詳情，都是通過靜態模板配置加上動態可變數據，最終呈現給終端用戶的。

下面【圖1】展現了卡券數據在C端用戶的展現形式，【圖2】表示了C端數據組裝過程。

?

?【圖1】卡券數據在C端展現形式

??

【圖2】C端數據組裝過程

以【圖2】為例，模板中有availableAmount 和voucherName 兩個變量，這兩個變量在動態變量數據有對應的值。用動態的值替換掉模板里面對應的這兩個變量，最后拼裝成“100元紅包名稱”。當這個紅包被使用了一次，消費了30元后，動態數據里面availableAmount 的值就會變成70。用戶再次進入到紅包詳情頁時，展現數據重新組裝后就會變成“70元紅包名稱”。?

1.2 問題發現

最近做項目過程中，把卡券組裝渲染邏輯好好的梳理了一遍，其中仔細研讀了【圖3】這段模板變量替換邏輯。這是一段老代碼，從卡包產品誕生之日起就存在，差不多有十年的時間了。其作用就是用動態數據替換掉模板里面的變量。這段代碼邏輯咋一看，并沒有什么問題，就是把模板里面兩個$ 之間（包含）的變量，用動態數據進行替換。考慮到這是一段極為核心又高頻的調用邏輯，于是看看有沒有性能優化的空間。

【圖3】模板變量替換代碼實現

把替換邏輯厘清了之后，第一感覺就是這段代碼有性能提升的空間。主要有兩點：

• 每次while 循環進行了兩次indexOf 操作
• 每次while 循環都進行了substring 操作

于是，就有了下面兩個疑問：

• 能夠減少indexOf 和substring 操作嗎？
• 真的每次都要進行模板變量查找嗎？

二、性能優化

帶著上面兩個問題，逐步進行性能優化并測試。

整個優化過程一共迭代了5版，并最終取得了性能提升超過10倍的效果。下面分別來介紹下不同版本的實現和性能對比。?

2.1 性能優化V1

這一版去掉了indexOf 和substring 操作，轉而使用另一種替換方式。

之前的替換邏輯是從頭到尾循環模板內容字符串，遇到$ 之間的變量就進行替換，過程中需要不斷的進行indexOf 和substring 操作。新的實現方式是在進行變量替換之前，通過循環模板內容字符串，利用雙指針把模板里面所有變量都提取出來，再對變量集合進行循環，依次替換掉模板內容里面的變量。

【圖4】性能優化V1代碼實現?

2.2 性能優化V2

靜態模板配置一般情況下不會發生變更。也就意味著，同一個模板對應的變量都是固定不變的。可以將模板id和模板變量集合進行一對一的緩存，減少每次替換之前的變量提取。

在決定使用緩存之前，要想好怎么實現緩存。有兩點需要注意：

• 用本地緩存代替TBase，減少大流量場景下對TBase的壓力
• 么控制本地緩存的有效數量，并在有限的內存占用情況下最大化緩存效率

可以借助Google Guava庫的緩存類來實現緩存邏輯，示例代碼見【圖5】

??

【圖5】緩存實現示例代碼

??【圖6】性能優化V2代碼實現

2.3 性能對比（1）

做完上面兩步之后進行了性能測試，性能對比如【圖7】所示。

【圖7】V1、V2版性能對比

通過性能對比發現，V1版相對于原始版有性能提升，帶緩存的V2版相對于不帶緩存的V1版也有性能提升。但隨著流量增大，性能優化效果逐步減弱。說明V1、V2版耗時優化的點，在整個模板變量替換耗時中占比并不高。也同時說明，整個模板變量替換邏輯當中，還存在其他更為耗時的點。

回過頭來再仔細看一遍變量替換邏輯，突然間意識到遺漏了一個”大問題“。就是這個String.replace 方法，該方法有兩個耗時點：

• 每次replace 都會進行模板編譯
• replace 都是創建一個新的對象進行返回

并且每次replace 之后還要進行變量的重新賦值。

??

【圖8】String.replace 代碼實現

2.4 性能優化V3

在V2版基礎上，去掉replace  方法，用StringBuilder  來實現。

??

【圖9】性能優化V3代碼實現

StringBuilder 實現過程中有一點要注意。V2版本中，提取變量返回的是一個Set 集合。返回集合中出現變量的順序和模板中變量順序會不一致，模板中有多個相同變量的情況下，也只會替換第一個出現的變量。所以要將變量提取返回的結果換成有序可重復的List ，才能保證邏輯的正確性。

2.5 性能優化V4

V3版優化之后，性能提升明顯，證明String.replace 方法才是整個模板變量替換邏輯中最為耗時的點。于是在原方法上只用StringBuilder 來替換String.replace ，得到V4版。

??

【圖10】性能優化V4代碼實現?

2.6 性能對比（2）

【圖11】V1、V2、V3、V4版性能對比

通過【圖11】可以明顯的發現，在進行StringBuilder 實現后，性能提升超過10倍，效果十分明顯。?

V4版耗時實際上比V3版帶緩存的還要少，說明V3版先提取變量再進行StringBuilder 組裝的過程，相對來說還是會更耗時一點。但V4版的代碼可讀性是不如V3版的，可以把V3版和V4版相結合，剔除掉緩存依賴，產生一個代碼可讀性和性能最佳的V5版。

2.7 性能優化V5

先提取變量，去掉緩存依賴，用StringBuilder 替換掉String.replace ，增加代碼可讀性。

??

【圖12】V5版代碼實現&100萬次循環耗時對比

三、總結

通過上面5個版本的性能優化，性能得到了超過10倍的提升。?

性能由高到低的順序是V4 > V3 > V5 > V2 > V1 > 未被優化的原始版。其中V3、V4、V5版的性能顯著優于V1和V2版，證明這段模板替換邏輯最為耗時的點為String.replace ，V3 > V5和V2 > V1表明，引入緩存對性能提升還是有一定幫助的。在代碼可讀性方面，V4是不如V3和V5的。

整個優化總結下來主要有兩點：

1、String.replace 方法涉及到模板編譯和新字符串生成，比較吃資源

2、StringBuilder 代替String.replace ，除了能夠縮短調用耗時，在空間上也能夠減少資源占用。因為StringBuilder.append 相對于String.replace 來說，能夠減少中間大量String 對象的創建和銷毀，能夠減少GC的壓力，從而降低CPU的負載。

性能優化顯而易見的好處是能夠節約機器資源。如果一個有2000臺服務器的應用，整體性能提升了10%，理論上來說，就相當于節省了200臺的機器。除了節省機器資源外，性能好的應用相對于性能差的應用，在應對流量突增時更不容易達到機器的性能瓶頸，在同樣流量場景下進行機器擴容時，也只需要更少的機器，從而能夠更快的完成擴容、應急操作。所以，性能好的應用相對于性能差的應用在穩定性方面也更勝一籌。

最后再回到本次文章的主題：是什么讓一段20行代碼的性能提升了10倍？

我的回答是：StringBuilder yyds！?