本文同步自我是一隻香脆的大雞排
有同學問我，對應用開發你有沒有值得注意或小技巧的地方可以分享的。比如適配、優化、排查錯誤什麼的。雞排把自己的總結筆記整理出來了。供大家參考。
開工準備
在專案業務程式碼開工之前，最好把這些問題都解決掉，否則必將釀成大禍害。它們是：
- 元件路由
- 非同步處理
- 元件化模組工程
- 全域性網路攔截器
- 異常統一處理器
- 基礎檢視元件封裝
- 日誌記錄工具
- 解決寫無數次一模一樣程式碼的模板（如自定義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。切勿使用notifyDataSetChanged()方法,這裡要用兩個引數的notifyItemChanged(1,"gfg")方法。
4.資料懶載入，或排隊載入。
5.混淆可以使包減小含:(xml 資源 class等)
6.如果玩得不是很6，儘量不要寫靜態引用，匿名內部類這種會導致記憶體洩漏的東西。如果很擔心自己失誤的寫了，一定要去分析它們，把他們揪出來。
7.Activity的層級不要太深。過深的層級會在低記憶體裝置上被回收棧底的Activity。
建議和技巧
1.發現某處程式碼可以複用性的封裝一下或者改良一下會更好的時候一定要乘早，不要拖延。（爛泥巴只會越來越爛，後面改=永遠沒可能）
2.debug編譯期間可以把用不到的abi過濾掉，會讓我們加速部署。
3.儘量保持較新的 support library依賴。因為較高的版本中修復了一些bug。
4.接入第三方包時，最好與自身模組保持獨立，做到隨時解耦，隨便複用。
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設上一張圖片過渡一下。
有不妥之處，歡迎指出和補充，拼死掙扎的Android程式設計師。