寫這篇文章，主要也是為了方便麵試。因為最近兩年的工作主要都是人臉解鎖，面試官問得比較多的一個問題是，工作當中遇到印象最深的難點問題是什麼，以及是如何解決的。最近兩年中印象最深刻的一個難點問題是：人臉解鎖相機衝突問題。
1、現象描述
相機衝突的問題的觸發場景是：當前正在使用相機應用，比如“掃一掃”、“拍照”等，快速按power鍵熄屏然後亮屏，觸發人臉解鎖功能，然後人臉解鎖完成並返回到熄屏前的相機應用介面。出現相機衝突的概率和按power鍵的速度有關，在解決這個問題前，這種相機衝突現象幾乎是必現，現象是相機應用介面卡死、黑屏、crash或者提示沒有許可權等。
2、原因分析
人臉解鎖具有對相機資源使用的最高許可權（這一點由相機驅動/框架層設定的），表現在兩個方面：
（1）當有其它應用正在使用相機資源時，如果啟動了人臉解鎖，那麼人臉解鎖會搶過相機資源。
（2）當人臉解鎖完畢後，需要一些時間去釋放相機（比如150ms），這期間如果有其它應用要使用相機資源，則會申請失敗。
這兩個場景都會產生相機衝突，相應的現象是：
（1）人臉解鎖搶了其它應用的相機資源，會導致其它應用異常，根據這些應用處理方式不同，現象也各有差異，有的直接crash，有的黑屏，有的卡在影像介面。
（2）如果是後一種場景，人臉解鎖還沒有釋放相機資源，而其它應用又要申請，這時候其它應用基本上都會彈出對話方塊，提示“沒有相機許可權”或者“相機被其它應用佔用”等類似的提示。
3、第一版解決方案
既然找到了如上兩種相機衝突的原因，那麼就可以對症下藥，當時通過白名單的方式出了一版解決方案。具體的做法是：
（1）針對第一個原因，在啟動人臉解鎖時佔用相機資源前，等待一定的時間，讓其它應用主動釋放掉相機資源後，再繼續申請相機，走人臉解鎖流程。通過自測發現，當前正在使用“掃一掃”等相機應用，熄屏時該應用會主動釋放掉相機資源，但不同應用的相機功能釋放的時間不同，有的需要100ms，有的需要150ms，有的需要200ms等。
所以解決辦法是：在程式碼中列一個白名單，記錄下不同相機應用所在元件的路徑，比如“com.android.camera.CameraActivity”（可以通過adb命令等方式獲取），然後通過測試找到該應用釋放相機的時間且記錄下來。這樣，當亮屏時，通過白名單來確定需要延遲啟動人臉解鎖的時間，比如：熄屏前正在使用“美團”的“掃一掃”，我在白名單中查到了“美團”的“掃一掃”所在元件的路徑，且確定其釋放相機需要100ms，那麼按power鍵亮屏後，我就先等待100ms，給“美團”足夠的時間主動釋放相機，然後再啟動人臉解鎖流程。這樣就避免了人臉解鎖暴力搶佔其它應用相機資源這種場景了。
（2）針對第二個原因，通過測試發現人臉解鎖自己釋放相機需要150ms的時間，所以當得知滅屏前使用的是相機類應用時（和上一原因採用白名單方式一樣），人臉解鎖完成後等待150ms後再讓鎖屏消失，返回到滅屏前的相機應用介面。此時該相機應用會重新申請相機，且人臉解鎖已經釋放完相機了，所以就不存在相機被佔用的嘗場景了。
4、第二版優化方案
第一版方案確實解決了相機衝突的問題，但是也有一些很明顯的弊端：
（1）碰到正在使用相機類應用時，人臉解鎖時間變長了，因為人臉解鎖前後都需要等待不少時間。這其中有些時間是不一定需要等待的，我們設定的等待時間是考慮的最壞的情況，比如亮屏時很有可能前面的相機資源已經釋放了，或者已經釋放一部分了，不需要再等待200ms這麼長時間才去啟動人臉解鎖。
（2）難以維護。經常使用的相機類應用太多了，即便只算上經常時用的，也有幾十款之多，需要將這些元件路徑都儲存在白名單中。而且有些應用改版升級，原有的路徑可能會有改動，那麼又得把新的路徑加入到白名單。同時由於軟硬體的升級，這些應用原本釋放相機資源的時間縮短了。
針對這些問題，又做了進一步的優化：
（1）呼叫框架提供的介面，實時判斷相機是否可用，並監聽相機的狀態。當亮屏時，如果此時相機資源是空閒的，那就直接呼叫人臉解鎖。如果發現相機正被其它應用給佔了，但還沒有釋放掉，那就等待。直到監聽到相機資源被釋放了（框架提供的回撥方法），就立刻繼續走人臉解鎖流程。這樣就避免了方案一中可能不必要的等待。這個方法其實很容易想到，但是最初相機團隊同事明確說明沒有實時監聽相機狀態的介面可以用，且最初需要解決衝突的場景不多，所以就採用了白名單方案。
（2）人臉解鎖完成後，通過相機框架/驅動團隊同事的配合，動態降低人臉解鎖佔用相機的許可權。這樣就無需等待150ms來保證人臉解鎖釋放相機了，解鎖完直接返回到其它應用的相機，這些應用可以直接搶過人臉解鎖的相機資源。這個方案需要框架團隊、相機驅動團隊聯調，且需要改動的地方比較多，所以剛開始是被否定的。