45

蚁阅 - 让 RSS 更好用

 4 years ago
source link: http://blog.guyskk.com/notes/蚁阅-让RSS更好用
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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

主要特点:

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

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

zyUfM3q.png!webV7bY73a.png!webIbYZ3mI.png!web

代码仓库以及部署文档:

接下来,我想聊聊我与 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 的最佳实践,但对于个人使用的应用来说性能和稳定性都能满足要求,简单方便相对而言更加重要。

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

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

关于商业化

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

现在我想清楚了:

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

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK