本文同步自我是一隻香脆的大雞排程序員
有同窗問我,對應用開發你有沒有值得注意或小技巧的地方能夠分享的。好比適配、優化、排查錯誤什麼的。雞排把本身的總結筆記整理出來了。供你們參考。api
在項目業務代碼開工以前,最好把這些問題都解決掉,不然必將釀成大禍害。它們是:網絡
特定的機型上出問題時,彆着急。咱們能夠嘗試如下幾個辦法。架構
1.若是app在調試的過程當中出現閃退,此時在logcat下日誌會被新起來的進程沖刷掉。這時須要把過濾器選擇爲No filter 把日誌級別選爲 error便可查看到上一次崩潰的日誌。app
2.有一種狀況是手機並不在咱們身邊,咱們也沒法使用調試工具。此時能夠接入一些第三方的日誌記錄工具。在開發狀態下不建議使用友盟 360之類sdk,由於頗有可能咱們的app根本沒法鏈接到網絡就崩潰了。 能夠選擇把日誌存到本地文件中。再由使用手機的人發回來。通常這我的是測試。異步
3.若是app未接入任何日誌保存工具,能夠在data/anr/目錄下查看到全部的ANR異常信息。但須要su權限。不然沒法訪問到。工具
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程序員。