作者：sam
原文：http://blog.isming.me/2016/08/08/red-android-evolution/
小红书Android客户端第一个版本于2014年8月8日发布，转眼到现在，小红书Android版本发版两周年多。趁机回顾一下小红书的Android版本，两年中我们踩过很多坑，收获很多经验，分享出来与大家共勉。
小红书从最初1.0到现在目前4.7版本，历经两年，安装包从原先的5M发展到现在的17M，产品模块也从原先的只有社区模块发展到了具有社区和电商两个大模块。App包含社区、电商、支付、推送、直播、统计等各种功能和模块，那么开始吧。
功能演进
两年的时间，30多个版本的迭代，许多功能都有了翻天覆地的变化。我们的新人欢迎页也是从最初的比较炫的效果发展到目前比较稳定的简洁版本。当初钟大侠花了无数个日日夜夜，苦心做出来了多个欢迎页动画，虽然现在已经不再使用，但是我们也学习到了一些新技术。后来，钟大侠还是将其贡献到了github开源社区中。
下载地址:
https://github.com/w446108264/XhsParallaxWelcome
下载地址:
https://github.com/w446108264/XhsWelcomeAnim
社区是小红书的核心价值之一，笔记是小红书社区的核心体现，毋庸置疑，笔记发布是小红书App的核心功能之一，我们一直在产品和技术上，优化我们的笔记发布流程和功能，包括我们将只支持分享单张图片，扩展到现在支持多张图片同时发布。同时支持更丰富的图片编辑效果，更加便捷的发布笔记。
小红书的笔记展现形式和大多数其他的图片社交App类似，我们也支持图上标签功能。最初小红书图上标签是同其他App类似的黑色的标签。不过在3.0之后，小红书创造了独特的树状标签，给用户带来焕然一新的体验，同时也被其他App竞相模仿。新的标签给技术也带了很多的挑战，我们重新定义了标签的结构，以及标签的生成和展示。可以查看我以前的博客，来看看我是怎样做标签的动画的。
（
http://blog.isming.me/2016/06/07/path-property-animation/
）
UI的改版，功能上的改动还有很多，这里不再一一提起。小红书Android整体上的风格和iOS保持一致，不过我们在15年初开始，对于App内的细节进行Material Design 适配，包括一些按钮风格、点击效果、字体规范、对话框等等，希望为Android用户带来更好的使用体验。
技术选型进化
在技术选型上，这里主要讲一下网络层的框架选型升级和图片加载库的升级。
网络框架的演进
App的最初框架是由钟大侠一人花了10来天完成，包括基本的网络请求框架、App大体的架构以及一些主要的功能。最初时候选择框架的原则就是选择自己最熟悉的，因此我们采用了
async-http
这套框架作为我们底层的网络请求框架，框架完成了网络的异步请求与回调，能够满足当时的需求。
然而仅仅不到半年之后，我们就决定了使用Volley来替换。替换以后，底层的网络请求代码更加清晰，在Volley返回的结果即直接返回了我们需要的Object，同时将统一的错误处理、公共的参数处理和一些公共的返回使用的参数，全部放在我们自定义的Request当中，这样外部请求所需要传入的参数更少，对于错误的处理更加简单，只需要考虑业务需要的Response，其他全局的返回内容则无需进行干扰。通过Volley的引入，帮助我们在业务的开发上变得更加便捷。引入Volley之初，Volley的底层使用的是HttpClient+HttpURLConnection，后期通过网上的资料发现OkHttp使用NIO更加高效，并且被Android 引入作为系统底层的网络请求，我们也将Volley的底层也替换为OkHttp。
与此同时，小红书的api请求也在不断进行RESTful，我们遇到一个问题就是经常找一个api的定义比较麻烦。大约在15年11月份，我们引入了Retrofit，通过二次改造，使其支持了公共参数的构建，以及对于GsonConvert的改进支持直接返回我们需要的Object，而且对于RESTful风格的良好支持给我们提供了极大的便利。配合RxJava，我们可以方便的进行多个api的同时请求、api返回的多个线程的切换。
图片加载框架的演进
小红书的笔记是以图片加文字为主体的内容，因此会有大量的图片显示需求。和网络框架选型类似，早期选择了比较熟悉的UIL来做图片加载，可以同时支持本地图片和网络图片的加载，在当时可以满足我们的基本需求。
15年初，我们开始使用更加高清的图片，随之加载速度变慢，占用更多的内存，而且这个时候UIL的作者基本很少维护。我们开始调研使用新的图片加载框架。此时Fresco刚刚出来，还不太稳定，当时没敢用。给我们的可选项有Picasso和Glide两个可选项，Picasso比较轻量，但是相比于UIL在性能上没有太好的提高。Glide代码量较大，不过它会在本地保存多份缓存（原始图片和实际显示尺寸的图片），这样加载本地缓存的时候，可以直接显示大小刚好的尺寸，减少解码的时间，因此会比UIL要快很多。
15年下半年，我们需要支持gif的动画显示，而Glide对动画的兼容性又不是特别好，这个时候我们直接切到了Fresco。同时Fresco对webp的良好支持，使得我们在后期切换到webp格式的时候，减少了很多工作量。Fresco在4.4及以下版本使用匿名内存来作为内存缓存，为我们减少OOM做了巨大的贡献。
我们使用的这几个图片加载框架，每个框架的使用都有非常大的区别，这就导致迁移的时候工作量巨大。为了降低迁移成本，我们封装了自己的
