ps：我是個產品，雖然是java轉的，但是程式碼都忘光了，這篇文章純粹是記錄討論解決方案，不涉及具體技術實現方法。

背景介紹： 一個bugly多年的忠實粉問我： 他：你們的產品在獲取崩潰bug的時候是實時上傳的嗎？ 我：不是，我這邊是使用者發生崩潰後，再次啟動應用的時候下拉配置（上傳）； 他：哦。那這樣有個問題呀，如果使用者崩了，直接解除安裝應用，豈不是我永遠也統計不到這個資料了？資料不準確呀！ 我：嗯，確實是這樣。 他：那我就不敢用了，有隱患。 我：（臥槽！你的東西是多爛，崩潰了人家立馬解除安裝）好，我這邊跟研發童鞋商量一下，把這裡優化一下。

場景分析： 1、使用者定位為新使用者，因為老使用者對應用會有一定的忍耐力，不會那麼隨便的就解除安裝（爛得突破天際除外）； 2、新使用者首次進入剛開始體驗（未發現亮點）的時候就發生了崩潰，才會導致其在使用者眼裡失去價值，從而解除安裝；

實現目標：應用崩潰時直接將crash資料下拉，並上傳到平臺數據庫中；

問題難點： 1、當前下拉的崩潰資料分為兩部分，一為崩潰截圖，一位崩潰資訊（裝置資訊、堆疊資訊什麼），這兩部分是非同步請求的，以安卓為例：在發生崩潰時，SDK會自動對介面進行截圖和下拉錯誤資料儲存在本地，然後在應用再次啟動時，將錯誤資料上報到SDK Android的庫，然後在上報到平臺的資料庫中，上報成功則返回值，再將截圖上報到平臺數據庫中； 2、要實現崩潰實時上報資料，就需要在發生崩潰到程序結束中間的時間內執行，或者通過其他辦法在程序結束後也可以執行； 3、當網路不穩定的時候，如何避免資料上報不上來或者重複上報； 4、資料準確性和完整性；

解決方案： 方案一： 1、通過api控制截圖的開啟和關閉，開啟截圖則不進行實施上報，關閉則實時上報；最大量的避免網路影響。 2、為錯誤資料新增id，當上傳重複資料的時候根據id進行去重； 3、資料上傳失敗後進行重複上傳，保障資料不丟失； 4、通過跑指令碼的方式，在程序結束後執行上報操作（但是不穩定）； 方案二： 1、截圖和錯誤資料都是進行實時，首次上報失敗後則等下次啟動時再上報‘； 2、其他步驟相同；

擔心點： 1、資料準確性和效能問題：客戶擔心點就是丟資料，但是我擔心這樣這樣還是會丟資料，而且更嚴重； 2、效能問題：無論是指令碼還是在控制程序結束時間，都可能存在更多不確定因素，會不會對使用者使用造成影響； 3、SDK負載：SDK包瘦身以及快取機制問題；

結論：哎。。。。。走一步看一步吧，幫不上忙只能聽聽看。