該文章為Android App 開(kāi)發(fā)過(guò)程中遇到的常見(jiàn)問(wèn)題總結(jié)，該總結(jié)也會(huì)持續(xù)不斷的優(yōu)化 完善當(dāng)中。后續(xù)開(kāi)發(fā)中一定會(huì)遇到各種各樣的問(wèn)題， 這些問(wèn)題會(huì)酌情不斷補(bǔ)充進(jìn)來(lái)。

我將遇到的問(wèn)題分為兩大類(lèi)，非技術(shù)問(wèn)題和技術(shù)問(wèn)題。

一、 非技術(shù)問(wèn)題。

　　非技術(shù)上的問(wèn)題一般為項(xiàng)目的管理問(wèn)題，重點(diǎn)是項(xiàng)目開(kāi)發(fā)過(guò)程中的協(xié)調(diào)溝通問(wèn)題。

　　1. 項(xiàng)目的開(kāi)展。

　　　　磨刀不誤砍柴工。 項(xiàng)目開(kāi)展前，團(tuán)隊(duì)可以抽出一些時(shí)間（不宜太長(zhǎng)）進(jìn)行充分的討論，大家各抒己見(jiàn)，表達(dá)自己對(duì)項(xiàng)目的觀點(diǎn)。討論的重點(diǎn)當(dāng)然是技術(shù)層面的，這個(gè)階段，項(xiàng)目帶頭人可以抽出自己認(rèn)為比較難實(shí)現(xiàn)或者可能開(kāi)發(fā)過(guò)程中耗時(shí)比較長(zhǎng)的點(diǎn)，以及面臨的比較新的問(wèn)題，放到屏幕上，大家一起討論，提出自己的解決該問(wèn)題的方法，達(dá)到集思廣益，找到最優(yōu)的解決方案的目的。另一方面來(lái)看，這個(gè)過(guò)程其實(shí)也是團(tuán)隊(duì)成員提高的過(guò)程，在這個(gè)過(guò)程當(dāng)中，大家互相借鑒、互相驗(yàn)證，拿自己的解決方案和別人的思路進(jìn)行比較，找到不足，提出建議或批評(píng)，這都是非常有益的。也避免了，個(gè)別成員閉門(mén)造車(chē)的現(xiàn)象出現(xiàn)。

　　　　討論的過(guò)程，也是一個(gè)確定開(kāi)發(fā)任務(wù)并進(jìn)行分配任務(wù)的過(guò)程。每個(gè)人各抒己見(jiàn)的過(guò)程中，充分發(fā)揚(yáng)民主，大家達(dá)成共識(shí)，這樣，在項(xiàng)目開(kāi)發(fā)的落實(shí)中，因?yàn)槊總€(gè)人都積極參與了，所以大家的熱情也會(huì)比較高漲。

????? 2. 項(xiàng)目的進(jìn)展。

　　　

　　3. 項(xiàng)目的跟蹤。

　　　可以參考敏捷開(kāi)發(fā)的流程。比如站立會(huì)議，進(jìn)行交流，及時(shí)發(fā)現(xiàn)并解決問(wèn)題。

　　4. 項(xiàng)目完成總結(jié)與評(píng)價(jià)。

　　　總結(jié)以下幾個(gè)方面：1） 開(kāi)發(fā)中測(cè)試反饋的bug總結(jié)： 1）歸類(lèi)總結(jié)。2）數(shù)量統(tǒng)計(jì)。

　　　　　　　　　　　　2） 后續(xù)的開(kāi)發(fā)中，應(yīng)該怎樣避免類(lèi)似的上述問(wèn)題。 開(kāi)發(fā)前，開(kāi)發(fā)中，開(kāi)發(fā)后 這三個(gè)過(guò)程中怎樣做？提出針對(duì)性強(qiáng)、切實(shí)可行的措施。

二、 技術(shù)層面的問(wèn)題。

　　1.? 代碼規(guī)范問(wèn)題。

　　　　該問(wèn)題曾在公司內(nèi)部的技術(shù)分享群中我曾經(jīng)提出過(guò)，我個(gè)人認(rèn)為代碼規(guī)范評(píng)判的標(biāo)準(zhǔn)就是：讓兩個(gè)人來(lái)寫(xiě)一段代碼（相同也可不同），讓第三者來(lái)看，他分辨不出這兩段代碼是由不同的兩個(gè)人寫(xiě)的。

????? 2. 代碼的質(zhì)量的保證。

?????????? 從三方面來(lái)看：

