在 8 月 17 日結束的 GTLC 全球技術領導力峯會廈門站分會活動上，美圖公司技術總監黃及峯（阿不）進行了《美圖秀秀工具到社區優化二三事》的主題演講。在演講中，他分享了美圖工具技術原理、技術架構與技術體驗的優化。TGO 鯤鵬會對其演講內容進行了分享和整理，以饗讀者。以下內容整理自阿不的現場發言：
編者注：查看阿不完整版 PPT，請在 TGO鯤鵬會公衆號（ID：tgo-kunpenghui）回覆“GTLC廈門站”自動獲取。
我在 2015 年加入美圖公司，目前負責美圖秀秀技術團隊。
在這幾年中，我經歷過的項目包括雲存儲、雲處理，還有美圖內部一些核心系統研發，比如流媒體系統和高可用體系建設等。在這些項目當中，我們非常注重用戶體驗，充分融合服務端和客戶端技術、結合全鏈路鏈路技術來整體優化用戶體驗。
美圖秀秀到目前爲止，發展已經接近 10 年時間了，產品形態也從一開始做傻瓜式的圖片處理工具，到精深比較專業的圖片美化和人像處理。美圖秀秀不僅獲得了海量用戶的信賴和喜歡，而且也讓我們技術團隊在圖片處理領域積累了比較多的經驗。從 2018 年開始，我們逐步嘗試做社交圈，整個產品的風格變得更加時尚、現代一些。我們也是希望通過美圖秀秀工具和社區的打通，給用戶帶來更多好玩的時尚生活方式。
接下來我會大體介紹下美圖秀秀工具和社區的基礎架構，通過兩個核心案例來簡單分享下我們是如何做技術性優化的工作。
工具技術原理
接下來，我將主要介紹工具方面的技術原理。這個技術原理其實也是一個“技術套路”，流程大致分兩步：第一、識別的圖片都有什麼樣的內容；第二、需要在識別圖片以後把部位分割出來，之後就可以選擇任意的調整。
那麼，在這個“技術套路”之下，美圖會要用到哪些技術呢？
- 核心是視覺 AI，將圖形圖像結合機器學習的技術體系去訓練我們的 AI 模型，完成內容識別和核心處理能力；
- 在視覺 AI 技術基礎之上，還包括一些工程化的落地、效果的開發，基本上是和圖形圖像處理相關的技術領域；
- 最後應用到工程時，非常重要的就是結合我們的素材進行設計，素材設計是我們產品成功與否的一個核心，當然底層也需要匹配我們的處理算法。
美圖公司不少黑科技來自於 AI 實驗室，我相信不少人也聽過，美圖 AI 實驗室在業界是比較出名的。目前該實驗室已經開放了美圖的一些 AI 能力，這些能力都可以在美圖 AI 開放平臺上能夠找到。
社區技術架構
美圖社區技術架構和業界的架構不會有太大的差別。業務端有主 App、小程序、H5 這些入口；後端有基於大數據學習和 AI 相關的核心推薦算法，包括地理位置的服務等；底層是比較常用的資源服務。因爲美圖秀秀社區的承載對象是圖片和視頻，所以我們核心的部分就是存儲和處理，還有整套流媒體的技術。
美圖的業務和技術當前都是構建在容器平臺上的，當然也有一套非常完善的大數據體系去支撐整套運營系統、統計分析和推薦系統。爲了保證整個服務的穩定性，我們有比較完善的監控告警體系和配套保障。優化指標依賴的就是我們的監控告警體系。
其中，穩定性保障分爲用戶端和服務端。服務端的開發關注資源、服務層的穩定性及質量的情況。在大規模用戶體驗優化時，只看服務端是不夠的，因爲用戶端纔是最直接的質量體現。
我們構建了一套完整的監控體系，包括通用網絡請求監控系統，流媒體專項監控、點播的起播時間、上傳性能監控等等，這些都涵蓋在我們整個體系裏面。通過監控系統的不斷完備，技術團隊可以方便地查看各項指標，極大地爲我們整體的優化提供了便利性。
我將技術上的體驗優化歸結爲三大類，第一就是偏靜態體驗類的，比如產品的啓動速度、運行流暢度、畫質等，其中，畫質是美圖產品非常核心的指標。第二是穩定性，包括崩潰率以及比較影響用戶的 ANR 的指標。第三是網絡體驗的優化，網絡體驗需要關注響應時間、錯誤率和服務穩定性等情況。這一項會相對複雜一些，因爲網絡有很強的動態性。
在整個體驗優化過程中，核心是需要有數據。在產品研發過程中我們需要把數據的採集、分析、調整策略這個流程打通，最終需要閉環。通過數據能更爲明確地指導整個優化過程。
下面我將重點分享崩潰率優化與網絡體驗優化，並且針對這兩個案例來介紹下我們的一些經驗。
穩定性優化
穩定性在整個優化前後有了一個比較明顯的提升，我們先來看下崩潰率優化效果：
在 5 月底之前，APP 崩潰率保持在一個相對比較高的狀態，並且每個月都有在往下走的趨勢；在 5 月底我們上了一個版本，崩潰數直接下降了 70% 左右。這裏只是一個過程的縮影，其實從 4 月開始，我們就按照崩潰的嚴重程度，解決每個版本崩潰量高的崩潰，爭取每個版本都能夠解決大頭的崩潰問題。
那爲什麼之前的崩潰率那麼高？我們又是怎樣去做的優化呢？
美圖秀秀 10 年的產品迭代過程當中，產品，技術，系統都發生了很大的變化，加上團隊的變動，由此帶來了很多的歷史包袱。此外，我們會接入很多第三方 SDK，每個第三方 SDK 都有自己的核心目標，有些可能甚至不會將穩定性列入他們的核心目標，由此就會帶來更大的挑戰。
有了這些問題之後，我們在上半年做了針對性的優化：
- 第一、找一個足於勝任這項工作的人專門負責這件事情，技術能力和推動事情的能力非常關鍵。
- 第二、產品內部逐步重構，所有的問題不是一步解決的，優先解決優先程度高的問題，並且不出現新的穩定性問題。
- 第三、對第三方接入的 SDK 制定性能標準和穩定性標準，確保在保證內部質量的前提下，對外部質量也必須要有充分的把控力。
在產品體驗穩定性優化到一定程度的時候，我們會制定穩定性標準。不同的崩潰率指標，我們會制定不同介入規範，比如什麼情況下我們會發緊急包等都會做出明確的約定。
除此之外，崩潰率的主動告警也是我們保證穩定性的重要一環。雖然 APP 的代碼一旦發佈後是穩定的（在沒有動態更新的前提下），但是仍然有可能會受到在線配置的一些變化和調整引起意外的崩潰情況。所以要保證線上的 APP 穩定性，主動的崩潰告警就顯得尤爲重要。
隨着這一系列的安排，我們產品穩定性表現也取得了明確的改善：
1、過去我們最嚴重的時候崩潰率接近 1%，到 6 月底的時候崩潰率下降到接近 0.07%，並且我們會持續化優化，未來目標是降至 0.05% 以下。
2、之前團隊由於各方面的原因，沒有足夠的時間，不能很好處理好這個事情，給團隊帶來比較大的壓力。通過這個這個問題的解決，讓團隊有打勝仗的感覺，能夠讓大家意識到團隊的進步足夠解決各種複雜的問題，建立了團隊信心和團隊成員的信任感，對於團隊氛圍改善有非常重大的作用。
網絡體驗優化
讓我們先來看看一個簡單的例子，通過這個例子也能較清晰地引申出網絡體驗優化的問題。我們素材中心多年來一直遺留一個問題，進入素材瀏覽頁面需要等待 3-4 秒，而且每次都需要這麼長的時間，用戶的使用成本相對比較高。那這裏延伸出來的一個疑問是，什麼樣的體驗纔算是好的？極端情況下應該讓用戶等多久？
下圖是我自己總結的用戶在完成一個用戶動作響應（比如打開頁面，播放一個視頻）的忍耐度指標。其中，200ms 是我認爲比較理想的一個值，但是一般情況可能會相對比較難穩定的達到這個標準。在我的經驗當中，600ms 到 1 秒之間也還是可以接受的。一旦用戶訪問一個頁面啓動一個產品需要達到 2s 時，用戶可能會處於非常焦慮的情緒中。當然如果等 10-30s，我覺得用戶使用過該產品一次就不會再使用第二次了。
網絡請求具有非常大的不確定性，主要由三個影響因素決定：第一、網絡鏈路因素，例如大家現在都用 4G 手機，想讓 2G、3G 手機用戶體驗非常好是不可能的。第二、是服務端的優化，比如服務優化從 100ms 降低到 50ms 對整體用戶動作響應的影響其實是微乎其微，幾乎沒有太大的影響，但是也必須得優化。第三、協議棧也很重要，當前我們的大部分網絡棧協議都是基於 TCP 基礎上的協議，目前比較前沿的協議棧的優化也在不斷取得進展，比如基於 UDP 的 quic 和 未來的 HTTP 3 等。
我們在做網絡優化的時候，第一需要數據，數據是指導我們做任何事情的標準。網絡請求有不同的階段，有很多指標，比如平均等待時間、DNS 解析時間、TCP 的時間等等，這些時間佔了大頭。在這些指標之後，纔是我們的發送時間、收包時間等等。優化就是利用各種各樣的手段去解決可能存在的問題。
針對客戶端的網絡優化手段，大概有以下的一些經驗思路：
第一個是超時設置，大部分開發人員可能會忽略這個設置，而忽略的其中一個原因可能是無法去評估到底什麼樣的超時時間是一個相對合理的值。如果我們從用戶的角度出發去思考，我們讓用戶等待多久會失去他。所以在工程實踐當中，我最開始把大部分場景下的超時時間都設置成 10s，調整之前都是 60s。一個基本的思考邏輯就是，除非特殊情況下，大部分的請求基本都能夠在幾百毫秒之內返回，如果一旦出現丟包或者網絡不好的情況，還不如儘快告知用戶可以儘快停止這次的等待，讓用戶有機會作出其它的選擇。
第二個是重試策略。短超時可以配合重試策略提升最終成功率。網絡出現鏈路波動的時候，丟包一旦多了，等待的時間就會越長，快速把它失敗掉，並且發送一個新的請求，可能很多時候會更快。
第三個是連接複用，即儘量複用鏈接，減少建聯時間和維護連接的成本。
第四個是客戶端緩存，梳理業務，去判斷有哪些業務數據時效性不是那麼高的，把能緩存在本地的數據都儘量緩存，這是優化客戶端體驗最有效直接的手段。
第五個是多路容災的手段，儘量讓資源避免單點，公網鏈路很大程度上也可以避免單點。行業內很多的大廠會做單元化的部署，讓用戶就近訪問，把用戶分割到就近的機房。如果是中心化的部署，可能有離部署節點很近的用戶，也有很遠的用戶，所以要去看調度邏輯。專有的鏈路優化不是讓我們自己去拉一條專線，因爲 CDN 都能幫你解決這些問題。所以專有鏈路優化對服務來講是非常簡單，並且受益很大的事情。
同樣，服務方面也得知道需要什麼樣的指標，才能指導你的優化邏輯。
我們關注響應時間可能會比較重視平均響應時間，還有一個很關鍵的時間就是響應時間的分佈。因爲一個服務有可能只有 10% 的請求是很慢很慢的，比如說 10s，但是就會因爲這一個把服務整個打死了。
舉個例子，我們服務啓動的時候經常會有一波服務波動，波動的時候會有一系列的指標全部都有異常，這個問題非常困擾我們。
通過復現、分析，我們發現的一個問題就是偏向鎖。除了對偏向鎖的優化之外，很重要的一個點就是預熱。假設沒有發現是偏向鎖的問題，現在第一波服務請求進來會出問題，我們也可以不解決這個偏向鎖的問題，採用預熱的方式，先慢慢逐步放量，把第一波的量降一些，降到可接受範圍之內，後面再承接正式量的時候，就比較穩定了。
服務優化從延遲角度上帶來的絕對收益有限，但最重要的是保證服務的穩定性，你需要經常模擬服務故障後的運行情況，常態化的故障演練是優化服務穩定性的保障。
總結
小結今天議題的內容，我在一開始介紹了工具和社區，美圖秀秀有完全不同的技術棧，工具的技術棧會偏領域性。美圖秀秀的產品大概有十年左右的生命週期，在這十年當中會有很多歷史問題的堆積，在未來持續迭代的時候還會有新的問題出來，我們就是在不斷解決問題的過程中成長。同樣地，優秀的產品體驗也能夠很好的幫助產品用戶增長。業務團隊經常是被產品需求趕着跑的，很多時候沒有時間思考自己的成長，做着做着不知道自己的成長性在哪裏。適度的對團隊提出更高的要求，培養追求卓越的團隊文化，是對個人和團隊共同成長的最佳手段。
演講嘉賓
黃及峯（阿不），美圖公司技術總監。目前負責美圖秀秀技術團隊工作。負責雲存儲系統，視頻圖片雲處理系統開發與架構工作，主導美拍短視頻成本體驗優化項目實施和落地。致力於提升研發效率，標準化項目從研發到上線的整套流程，主導了業務容器化到自動彈性調度線上落地。關注用戶體驗，組件客戶端體驗優化團隊，建立了基於數據驅動，涵蓋到客戶端和後端資源的全鏈路的體驗優化和質量監控體系。
活動推薦
9 月 21 日，GTLC 南京站將正式拉開帷幕。三星電子（中國）高級總監 & TGO 鯤鵬會會員劉明、WIFI 萬能鑰匙事業羣 CEO & TGO 鯤鵬會會員萬玉權等一批業界優秀的技術領導者，將悉數到場，分享領先的技術管理思考與理念，從而爲南京本地及遠道而來的技術人提供一次精彩的、深度的探討學習及拓展人脈的平臺或機會。識別下方二維碼點擊「詳情」查看 GTLC 南京站相關內容，現在購買 2 張以上門票，還可以享受團購優惠哦！
TGO鯤鵬會，是極客邦科技旗下高端技術人聚集和交流的組織，旨在組建全球最具影響力的科技領導者社交網絡，線上線下相結合，爲會員提供專享服務。目前，TGO鯤鵬會已在北京、上海、杭州、廣州、深圳、成都、硅谷、臺灣、南京、廈門、武漢、蘇州十二個城市設立分會。現在全球擁有在冊會員 800+ 名，60% 爲 CTO、技術 VP、技術合夥人。
會員覆蓋了 BATJ 等互聯網巨頭公司技術領導者，同時，阿里巴巴王堅博士、同程藝龍技術委員會主任張海龍、蘇寧易購 IT 總部執行副總裁喬新亮已經受邀，成爲 TGO 鯤鵬會榮譽導師。