很多深度技術的小伙伴都為Win10系統中的“UI分裂癥”都讓很多老用戶頭疼，說它不上進吧，很多新功能在線，說它很棒吧，卻處處流露著各種“不靠譜”的設計。

特別是Win10系統已經上線五年多，無論UI還是功能連貫性方面，都很難稱其為出色，可能還有很多win7系統用戶都不選擇升級win10系統。

而定于今年下半年發布的Win10 21H2（太陽谷項目），則被微軟稱之為史上最重要的界面升級。那么這傳說中的“太陽谷（Sun Valley）”究竟是個什么樣子？深度系統小編特意做了一番匯總，讓大家先睹為快！

你心目中的Win10到底是個什么樣子？

1. 方角？圓角？

都說設計界是一個大輪回，這話一點兒不假。幾年前，當大家都看膩了圓角風格后，Win8首當其沖，將自己改成了方角。又過了幾年，當大家又厭煩Win10的方角元素后，它又琢磨著改回圓角。在一組曝光了的太陽谷設計圖中，我們看到了很多與以往不同的設計。窗口、菜單、上下文等，都加入了圓角元素。

據悉Win10的“圓角化改造”可能分為若干階段，首先是系統及各項內置組件，后期則會延伸到第三方應用。盡管只是一個微小的美學變化，但的確可以提升整個Windows的精致感！

返璞歸真的“圓角化設計”

2. 浮動化元素

“浮動化”將是未來Win10一個很明顯的變化。在新版Win10中，微軟似乎要為我們打造一個更炫酷的菜單，在一份泄露出來的工程模擬圖中，我們看到了一個與現版“略顯不同”的菜單。

它擁有著現版開始菜單的所有元素，卻已不再和任務欄綁定，同時邊框也改成了更加柔和的圓角。

所有這些是不是都有些似曾相識？沒錯！之前發布的Win10X RTM就是采用類似的設計。

懸浮開始菜單的工程模擬圖

當然開始菜單只是一個開始，窗口縮略圖、Jumplist、通知信息……，在微軟眼中，所有一切皆可懸浮，而這一切是不是想想就覺得很棒呢！

Win10X已經率先使用上了

3. 操作中心

Win10操作中心一直利用率不高，這一方面與其不開放的按鈕設置有關，另一方面也有大眾的使用習慣。下一步，微軟將采用一個和Win10X相類似的分體化操作中心，最大的改變就是操作與通知分離。

除了操作按鈕可以完成更多功能外，一些快捷面板也煥新亮相，這其中就包含音樂控制器和音量調節面板。

先前出現在Win10X中的新版通知中心，很可能是Win10的前奏

4. 設置面板

“設置”將繼續完成兼容控制面板這一“偉大重任”，但除此之外，我們或許能夠見到一個不一樣的“設置”。

下圖是已經出現在Win10開發版中的設置面板截圖。除了下方按鈕外，置頂端則是一個非常搶眼的大橫欄，里面包含了賬戶信息以及當前的Windows更新狀態。

目前開發版還不允許用戶自定義該區域，但后期很可能開放這一權限。

這是Win10開發版中的設置面板截圖

5. 統一UI設計

分裂化的UI設計，一直是用戶吐槽的焦點。在下一版Win10中，微軟已經下決心解決這一問題，除了資源管理器這個老大難問題外，之前很多被忽略過的組件也將獲得升級，比如大家十分熟悉的輸入法，以及其他內置組件。

統一UI升級后的內置輸入法

曾出現在Win10X RTM中的UWP版資源管理器

6. 任務欄信息流

盡管有關開始菜單的爭論一直不斷，但不可否認，磁貼設計在很大程度上解決了用戶的日常信息讀取問題。

在最新版Win10開發版中，一項新功能出現在了任務欄右側，這是一個酷似磁貼的資源面板，提供了新聞、天氣、股市、賽程等信息。只要將鼠標懸停到任務欄的天氣圖標上，即可見到詳情。

