大家社区 APP( http://www.dajiashequ.com )和四次元新浪微博的比较，以及阅读四次元新浪微博客户端的感想

笔者基础Android客户端已经两年有余，在两年时间里，一直在慢慢地修改并积累自己的Android应用框架。一直在进步，但是进步的速度越来越慢，加上公司的项目时间比较短，一直没有机会去接触一些较新的项目，最近终于闲下来，总结一下自己做的东西，也读了别人的东西，现在分享出来，给大家一个参考。

首先介绍一下大家社区主APP,他是企业级的社交类应用。具体详情可以点击链接，查看详情： 大家社区官网

我一直认为，框架对于移动应用很重要，如果能够积累一个好的框架，可以快速开发一个APP，甚至于可以快速移植到其他项目中，废话少说，下面是主App和四次元新浪微博的比较。

我觉得可以带着问题去看别的项目，这样的提高比较快，因此先列出大家社区的问题：

1， 数据库主线程加载，阻塞UI，影响用户体验。

2， 网络请求不能够取消

3， View层的封装太少。（可能与Android通过XML布局相关，但是一定的封装还是必不可少的 ）

4， 图片加载没有请求池

1， 数据库比较

二者的DBHelper均有同意管理,这一块差异并不是特别大，唯一的差异是，大家社区主APP是在主线程操作数据库，而四次元是在子线程操作数据库。在主线程做大量的数据读写，对于移动端，笔者认为至少对Android应用（IOS尚未研究），会大大降低他的用户体验，造成UI的加载不流畅。但是四次元新浪微博也存在一个问题，四次元是在Activity开启AsyncTask去加载数据，没有统一的数据访问出入口。

2，关于UI结构的比较。

这一块差异不是特别大，值得主APP学习的是，有一些公用的东西，比如群组消息，我关注的消息，在四次元中，做了相应的抽象，这一点是主APP的不足。

3， 网络访问层。

在网络访问层，主APP的封装比四次元较好，可能因为封装引起一个问题，线程无法取消。这一块可以通过AsyncTask，或许可以完成。在BaseService中，访问网络，可以将AsyncTask对象返回给Activity,做相应的取消处理。

4， 图片加载

主APP在图片加载这一块比较混乱。首先不同地方的头像加载方法没有复用，这个暂且不受，后面可以根据实际情况修改相关代码。说一个主APP效率方面的问题：

先举个例子吧

在一个ListView中有3条Feed均是同一用户发布的，这时候会开启3个线程同时去加载这张图片，在现有的图片请求框架XUtil, Univsal-Image-Load包括四次元微博中，均做了同一件事情，在请求网络的时候，判断当前URL已经加载，如果已经加载，将该请求放入回调队列，等待之前线程加载完成，统一回调。我觉得这个对于性能的提升有很大帮助的。

在图片加载还有一个很重要的优化项，当前并没有想到好的实现方式：

监听ListView的滑动状态，如果在滑动中，不去加载头像，当滑动停止，再去加载头像，我觉得这个可能是解决Android的ListView滑动不如IOS流畅的一个方面。

觉得还有很多优化项，已有有机会，慢慢补充吧，暂时先写到这里。