Android开发总结

出来工作半年多了，没啥好交代的，就说说自己半年来的Android开发经历。

1.IDE

     这半年来，从Eclipse到Android Studio，经历了两个IDE，在这里做一下简单的评价。

如果真要说，Android Studio是基本上大胜Eclipse的，至少Android Studio不会像Eclipse那样卡，公司配的电脑是渣了点，64位，win7，只有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构建，而谷歌现在推崇的方式就是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还是很好用的，尤其是对象一建好，表就建好了，特别方便，还有就是数据库的升级也非常方便。

有个不好的地方就是，可以直接操作表对象，这样很可能就会将不想存的数据存进表里，于是就封装了一下，不能直接操作表对象，而是操作实体对象，数据库的操作都是通过实体对象的接口方法，而接口方法调用的就是表对象的方法。

4.网络库和异步库

这部分的工作并不是我做的，但还是可以说一下。

一开始是自己封装的网络库，但封装得太复杂了，很难维护，而且它不是一个简单的网络库，是一个网络异步和本地异步一起实现的库，基于大量的回调，使用起来也是不错的。

后来换成Volley，不过就发现Volley的实现不太满足我们的要求，就用OkHttp将Volley的底层改掉，然后上层的接口形式采用链式调用的方式，代码的形式更加简单。

原生的异步AsnyTask简直就是个坑，它就是一个任务队列，多个任务执行并不是并发的，有可能就卡在其中一个出不来了。。。试过debug的时候跳进去就跳不出来了。。。后来就自己写了一个，也是采用链式调用的接口形式。

5.事件

采用EventBus作为事件管理，简直就是爽。简简单单就可以跨线程，跨组件通信，很多以前要很复杂才能实现的功能一下子就可以实现了。

6.UI

UI上，倒是很难讲的一个方面，采用ButterKnife减少了工作量，并且基本上采用组件思想，能够提炼出组件的就变成组件，方便替换，而且形式上，偏近于MVVM的形式，可以针对业务逻辑编写单元测试，原因就是逻辑业务都在ViewModel上。

大体笼统的就是这几个方面，后面有时间会针对具体的方面进行阐述。