不過正如你所想到的，信息流的出現很明顯是針對現版的磁貼，聯想到之前坊間一直傳言的微軟將取消開始菜單磁貼的傳聞，這是否又會是一個佐證呢！

任務欄信息流主要集合了一些常用資訊

7. 電源與電池

Win10的電源管理模塊，一直都不太令人滿意，尤其是和MAC相比時，能夠明顯感覺出兩者的差距。

在新版泄露圖中，微軟似乎有意將電池與電源合并到一起，并重新命名為“Power & Battery”。

而除了名稱上的改變外，一個更加強大而豐富的電量管理界面，也將出現在我們面前。

泄露的新版Win10電源與電池頁面

8. 每日云壁紙

BingWallpaper是微軟出品的一款壁紙切換工具，能夠自動將Bing的每日圖片設置為本機壁紙。

在一份泄露圖中，微軟似乎在考慮一個更為徹底的選項，即直接將該功能內置到Win10的壁紙設置中。于是很多小伙伴們期望的每天開機自動換壁紙功能，就這樣快樂地實現了。

問題是，如果能給壁紙加個遮罩或是自動模糊選項，是不是會更實用呢！

讓壁紙每天自動更新

9. 動畫版鎖屏

除了臺式機，Win10的另一大戰場就是便攜式設備?，F版Win 10的鎖屏界面已經沿用很長時間，并且沒有新功能加入。

而隨著Win10本身對Parallax 3D支持越來越好，那些帶有加速度計的平板或二合一設備，或許能夠見到一個更加炫酷的鎖屏，比方說——當你將設備旋轉的時候。

支持加速計的平板設備將看到更炫酷的鎖屏體驗

10. 攝像頭設置

現版Win10并不支持攝像頭調整，這在很多場景中其實是不方便的。有消息稱，微軟正計劃為Win10添加一個全局性攝像頭設置。

除了預覽功能外，它也可以對攝像頭方向、亮度、對比度等參數進行調整。

不過目前有關該功能的介紹還不多，感興趣的小伙伴可以后期多關注一下。

21H2中可能加入的全局攝像頭設置

11. 全新分屏

面對日益眾多的高分屏及帶魚屏，Win10的4分屏功能顯得越來越無力。有消息稱，微軟正準備在下一版中對“分屏”功能進行升級。

新分屏除了繼續按照窗口比例劃分屏幕外，當你將窗口拖拽到屏幕角落，系統還會自動調節窗口的大小并排列，以方便用戶操作多個應用。

此外微軟的御用外掛——PowerToys也有類似功能，可以讓用戶自定義分屏邏輯。

微軟御用外掛PowerToys里的自定義分屏

12. Windows SETS

Windows SETS是微軟基于標簽開發的一款窗口布局，說白了就是系統內置的窗口多標簽功能。

Windows SETS并不算一項新功能，2018年就曾通過Windows Insiders進行了短暫測試。不過后期由于種種原因，這項功能并未與我們見面。

有消息稱，該功能還在微軟的考量范圍中，并準備在適當的時候推出。但具體如何實現，實現什么樣子，就只能等到時候再說了。

網上泄露的有關Windows Sets的設置界面

13. 郵件和日歷

目前Win10內置的是一款簡易版“郵件和日歷”，但據統計，該功能的實際使用頻率并不高，因此微軟正考慮通過Win10中內置Outlook來替代原有的“郵件和日歷”。

據悉該想法實現后，Win10將擁有與目前MAC相類似的多端處理能力，即包括電子郵件、To-Do、聯系人、日程。

當然考慮到與標準版Outlook的關系，估計大概率又會是和OneNote一樣的結果，即系統中內置一個免費版，用戶則根據自己需要選擇是否升級為收費版。

通過Outlook替代現有的郵件和日歷

14. Windows語音輸入

“Windows語音輸入”將取代現有的“Windows聽寫”，在這項功能的支持下，用戶可以在Win10的任何一個文本框內，以語音方式完成錄入。

