蚁阅 – 让 RSS 更好用

时光如梭,打磨了整整一年,蚁阅终于迎来正式版!

主要特点:

  • 非社交,无广告,无推荐,专注阅读
  • 为移动端优化,适合随时随地阅读
  • 按订阅更新频率区分消息,好文章慢慢看,读资讯一目十行
  • 输入博客地址,智能查找订阅,支持批量导入导出
  • 智能图片代理,解决图片无法加载问题
  • 开源,可以自己部署,也可以直接用在线版

开箱即用地址: https://rss.anyant.com (建议用手机浏览器访问)

代码仓库以及部署文档:

接下来,我想聊聊我与 RSS 的故事。

初识RSS

大约 4 ~ 5 年前,我还在编程入门阶段,依稀记得看过一些博客文章介绍 RSS 的种种好处, 但我对它还没有什么感觉。

那时候有部著名的电影 互联网之子 我非常喜欢, 其中就提到了 RSS,主人公「从参与基础互联网协议 RSS 到联合创办 Reddit,斯沃茨的足迹遍及整个互联网」。

在我的第一印象里,RSS 充满了传奇色彩,但我不清楚它真正有什么用处,也不明白为什么那么多人吹捧它支持它。 当我点开 RSS 链接,浏览器显示一堆乱七八糟的 XML 时,我就超级迷惑,然后默默关闭浏览器标签。 现在你可以给博客配置 漂亮的RSS

RSS体验

两年前当我编程学习到一定深度,开始感觉到自己获取信息的方式太低效。 我的信息源主要是「微信公众号,知乎,开发者头条,V2EX」,这些信息里夹杂着广告,营销推广软文, 以及无意义的灌水,里面缺乏更有深度和思考的文章。

我再次想起 RSS,我隐约感觉到它能改变我获取信息的方式,找到更优质的信息源。 经过一番搜索,我选择了 Stringer , 它是一个可以自己部署的 Web 服务,界面非常简洁,它的标语「Anti-social RSS Reader」让我觉得很别具一格。

我买了台小虚拟机部署好 Stringer,添加了一些论坛和我看过觉得不错的博客,每天都能收到有意思的文章和资讯。 就这样使用了半年,我发现 Stringer 对移动端支持很差,便自己修改了样式适配移动端, 还提了个 Pull Request

之后我发现 Stringer 还有一些缺陷很难解决,例如它的文章按时间轴排序,不同的信息源混合在一起, 这就导致资讯类消息经常淹没偶尔更新的博客。还有个问题是它的全标已读无法处理太大数据量, 如果我空了一周没看订阅,程序基本就卡死了,只能登录服务器写 SQL 清理数据。

我也尝试了 InoreaderFeedly , 它们最大的问题是功能太多了,而且具有社交和推荐这两个我不喜欢的属性。 我希望阅读足够简单,阅读器提供好的阅读体验和阅读效率,最有价值的是文字内容本身而不是花哨的功能。

我开始萌生自己写一个 RSS 阅读器的想法。

蚁阅诞生

「非社交,无广告,无推荐,专注阅读」是我对蚁阅设定的第一条准则,这条准则是蚁阅的灵魂, 它指导了整个设计和开发,也决定了蚁阅的发展方向。

2017 年 10 月 20 日,我写下蚁阅第一行代码,蚁阅就此诞生。

第一版本的代码尝试了很多异步 IO 的技术,因为 RSS 阅读器本身就是个爬虫,异步 IO 天然适合处理大量的网络请求。 当时 Python 异步 IO 的技术很不成熟,所以自己造了很多轮子, 可以参见我当时写的 Asyncio-vs-Curio: Worse-Is-Better 。 后来发现这是个天坑,我花费了太多时间在造轮子,而业务代码都在踩各种轮子带来的坑,项目进展缓慢。

