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

笔者基础Androidclient已经两年有余，在两年时间里，一直在慢慢地改动并积累自己的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流畅的一个方面。

认为还有非常多优化项，已有有机会，慢慢补充吧。临时先写到这里。