而這項功能的最大受益者，就是各種便攜設備使用者，借助它可以大幅提升輸入效率。

泄露的“Windows語音輸入”面板

15. 固態硬盤壽命預警

由于固態硬盤的先天結構，使得它在損壞后恢復難度很大。為了解決這一問題，微軟計劃在新版Windows中加入一項專門針對固態硬盤的存儲健康監測功能。

該功能會在固態硬盤出現重大安全隱患前，向用戶彈出預警，通知用戶及時備份重要資料。

固態硬盤壽命預警

16. 新功能提醒

目前用戶獲取 Windows新功能的渠道，主要集中在各大資訊網站，有時甚至更新完畢，都不知道新系統到底更新了啥。

在下個版本中，微軟正計劃通過一種彈窗形式，向用戶展示新版的各項變化。每當系統更新完畢，就會有一個彈窗出現，里面會簡要介紹出該版本的重要變化，以便用戶閱讀。

新功能提醒

17. 一體式搜索框

用過Mac的人，一定對里面的Spotlight印象深刻，這是蘋果的一體式搜索欄。除了可以實現基本的文件搜索外，它還加入了天氣預報、計算器、單位換算、匯率換算、附近餐館等生活搜索功能。

有消息稱，微軟打算將其御用外掛PowerToys的部分功能內置到系統中，這其中就包括那個和Spotlight長得很像的搜索面板。

與Spotlight一樣，PowerToys搜索欄也能通過熱鍵呼出（Alt+空格），而且界面也要比現版的Windows搜索更直觀。

目前PowerToys同樣也是定位在文件搜索層面，后期如果能和Cortana聯動，就能實現類似于Spotlight的綜合搜索效果。

現版PowerToys里的一體式搜索框

18. 全新窗口動畫

Mac的過渡動畫一直讓很多用戶著迷，在即將到來的Win10 21H2中，我們或許能夠見到一套全新的過渡動畫。目前該動畫已經在Win10開發版中亮相，除了適用于系統窗口外，也適用于第三方應用里的對話面板。

PS對話框呈現的新版過渡動效

19. Edge開啟桌面小工具

桌面小工具曾是微軟為Vista/Win7開發的一套小功能，但隨著Win8磁貼的推出，桌面小工具開始慢慢淡出歷史舞臺。

有消息稱，微軟決定重啟桌面小工具。但與以往不同，此次承接桌面小工具的是微軟基于Chromium內核打造的新版Edge，同時小工具的方向也更加明確于新聞、天氣、股票等資訊。

與以往固定到任務欄上不同，小工具可以在關閉瀏覽器后繼續工作，這一點在很大程度上提升了該功能的實用性。

泄露的Edge桌面小工具截圖，當然這個圖文是無關的。

寫在最后

毫無疑問，“太陽谷”的出現將會在UI以及用戶體驗上，帶給我們更多的改變。作為Win10系統中五年間最大一次界面調整，微軟這一次的誠意的確蠻大。當然由于新版尚未發布，目前還無法確定這些變化是否全部應用在21H2系統版本中。但這一次大刀闊斧式的改變，是否能讓這款經典操作系統煥發第二春呢！
以上就是深度技術系統分享關于win10 21H2系統好用嗎？和新特性的介紹，希望對大家有所幫助。

希望本文可以帶給大家一個相對全局的視角看待卡頓問題，認識到卡頓是什么、卡頓的成因、卡頓的分類、卡頓的優化和一些經驗積累，有的放矢地解決 App 流暢性問題。接下來會從以下五個方面進行講述：

?什么是卡頓

?為什么會發生卡頓

?如何評價卡頓

?如何優化卡頓

?加入我們

1. 什么是卡頓