前端和设计也遇到了问题。因为没有设计经验,我就直接写了前端代码,然后发现自己一直在不停地改代码调整布局和样式, 调了很久也没有做出一个统一协调的整体,前端界面就像是胡乱拼凑在一起的。

经过三个月的开发,蚁阅依旧无法投入使用,我也感觉到现有的状态和能力无法完成这个产品。 再加上这段时间又有毕业,实习,工作这些事情,蚁阅的开发就搁置了。

蚁阅重来

之后的一段时间,我开始提升自己的设计能力。 我平时看过不少设计方面的书籍,主要是偏原理和方法论的,最欠缺的是设计实践能力。

我参考独立开发者 Larry 的帖子 「 独立开发者如何学习设计? 」 买了《30天学会绘画》以及一块 Wacom 数位板,每天练习设计基本功。 最开始我是在 Linux 系统上用 Inkscape 练习, 后来买了 Mac 电脑,就改用 Sketch 了。

两个月后,我开始做蚁阅的设计,借助 Sketch 这个强大易用的工具,再加上蚁阅界面本身比较简单, 我很快完成了设计,整个过程没有遇到太大的障碍。我还保留着蚁阅设计图。

设计问题解决之后,接着解决编程实现问题。 后端方面,我扔掉自己造的异步 IO 框架,换成最具生产力的 DjangoAioHttp , 扔掉自己造的异步任务调度框架,换成最流行的 CeleryRedis 。 前端方面,把 React 换成我最熟悉也最好上手的 Vue.js 全家桶,采用 Mobile First 策略, 使用比较流行的 Muse-UI 框架。

2019 年 5 月,蚁阅基本开发完成,我开始将它作为日常 RSS 工具使用,并继续完善。 一个月后,我在 V2EX 发布帖子 蚁阅 – 让 RSS 更好用,轻松订阅你喜欢的博客和资讯 , 这是蚁阅第一次发布,受到很多网友关注,我也收到了很多反馈和建议。 我决定把蚁阅做的更完善,做成一个真正好用的产品!

蚁阅正式版

蚁阅第一次发布之后,还有很多问题需要解决:

  • 很多 Bug 待修复,UI细节需要完善
  • 缺少一些功能,比如批量清理订阅
  • 性能和稳定性不足,其中 Celery 太占内存,进程经常崩溃
  • 部署太繁琐,文档不完善

接下来的半年,我就在解决这些问题。

其中 Celery 的问题很难解决,要么加内存升配置,要么自己改源码或造轮子。 我没忍住重新造了轮子,但这次我把轮子和蚁阅代码放在一起,不单独维护。 造轮子的过程很烧脑,我特地学习了 Erlang 语言,看了 Erlang程序设计 , 参考了 Akka 的设计,看了很多 Actor 编程模型的资料去解决背压(Back Pressure)问题, 还自己实现了状态机和存储。经过很多个烧脑的夜晚,这个异步任务框架终于能正确且高效地工作了。

部署问题有个小伙伴写了 简单几步打造个人集群和自动化流水线 , 这个方案对于批量自动化部署服务时是很有用的,但整体还是比较复杂,要做很多配置。 我最终选择了把蚁阅的所有服务打包在一个容器里,这样手动部署就会非常简单。这个做法虽然不符合 Docker 的最佳实践,但对于个人使用的应用来说性能和稳定性都能满足要求,简单方便相对而言更加重要。

这几天我把蚁阅的代码库及文档都整理了一下,项目也得到码云官方的推荐。

现在,蚁阅正式版发布,希望大家喜欢!

关于商业化

蚁阅第一次发布时,有网友来信问我商业化方面有什么打算,我那时并没有什么想法, 唯一能确定的就是我想做一个我自己喜欢的产品。

现在我想清楚了:

  • 当用户很多,服务器成本很高, 捐款 又很少时,我会考虑要求用户付费。
  • 永远保持开源,开源版和在线版功能完全一样,随时可以自己部署使用。

蚁阅将不忘初心,继续前行!