基於android4.4系統行車記錄應用黑屏問題分析及對策
筆者最近遇到一個棘手的問題，那就是行車記錄應用出現黑屏的問題，現象就是進入行車記錄應用surface是黑的，錄像文件幾分鐘一個的那種，每個文件的大小都是零。看到這個大家都非常重視，對於車載產品來說，行車記錄功能需要保持長時間正常工作，出現這種問題肯定是不能接受的，必須解決！那這個問題是怎麼出現的呢？
跟了很長時間，同時動用了8臺相同的機器來單獨做行車記錄的拷機測試，12個小時內都不會出問題，但是超過24小時，就有那麼2-3臺機器會出現黑屏的問題，時間越長出問題的機器會增多，當然筆者在連續測試3X24小時的情況下，還有那麼1-2臺機器是毫髮無損的正常工作！不是短時間就能出來，不是每臺都能遇到，遇到這樣的問題，大家可能都會覺得很棘手吧！那怎麼解決呢？
/*****************************************************************************************************/
聲明：本博內容均由http://blog.csdn.net/edsam49原創，轉載請註明出處，謝謝！
/*****************************************************************************************************/
要解決問題，我們也只能多做實驗了，加一些測試代碼用於調試，另外必須增加一個持續抓取系統打印信息的功能，否則這麼長時間，不可能都拿一臺機器在旁邊抓打印吧！即使可以，也很不方便是不是，也沒那麼多電腦做到一機配一PC吧！持續抓打印這個功能相對比較簡單，筆者在一年多前寫過類似這方面的博文，有需要的可以去翻閱一下。
首先來看一下出問題時的打印是個什麼樣的狀態吧！
10-09 01:10:32.670 E/V4L2CameraDevice( 1205): select timeout
10-09 01:10:32.670 W/V4L2CameraDevice( 1205): wait v4l2 buffer time out
10-09 01:10:32.670 W/V4L2CameraDevice( 1205): nmCurAvailBufferCnt: 2
10-09 01:10:32.670 W/V4L2CameraDevice( 1205): buffer: 0 ( refCnt:0 index:0 )
10-09 01:10:32.670 W/V4L2CameraDevice( 1205): buffer: 1 ( refCnt:1 index:1 )
10-09 01:10:32.670 W/V4L2CameraDevice( 1205): buffer: 2 ( refCnt:1 index:2 )
10-09 01:10:32.670 W/V4L2CameraDevice( 1205): buffer: 3 ( refCnt:1 index:3 )
10-09 01:10:32.670 W/V4L2CameraDevice( 1205): buffer: 4 ( refCnt:1 index:4 )
10-09 01:10:32.670 W/V4L2CameraDevice( 1205): buffer: 5 ( refCnt:0 index:5 )
10-09 01:10:32.670 W/V4L2CameraDevice( 1205): buffer: 6 ( refCnt:1 index:6 )
10-09 01:10:32.670 W/V4L2CameraDevice( 1205): preview_num: 0, picture_num: 0
10-09 01:10:33.110 D/dalvikvm( 2011): GC_FOR_ALLOC freed 1603K, 40% free 4102K/6796K, paused 51ms, total 51ms
10-09 01:10:34.690 E/V4L2CameraDevice( 1205): select timeout
10-09 01:10:34.690 W/V4L2CameraDevice( 1205): wait v4l2 buffer time out
10-09 01:10:34.690 W/V4L2CameraDevice( 1205): nmCurAvailBufferCnt: 2
10-09 01:10:34.690 W/V4L2CameraDevice( 1205): buffer: 0 ( refCnt:0 index:0 )
10-09 01:10:34.690 W/V4L2CameraDevice( 1205): buffer: 1 ( refCnt:1 index:1 )
10-09 01:10:34.690 W/V4L2CameraDevice( 1205): buffer: 2 ( refCnt:1 index:2 )
10-09 01:10:34.690 W/V4L2CameraDevice( 1205): buffer: 3 ( refCnt:1 index:3 )
10-09 01:10:34.690 W/V4L2CameraDevice( 1205): buffer: 4 ( refCnt:1 index:4 )
10-09 01:10:34.690 W/V4L2CameraDevice( 1205): buffer: 5 ( refCnt:0 index:5 )
10-09 01:10:34.690 W/V4L2CameraDevice( 1205): buffer: 6 ( refCnt:1 index:6 )
10-09 01:10:34.690 W/V4L2CameraDevice( 1205): preview_num: 0, picture_num: 0
10-09 01:10:35.500 D/dalvikvm( 2011): GC_FOR_ALLOC freed 1392K, 40% free 4102K/6796K, paused 44ms, total 44ms
10-09 01:10:36.700 E/V4L2CameraDevice( 1205): select timeout
10-09 01:10:36.700 W/V4L2CameraDevice( 1205): wait v4l2 buffer time out
10-09 01:10:36.700 W/V4L2CameraDevice( 1205): nmCurAvailBufferCnt: 2
10-09 01:10:36.700 W/V4L2CameraDevice( 1205): buffer: 0 ( refCnt:0 index:0 )
10-09 01:10:36.700 W/V4L2CameraDevice( 1205): buffer: 1 ( refCnt:1 index:1 )
10-09 01:10:36.700 W/V4L2CameraDevice( 1205): buffer: 2 ( refCnt:1 index:2 )
10-09 01:10:36.700 W/V4L2CameraDevice( 1205): buffer: 3 ( refCnt:1 index:3 )
10-09 01:10:36.700 W/V4L2CameraDevice( 1205): buffer: 4 ( refCnt:1 index:4 )
10-09 01:10:36.700 W/V4L2CameraDevice( 1205): buffer: 5 ( refCnt:0 index:5 )
10-09 01:10:36.700 W/V4L2CameraDevice( 1205): buffer: 6 ( refCnt:1 index:6 )
10-09 01:10:36.700 W/V4L2CameraDevice( 1205): preview_num: 0, picture_num: 0
10-09 01:10:37.050 D/MXNavi-JNI( 2726): send_Msg_to_control onUpdateGuidePointInfo pturninfo HighSpeedFlag:1,ulDistance370,destinationDistance:796,ulTurnid:5----EEyeGuideInfo{0-0-0}
10-09 01:10:37.080 D/MXNavi-JNI( 2726): send_Msg_to_control onUpdateGuidePointInfo pturninfo HighSpeedFlag:1,ulDistance370,destinationDistance:796,ulTurnid:5----EEyeGuideInfo{0-0-0}
10-09 01:10:37.190 D/MXNavi-JNI( 2726): snd_start_play_sound
10-09 01:10:37.190 V/jeavox ( 1657): MiddleWareService onNaviInfoSpecialStatusChanged####1 1
10-09 01:10:37.190 I/jeavox ( 1657): MiddleWareService NaviAudiowillPlay##1NAVI_RADAR_Coming 0
10-09 01:10:37.920 D/dalvikvm( 2011): GC_FOR_ALLOC freed 1430K, 40% free 4102K/6796K, paused 47ms, total 48ms
10-09 01:10:38.710 E/V4L2CameraDevice( 1205): select timeout
10-09 01:10:38.710 W/V4L2CameraDevice( 1205): wait v4l2 buffer time out
10-09 01:10:38.710 W/V4L2CameraDevice( 1205): nmCurAvailBufferCnt: 2
10-09 01:10:38.710 W/V4L2CameraDevice( 1205): buffer: 0 ( refCnt:0 index:0 )
10-09 01:10:38.710 W/V4L2CameraDevice( 1205): buffer: 1 ( refCnt:1 index:1 )
10-09 01:10:38.710 W/V4L2CameraDevice( 1205): buffer: 2 ( refCnt:1 index:2 )
10-09 01:10:38.710 W/V4L2CameraDevice( 1205): buffer: 3 ( refCnt:1 index:3 )
10-09 01:10:38.710 W/V4L2CameraDevice( 1205): buffer: 4 ( refCnt:1 index:4 )
10-09 01:10:38.710 W/V4L2CameraDevice( 1205): buffer: 5 ( refCnt:0 index:5 )
10-09 01:10:38.710 W/V4L2CameraDevice( 1205): buffer: 6 ( refCnt:1 index:6 )
10-09 01:10:38.710 W/V4L2CameraDevice( 1205): preview_num: 0, picture_num: 0
10-09 01:10:40.180 D/Clock_Component( 1205): ----adjust ratio:1 ,precise_adjust_ratio:1, ref:2703668109 sys:2703728392 diff:-60283 diff-percent:-1 ----
10-09 01:10:40.230 D/dalvikvm( 2011): GC_FOR_ALLOC freed 1409K, 40% free 4102K/6796K, paused 54ms, total 55ms
10-09 01:10:40.720 E/V4L2CameraDevice( 1205): select timeout
10-09 01:10:40.720 W/V4L2CameraDevice( 1205): wait v4l2 buffer time out
10-09 01:10:40.720 W/V4L2CameraDevice( 1205): nmCurAvailBufferCnt: 2
10-09 01:10:40.720 W/V4L2CameraDevice( 1205): buffer: 0 ( refCnt:0 index:0 )
10-09 01:10:40.720 W/V4L2CameraDevice( 1205): buffer: 1 ( refCnt:1 index:1 )
10-09 01:10:40.720 W/V4L2CameraDevice( 1205): buffer: 2 ( refCnt:1 index:2 )
10-09 01:10:40.720 W/V4L2CameraDevice( 1205): buffer: 3 ( refCnt:1 index:3 )
10-09 01:10:40.720 W/V4L2CameraDevice( 1205): buffer: 4 ( refCnt:1 index:4 )
10-09 01:10:40.720 W/V4L2CameraDevice( 1205): buffer: 5 ( refCnt:0 index:5 )
10-09 01:10:40.720 W/V4L2CameraDevice( 1205): buffer: 6 ( refCnt:1 index:6 )很明顯是select超時了，爲什麼超時了呢？是由於buffer的問題！沒有足夠的空buffer！上面的打印有每個buffer的refCnt，從打印上分析一個是錄像編碼那邊可能沒正常釋放，造成沒釋放的原因可能有系統任務多比較忙，也可能是SD卡讀寫速度跟不上，造成短時堵車，buffer沒正常處理，總的來說我還是懷疑錄像編碼模塊出的問題。但是有一個很現實的問題，就是這種問題在原廠那邊不是很重視，也是公司地位不門當戶對，也因爲這個行業還不是貢獻他們GDP的拳頭。人家不投入那麼多精力幫你，你能怎麼辦？跟老闆說，原廠不解決，我們沒辦法！這樣當然不行，很多客觀的條件我們短時解決平衡不了的。那總得有招吧！
筆者在測試發現，每次黑屏以後，該應用需要全部退出，再開啓，又能正常工作。在HAL層出問題了，一旦出現這種select超時的問題，它是不會自愈的，多長時間都一樣，那我想總可以想辦法讓應用知道這個事吧！上面知道這個事，不就有辦法解決了嘛！雖然這不是最佳的解決辦法，但是是合符目前各種現狀的！停止再重新開啓，大概需要1秒鐘，也就是說會丟一秒鐘的數據。這個在我看來這還屬於可以接受的一個範圍吧！
那怎麼上報呢？其實camera裏面有現成的一套，只要利用起來就好了！在camera.java裏面有一個重要的接口如下：
/**
* Registers a callback to be invoked when an error occurs.
* @param cb The callback to run
*/
public final void setErrorCallback(ErrorCallback cb)
{
mErrorCallback = cb;
}通過這個接口註冊可能作監聽錯誤，註冊了就相當於有一個鉤子在那等了！那誘餌怎麼拋出呢？還是得看看V4L2CameraDevice.cpp，這裏面已經有一個現成的mCallbackNotifier，並且mCallbackNotifier它還有一個onCameraDeviceError（）這樣一個現成的接口，那不就簡單了嘛！
因此，在select超時的地方，直接通過mCallbackNotifier去call onCameraDeviceError，順帶一個特殊的錯誤號，這樣行車記錄應用監聽到錯誤，對比一下錯誤碼，不就可以做處理了嘛！
筆者通過8臺機器，連續測試了將近110個小時，發現8臺機器都還在正常工作，沒有出現黑屏的問題！同時，我也看了一下其中5臺的系統打印，確實都曾出現過select超時的問題！那說明我們的處理方法手段還是有效的。雖然不是什麼很高明的方法，但是還是一條切合實際的路!
很多時候，我們沒有那麼多的資源，又要幹一些事情，當然需要想一些辦法了！
