蚁阅 - 让 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 清理数据。
我也尝试了 Inoreader 和 Feedly， 它们最大的问题是功能太多了，而且具有社交和推荐这两个我不喜欢的属性。 我希望阅读足够简单，阅读器提供好的阅读体验和阅读效率，最有价值的是文字内容本身而不是花哨的功能。
我开始萌生自己写一个 RSS 阅读器的想法。
蚁阅诞生
「非社交，无广告，无推荐，专注阅读」是我对蚁阅设定的第一条准则，这条准则是蚁阅的灵魂， 它指导了整个设计和开发，也决定了蚁阅的发展方向。
2017 年 10 月 20 日，我写下蚁阅第一行代码，蚁阅就此诞生。
第一版本的代码尝试了很多异步 IO 的技术，因为 RSS 阅读器本身就是个爬虫，异步 IO 天然适合处理大量的网络请求。 当时 Python 异步 IO 的技术很不成熟，所以自己造了很多轮子， 可以参见我当时写的 Asyncio-vs-Curio: Worse-Is-Better。 后来发现这是个天坑，我花费了太多时间在造轮子，而业务代码都在踩各种轮子带来的坑，项目进展缓慢。
前端和设计也遇到了问题。因为没有设计经验，我就直接写了前端代码，然后发现自己一直在不停地改代码调整布局和样式， 调了很久也没有做出一个统一协调的整体，前端界面就像是胡乱拼凑在一起的。
经过三个月的开发，蚁阅依旧无法投入使用，我也感觉到现有的状态和能力无法完成这个产品。 再加上这段时间又有毕业，实习，工作这些事情，蚁阅的开发就搁置了。
蚁阅重来
之后的一段时间，我开始提升自己的设计能力。 我平时看过不少设计方面的书籍，主要是偏原理和方法论的，最欠缺的是设计实践能力。
我参考独立开发者 Larry 的帖子 「独立开发者如何学习设计？」 买了《30天学会绘画》以及一块 Wacom 数位板，每天练习设计基本功。 最开始我是在 Linux 系统上用 Inkscape 练习， 后来买了 Mac 电脑，就改用 Sketch 了。
两个月后，我开始做蚁阅的设计，借助 Sketch 这个强大易用的工具，再加上蚁阅界面本身比较简单， 我很快完成了设计，整个过程没有遇到太大的障碍。我还保留着 蚁阅设计图。
设计问题解决之后，接着解决编程实现问题。 后端方面，我扔掉自己造的异步 IO 框架，换成最具生产力的 Django 和 AioHttp， 扔掉自己造的异步任务调度框架，换成最流行的 Celery 和 Redis。 前端方面，把 React 换成我最熟悉也最好上手的 Vue.js 全家桶，采用 Mobile First 策略， 使用比较流行的 Muse-UI 框架。
2019 年 5 月，蚁阅基本开发完成，我开始将它作为日常 RSS 工具使用，并继续完善。 一个月后，我在 V2EX 发布帖子 蚁阅 - 让 RSS 更好用，轻松订阅你喜欢的博客和资讯， 这是蚁阅第一次发布，受到很多网友关注，我也收到了很多反馈和建议。 我决定把蚁阅做的更完善，做成一个真正好用的产品！
蚁阅正式版
蚁阅第一次发布之后，还有很多问题需要解决：
- 很多 Bug 待修复，UI细节需要完善
- 缺少一些功能，比如批量清理订阅
- 性能和稳定性不足，其中 Celery 太占内存，进程经常崩溃
- 部署太繁琐，文档不完善
接下来的半年，我就在解决这些问题。
其中 Celery 的问题很难解决，要么加内存升配置，要么自己改源码或造轮子。 我没忍住重新造了轮子，但这次我把轮子和蚁阅代码放在一起，不单独维护。 造轮子的过程很烧脑，我特地学习了 Erlang 语言，看了 Erlang程序设计， 参考了 Akka 的设计，看了很多 Actor 编程模型的资料去解决背压(Back Pressure)问题， 还自己实现了状态机和存储。经过很多个烧脑的夜晚，这个异步任务框架终于能正确且高效地工作了。
部署问题有个小伙伴写了 简单几步打造个人集群和自动化流水线， 这个方案对于批量自动化部署服务时是很有用的，但整体还是比较复杂，要做很多配置。 我最终选择了把蚁阅的所有服务打包在一个容器里，这样手动部署就会非常简单。这个做法虽然不符合 Docker 的最佳实践，但对于个人使用的应用来说性能和稳定性都能满足要求，简单方便相对而言更加重要。
这几天我把蚁阅的代码库及文档都整理了一下，项目也得到码云官方的推荐。
现在，蚁阅正式版发布，希望大家喜欢！
关于商业化
蚁阅第一次发布时，有网友来信问我商业化方面有什么打算，我那时并没有什么想法， 唯一能确定的就是我想做一个我自己喜欢的产品。
现在我想清楚了：
- 当用户很多，服务器成本很高，捐款又很少时，我会考虑要求用户付费。
- 永远保持开源，开源版和在线版功能完全一样，随时可以自己部署使用。
蚁阅将不忘初心，继续前行！