卡頓，顧名思義就是用戶體感界面不流暢。我們知道手機的屏幕畫面是按照一定頻率來刷新的，理論上講，24 幀的畫面更新就能讓人眼感覺是連貫的。但是實際上，這個只是針對普通的視頻而言。對于一些強交互或者較為敏感的場景來說，比如游戲，起碼需要 60 幀，30 幀的游戲會讓人感覺不適；位移或者大幅度動畫 30 幀會有明顯頓挫感；跟手動畫如果能到 90 幀甚至 120 幀，會讓人感覺十分細膩，這也是近來廠商主打高刷牌的原因。

對于用戶來說，從體感角度大致可以將卡頓分為以下幾類：

這些體驗對于用戶可以說是非常糟糕的，甚至會引起感官的煩躁，進而導致用戶不愿意繼續停留在我們的 App?？梢哉f，流暢的體驗對于用戶來說至關重要。

2. 為什么會發生卡頓

用戶體感的卡頓問題原因很多，且常常是一個復合型的問題，為了聚焦，這里暫只考慮真正意義上的掉幀卡頓。

2.1 繞不開的 VSYNC

我們通常會說，屏幕的刷新率是 60 幀，需要在 16ms 內做完所有的操作才不會造成卡頓。但是這里需要明確幾個基本問題：

1. 為什么是 16ms？
2. 16ms 內都需要完成什么？
3. 系統如何盡力保證任務在 16ms 內完成？
4. 16ms 內沒有完成，一定會造成卡頓嗎？

這里先回答第一個問題：為什么是 16ms。早期的 Android 是沒有 vsync 機制的，CPU 和 GPU 的配合也比較混亂，這也造成著名的 tearing 問題，即 CPU/GPU 直接更新正在顯示的屏幕 buffer 造成畫面撕裂。后續 Android 引入了雙緩沖機制，但是 buffer 的切換也需要一個比較合適的時機，也就是屏幕掃描完上一幀后的時機，這也就是引入 vsync 的原因。

早先一般的屏幕刷新率是 60fps，所以每個 vsync 信號的間隔也是 16ms，不過隨著技術的更迭以及廠商對于流暢性的追求，越來越多 90fps 和 120fps 的手機面世，相對應的間隔也就變成了 11ms 和 8ms。

那既然有了 VSYNC，誰在消費 VSYNC？其實 Android 的 VSYNC 消費者有兩個，也就對應兩類 VSYNC 信號，分別是 VSYNC-app 和 VSYNC-sf，所對應的也是上層 view 繪制和 surfaceFlinger 的合成，具體的我們接下來詳細說。

這里還有一些比較有意思的點，有些廠商會有 vsync offset 的設計，App 和 sf 的 vsync 信號之間是有偏移量的，這也在一定程度上使得 App 和 sf 的協同效應更好。

2.2 View 顛沛流離的一生

在講下一 part 之前先引入一個話題：

一個 view 究竟是如何顯示在屏幕上的？

我們一般都比較了解 view 渲染的三大流程，但是 view 的渲染遠不止于此：

此處以一個通用的硬件加速流程來表征

1. Vsync 調度：很多同學的一個認知誤區在于認為 vsync 是每 16ms 都會有的，但是其實 vsync 是需要調度的，沒有調度就不會有回調；
2. 消息調度：主要是 doframe 的消息調度，如果消息被阻塞，會直接造成卡頓；
3. input 處理：觸摸事件的處理；
4. 動畫處理：animator 動畫執行和渲染；
5. view 處理：主要是 view 相關的遍歷和三大流程；
6. measure、layout、draw：view 三大流程的執行；
7. DisplayList 更新：view 硬件加速后的 draw op；
8. OpenGL 指令轉換：繪制指令轉換為 OpenGL 指令；
9. 指令 buffer 交換：OpenGL 的指令交換到 GPU 內部執行；
10. GPU 處理：GPU 對數據的處理過程；
11. layer 合成：surface buffer 合成屏幕顯示 buffer 的流程；
12. 光柵化：將矢量圖轉換為位圖；
13. Display：顯示控制；
14. buffer 切換：切換屏幕顯示的幀 buffer；

