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

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

一、 非技術問題。

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

　　1. 項目的開展。

　　　　磨刀不誤砍柴工。 項目開展前，團隊可以抽出一些時間（不宜太長）進行充分的討論，大家各抒己見，表達自己對項目的觀點。討論的重點當然是技術層面的，這個階段，項目帶頭人可以抽出自己認為比較難實現或者可能開發過程中耗時比較長的點，以及面臨的比較新的問題，放到屏幕上，大家一起討論，提出自己的解決該問題的方法，達到集思廣益，找到最優的解決方案的目的。另一方面來看，這個過程其實也是團隊成員提高的過程，在這個過程當中，大家互相借鑒、互相驗證，拿自己的解決方案和別人的思路進行比較，找到不足，提出建議或批評，這都是非常有益的。也避免了，個別成員閉門造車的現象出現。

　　　　討論的過程，也是一個確定開發任務并進行分配任務的過程。每個人各抒己見的過程中，充分發揚民主，大家達成共識，這樣，在項目開發的落實中，因為每個人都積極參與了，所以大家的熱情也會比較高漲。

????? 2. 項目的進展。

　　　

　　3. 項目的跟蹤。

　　　可以參考敏捷開發的流程。比如站立會議，進行交流，及時發現并解決問題。

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

　　　總結以下幾個方面：1） 開發中測試反饋的bug總結： 1）歸類總結。2）數量統計。

　　　　　　　　　　　　2） 后續的開發中，應該怎樣避免類似的上述問題。 開發前，開發中，開發后 這三個過程中怎樣做？提出針對性強、切實可行的措施。

二、 技術層面的問題。

　　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、網絡等操作?！　?br />在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

轉載于:https://www.cnblogs.com/sxzheng/p/5633327.html

總結

以上是生活随笔為你收集整理的Android开发过程中的部分经验总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。