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上。

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

 

posted @ 2014-12-31 00:17  文酱  阅读(12721)  评论(11编辑  收藏  举报