開工準備

在項目業務代碼開工之前，最好把這些問題都解決掉，否則必將釀成大禍害。它們是：

• 組件路由
• 異步處理
• 組件化模塊工程
• 全局網絡攔截器
• 異常統一處理器
• 基礎視圖組件封裝
• 日志記錄工具
• 解決寫無數次一模一樣代碼的模板（如自定義MVP模板）

機型適配

特定的機型上出問題時，別著急。我們可以嘗試以下幾個辦法。

• 反編譯rom，看底層改動(條件略高)
• 聯系該廠商的工程師（如果可以的話）
• 拷貝整個我們調用api的源碼進行單獨依賴，而放棄系統內的
• 逆向在該機型上正常的同類app，參考逆向后的代碼實現
• 參考各個版本不同的Android API變化，可以從源碼入手進行對
• 利用反射獲取該特定機型上的某個我們想知道的方法，動態調試

排查崩潰閃退日志:

1.如果app在調試的過程中出現閃退,此時在logcat下日志會被新起來的進程沖刷掉。這時需要把過濾器選擇為No filter 把日志級別選為 error即可查看到上一次崩潰的日志。

2.有一種情況是手機并不在我們身邊,我們也無法使用調試工具。此時可以接入一些第三方的日志記錄工具。在開發狀態下不建議使用友盟 360之類sdk,因為很有可能我們的app根本無法連接到網絡就崩潰了。 可以選擇把日志存到本地文件中。再又使用手機的人發回來。一般這個人是測試。

3.如果app未接入任何日志保存工具,可以在data/anr/目錄下查看到所有的ANR異常信息。但需要su權限。否則無法訪問到。

APP性能體驗優化

1.素材有必要使用壓縮后的。推薦熊貓PNG壓縮。

2.資源能用代碼畫盡量使用代碼去畫，而不要使用靜態資源。

3.在復雜的布局上,比如很多app的首頁需要加載不同類型的item。使用了RecyclerView多類型加載,刷新數據時一定要使用單獨對item刷新api。切勿使用notifyitemchanged()方法,這里要用兩個參數的notifyItemChanged(1,"gfg")方法。

4.數據懶加載，或排隊加載

5.混淆可以使包減小含:(xml 資源 class等)

6.如果玩得不是很6，盡量不要寫靜態引用，匿名內部類這種會導致內存泄漏的東西。如果很擔心自己失誤的寫了，一定要去分析它們，把他們揪出來。

7.Activity的層級不要太深。過深會在低內存設備上被回收棧底的。

建議和技巧

1.發現某處代碼可以復用性的封裝一下或者改良一下會更好的時候一定要乘早，不要拖延。（爛泥巴只會越來越爛，后面改=永遠沒可能）

2.debug編譯期間可以把用不到的abi過濾掉，會讓我們加速部署。

3.盡量保持較新的 support library依賴。因為較高的版本中修復了一些bug。

4.接入第三方包時，最好與自身模塊保持獨立，做到隨時解耦，隨便復用。

接入第三方包時，最好與自身模塊保持獨立，做到隨時解耦，隨便復用?？赡芎芏嗳瞬焕斫猓号e個例子，如果需要將imgloader替換成fresco，若之前獨立出自己的方法，則會很簡單，否則得一個個替換，賊麻煩。

5.多個native庫依賴時，若發現某些abi上不支持，那么就需要保持最小的abi。否則會給某些機型優先讀取它更合適的架構。會造成災難性的崩潰。如:ARM文件夾中含兩個so，ARMv8中只有一個。屆時手機優先加載了ARMV8的情況下，將帶來找不到so庫的崩潰異常。

6.不要太隨性的引入第三方依賴庫，如果只是用了很小一部分功能，建議剝出來自己封裝。

7.第三方的包含私有api為暴露時，記得用反射去實現。當然這一切需要我們能翻他們的sdk源碼讀。也許被混淆了。這時就可以使用動態調試去跟蹤。

8.多數情況下官方的support包比第三方要好得多。只是我們不知道，或者不熟悉。

9.漸變圖、純色圖、帶一根線的圖用shape，不要靜態圖。會引發血案！

10.當無法通過搜索解決問題的時候，讀源碼是最快的解決思路。千萬不要瞎猜和嘗試隨緣寫代碼來解決問題。

11.封裝控件時注意對資源類型做校驗
如:Image.setImageResource(img);
這里的img需要做強校驗，類型檢測，防止別人用的時候不小心寫錯了。因為如果我們不主動拋出異常。靠LayoutInflater通過反射去解析xml時提示出了的錯誤日志非常難看。一般還會伴隨一大堆調用棧和閃退出現。

12.冷啟動優化，不要在Application啟動時里做過多的任務&第一個Activity里也是一樣。最好把初始化的白屏Window設上一張圖片過渡一下。