Google 將這個過程劃分為：其他時間/VSync 延遲、輸入處理、動畫、測量/布局、繪制、同步和上傳、命令問題、交換緩沖區。也就是我們常用的 GPU 嚴格模式，其實道理是一樣的。到這里，我們也就回答出來了第二個問題：16ms 內都需要完成什么？

準確地說，這里仍可以進一步細化：16ms 內完成 APP 側數據的生產；16ms 內完成 sf layer 的合成

View 的視覺效果正是通過這一整條復雜的鏈路一步步展示出來的，有了這個前提，那就可以得出一個結論：上述任意鏈路發生卡頓，均會造成卡頓。

2.3 生產者和消費者

我們再回到 Vsync 的話題，消費 Vsync 的雙方分別是 App 和 sf，其中 App 代表的是生產者，sf 代表的是消費者，兩者交付的中間產物則是 surface buffer。

再具體一點，生產者大致可以分為兩類，一類是以 window 為代表的頁面，也就是我們平時所看到的 view 樹這一套；另一類是以視頻流為代表的可以直接和 surface 完成數據交換的來源，比如相機預覽等。

對于一般的生產者和消費者模式，我們知道會存在相互阻塞的問題。比如生產者速度快但是消費者速度慢，亦或是生產者速度慢消費者速度快，都會導致整體速度慢且造成資源浪費。所以 Vsync 的協同以及雙緩沖甚至三緩沖的作用就體現出來了。

思考一個問題：是否緩沖的個數越多越好？過多的緩沖會造成什么問題？

答案是會造成另一個嚴重的問題：lag，響應延遲

這里結合 view 的一生，我們可以把兩個流程合在一起，讓我們的視角再高一層：

2.4 機制上的保護

這里我們來回答第三個問題，從系統的渲染架構上來說，機制上的保護主要有幾方面：

1. Vsync 機制的協同；
2. 多緩沖設計；
3. surface 的提供；
4. 同步屏障的保護；
5. 硬件繪制的支持；
6. 渲染線程的支持；
7. GPU 合成加速；

這些機制上的保護在系統層面最大程度地保障了 App 體驗的流暢性，但是并不能幫我們徹底解決卡頓。為了提供更加流暢的體驗，一方面，我們可以加強系統的機制保護，比如 FWatchDog；另一方面，需要我們從 App 的角度入手，治理應用內的卡頓問題。

2.5 再看卡頓的成因

經過上面的討論，我們得出一個卡頓分析的核心理論支撐：渲染機制中的任何流轉過程發生異常，均會造成卡頓。

那么接下來，我們逐個分析，看看都會有哪些原因可能造成卡頓。

2.5.1 渲染流程

