Android開發過程中的部分經驗總結

標籤：

該文章為Android App 開發過程中遇到的常見問題總結，該總結也會持續不斷的最佳化 完善當中。後續開發中一定會遇到各種各樣的問題， 這些問題會酌情不斷補充進來。

我將遇到的問題分為兩大類，非技術問題和技術問題。

一、 非技術問題。

　　非技術上的問題一般為項目的管理問題，重點是項目開發過程中的協調溝通問題。

　　1. 項目的開展。

      2. 項目的進展。

　　3. 項目的跟蹤。

　　4. 項目完成總結與評價。

二、 技術層面的問題。

　　1.  代碼規範問題。

　　　　該問題曾在公司內部的技術分享群中我曾經提出過，我個人認為代碼規範評判的標準就是：讓兩個人來寫一段代碼（相同也可不同），讓第三者來看，他分辨不出這兩段代碼是由不同的兩個人寫的。

      2. 代碼的品質的保證。

           從三方面來看：

　　　　（1） 對未來實際生產情況的準確判斷和預估。判斷大規模使用方式下，能不能抗住高並發或大業務量的壓力。

　　　　（2） 程式員在寫代碼時，自身對代碼品質是否有嚴格的要求和高層次的追求。比如單元測試是否能保證百分百覆蓋， 邊界條件是否考慮完全等等不一而足。

　　　　（3） 對技術能力是否有不斷提高的內在需求，是否是在不斷深入研究相關技術，並拓展自身的技術視野。

　　對以上三個方面立刻關注雖然不能取得立杆見影的效果，但長期來看，如果能持之以恒、潛移默化的踐行，我相信，對個人技術層面的提升效果還是非常顯著的。

 

三、 下面簡單舉例談談一些技術層面的問題:

　　Android 開發過程中遇到的問題都是較為瑣碎的，一般通過搜尋引擎，參考別人的解決方案，都可以得到較好的解決。

因此這裡重點談下Android App 效能最佳化的問題。

　　1 、降低執行時間
　　這部分包括：緩衝、資料存放區最佳化、演算法最佳化、JNI、邏輯最佳化、需求最佳化幾種最佳化方式。
　　(1). 緩衝
　　緩衝主要包括對象緩衝、IO緩衝、網路緩衝、DB緩衝，對象緩衝能減少記憶體的分配，IO緩衝減少磁碟的讀寫次數，網路緩衝減少網路傳輸，DB緩衝較少Database的訪問次數。
　　在記憶體、檔案、資料庫、網路的讀寫速度中，記憶體都是最優的，且速度數量級差別，所以盡量將需要頻繁訪問或訪問一次消耗較大的資料存放區在緩衝中。

　　Android中常使用緩衝:
　　訊息緩衝
　　通過handler.obtainMessage複用之前的message，如下：

handler.sendMessage(handler.obtainMessage(0, object));

　　(2). 資料存放區最佳化
　　包括資料類型、資料結構的選擇。
　　a. 資料類型選擇
　　字串拼接用StringBuilder代替String，在非並發情況下用StringBuilder代替StringBuffer。如果你對字串的長度有大致瞭解，如100字元左右，可以直接new StringBuilder(128)指定初始大小，減少空間不夠時的再次分配。
　　64位類型如long double的處理比32位如int慢
　　使用SoftReference、WeakReference相對正常的強應用來說更有利於系統記憶體回收
　　final類型儲存在常量區中讀取效率更高
　　LocalBroadcastManager代替普通BroadcastReceiver，效率和安全性都更高

　　b. 資料結構選擇
　　常見的資料結構選擇如：
　　ArrayList和LinkedList的選擇，ArrayList根據index取值更快，LinkedList更占記憶體、隨機插入刪除更快速、擴容效率更高。一般推薦ArrayList。
　　ArrayList、HashMap、LinkedHashMap、HashSet的選擇，hash系列資料結構查詢速度更優，ArrayList儲存有序元素，HashMap為索引值對資料結構，LinkedHashMap可以記住加入次序的hashMap，HashSet不允許重複元素。
　　HashMap、WeakHashMap選擇，WeakHashMap中元素可在適當時候被系統記憶體回收行程自動回收，所以適合在記憶體緊張型中使用。Collections.synchronizedMap和ConcurrentHashMap的選擇，ConcurrentHashMap為細分鎖，鎖粒度更小，並發效能更優。Collections.synchronizedMap為對象鎖，自己添加函數進行鎖控制更方便。

　　Android也提供了一些效能更優的資料類型，如SparseArray、SparseBooleanArray、SparseIntArray、Pair。
Sparse系列的資料結構是為key為int情況的特殊處理，採用二分尋找及簡單的數組儲存，加上不需要泛型轉換的開銷，相對Map來說效能更優。不過我不太明白為啥預設的容量大小是10，是做過資料統計嗎，還是說現在的記憶體最佳化不需要考慮這些東西，寫16會死嗎，還是建議大家根據自己可能的容量設定初始值。

　　(3). 演算法最佳化
　　這個主題比較大，需要具體問題具體分析，盡量不用O(n*n)時間複雜度以上的演算法，必要時候可用空間換時間。查詢考慮hash和二分，盡量不用遞迴。

遞迴使用不當，容易引發棧溢出問題。

　　(4). JNI
　　Android應用程式大都通過Java開發，需要Dalvik的JIT編譯器將Java位元組碼轉換成本地代碼運行，而本地代碼可以直接由裝置管理員直接執行，節省了中間步驟，所以執行速度更快。不過需要注意從Java空間切換到本地空間需要開銷，同時JIT編譯器也能產生最佳化的本地代碼，所以糟糕的本地代碼不一定效能更優。

　　(5). 邏輯最佳化
這個不同於演算法，主要是理清程式邏輯，減少不必要的操作。

　　(6). 需求最佳化
這個就不說了，對於sb的需求可能帶來的效能問題，只能說做為一個合格的程式員不能只是執行者，要學會說NO。不過不能拿這種介面敷衍產品經理哦。

　　2、非同步，利用多線程提高TPS
　　充分利用多核Cpu優勢，利用線程解決密集型計算、IO、網路等操作。　　
在Android應用程式中由於系統ANR的限制，將可能造成主線程逾時操作放入另外的背景工作執行緒中。在背景工作執行緒中可以通過handler和主線程互動。　　

　　4、網路最佳化
　　以下是網路最佳化中一些用戶端和伺服器端需要盡量遵守的準則：
　　a. 圖片必須緩衝，最好根據機型做圖片做圖片適配
　　b. 所有http請求必須添加httptimeout

　　c. 開啟gzip壓縮
　　d. api介面資料以json格式返回，而不是xml或html
　　e. 根據http頭資訊中的Cache-Control及expires域確定是否緩衝請求結果。

　　f. 確定網路請求的connection是否keep-alive
　　g. 減少網路請求次數，伺服器端適當做請求合并。
　　h. 減少重新導向次數
　　i. api介面伺服器端回應時間不超過100ms

Android開發過程中的部分經驗總結