【51CTO.com原創(chuàng)稿件】Android開發(fā)過(guò)程常見的坑有三類：開發(fā)工具選取、技術(shù)文檔、列表頁(yè)加載

[[184546]]

Android開發(fā)

開發(fā)工具選取

1、開發(fā)中遇到的坑，說(shuō)一個(gè)IDE的選擇，我建議，使用你擅長(zhǎng)的IDE，很多時(shí)候，面對(duì)大家都說(shuō)好的IDE，盲目的跟風(fēng)，結(jié)果把很多時(shí)間浪費(fèi)在折騰IDE上了。（北京-陽(yáng)陽(yáng)-安卓）

2、Eclipse 和Android Studio對(duì)比，HTML和原生對(duì)比，MVC、MVP、MVVM對(duì)比。技術(shù)選型影響的成本對(duì)比、性能對(duì)比等等。適合自己，擅長(zhǎng)的工具，這個(gè)對(duì)于新人一開始很難判斷的，很多人也都有過(guò)把每一個(gè)IDE都玩?zhèn)€遍，最后才固定下來(lái)。IDE說(shuō)到底是為提高開發(fā)效率，方便維護(hù)代碼的工具，如果一個(gè)工具能實(shí)現(xiàn)你目前開發(fā)能力所需要的，那就夠了。不需要極度追求完美，有強(qiáng)大復(fù)雜功能的，有也很少用，多此一舉，甚至為此花不少時(shí)間去學(xué)配置。（廣州-益達(dá)-大數(shù)據(jù)）

3、AS確實(shí)方便不少，HTML和原生還是根據(jù)自己公司的業(yè)務(wù)需求來(lái)。（重慶-zee-終端）

4、Android開發(fā)代碼規(guī)范優(yōu)美很重要，特別是可讀性和可拓展性，APP是頻繁更新的產(chǎn)品，如果前期開發(fā)不考慮這個(gè)，后期維護(hù)和升級(jí)成本會(huì)遠(yuǎn)遠(yuǎn)大于開發(fā)成本，甚至成了一次性的東西。個(gè)人用文本編輯器的時(shí)間，比用IDE來(lái)的多。固定一個(gè)，用久了，快捷鍵也慢慢記住了。（廣州-狄欽dQ-PHP）

5、高手記事本都可以寫出優(yōu)雅的代碼出來(lái)，但即便給新手再?gòu)?qiáng)大的工具都未必寫的好。重視基礎(chǔ)，做你擅長(zhǎng)，其余外包，常見搭配Sublime Text+Vim（成都-恩威-云計(jì)算）

6、開發(fā)用過(guò)Eclipse和Android Studio，這兩種工具的切換最不習(xí)慣的是快捷鍵?，F(xiàn)在基本固定是AS了，只有很少時(shí)候需要用到Eclipse，但那快捷鍵用起真是捉急。（重慶-小包-Android）

更新文檔，特別是做好需求分析

7、項(xiàng)目伊始的話，盡量多寫文檔。類文檔，協(xié)議接口，接口負(fù)責(zé)人， 需求文檔，需求負(fù)責(zé)人。（深圳-sky-c++開發(fā)）

8、沒有文檔就不好處理，尤其是代碼亂的情況下。很多代碼寫完了，在里面注視一個(gè)此處邏輯有問(wèn)題。雖然有文檔和設(shè)計(jì)圖，但都是最老版本，后續(xù)改的可能與老版本的文檔不一樣。但究竟是哪里不一樣卻沒有更新標(biāo)注。最后，只能通過(guò)代碼來(lái)看業(yè)務(wù)要實(shí)現(xiàn)的功能。所以實(shí)時(shí)更新文檔，記錄每一處變更很重要。（成都-哈韓浪子-JAVA）

9、Android開發(fā)要寫好文檔，特別是做好需求分析。引導(dǎo)客戶了解他們需要什么系統(tǒng)?？梢酝ㄟ^(guò)設(shè)計(jì)原型讓客戶了解需求。做好前期的系統(tǒng)規(guī)劃，把握開發(fā)流程。不斷迭代，不斷與客戶交流，完成系統(tǒng)。按照計(jì)劃執(zhí)行，按流程走。否則會(huì)死的很慘，心有體會(huì)。（合肥-飛哥-Java）

列表頁(yè)加載

10、Android開發(fā)中講一個(gè)坑，列表頁(yè)加載。開始用 Image-Loader時(shí)， 大量的圖片 card，真心是慢。首先，WeakRefence弱引用，效果不好， 時(shí)不時(shí)的OOM。于是反復(fù)對(duì)比了幾個(gè)框架，重新確定了Glide庫(kù)。效果好多了，但還是有OOM的事情出現(xiàn)，debug整個(gè)加載流程，發(fā)現(xiàn)原圖本來(lái)就大，傳輸和Decoder花費(fèi)的時(shí)間占比最大。so解決數(shù)據(jù)源的問(wèn)題， 圖片存儲(chǔ)采用云存儲(chǔ)，當(dāng)時(shí)在七牛和阿里云中間選擇了七牛。并把圖像處理的功能交給云服務(wù)。最終，該頁(yè)面的OOM降低到了 0.01% 以下。同時(shí)應(yīng)用中的OOM也降低到了 0.3% 以下。這算是 OOM的一種填坑方法吧。

還有一個(gè)，在兩年前的一個(gè)Android項(xiàng)目中，采用了UDP來(lái)上傳日志，發(fā)現(xiàn)有的時(shí)候可以上傳成功，有的時(shí)候不行，百思不解，邏輯刷了三遍沒問(wèn)題。在反復(fù)制造測(cè)試數(shù)據(jù)的過(guò)程中發(fā)現(xiàn)，上傳周期內(nèi)如果數(shù)據(jù)量大于一定數(shù)值就會(huì)出現(xiàn)該現(xiàn)象，對(duì)UDP的數(shù)據(jù)包限制問(wèn)題，加一個(gè)循環(huán)判斷，問(wèn)題解決。（北京-曹洪偉-半吊子全棧工匠）

歡迎加入51CTO開發(fā)者QQ交流群 370892523學(xué)習(xí)。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】