仿煎蛋jiandan应用客户端源码

最新推荐文章于 2024-03-31 18:34:40 发布

chenhaimeimeng

最新推荐文章于 2024-03-31 18:34:40 发布

阅读量1k

点赞数

文章标签：应用源码

本文链接：https://blog.csdn.net/chenhaimeimeng/article/details/50259781

版权

项目源码下载：

http://code.662p.com/view/10654.html

效果图

<ignore_js_op>
<ignore_js_op>

项目整体介绍

从上面的效果图也可以看出来，我们使用的是Material Design风格，但是并不纯正，为了兼容4.x版本，我们使用Theme.AppCampat兼容主题、RecycleView和CardView来完成，从整体视觉效果来看比较统一和美观。同时为了整体的效果，使用开源项目material-Dialogs来实现Material Design效果的对话框，这个在点击回复，完善个人信息的功能点上有所体现。

除了界面，网络请求框架我选择的是Volley，原因是Volley对小数据量、请求频繁的网络操作进行了优化，对于这个项目比较合适，而且作为Google的推荐项目，现在已经完善的比较成熟了，经过了很多项目的实战验证，所以比较放心。而且扩展性非常强，可以定制我们自己的请求解析需求，这一点相信看过我项目的朋友，应该有所感受，在com.socks.jiandan.net包下的请求类都经过了我的定制，使用方便。而且很重要的一点是，Volley在2.3之后是基于HttpURLConnection的封装实现，默认支持gzip压缩，在4.0之后的版本，还支持结果缓存，所以在性能和数据传输量上，相比HttpClient有很大的提高。

在本项目中一个很重要的功能就是加载图片，所以在图片加载框架上需要特别注意。最初我选择的图片加载框架是Fresco，因为之前翻译过关于Fresco的特性的文章，感觉非常的强大，所以想试一试。但是在后面使用的时候，还是遇到了很多的问题，让我不得不暂时放弃Fresco，改用UIL。原因如下：

推出时间太短，虽然功能强大，但是还没经过考验，还不很成熟。Fresco的更新频率很快，我开始用的时候还是0.1.0版本，后来在加载图片的时候遇到问题，在这个版本上，Fresco没有对有304缓存的图片进行处理，所以在加载这类图片的时候会出现失败，我给Fresco项目提交issue之后，他们回复我，Fresco已经升级，在0.2.0完成了问题修复。所以我觉得，Fresco还需要一段时间的考验和完善，才能被用到生产环境中，现在我不很推荐大家在项目中使用
不支持wrap_content。放弃Fresco的一个很重要的原因就是因为它不支持wrap_content，Fresco只支持match和固定长宽，在这个项目中需要展示大量宽度match，高度不定的图片，因为Fresco显示图片的控件也是自己定制的，所以自定义控件这条路也比较难走，在没有找到更好的解决方案的情况下，我决定暂时放弃Fresco，改用UIL。在本项目中，只有在评论列表页的头像是使用的Fresco，其他地方都是使用UIL和自定义控件实现，具体实现方案我会在下面讲到。

在IOC框架的选择上，使用butter knife，之前一直使用AFinal，但是AFinal属于运行期绑定，会影响性能，butter knife属于编译期绑定，不会影响。使用butter knife使用非常方便，就拿来一用。在本项目中，我感觉其实并不是很需要IOC，仅作一个尝试而已，不必深究。

在完成网络状态切换的功能上，需要在MainActivity注册一个网络状态监听器，当网络状态发生改变的时候，通知当前显示的Fragment切换图片的加载模式，或者是提示网络状态变化情况。在这种需求下，使用接口是可以完成的，每个Fragment都实现MainActivity的一个接口，当网络状态发生变化的时候，MainActivity调用Fragment的接口方法即可。但是这样不仅很麻烦，而且会增加耦合性，为此，我使用EventBus完成了这个功能，实现很简单，大家看源码就可以，耦合度为0。

这个项目中的所有数据接口基本都是Json格式，所以选择一个好的解析框架是很重要的。我之前写过三篇文章介绍了Json的不同解析方法，虽然Jackson的解析速度快，但是gson确实用起来很熟悉，而且我们要解析的数据量并不大，性能上的差异微乎其微，所以我选择了我比较熟悉的gson。在解析的一些地方还用到了一些JSON，这个大家可以自由选择。