辭舊迎新。
2018的工作總結一直拖着拖到現在忍不下去了終於扣了半天扣出一個總結。
2018年已經過去，回看，有努力，有成果，也有遺憾，有無奈。
由於不考慮kpi，所以主要總結遺憾和無奈。
最大的遺憾
是立了一個爲聽障／視障人士開發更滿足他們需求的功能交互的flag，結果無疾而終。
目前蘋果手機做的相對比較好，但是價格較貴，聽視障礙人士很多收入不高，android手機價格相對便宜但是這方面做的不太好，第三方軟件受限於權限問題，某些方面可能做不了系統廠家可以做的事。
原因有很多成分，自己努力堅持不夠吧。
最大的無奈是
在軟件供應鏈上被巨頭鄙視了。
儘管做了很多努力，比如配套的生態，重點宣傳等共贏措施。
原因有很多成分，也許是自身體量的問題，巨頭看不上，也許是溝通問題，沒找對門路或者沒能打動對方。
沒有bug的一年，不是完整的一年，2018年bug主要分佈：
新需求產生的bug爲33%。
也就是自己作出來的問題佔了1/3。可以理解。
年度最作，錄像防抖方案存在瑕疵，永遠有20多幀視頻cache在防抖模塊裏，只有在結束的時候才能flush出來，20多幀視頻在時間維度上差不多要1秒鐘了，在結束之前音頻相應的就多了1秒鐘，而從錄像的框架和編碼的實現上都不會在兼顧這種奇葩情況上浪費時間，所以錄像播放的最後1秒只有聲音沒有視頻觀看體驗很不好。
最終權衡再三妥協再三，最佳方案是，作了一個小模塊cache音頻1秒鐘左右，結束的時候音頻cache和視頻cache默認被放棄，這樣錄出來的視頻就非常同步了，雖然最後800毫秒左右會丟掉，這是綜合最大效益的方案了，硬傷沒辦法。
傳統框架上的問題爲27%。
不到三分之一，比如解碼，播放，交互等等。
聲音和音質的問題佔了15%。
包括測出來的和用戶反饋的。
視頻圖像質量的問題報告或反饋幾乎沒有(彩條，綠屏，馬賽克，不完整等屬於視頻圖像解碼顯示問題不屬於質量問題)。
有2個原因，用戶對視頻圖像質量的變化不敏感或者不挑剔，或者用戶羣還沒有形成這樣的意識環境，視頻圖片行業內容爲王，有的看就行還要啥自行車，還有就是視頻行業的內容巨頭們也是很關注視頻的質量的體驗的，當然他們也關心帶寬，所以他們提供了有前提條件的內容質量，但是也不盡然，最近在重溫西遊記前半部分，無論哪個檔次畫面都讓我覺得還不如我小時候看的crt畫面清楚。
但是音質就不一樣了，我們對聲音更敏感和挑剔，一首3分鐘的音樂，中間出現兩次雜音或者卡頓之類的，就要罵娘了。
可能還有部分原因是用戶沒有畫質反饋入口，這個可以完善。
CTS/GTS/VTS等問題佔比11%。
這是google爲了保證android開放生態下系統服務一致性安全性等方面的強制措施。
而且各種TS越來越多，收的越來越緊。好好搞，google會考試的，考不過後果很嚴重的，上個月的搞完了嗎，這個月還有，忙起來，省的你們閒得想自己搞個操作系統。
性能，功耗，穩定性佔比6%。
框架的性能，功耗在cpu一定的情況下80%是一定的，20%可能存在優化空間。業務上的功耗性能問題會比框架要多得多。
穩定性問題佔了大部分，框架承上啓下提供了一些服務，上層業務在框架上發展，框架的缺陷或底層缺陷導致的框架不可用或可用性變差，會表現在上層業務上，有些業務是系統業務會引發連串的系統問題導致系統不可用或可用性降低，用戶體驗變差，如果上層業務不受影響，誰管你框架的死活，當然這是不可能的，業務是魚框架是水。
平臺漏洞佔比5%。
單獨拿出來是因爲，這種坑太深太隱蔽，而且造成的後果比較嚴重。
幾家平臺坑的各有特點，某家最坑，使用這個平臺的客戶較少，不過代碼最乾淨，研發投入最大。
這裏要頒發兩個年度最佳應用一個是海外的sweetsanp，一個是酷狗音樂，它們暴露了兩個很嚴重的平臺漏洞。
（1）.sweetsnap遇到的問題。
是無法正常錄像，框架層面也沒有報告給app，app在這個過程中認爲一切正常，調查發現sweetsnap在使用編碼接口時，參數設置存在邏輯問題：它使用了b frame，但是b frame個數爲0，而p frame的個數大於0。
首先，這樣設置在編碼原理上是有問題的，但是mediacodec api並沒有顯示的限制這種設置或者說明，那樣的話增加了接口的複雜度，對開發者是不友好的，邊界的檢查放在了框架設置更底層的hal層，然後把結果逐層上報。
這裏平臺上v4l2邊界檢查的邏輯出現了漏洞，放過了使用b frame，但是b frame爲0， p frame不爲0的情況，沒有正確上報問題，實際編碼又沒有成功。
（2）.酷狗音樂遇到的問題。
是功耗比正常數據大了300多mA。
看systrace統計，audiotrack中的一個線程佔有cpu時間異常，感覺在空跑。
發現是mMyCond.waitRelative(lock, paused_ns)這個函數實效，進一步調查發現這個函數在應用處於32bit運行時失效，基本所有音視頻第三方應用都是32bit運行時，都採用audiotrack輸出聲音，所有基本都有這個問題。
用我們可以切換32/64bit運行時的demo發現，在32bit下也是這種失效情況，64bit下函數有效，由於參數paused_ns數值比較大，加上32bit/64bit的差異，懷疑是溢出問題。
最後發現waitRelative最終實現是libc的__pthread_cond_waittimeout函數，超時參數在32bit下CLOCK設置爲REALTIME時，會發生溢出，需要將CLOCK調整爲MONOTONIC。
開發者提出的問題佔比在3%。
但有一部分問題系統層面也不好處理或者沒有義務處理需要開發者自己關注注意api的使用。
一些api使用開發者很熟悉了比如bitmap用完要記得recycle，culsor要記得close之類的，網上類似的文章也一大堆，但是有些api或參數的使用注意事項幾乎沒有介紹。
（1）.對於沒有正確使用api的android設計了一些懲罰機制。
應用開發者應該很清楚exception這個機制。
在 android除了exception機制之外其實還有其他提醒開發者的方式，比如assert, abort等，但是它們不像exception這麼溫柔了，直接用自殺的方式告訴你兄弟這樣搞不對。
比如app要錄像，錄屏的時候，分辨率寬高最好設置成2的倍數，也就是不要出現奇數，16的倍數最好，方便底層編碼工作，有些平臺對不是2的倍數的情況，會直接在native層abort導致程序異常。
而如果對多媒體視頻不太瞭解的java工程師往往比較迷惑暫時找不到頭緒。即使看到native fatal backtrace。
即使在webrtc這樣非常流行的開源庫裏，在一個動態分辨率的調整的模塊裏也存在類似問題，它降低分辨率的算法是直接寬高各處以2，這樣降低分辨率的梯度不夠平滑不說，如果分辨率處以2最後會變成奇數，造成兼容性問題。
（2）.還有一種應用更過分，佔着所有坑，別人來了沒坑用。
（2.1）.比如有些開發者，在自己的應用裏，無限制的使用mediaplayer但短期內不釋放，用了幾個發現用不了。
這是因爲mediaplayer爲開發者提供播放便利的同時，它也隱藏了很多細節比如解析解碼等模塊或資源的管理。
一個mediaplayer對象的創建或使用就代表了一套解析解碼等相關資源的分配，只有這個mediaplayer被釋放了（不一定java對象被回收），這套資源纔會回收釋放，這也是mediaplayer提供release這個接口的設計初衷，讓開發者儘早釋放配套資源，可以在java對象被回收之前。
如果這些配套資源都是軟件的，在內存允許的情況下，理論上是不存在對象個數限制的，但是解碼器有些是硬件的尤其常用的h264,h265等，硬件資源是有限制的，管理解碼器的框架叫omx，硬件解碼器omx實例的個數是有限的。
對於h264等格式android播放框架默認優先使用硬件解碼，一個mediaplayer對象分配一個硬件解碼器omx實例，但是有個數限制，超過個數分配不出來。
而android框架上並沒有硬件分配不出來轉去分配軟解碼器的設計（如果這麼做會產生另外一個困惑，開發者不知道你第n個解碼器是軟的還是硬的）。
硬件解碼器omx實例個數每個平臺不一樣最少的也有2個，最多的可能有8個，同時播放2個視頻夠了吧(2個mediaplayer對象)，如果真有特殊需求，就不要用mediaplayer了，用android的mediaextractor,mediacodec去同時調用硬件和軟件解碼器，或者自己用ffmpeg實現解碼播放。
（2.2）.除了佔着mediaplayer不放的，還有佔着audiotrack不放的。
而且是某些日活上億超級應用，用戶每天都會打開。
有些定製系統爲了用戶體驗追求快速啓動，會把一些超級應用放進一個名單裏，不會被真正殺死。
audiotrack也是有限的，最多32個，如果被超級應用全部吃掉，不釋放或泄漏了，其他有音頻輸出需求的應用再也獲取不到audiotrack實例，用戶就聽不到聲音了，而且用戶殺死也沒用，因爲它沒被真正殺死。
my chaos monkey design
what is chaos monkey?
名字來源於netflix的一個開源項目chaos monkey，該項目故意製造一些線上問題然後看整個系統包括軟件，人員等的反應能力。逆向思維，值得學習。
在這裏是一套自動化測試體系，包含了對邊界條件，性能，重點api等掃描的測試用例和自動化過程實現。是對android官方提供的資源的一個補充。
buster。
靈感也來源於netflix的chaos monkey。
在移動端實際工作中，經常會遇到一些逼近或突破軟件系統極限的問題，對軟件的邊界設計是一個考驗，也會暴露很多問題。
這些問題，散落在各個模塊的bug系統裏，即使有關注也是各個模塊人工跟蹤可重複性差，並沒有作爲一類問題加以重視。buster做的是，將這些問題作爲一類問題，並且利用自動化的方式實現高可重複性，提高掃描或迴歸等測試效率。
比如，一張巨大的圖片，應用在前臺解碼時幾乎會耗盡所有的內存，系統剩餘可用內存會逼近0。
這個時候會發生一些不可以預期的嚴重問題，也許是前臺應用會崩潰界面閃退，也許是其它模塊內存得不到分配導致系統卡死等等。
現實的場景有很多，比如微信朋友圈發圖選圖的時候打不開或閃退，文檔或圖庫等閃退或導致系統卡死等等，這些地方都會去解碼圖片，如果解碼列表裏有一張巨大的圖片就會發生這些問題。
chanpion。
關注框架重點api的性能，核心是它的benchmarks，這些數據是通過對比不同平臺，廠家，機型的出來的。
屬於同一代的平臺會拿來進行比較，但是也要注意測試時，同一代的平臺不同廠家產品，運行時的當前cpu頻率，比如都是660的平臺，同一測試場景結果差異比較大，要關注下當前cpu頻率是否有差別，有些廠家會通過調頻做一些加速。
還有一個方法確定，就是把執行過程拆分成一個個原子步驟，每一步耗時，在總耗時少和總耗時多的產品上都統計出來，如果每一原子步驟耗時都沒有異常大的說明你的這個過程問題不大，差異應該在不同產品cpu頻率不同，反之如果在耗時多的產品上執行過程中某一原子步耗時過長，這裏可能存在問題需要優化。
straight。
是api的demo實現，便於問題的驗證和對比，也可以給開發者作爲參考。
主要是場景和feature demo，更貼近於實際問題，是對android api demo的一個補充。
比如，通過實現多路錄音，來模擬錄音的同時錄像，voip通話之類的場景。
展望2019
less is more & slow down。
一個詞概括就是focus，在有限資源的前提下，專注1，2件最有價值最有意義的事情。
2019我們還有機會嗎，試過才知道。