Android開發總結

標籤：

     出來工作半年多了，沒啥好交代的，就說說自己半年來的Android開發經曆。

1.IDE

     這半年來，從Eclipse到Android Studio，經曆了兩個IDE，在這裡做一下簡單的評價。

     如果真要說，Android Studio是基本上大勝Eclipse的，至少Android Studio不會像Eclipse那樣卡，公司配的電腦是渣了點，64位，wein7，只有4G記憶體，跑Eclipse跑久了簡直就是噩夢。

     Android Studio的智能提示比Eclipse強多了，快速鍵也很強大。至於工程的組織圖，Android Studio和Eclipse的差距還是很大的，但習慣了也不覺得有啥，哪種都行。

     Android Studio有個不好的地方就是無法在同一個視窗顯示多個工程，所以只能多開一個。。。

     Android Studio採用Gradle構建，一開始的構建簡直是喪心病狂。。。如果沒有VPN，想都不敢想。。。構建上，Eclipse是比Android Studio快，但Android Studio導第三方庫很方便，寫一個Gradle指令碼就行，並且配置上更加靈活。可以這樣說：Eclipse是幫我們搭好了房子，我們只要熟悉它就行，而Android Studio是讓我們用工具去搭建自己喜歡的房子。

    更加重要的是，aar包只能由Android Studio構建，而Google現在推崇的方式就是aar包，所以以後開源的項目很有可能都是打成aar包，並且基本上，大部分的開源項目已經是採用Gradle構建。。。

    Android Studio一個不好的地方就是升級太快，在半年的 時間內，我從0.8.1升級到1.0。。。可惡的是，每次升級，Gradle也升級，並且還斷代。。。雖然麼官方現在是版本穩定了，因為IDEA已經出了新版本了，但我試過1.0出事了，直接撤回0.9.4。。。

    總體而言，未來Android開發一定是用Android Studio或者IDEA,Eclipse已經被官方拋棄了。。。

2.版本控制工具

     我使用SVN比較少，剛工作的時候，剛好就是把SVN換成Git，但對於Git的使用方式也經曆了一番變化。

     一開始使用Git，就像SVN一樣，一個master分支，大家都往上面推，一旦出事了，大家都卡住了。。。後來使用SourceTree做管理，分支切換，提交和解決衝突好多了。現在的開發模式是這樣的：

     master分支是正式分支，在沒確保穩定之前是不會推東西上去的，dev分支是開發分支，而每個人本地也有一個dev分支，大家可以根據自己的需求在本地開多幾個分支，這樣就不會出現master分支無法發布的現象，因為master分支永遠是正確的。

     遺憾的是，由於使用的是工具，雖然對命令列還是不熟悉。。。

3.資料庫

     資料庫一開始採用的是原生，編寫了一大堆Helper，而且光是存表，就已經寫了很多代碼，一個一個set進去。。。後來換成對象資料庫LitePal，好多了，但LitePal本身的效率是原生的三分之一，但基本的情況已經足夠了。。。不過，必須直視的是，LitePal的功能支援還不夠完善，一開始不支援索引，後來的版本才支援，並且很多情況下，採用Sql語句都比使用LitePal的介面方法方便多了，LitePal的尋找資料竟然是根據那個自增長的id。。。。只要稍微改一下，LitePal還是很好用的，尤其是對象一建好，表就建好了，特別方便，還有就是資料庫的升級也非常方便。但LitePal也有一些地方很坑，比如說，表的布爾值欄位必須是通過isXX方法來擷取，而不是setXX方法。。。

     有個不好的地方就是，可以直接動作表對象，這樣很可能就會將不想存的資料存進表裡，於是就封裝了一下，不能直接動作表對象，而是操作實體物件，資料庫的操作都是通過實體物件的介面方法，而介面方法調用的就是表對象的方法。

4.網路程式庫和非同步庫

     這部分的工作並不是我做的，但還是可以說一下。

     一開始是自己封裝的網路程式庫，但封裝得太複雜了，很難維護，而且它不是一個簡單的網路程式庫，是一個網路非同步和本地非同步一起實現的庫，基於大量的回調，使用起來也是不錯的。

     後來換成Volley，不過就發現Volley的實現不太滿足我們的要求，就用OkHttp將Volley的底層改掉，然後上層的介面形式採用鏈式調用的方式，代碼的形式更加簡單。

     原生的非同步AsnyTask簡直就是個坑，它就是一個任務隊列，多個任務執行並不是並發的，有可能就卡在其中一個出不來了。。。試過debug的時候跳進去就跳不出來了。。。後來就自己寫了一個，也是採用鏈式調用的介面形式。

5.事件

     採用EventBus作為事件管理，簡直就是爽。簡簡單單就可以跨線程，跨組件通訊，很多以前要很複雜才能實現的功能一下子就可以實現了。

6.UI

     UI上，倒是很難講的一個方面，採用ButterKnife減少了工作量，並且基本上採用組件思想，能夠提煉出組件的就變成組件，方便替換，而且形式上，偏近與MVVM的形式，可以針對商務邏輯編寫單元測試，原因就是邏輯業務都在ViewModel上。

     大體籠統的就是這幾個方面，後面有時間會針對具體的方面進行闡述。

 

Android開發總結