某版本項目延期總結

某版本延期總結

問題：

技術方面：

• OOM：風控SDK的lifelistener，致使持有activity，內存沒法釋放

• 屢次操做下單流程，程序崩潰：線程管理混亂，致使線程不斷建立，內存OOM（具體的緣由沒有定位到，只是看到的表象）

• 併發的讀寫文件：多線程的文件讀寫，引起出來的流問題

暴露出來的問題：

• SDK的測試驗證過程與業務開發不一樣，並且影響面更大（原先的業務測試流程沒法適用），隱蔽性更大

• 沒有緊跟bugly，沒有及時發現問題

• 沒有關注app的性能與內存

• try，catch並無及時暴露出問題

• 代碼方案，須要審覈

• 未刪除不用的資源與代碼

須要作的事情：

• 排查全部出現線上crash的代碼

• SDK測試監控，流程更完善

• B，C端的app性能監控，優化

學到的東西：

• 開發，測試流程必須規範

• activitylifelistener的慎重使用，建議使用弱引用

• 併發文件的讀寫

• 須要及時的反饋（反饋的重要性）

• 第三方的框架使用更理性

• JVM的知識須要深刻

• 線程的知識須要深刻

• 性能優化的知識須要深刻

SDK發佈流程：

階段一--開發自測：

• 關注代碼功能的跑通

• 關注exception的問題

階段二--業務方引入：

• 日誌記錄

• 關注SDK的引入，有沒有引出新的exception

• 是否引發了crash

• 是否引發了內存泄漏，OOM

• 線程數的泛濫

• 是否引發了app的卡頓

• 此階段的SDK爲SNAPSHOT版本，這個階段的代碼不作try，catch，儘量得讓他崩潰，且SDK的catch（有些代碼必須防止try cache的，好比文件讀寫）的excepton，上傳到bugly

階段三--上線：

• 發佈前，改用正式版本

• 此階段的SDK爲release版本，會作try catch處理，同時移除exception的bugly的上傳

• 關注線上的crash