這個問題不知道為什麼，非常非常非常常被問到，如果只是要從理論上、技術面上來說的話，答案也非常簡單：沒有。當然實務上來說，這是非常低情商的回答，講出去被打不要怪我。

哪一層的效能？

跟所有所謂效能的問題一樣，理論上要先釐清一下，現在在說的效能，是指哪一層的效能。是在說載入的時候，還是第一次渲染的時候，還是第二次渲染畫面更新的時候，還是其他哪一個關鍵渲染路徑上的節點，還是哪一個 web vitals 或是其他指標。另外所謂的效能問題，是客觀上載入速度比其他競品慢了多少毫秒，還是主觀上畫面肉眼看起來比較卡，還是無論如何我就是快還要更快，ASAP。

當然實務上來說，一來我們身為前端工程師，不太可能這麼……咄咄逼人，雖然是在釐清問題，但是外觀看起來像在挑毛病，拿問題回答問題，問一句頂十句，這在觀感上好像也不太好。二來不諱言的是，以上也有點打稻草人的成分在，在工程師的世界裡面，效能問題跟外國人問說 how was your weekend 一樣，問的人可能不一定有要認真聽你仔細講解，但通常也不是完完全全無腦隨口問問。

總之在回答這個問題之前，一來要先聚焦問題，避免張飛打岳飛，二來要稍微 read between the lines，如果有辦法抓到對方真正想問的點，那當然是最好的，但就算不行，如果能大概猜到對方的情緒或立場，那也會非常有幫助。

七分吃三分練

扯的好像有點遠，再聚焦到前端技術層面的話，效能問題可以非常大略地分成載入跟渲染兩部分，其中渲染的部分比較好理解，Rive 畢竟只是 2D 動畫，又是用 canvas 加上 requestAnimationFrame，因此除非是每一幀裡面做了太多事卡住，不然是真的殊難想像渲染這塊會有什麼效能瓶頸。

載入的部分牽涉到 Rive 的檔案大小跟載入的策略，根據 Rive 官方自己的說法，以同樣表現的動畫來說，Rive 比競品 Lottie 小 10-15 倍。就我個人的經驗來說，Rive 不一定是最小的，但也不會大到哪裡去。再配合適當的載入策略：分割資源、提前或延後載入、做好快取等等，通常不會有問題。

或者換句話說好了，健身是七分吃三分練，剩下九十趴靠打藥。所謂 Rive 效能的問題，無論是渲染還是載入都是，七分靠前端、三分靠裝置、剩下九十趴靠設計師。實務上最常遇到的情況是，設計師大大們……對美感與細節非常有品味與堅持，一個一秒的動畫塞了三百張圖片再加四個字體，或是每一幀要先打 API 或 call DB 拿真資料，諸如此類的。在這種情況下，當然前端基於他的職業道德跟敬業精神，還是要盡可能的調校好效能，但就跟健身一樣，吃跟練跟打藥不衝突。

高情商的回答

綜合以上兩點，我們大概可以知道，所謂 Rive 效能的問題，一來對方不一定真的有想得那麼深入，甚至可能不一定真的在問效能，二來不一定是工程師可以完全處理的。所以這個問題除了從理論或技術的角度去回答以外，最好稍微提到這兩件事，但在此同時，也不要表現得太直接或太厭世，而且也要注意篇幅，講那麼多沒人聽得懂，這其中的邊界是真的沒有很好抓，我也還在練習。

總之如果是目前的我，再一次被現場問到的話，我可能會這樣回：

「恩在通常的情況下不會有效能問題，Rive 的檔案大小非常小，而且前端可以用快取或其他策略進一步最佳化載入時間，渲染的部分也有用 canvas 加上 requestAnimationFrame 處理。不過效能的最佳化牽涉到關鍵渲染路徑上的很多層面，如果你有特別想問哪一層的話，我可以再深入回答。同時實務上來說，如果能跟設計師們密切合作、對齊認知的話，就算有效能的問題，也可以更早一步的解決，盡早發現盡早治療。」