1. Vsync 調度：這個是起始點，但是調度的過程會經過線程切換以及一些委派的邏輯，有可能造成卡頓，但是一般可能性比較小，我們也基本無法介入；
2. 消息調度：主要是 doframe Message 的調度，這就是一個普通的 Handler 調度，如果這個調度被其他的 Message 阻塞產生了時延，會直接導致后續的所有流程不會被觸發。這里直播建立了一個 FWtachDog 機制，可以通過優化消息調度達到插幀的效果，使得界面更加流暢；
3. input 處理：input 是一次 Vsync 調度最先執行的邏輯，主要處理 input 事件。如果有大量的事件堆積或者在事件分發邏輯中加入大量耗時業務邏輯，會造成當前幀的時長被拉大，造成卡頓。抖音基礎技術同學也有嘗試過事件采樣的方案，減少 event 的處理，取得了不錯的效果；
4. 動畫處理：主要是 animator 動畫的更新，同理，動畫數量過多，或者動畫的更新中有比較耗時的邏輯，也會造成當前幀的渲染卡頓。對動畫的降幀和降復雜度其實解決的就是這個問題；
5. view 處理：主要是接下來的三大流程，過度繪制、頻繁刷新、復雜的視圖效果都是此處造成卡頓的主要原因。比如我們平時所說的降低頁面層級，主要解決的就是這個問題；
6. measure/layout/draw：view 渲染的三大流程，因為涉及到遍歷和高頻執行，所以這里涉及到的耗時問題均會被放大，比如我們會降不能在 draw 里面調用耗時函數，不能 new 對象等等；
7. DisplayList 的更新：這里主要是 canvas 和 displaylist 的映射，一般不會存在卡頓問題，反而可能存在映射失敗導致的顯示問題；
8. OpenGL 指令轉換：這里主要是將 canvas 的命令轉換為 OpenGL 的指令，一般不存在問題。不過這里倒是有一個可以探索的點，會不會存在一類特殊的 canvas 指令，轉換后的 OpenGL 指令消耗比較大，進而導致 GPU 的損耗？有了解的同學可以探討一下；
9. buffer 交換：這里主要指 OpenGL 指令集交換給 GPU，這個一般和指令的復雜度有關。一個有意思的事兒是這里一度被我們作為線上采集 GPU 指標的數據源，但是由于多緩沖的因素數據準確度不夠被放棄了；
10. GPU 處理：顧名思義，這里是 GPU 對數據的處理，耗時主要和任務量和紋理復雜度有關。這也就是我們降低 GPU 負載有助于降低卡頓的原因；
11. layer 合成：這里主要是 layer 的 compose 的工作，一般接觸不到。偶爾發現 sf 的 vsync 信號被 delay 的情況，造成 buffer 供應不及時，暫時還不清楚原因；
12. 光柵化/Display：這里暫時忽略，底層系統行為；
13. Buffer 切換：主要是屏幕的顯示，這里 buffer 的數量也會影響幀的整體延遲，不過是系統行為，不能干預。

2.5.2 視頻流

除了上述的渲染流程引起的卡頓，還有一些其他的因素，典型的就是視頻流。

1. 渲染卡頓：主要是 TextureView 渲染，textureview 跟隨 window 共用一個 surface，每一幀均需要一起協同渲染并相互影響，UI 卡頓會造成視頻流卡頓，視頻流的卡頓有時候也會造成 UI 的卡頓；
2. 解碼：解碼主要是將數據流解碼為 surface 可消費的 buffer 數據，是除了網絡外最重要的耗時點。現在我們一般都會采用硬解，比軟解的性能高很多。但是幀的復雜度、編碼算法的復雜度、分辨率等也會直接導致解碼耗時被拉長；
3. OpenGL 處理：有時會對解碼完成的數據做二次處理，這個如果比較耗時會直接導致渲染卡頓；
4. 網絡：這個就不再贅述了，包括 DNS 節點優選、cdn 服務、GOP 配置等；
5. 推流異常：這個屬于數據源出了問題，這里暫時以用戶側的視角為主，暫不討論。

2.5.3 系統負載

1. 內存：內存的吃緊會直接導致 GC 的增加甚至 ANR，是造成卡頓的一個不可忽視的因素；
2. CPU：CPU 對卡頓的影響主要在于線程調度慢、任務執行的慢和資源競爭，比如降頻會直接導致應用卡頓；
3. GPU：GPU 的影響見渲染流程，但是其實還會間接影響到功耗和發熱；
4. 功耗/發熱：功耗和發熱一般是不分家的，高功耗會引起高發熱，進而會引起系統保護，比如降頻、熱緩解等，間接的導致卡頓。

2.6 卡頓的分類

我們此處再整體整理并歸類，為了更完備一些，這里將推流也放了上來。在一定程度上，我們遇到的所有卡頓問題，均能在這里找到理論依據，這也是指導我們優化卡頓問題的理論支撐。

3. 如何評價卡頓

3.1 線上指標

3.2 線下指標

