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