小红书

小红书从最初1.0到现在目前4.7版本，历经两年，

功能演进

两年的

下载地址:

社区是小红书的核心价值之一，笔记是小红书社区的核心体现，毋庸置疑，笔记发布是小红书App的核心功能之一，我们一直在产品和技术上，优化我们的笔记发布流程和功能，包括我们将只支持分享单张

小红书的笔记展现形式和大多数其他的图片社交App类似，我们也支持图上标签功能。最初小红书图上标签是同其他App类似的黑色的标签。不过在3.0之后，小红书创造了独特的树状标签，给用户带来焕然一新的体验，同时也被其他App竞相模仿。新的标签给技术也带了很多的挑战，我们重新定义了标签的结构，以及标签的生成和展示。可以查看我以前的

技术选型进化

在技术选型上，这里主要讲一下网络层的框架选型升级和图片加载库的升级。

网络框架的演进

App的最初框架是由钟大侠一人花了10来天完成，包括基本的网络请求框架、App大体的架构以及一些主要的功能。最初时候选择框架的原则就是选择自己最熟悉的，因此我们采用了 async-http 这套框架作为我们底层的网络请求框架，框架完成了网络的异步请求与回调，能够满足当时的

然而仅仅不到半年之后，我们就决定了使用Volley来替换。替换以后，底层的网络请求

与此同时，小红书的api请求也在不断进行

图片加载框架的演进

小红书的笔记是以图片加文字为主体的内容，因此会有大量的图片显示需求。和网络框架选型类似，早期选择了比较熟悉的UIL来做图片加载，可以同时支持本地图片和网络图片的加载，在当时可以满足我们的基本需求。

15年初，我们开始使用更加高清的图片，随之加载速度变慢，占用更多的内存，而且这个时候UIL的作者基本很少维护。我们开始调研使用新的图片加载框架。此时Fresco刚刚出来，还不太稳定，当时没敢用。给我们的可选项有Picasso和Glide两个可选项，Picasso比较轻量，但是相比于UIL在性能上没有太好的提高。Glide代码量较大，不过它会在本地保存多份缓存(原始图片和实际显示尺寸的图片)，这样加载本地缓存的时候，可以直接显示大小刚好的尺寸，减少解码的时间，因此会比UIL要快很多。

15年下半年，我们需要支持gif的动画显示，而Glide对动画的兼容性又不是特别好，这个时候我们直接切到了Fresco。同时Fresco对

我们使用的这几个图片加载框架，每个框架的使用都有非常大的区别，这就导致迁移的时候工作量巨大。为了降低迁移成本，我们封装了自己的ImageLoader，在ImageLoader中来实现具体的图片加载，这样保证在迁移的时候，最大程度的降低代码的改动(不过在迁移到Fresco的时候还是改动巨大，因为我们不能直接使用ImageView了o(︶︿︶)o。

推送的升级

推送，我觉得也有必要说一说。最初我们快速选用了

架构升级

由于一直以来在业务开发占用的时间比较多，目前App的整体架构没有做过太大的改变。

在Adapter的使用方面，我们将ListView或RecyclerView的Item放到单独的ItemHander，这样可以在不同的页面可以通过将不同的Item组装到一起，从而满足不同地方的需求。这样可以在ListView或RecyclerView来复用相同的代码，提高代码的可维护性。

前面网络层说到我们的错误处理，这个也是做过比较大的升级。最初时候，网络错误、http请求错误、后台和客户端的错误，都分别在不同的层级进行处理。目前我们在发生错误的时候将错误全部以Exception的方式抛出，最后在上层进行错误的处理。

App中的状态

App中占比很大的部分是从网络请求数据，获得数据后进行展示，还是以MVC为主。在一些模块的部分地方，做一些da

其他周边进化

我们的开发最初是使用Ecl

APK最初大约只有5M，历史最高峰达到了23M，在App减肥上我们也做了一些努力，主要是使用tinypng压缩图片，so只保留arm的支持。项目的复杂也使得每次

现在持续集成还是蛮火的，自然我们也在用。最初的时候，我们每天需要手动打包，打完包之后打开fir的

未完待续

本文介绍了我们两年来的一些大的变化，通过一篇

现在我们的Android还有坑位，如果你有兴趣，就赶紧发送简历来占坑吧，我的邮箱是: msang#xiaohongshu.com (请手动替换#为@)

本文同步发布于小红书技术REDHacker ,可如下扫描red-hacker 进行关注。