　　　　（1） 對(duì)未來(lái)實(shí)際生產(chǎn)情況的準(zhǔn)確判斷和預(yù)估。判斷大規(guī)模使用情況下，能不能抗住高并發(fā)或大業(yè)務(wù)量的壓力。

　　　　（2） 程序員在寫(xiě)代碼時(shí)，自身對(duì)代碼質(zhì)量是否有嚴(yán)格的要求和高層次的追求。比如單元測(cè)試是否能保證百分百覆蓋， 邊界條件是否考慮完全等等不一而足。

　　　　（3） 對(duì)技術(shù)能力是否有不斷提高的內(nèi)在需求，是否是在不斷深入研究相關(guān)技術(shù)，并拓展自身的技術(shù)視野。

　　對(duì)以上三個(gè)方面立刻關(guān)注雖然不能取得立桿見(jiàn)影的效果，但長(zhǎng)期來(lái)看，如果能持之以恒、潛移默化的踐行，我相信，對(duì)個(gè)人技術(shù)層面的提升效果還是非常顯著的。

?

三、 下面簡(jiǎn)單舉例談?wù)勔恍┘夹g(shù)層面的問(wèn)題:

　　Android 開(kāi)發(fā)過(guò)程中遇到的問(wèn)題都是較為瑣碎的，一般通過(guò)搜索引擎，參考別人的解決方案，都可以得到較好的解決。

?

因此這里重點(diǎn)談下Android App 性能優(yōu)化的問(wèn)題。

　　1 、降低執(zhí)行時(shí)間
　　這部分包括：緩存、數(shù)據(jù)存儲(chǔ)優(yōu)化、算法優(yōu)化、JNI、邏輯優(yōu)化、需求優(yōu)化幾種優(yōu)化方式。
　　(1). 緩存
　　緩存主要包括對(duì)象緩存、IO緩存、網(wǎng)絡(luò)緩存、DB緩存，對(duì)象緩存能減少內(nèi)存的分配，IO緩存減少磁盤(pán)的讀寫(xiě)次數(shù)，網(wǎng)絡(luò)緩存減少網(wǎng)絡(luò)傳輸，DB緩存較少Database的訪問(wèn)次數(shù)。
　　在內(nèi)存、文件、數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)的讀寫(xiě)速度中，內(nèi)存都是最優(yōu)的，且速度數(shù)量級(jí)差別，所以盡量將需要頻繁訪問(wèn)或訪問(wèn)一次消耗較大的數(shù)據(jù)存儲(chǔ)在緩存中。

　　Android中常使用緩存:
　　消息緩存
　　通過(guò)handler.obtainMessage復(fù)用之前的message，如下：

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

　　(2). 數(shù)據(jù)存儲(chǔ)優(yōu)化
　　包括數(shù)據(jù)類(lèi)型、數(shù)據(jù)結(jié)構(gòu)的選擇。
　　a. 數(shù)據(jù)類(lèi)型選擇
　　字符串拼接用StringBuilder代替String，在非并發(fā)情況下用StringBuilder代替StringBuffer。如果你對(duì)字符串的長(zhǎng) 度有大致了解，如100字符左右，可以直接new StringBuilder(128)指定初始大小，減少空間不夠時(shí)的再次分配。
　　64位類(lèi)型如long double的處理比32位如int慢
　　使用SoftReference、WeakReference相對(duì)正常的強(qiáng)應(yīng)用來(lái)說(shuō)更有利于系統(tǒng)垃圾回收
　　final類(lèi)型存儲(chǔ)在常量區(qū)中讀取效率更高
　　LocalBroadcastManager代替普通BroadcastReceiver，效率和安全性都更高

　　b. 數(shù)據(jù)結(jié)構(gòu)選擇
　　常見(jiàn)的數(shù)據(jù)結(jié)構(gòu)選擇如：
　　ArrayList和LinkedList的選擇，ArrayList根據(jù)index取值更快，LinkedList更占內(nèi)存、隨機(jī)插入刪除更快速、擴(kuò)容效率更高。一般推薦ArrayList。
　　ArrayList、 HashMap、LinkedHashMap、HashSet的選擇，hash系列數(shù)據(jù)結(jié)構(gòu)查詢速度更優(yōu)，ArrayList存儲(chǔ)有序元 素，HashMap為鍵值對(duì)數(shù)據(jù)結(jié)構(gòu)，LinkedHashMap可以記住加入次序的hashMap，HashSet不允許重復(fù)元素。
　　HashMap、WeakHashMap選擇，WeakHashMap中元素可在適當(dāng)時(shí)候被系統(tǒng)垃圾回收器自動(dòng)回收，所以適合在內(nèi)存緊張型中使用。Collections.synchronizedMap 和ConcurrentHashMap的選擇，ConcurrentHashMap為細(xì)分鎖，鎖粒度更小，并發(fā)性能更優(yōu)。 Collections.synchronizedMap為對(duì)象鎖，自己添加函數(shù)進(jìn)行鎖控制更方便。

