一．項目背景
公司是一家物聯網公司，意向自研一款人臉會議考勤簽到面板機，為了提高產品競爭力，主打性價比+定制化差異（硬件便宜好用，軟件頁面炫酷叼炸天）；軟件研發部需要支撐配套的人臉會議考勤安卓平板應用。主要業務功能有：人臉識別功能（人臉采集、對比識別、人臉庫管理），會議模塊，考勤簽到功能，定制化互動模塊。
人臉識別交互示意圖（網絡圖）
（原頁面實現由識別定位框+骨骼輪廓圖+信息卡片+動畫構成）
與硬件產品經理的溝通后，提供一套樣機和一套產品清單來支撐軟件研發的開發和測試。
主板是RK3288四核 1.8GHZ.2g內存。8G存儲的板子，安卓5.1的操作系統。屏幕是15.6英寸 1920*1080分辨率 10點式電容觸摸屏。
（RK3288主板 ）
（RK3288主板核心參數）
框架選型是使用的React Native+tracker.js，考慮控制成本，沒有集成市面上的Android人臉識別SDK。通過經驗使用tracker.js替代opencv實現端的人臉識別捕捉，服務端實現人臉對比（這里為后續的錯誤埋下了伏筆），經過一段時間加班加點，開發了人臉會議考勤系統V0.1-Alpha版。
采購流程是比較慢的，等到開發板到了開始一輪真機測試運行，搞了一輪以后組員說束手無策，別的機子都好好的，就這個不行，懷疑硬件問題。
排除硬件原因后，我整體的牽頭開始對于系統進行性能優化。
問題以及所遇到的挑戰
1.問題
1.人臉識別不流暢，人畫不同步，明顯延遲，人員高頻次出入鏡頭框會伴隨頓挫感。
2.POE供電，長時間運行軟件運行發熱發燙。
3.概率偶發性閃退現象，捕捉不到有價值的異常日志。
2.挑戰
1.沒有使用純安卓開發（組員基本不會安卓原生開發）+人臉識別安卓SDK（控制成本的訴求）。限制了性能的上限。
2.硬件性能低。RK3288處理器，搭載的Mali-T764GPU，在14年當年算是神U，被譽為國產最強ARM處理器，但是已經6、7年過去了，我們采用的也是基礎版。安卓板人臉機還需要內置一些其他相關軟件，對性能和穩定性的要求還是比較高的。
3.概率性存在ANR/閃退崩潰問題，報錯模糊，定位不到問題。
4.組員整體為前端開發人員，對于app的優化和調試經驗不足。
二．解決問題的步驟
1.復盤設計
忠告，先不要盯著問題本身。尤其是對于性能問題，這是大忌。這是對于很多開發人員都容易犯的錯誤，甚者用精妙的技巧去掩蓋系統設計上的缺陷。（產品設計，架構設計，原型設計，交互設計，UI設計等等）
如果系統運行或者測試中出現了遠高于閾值的問題，第一步一定是先回過頭來看系統的看設計。（一定是）
沒有經驗的程序員會一頭扎入bug中，富有經驗的程序員會利用自有的思維方式了解問題，定位問題，分析問題，解決問題，驗證問題。而作為一個合格的架構師，或者技術團隊的leader。一定要學會“揪頭發”思維。
很多系統需要優化的問題，往往并不僅僅是一個技術問題，根源上可能是一個不合理的產品設計，冗余的架構，反人類的交互，層次過深的UI導致的。而由于系統的復雜度和團隊的溝通成本以及后期需求變動與場景的細化，往往在項目初期有些問題是很難暴露的。所以對于軟件系統的性能優化，第一步要復盤之前的設計與行為是否合理。
而事實上，所謂的差異化設計，在通過梳理精簡，剔除掉不合理因素后，對于一個工業平板app它的動畫和交互還是太復雜了。
2.數據分析
本項目人臉檢測驗收標準：
包大小：~ 100M
最小人臉檢測大小：50px * 50px
可識別人臉角度：yaw ≤ ±30°, pitch ≤ ±30°
檢測速度：100ms 720p*
追蹤速度：50ms 720p*
人臉檢測耗時：< 200ms
人臉庫檢索速度：< 100ms
檢測+識別全流程耗時 < 500ms（app其他性能指標不做過多敘述）
工程化的一個要素就是用設定的標準去衡量離散型數據。如果優化沒有可量化的渲染性能評判標準，就是開發者\leader拍腦門決定了，所以不僅僅是測試人員需要了解這些指標，開發者也要學會使用測試工具去定位問題、驗證數據。
ok開始行動， Android adb網絡連接安卓主板測試，安裝apk。
1.渲染模式分析
打開安卓開發者模式，檢查 GPU 渲染速度和過度繪制，篩選出渲染壓力過大的頁面，
（GPU 渲染模式分析示意圖）
（渲染顏色說明）
過度繪制：實際上對于過度繪制相關的優化，要考慮投入產出比，過于精細的優化整體產出是不高的，該項目中只對于過度繪制紅色區域（過度繪制4次及以上區域）進行優化。
2.分析耗電情況
由于軟件伴有運行發熱發燙的現象，那么一定要分析耗電情況。
耗電統計是系統組件，也就是說系統運行他就一直在統計。所以獲取統計報告的時候需要將統計重置。
1.先斷開adb服務，然后開啟adb服務
adb kill-server 防止沖突和臟數據。重啟adb。
adb devices就會自動連接查找手機。當然也可以adb start-server
2 .重置電池數據收集
adb shell dumpsys batterystats –enable full-wake-history
adb shell dumpsys batterystats –reset
正常情況下，我們應該斷開充電器并斷開usb連接（連接時充電），這樣會大大影響統計有效性。但是由于我們是poe供電，具體情況具體分析，使用數據輔助查找異常點。因為我們是5.1系統，所以使用adb命令：
由于txt報告實在是比較大，10幾個m肉眼看不太現實，一般都配合Battery Historian這個工具來使用。
（注意：Battery Historian是android 5.0（api 21）及以上使用，如果有幸還在使用安卓4.4工業面板的可以略過此條了。）
抱著合理分工的心態，我將報文發給了某測試同學。（狗頭）
（Battery Historian示例圖）
3.線程活動與CPU分析
線程活動與CPU分析 工具有很多，但是Android Studio自帶的他不香嗎？（Rn安卓打包還是用Android Studio，使用vscode打包坑太多了。）
針對異常點進行分析。
（Android Studio CPU 分析器 示例圖）
4.數據匯總
數據顯示CPU的負擔過重，tracking導致進程有阻塞現象。
實際上大家一直認為是完全由于渲染壓力大導致的頁面卡頓，（渲染是RN 整個框架的瓶頸），報表數據顯示的恰恰相反，對于人臉識別，GPU并沒跑滿，圖形界面的渲染工作只有部分由GPU進行的，當tracking阻塞后會暫時等待發生卡頓，再逐個完成canvas 關鍵點渲染定位，調用接口，取得返回數據后渲染信息卡片和執行動畫時導致第二次輕微卡頓（RN渲染卡頓），然后性能反應正弦函數波動，同時卡頓和不流暢現象消失。
導致“拍腦袋”定位問題就是因為前端同事對于日志和數據分析工具的使用是普遍不夠的。
3.定位問題
定位問題的方法有多種，像大家常用的二分查找法（二分注釋、二分回滾）。或者斷點調試、分析日志。都可以有效的幫助我們快速定位問題。
那么通過數據的分析以及工具提供的關鍵類，我們也是比較清晰的找出了問題：信息卡片動畫+canvas特效+人臉識別相關函數。
4.分析問題
原有的實現方式：引入全部的相關js，new多個tracking.objectTracker來檢測人臉、眼睛、嘴的區域。在通過canvas實現人臉關鍵點的展示效果，
（Tracking.js文件目錄示意圖）
而對人臉進行采集。Tracking.js 是使用 CPU 進行計算的，在圖像的矩陣運算效率上，相對 GPU 要慢一些。
此時，有了數據的支撐，決定替換人臉識別框架層配合RN進行嘗試性優化，采用face-api.js
face-api.js
基于 TensorFlow.js 內核，實現了三種卷積神經網絡架構，用于完成人臉檢測、識別和特征點檢測任務，可以在瀏覽器中進行人臉識別。其內部實現了一個非常輕巧，快速，準確的 68 點面部標志探測器。支持多種 tf 模型，微小模型僅為 80kb。另外，它還支持 GPU 加速，相關操作可以使用 WebGL 運行。
針對人臉檢測工作實現了一個 SSD（Single Shot Multibox Detector）算法，它本質上是一個基于 MobileNetV1 的卷積神經網絡（CNN），在網絡的頂層加入了一些人臉邊框預測層。
（face-api面部標志探測器）
確認替換后，針對于React Native線程調度做一下調優，為了方便理解，我簡單繪制了一個示意圖，講解下流程：
•JS Thread：React 等 JavaScript 代碼都在這個線程執行。
•Bridge：連接橋，具有異步，序列化，批處理的特點
•Shadow Thread：進行布局計算和構造 UI 界面的線程。
•Native modules提供 Native 功能（比如相冊、藍牙）
•UI Thread：Android/iOS（或其它平臺）應用中的主線程。
（ReactNative線程示意圖）
比如我們繪制一個UI，JS thread會先對其序列化,形成一條UIManager.createView 消息，然后通過Bridge發到Shadow Thread。Shadow Tread接收到這條信息后，先反序列化，形成Shadow tree，再轉換原生布局信息，傳給UI thread。
而UI thread 拿到消息后，同樣先反序列化，然后根據所給布局信息，進行繪制。
而這一系列都強依賴于 bridge，像高度計算、UI更新每次的操作都通過 bridge傳遞，任務一多，就會生成任務隊列，異步操作批量處理，一些前端的更新很難及時反應到 UI 上，特別是類似于更新頻率較高的動畫操作，任務較多，很難保證每一幀及時渲染。
那么，優化的方向：
1.減少 JS Thread 和 UI Thread 之間的異步通信，或者減少較少JSON的大小
2.盡量減少 JS Thread 側的計算
5.解決問題
整體解決方案是face-api替代tracker；React Native做一下調優。下面主要分三步講下React Native調優。
1.開啟動畫原生驅動
useNativeDrive: true
JS Thread 和 UI Thread 之間是通過 JSON 字符串傳遞消息的。對于一些非布局的屬性、直接事件，（useNativeDriver 這個屬性只能使用到只有非布局相關的動畫屬性上，例如 transform 和 opacity。布局相關的屬性，比如說 height 和 position 相關的屬性，開啟后會報錯。）比如人臉識別成功，人員信息卡片動畫，我們可以使用 useNativeDrive: true 開啟原生動畫驅動。
Animated.timing(this.state.animatedValue, { toValue: 1, duration: 500, useNativeDriver: true, // <– Add this }).start();
通過啟用原生驅動，我們在啟動動畫前就把其所有配置信息都發送到原生端，利用原生代碼在 UI 線程執行動畫，而不用每一幀都在兩端間來回溝通。如此一來，動畫一開始就完全脫離了 JS 線程，因此此時即便 JS 線程被卡住，也不會影響到動畫了。
2.使用交互管理器 InteractionManager
使用InteractionManager可以讓一些耗時的任務在交互操作或者動畫完成之后進行執行，比如：會場分布的跳轉動畫。目的是平衡復雜任務和交互動畫之間的執行時機。
const handle = InteractionManager.createInteractionHandle();// 執行動畫… (`runAfterInteractions`中的任務現在開始排隊等候)// 在動畫完成之后開始清除句柄：InteractionManager.clearInteractionHandle(handle);// 在所有句柄都清除之后，現在開始依序執行隊列中的任務
根據官方解釋的解釋：runAfterInteractions接受一個回調函數，或是一個PromiseTask對象，該對象返回一個Promise。如果提供的參數是一個PromiseTask， 那么即便是異步的它也會阻塞任務隊列，直到它執行完畢后，才會執行下一個任務。這樣就可以按需優化動畫流暢度。
3.重新渲染
React中，當父組件中觸發setState， 未修改任何state中的值也會引起所有子組件的重新渲染， 或者當父組件傳給子組件的props發生改變， 不管該props是否被子組件用到， 也都會去重新渲染子組件。
那么，針對重新渲染問題，使用PureComponent和shouldComponentUpdate對于普通函數進行優化；對于hook組件使用memo優化；
至驗證后整體得到改善，交互較為流暢，達到基本性能指標。現在主要是針對于概率性問題是否復現。尋求測試同事的幫助。
6.驗證問題（性能監控平臺的應用）
首先為什么要使用性能監控平臺：1.處理重復信息，避免一些問題在多個APP上重復處理，或者在一個APP上反復處理；2持續捕捉重要可疑信息，提升效率，降低人力成本。
其次什么時候、什么場景下使用性能監控平臺：除了測試、運維需要使用性能監控平臺，開發者也要學會利用性能監控平臺去輔助定位解決問題，這里推薦兩個方案：
1.Google Android Vitals + Firebase
Android vitals是Google為提高Android設備穩定性和性能而推出的一項計劃， Google Play 的Android vitals控制臺可以突出顯示崩潰率、ANR 發生率、喚醒次數過多以及喚醒鎖定被卡住等指標。包含了開發者常用功能，關鍵是不侵入代碼，應用比較方便。
而Firebase除此之外還可以獲取詳細的自定義崩潰報告數據，以了解應用中出現的崩潰情況。該工具會按相似堆棧軌跡將崩潰分門別類，并根據崩潰對用戶所產生影響的嚴重程度進行分級。除了接收自動生成的報告外，還可以通過記錄自定義事件來獲知導致應用崩潰的操作。
（Vitals + Firebase功能對比圖）
所以一般情況下使用Android Vitals可處理大部分簡單問題，并可搭配Firebase靈活處理自定義事件。
不太方便的是Google國內限制，需要公司申請專線跨境聯網，并且網絡波動時，經常需要身份驗證（這點比較煩人）。
費用上：Android Vitals使用免費，但是需要25$注冊開發者賬號；Firebase有免費版和付費版。適合外企、跨國公司或者有相關資質的公司研發使用。
2.友盟+ U-APM
由于Google國內限制，很多企業沒有網絡報備不能連接外網，那么友盟+ 的U-APM也可以完美滿足以上需求。針對于我的項目，我這里是選擇接入友盟+SDK由測試同事協助問題檢測。
APM是友盟+推出的一款面向開發者監控應用的穩定性數據產品——U-APM應用性能監控平臺，提供實時、可靠、全面的應用崩潰、ANR、自定義異常等捕獲能力，支持多場景、多通道智能告警監控，幫助App開發者深入了解應用的性能和穩定性，高效提升應用質量，還原崩潰用戶的訪問路徑和業務現場，縮短故障排查時間。
（APM核心技術與優勢）
為什么選擇友盟+ U-APM 應用性能監控平臺：
該產品通過發現線上問題-快速定位問題-高效解決問題打造體系化線上質量監控平臺。擁有支持實時監控線上App崩潰趨勢，7*24小時監控告警與修復驗證，復現用戶崩潰現場，關鍵環節的重點監控，修復測試等特點。
并且有阿里技術背書，提供長期穩定的產品迭代和項目服務及專家咨詢能力。可以滿足研發、測試、運維的諸多需求。
（U-APM與競品功能對比）
由此可見，U-APM在同類型產品中還是具有很大的競爭力。
在本項目中我們著重捕捉分析，崩潰分析以及卡頓分析，U-AMP提供報表輔助分析崩潰，并對于崩潰信息提供詳細的日志，快照。對于卡頓捕捉，U-APM是通過主線程的響應時間，將有卡頓體驗的設備信息、卡頓日志進行上報。
（U-APM崩潰信息日志示例圖）
但是從報文直接看錯誤堆棧非常麻煩， U-APM利用聚合算法提供了卡頓模塊的功能，有效節省開發者大量挖掘問題的時間。
卡頓模塊支持正序、倒序兩種聚合形式：篩選影響用戶量大的200個堆棧從棧頂到棧底雙向聚合，幫助挖掘造成卡頓問題的最核心問題
兩種方法均展示出現頻率前10的模塊，子樹深度最多支持50層，幫助下挖詳細的卡頓模塊信息。
（U-APM卡頓模塊示例圖）
除此之外，U-APM中還提供了啟動分析、內存分析、網絡分析，用戶細查模塊，方便處理一些常見的問題，這里不過多闡述了。
那么我們最終通過U-APM也是順利的驗證問題、解決問題。完成了整個研發閉環。
三．項目總結
1.不要盯著問題看。對于app的性能優化也好，系統優化也好。問題的表象可能是由于本質的副作用帶來的。例如，本項目中局部現象是卡頓、不流暢，只盯著現象，我們很可能陷入優化困境，去優化渲染、減少canvas繪圖，甚至精簡業務。而最終突破我們的性能瓶頸是通過修改實現方式達成的，更適合業務場景、更能發揮機器性能。而這一切，需要數據去支撐。
2. 用數據說話。不要憑感覺，去檢測性能問題、評估性能優化的效果，要有可量化的渲染性能評判標準，以及可量化、可視化的優化工具。利用經驗去感覺、猜測對于團隊是沒有沉淀的，而數據和工具是可以傳承的。例如：對于優化性能如果沒有標準，對于結果沒有數據體現。那么整體的工作是沒有意義的，成功與否全靠leader拍腦門決定。
3.使用低配置的設備：同樣的程序，在低端配置的設備中，相同的問題會暴露得更為明顯。例如:在前期安卓開發真機上并沒有卡頓現象，放在工業真機上才暴露出卡頓等問題。而對于高低端設備都能帶來很好的用戶體驗，一直是一個很重要的問題。
4.權衡利弊：在能夠保證產品穩定、按時完成需求的前提下去做優化，投入產出比過高時，應采取其他方案，切勿過度優化。永遠不要忘記，優化性能的目的是提高用戶體驗，而不是炫技。
5.拋棄沉沒成本：對于研發中已經付出且不可收回的成本，不要影響未來的決策，例如：對于已經使用track開發的人臉識別模塊，數據證明選型影響到了性能。投入產出比在可接受范圍內，越早替換預期收益越高。
