兩年的Android成長之路（一）
前言
又是一年，畢業就成了名副其實的程式設計師。兩年多Android開發，從最初的小白，到現在可以自己設計一些東西；從最初面對需求的茫然，到現在遊刃有餘，一路的成長和成果，到此做個小結。大牛可以略過，希望能對剛剛踏上Android這條路的同學有一點點幫助。
Android架構的演進（一）
一、架構v0.1（假裝有架構）
-
最初剛工作時，獨立開發，並沒有想太多(也不懂)，專案緊，任務重，很多東西都是自己看著人家的照葫蘆畫瓢，可以說並沒有什麼架構，但是對於當時一開始的業務還是能應對的了的。
網路連線利用HttpClient自己封裝了一套，應對當時的專案體量還是可以，並且也做到了一些常規的功能，例如執行緒的變換、資料的解析這些常用的功能；圖片載入在ImageLoader的基礎自己也做了一層封裝，應對固定的佔位圖等。很多這種小的功能元件都是哪裡用複製到哪裡，雖然麻煩，但是能解決問題。 - 很快，隨著開發進行和業務增長，問題開始出現了。
1）程式碼太亂
沒有合理的封裝和抽取，沒有對業務功能進行劃分，沒有清晰的程式碼約束等等直接導致程式碼自己都懶得看，一團亂麻；
2）封裝的元件難以滿足業務需求
最致命的是對於業務開發需要不斷的從複製出來的程式碼上進行更改，以及一些自己寫的元件很難滿足業務需求，導致開發進度慢，功能實現吃力，到此已經表現出力不從心；
3）程式碼耦合嚴重
Activity直接承擔了所有業務邏輯實現，元件和業務耦合在一起，沒有做區分，可重用的元件很多都是複製過去的，修改起來相當費勁；
4）部分技術實現很業餘
對於一些業務的技術實現採取了很多不合理的解決辦法，直接導致程式碼可讀性太差，很難理解實現原理；
5）開發新應用需要從頭來過
當公司需要開發新的應用時，另一問題就出現了，一切都需要從頭搭建，因為很多元件都和業務耦合在一起，沒法直接拿過來用；
6）整個專案是拼拼湊湊，哪有漏洞堵哪裡，沒有任何章法。
二、架構v0.2(好像有架構)
- 問題和痛點都找到了，開始重構
1）啟蒙專案
IOS同事肖偉肖大神推薦了給我Coding
Android端開源專案，看完這個開源專案，雖然懵懵懂，但是也有茅塞頓開的感覺，原來還有那麼多的開源框架可以使用，而且在程式碼的書寫上也有很多新的認識，至此，初步懂得如何站在巨人的肩膀上去實現自己的目標。所以，多看他人的專案對自己成長很有幫助，特別是初學者。
2）技術選型
因為之前都是自己封裝的元件，所以很多東西做的並不完善，這次選擇開源成熟的框架。
整個技術選型基本上分為：網路連線庫、圖片處理庫、資料庫操作框架、UI控制元件、工具庫等。
網路框架選用Volley，因為Volley對於初學者，使用簡單，功能齊全，入門較容易，並在這之上做了一次中間層的封裝，方便對網路框架的替換和統一的功能的實現。
圖片載入還是選用的ImageLoader，並沒有太大變化，但是對記憶體進行了優化。資料庫那時候還沒有過多使用，所以這塊忽略。
3）程式碼劃分
程式碼主要分為了業務程式碼還有可以複用的程式碼。
業務程式碼主要按業務模組進行劃分，這樣的好處就是當前業務內的程式碼都在一起，管理方便，並且查詢維護更加容易。
4）業務實現
在實現業務時，考慮的要更加全面，比如有沒有更好的實現方式，業務程式碼能否複用，怎樣實現能更好應對一些需求的變化等。
2.重構完成後新的問題
1）仍有大量可以封裝抽取的程式碼
比如：網路請求的進度窗，錯誤回撥的處理等
2）業務實現仍有可以優化的空間
比如：登入模組的登入和退出在整個應用任何一處都有可能呼叫，這樣如果只是實現了登入頁面的登入，那麼在其他地方需要登入時還需要再次實現，退出登入更是如此，所以如何將業務拆分成可複用的程式碼塊又是一個可優化的。
3）業務程式碼和元件程式碼仍有大量耦合
雖然開發前的規劃已經想到要避免，但是實際開發中難免還是會出現，開發過程中會發現，有很多業務上的程式碼如果放到了元件中去處理，那麼整個複雜度會降低很多，並且實現起來也容易很多，然後這將是最大的大坑，因為當元件需要多次複用時，這些業務程式碼將成為絆腳石，所以謹記，不要因為時間緊任務重而降低程式碼質量；還有其他的耦合也可能是設計上的缺陷，導致一部分業務程式碼一定要放在元件中。
4）架構不夠穩定，問題頻發
開發過程中的技術調研和技術方案的確定十分重要。例如：應用中的紅點儲存方案的不合理，將會給整個應用的開發帶來非常多的不穩定，因為類似紅點這種東西，可能出現在整個應用的任何地方，並且很可能是巢狀計數的，很多業務功能都有這種特性，所以如果沒有制定好技術方案，整個後期維護和擴充套件會有很多壁壘。
5）問題難以定位和修復
程式碼的嚴謹並且邏輯足夠的清晰，整個實現有路可尋，那麼問題定位就要容易的多，如果實現混亂，可能導致問題出現的地方過多，將給問題定位帶來極高的難度，並且修復時很可能不能全面修復和引發新的問題。程式碼的耦合也會是問題定位和修復的障礙，並且沒有任何的設計模式，也會導致個別類的的體量很大，可讀性很差。
3.隨著學會的東西越來越多，再次重新設計架構勢不可擋。
最新的架構將寫在下一篇部落格，並且是更偏向技術的部落格，本篇部落格作為成長曆程的部落格，很多東西記不清，寫不全，歡迎提出問題。