　　Android也提供了一些性能更優(yōu)的數(shù)據(jù)類(lèi)型，如SparseArray、SparseBooleanArray、SparseIntArray、Pair。
Sparse 系列的數(shù)據(jù)結(jié)構(gòu)是為key為int情況的特殊處理，采用二分查找及簡(jiǎn)單的數(shù)組存儲(chǔ)，加上不需要泛型轉(zhuǎn)換的開(kāi)銷(xiāo)，相對(duì)Map來(lái)說(shuō)性能更優(yōu)。不過(guò)我不太明白為 啥默認(rèn)的容量大小是10，是做過(guò)數(shù)據(jù)統(tǒng)計(jì)嗎，還是說(shuō)現(xiàn)在的內(nèi)存優(yōu)化不需要考慮這些東西，寫(xiě)16會(huì)死嗎，還是建議大家根據(jù)自己可能的容量設(shè)置初始值。

　　(3). 算法優(yōu)化
　　這個(gè)主題比較大，需要具體問(wèn)題具體分析，盡量不用O(n*n)時(shí)間復(fù)雜度以上的算法，必要時(shí)候可用空間換時(shí)間。查詢考慮hash和二分，盡量不用遞歸。

遞歸使用不當(dāng)，容易引發(fā)棧溢出問(wèn)題。

　　(4). JNI
　　Android應(yīng)用程序大都通過(guò)Java開(kāi)發(fā)，需要Dalvik的JIT編譯器將 Java字節(jié)碼轉(zhuǎn)換成本地代碼運(yùn)行，而本地代碼可以直接由設(shè)備管理器直接執(zhí)行，節(jié)省了中間步驟，所以執(zhí)行速度更快。不過(guò)需要注意從Java空間切換到本地 空間需要開(kāi)銷(xiāo)，同時(shí)JIT編譯器也能生成優(yōu)化的本地代碼，所以糟糕的本地代碼不一定性能更優(yōu)。

　　(5). 邏輯優(yōu)化
這個(gè)不同于算法，主要是理清程序邏輯，減少不必要的操作。

　　(6). 需求優(yōu)化
這個(gè)就不說(shuō)了，對(duì)于sb的需求可能帶來(lái)的性能問(wèn)題，只能說(shuō)做為一個(gè)合格的程序員不能只是執(zhí)行者，要學(xué)會(huì)說(shuō)NO。不過(guò)不能拿這種接口敷衍產(chǎn)品經(jīng)理哦。

　　2、異步，利用多線程提高TPS
　　充分利用多核Cpu優(yōu)勢(shì)，利用線程解決密集型計(jì)算、IO、網(wǎng)絡(luò)等操作?！　?br />在Android應(yīng)用程序中由于系統(tǒng)ANR的限制，將可能造成主線程超時(shí)操作放入另外的工作線程中。在工作線程中可以通過(guò)handler和主線程交互?！　?/p>

　　4、網(wǎng)絡(luò)優(yōu)化
　　以下是網(wǎng)絡(luò)優(yōu)化中一些客戶端和服務(wù)器端需要盡量遵守的準(zhǔn)則：
　　a. 圖片必須緩存，最好根據(jù)機(jī)型做圖片做圖片適配
　　b. 所有http請(qǐng)求必須添加httptimeout

　　c. 開(kāi)啟gzip壓縮
　　d. api接口數(shù)據(jù)以json格式返回，而不是xml或html
　　e. 根據(jù)http頭信息中的Cache-Control及expires域確定是否緩存請(qǐng)求結(jié)果。

　　f. 確定網(wǎng)絡(luò)請(qǐng)求的connection是否keep-alive
　　g. 減少網(wǎng)絡(luò)請(qǐng)求次數(shù)，服務(wù)器端適當(dāng)做請(qǐng)求合并。
　　h. 減少重定向次數(shù)
　　i. api接口服務(wù)器端響應(yīng)時(shí)間不超過(guò)100ms

轉(zhuǎn)載于:https://www.cnblogs.com/sxzheng/p/5633327.html

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。