背景
降功耗，提清晰度（華爲超分算法），流暢度（一加插幀算法）
規劃
爲了surfaceView能穩定能上線，採用和華爲（歷史就有合作）合作的方式進行，一共分爲3個階段推進。
具體如下：
- SurfaceView可用
- 保證surfaceView可用，無crash。
- SurfaceView 首幀優化
- 保證使用surfaceView的情況，首幀和textureview持平
- SurfaceControl 最佳實踐，android 系統 >= 10.0 可用
踩坑及解決方案
1. 黑屏
1. Zorder -3
surfaceview送顯（送顯就是給surfaceview填充圖像數據）晚了，導致surfaceView無內容繪製，導致黑屏。
排查方向切換過程中dummy surface（佔位不黑屏作用）或者surface + play 綁定關係出現異常。正常情況下只要player 正常 codec工作，就會送幀數據給surfaceview。
2. surface + player 張冠李戴
架構情況導致，不通用
3. 退後臺過程中屏幕黑屏
dummy surface 的是否使用了。由於surfaceView 只要gone掉，surface立馬銷燬，會出現黑屏情況，爲了避免，這種情況，可以通過設置setSurface(null)的方式，通知播放器使用dummy surface 佔位，優化體驗。
2. 各種 Crash
crash主要分爲2類：
第一個類，系統定製化導致（各個廠商都在優化GUI框架），經過嘗試，可以得到以下基本共識：
1. 巴西和泰國市場的主流機型，除了三星（海外三星問題推動困難）外，8以上系統無明顯問題。
2.國內市場，華爲8系統有風險（最好不上，rom兼容據說有問題），9系統（沒問題）和 10系統（退後臺，問題已經修復），1加內側無明顯問題。
第二個類，業務代碼導致，主要是考慮點，“異步”、“臨界點”。
3. 首幀數據負向
在第一期中，主要考慮可用，實際prepare時間延後，在surfaceView# surfaceCreated 回調後觸發播放邏輯，用戶感知的首刷時間驗證，數據負向。
在第二期中，
方案1: 通過保證在surface未回調前，先prepare player 在surfaceView# surfaceCreated回調後，在進行setSurface，在觸發start（必先出現黑屏播放）。
方案2 : 通過保證在surface未回調前，先prepare player，然後將SurfaceView的控制權交給Player（setSurfaceHolder)。
第二期難點，切記別張冠李戴。
回顧
對播放底層來說，使用SurfaceView 和TextureView 二者提供的surface 無明顯的差別，均是把解碼的數據放到指定的指針地址。然後通過系統的SurfaceFlinger進行surface的整合和顯示。
surfaceView的一切收益，都是由surfaceView的擁有獨立surface 所帶來的，其主要的兼容性問題也與此密切相關。
surfaceView surface不能緩存（10.0之前），surfaceView的渲染，必須在surfceView的surfaceCreated 和 surfaceDestroyed 狀態之間使用。所以想使用好surface，必然要通過View的visible和gone來控制surface的生命週期。尤其注意切換頁面的時候，view顯示隱藏狀態的處理。
想提高速度，必然要打破SurfaceView的顯示狀態，前置prepare player。
展望
隨着各個廠商的定製化的逐漸完善，bug越來越少，surafceView的推進上來看，最適合
SurfaceControl 方案，預期會在數據體驗上和textureView打平。