Diggo 是字節自研的一個開放的開發調試工具平臺，是一個集「評價、分析、調試」為一體的，一站式工具平臺。內置性能測評、界面分析、卡頓分析、內存分析、崩潰分析、即時調試等基礎分析能力，可為產品開發階段提供強大助力。

4. 如何優化卡頓

4.1 常用的工具

4.1.1 線上工具

4.1.2 線下工具

4.2 常用的思路

這里主要針對 UI 卡頓和 UI/流相互影響打來的卡頓。

對于 UI 卡頓來說，我們手握卡頓優化的 8 板大斧子，所向披靡：

1. 下線代碼；
2. 減少執行次數；
3. 異步；
4. 打散；
5. 預熱；
6. 復用；
7. 方案優化；
8. 硬件加速；

總體思路就是「能不干就不干、能少干就少干、能早點干就早點兒干、能晚點兒干就晚點兒干、能讓別人干就讓別人干、能干完一次當 10 次就只干一次，實在不行，再考慮自己大干一場」。

這里例舉出一些常見的優化思路，注意這一定也不可能是全部，如果有其他好的優化思路，我們可以一起交流。

4.3 一些做過的事兒

4.3.1 解決 UI 卡頓引起的流卡頓

直播對于 SurfaceView 的切換是一個長期的專項，分為多期逐步將 SurfaceView 在直播全量落地，場景覆蓋秀場直播、聊天室、游戲直播、電商直播、媒體直播等，業務上對于滲透率和停留時長有比較顯著的收益，同時功耗的收益也很可觀。

這里是一個權衡的問題，SurfaceView 的兼容性問題 pk 帶來的收益是否能打平，一般來說，越是復雜的業務場景，收益約大。

4.3.2 解決 message 調度

FWatchDog 是基于對 MessageQueue 的調度策略和同步屏障原理，以均幀耗時為閾值判定丟幀后主動在 MessageQueue 中插入同步屏障，保證渲染異步 message 和 doframe 的優先執行，達到一種渲染插幀的效果，同時具備 ANR 自動恢復同步屏障的能力，保障打散的有效。

所以 FWatchDog 和打散是好的搭檔，能產生 1+1 大于 2 的效果。

4.3.3 減少執行次數

一個典型的應用場景就是滑動場景的 GC 抑制，能夠顯著提高用戶上下滑的使用體驗。這個場景相信每個業務都會存在，特別是存在大量遍歷的邏輯，優化效果明顯。

4.3.4 代碼下線

一些老的框架、無用的邏輯以及存在性不高的代碼都可以下線，這里基本業務強相關，就不舉具體的例子了。

4.3.5 解決耗時函數（打散/異步）

首先是打散，直播做了很多 task 的拆分以及打散，第一可以減輕當前渲染幀的耗時壓力，第二可以和 FWatchDog 結合達到插幀的效果。這里其實還可以控制 task 的執行優先級，包括隊列的插隊等，總之 MessageQueue 的合理調度是很有必要的。

異步的使用也相對比較多，一個埋點日志的框架，以及一些 inflate 的加載等，都可以使用異步來解決卡頓問題。

4.3.6 預熱

直播提供了一個預熱框架，可以讓直播內部的一次性成本邏輯得到在宿主側執行的機會，同時提供完備的隊列優先級管理、同步異步管理和 task 生命周期管理，降低直播內部首次加載的卡頓問題。

4.3.7 硬件加速

拉高硬件的運行性能，比如 CPU 頻率、GPU 頻率、線程綁大核以及網絡相關的調優，從底層提高 App 的運行體驗。

5. 加入我們

直播客戶端技術團隊是一個集體驗優化、平臺建設、跨端、端智能、穩定性為一體的綜合性團隊，團隊氛圍 nice，技術成長快，有充足的自由度發揮自己的特長，為億級 DAU 產品保駕護航，也面臨更加豐富多樣的挑戰，每一行代碼都會讓數億的用戶體驗變得更好！現誠邀各位英才加入，對這些方向感興趣的同學都可以來聊一聊，內推鏈接：「鏈接」