Resser

KO | EN

gitlite — search

#ui #rag #chatgpt #sql #gemini #go #linux #list #machine-learning #php

(★ 75)

基于微信小程序的RSS阅读器开源、美观、完整｜微信搜索resser体验

Resser Latest Version Download

ZIP Download

# Use via CDN

jsDelivr

jsDelivr serves any public GitHub repository as a CDN with zero setup. Pick a version and a file to get a ready-to-paste link and snippet.

Version

File path

Link

Example

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

基于微信小程序的RSS阅读器 开源、美观、完整

> 直接拿给微信开放社区写的稿子来用了
> 涉及娱乐、资讯板块微信不让上线，所以只能以这种形式跟大家见面了

延伸阅读：[一场比赛，一窥小程序的有限与无限](https://developers.weixin.qq.com/community/develop/article/doc/0006c0d14441001584e8b571456c13)

## What-——-我们开发的是什么？

我们开发的「Resser 阅见」（以下简称「阅见」）是一款基于RSS/ATOM的资讯聚合阅读小程序，其特点是门槛低，姿态新，聚合度高。

说得太拗口？看图就懂了👇  
![「阅见」小程序页面截图](http://pic.rhinoc.top/2019-06-22-15612124193035.jpg)

<figcaption class="image-caption">「阅见」小程序页面截图</figcaption>

接触过RSS的朋友可能会说，“哦，不就是个RSS阅读器嘛，RSS不是已经半死不活了吗”。的确，「阅见」就是一款基于微信小程序平台的RSS的阅读器。不过，我们降低了RSS的使用门槛，让普通用户能像关注微信公众号一样简单的关注自己喜欢的几乎所有内容（从微信公众号、B站到微博等），而高级用户也能延续RSS的使用习惯玩出各种高阶功能。

由于小程序尚在参赛阶段，为了评委能第一时间用上最新版本的小程序，我们还未将小程序正式上线，因此很遗憾大家暂时无法体验到小程序的功能了。

## How-——-我们是怎样从入门到不入土的？

作为在校生，要从繁忙的课程和考试中抽出时间来开发一个完整的小程序，着实不易。能在ddl之前完成这个项目，主要归功于我们团队良好的时间规划和任务安排。作为队长，我将比赛过程分为备赛、开发、精修三大过程。

### 备赛过程

#### 对上届获奖作品分析

既然开发这个小程序的目的是为了参赛，那么当然要奔着获奖为终极目标。因此，团队在4月份体验了去年获奖的30个小程序，从小程序的界面、操作、新颖程度等方面进行分析。在体验这些优秀作品的同时，我们也获益良多。产品中让我们惊喜的点可以作为之后开发的参考和灵感，产品中使用不畅的地方也为我们提前敲响警钟。  
![上届获奖作品分析（部分）](http://pic.rhinoc.top/2019-06-21-06BF6988-ABAF-4B9E-87C2-C21632736E38.png)

<figcaption class="image-caption">上届获奖作品分析（部分）</figcaption>

#### 初步入门

在参赛之前，我们团队中无一人有小程序开发经验，但是凭着初生牛犊不怕虎的精神和魄力，我们照着学做小程序-学堂在线-精品中文慕课(mooc)平台上的课程和官方开发文档实现了对小程序的初步入门。  
当然，学习小程序的开发并不是一个单向的吸收知识的过程，边学边做是最好的入门方式。

### 开发过程

#### 前期规划

考虑到我们开发小程序的过程也是学习小程序的过程，我们并不清楚某个提出的功能是否能得到实现。因此，我们先确定了小程序的大体架构，也就是页面的布局，每个页面要实现怎样的功能，通过什么方式去实现。通过经验的累积，再逐步往这个框架中填沙子，这样便不至于出现“走一步看一步”的窘况。  
![页面框架规划](http://pic.rhinoc.top/2019-06-21-D1C1A575-6A08-4B59-B703-613DCFC14435.png)

<figcaption class="image-caption">页面框架规划</figcaption>

#### 协同工具

由于团队规模很小，只由两人构成，因此使用各种todo工具就显得杀鸡用牛刀了，我们选择的团队协作工具是非常质朴而接地气的——QQ群。  
![使用QQ群文件布置任务并保存资料](http://pic.rhinoc.top/2019-06-21-D6B1CEAC-7D37-4FCC-9F3B-3119B2C0582E.png)

<figcaption class="image-caption">使用QQ群文件布置任务并保存资料</figcaption>

在每周我会给团队布置任务并要求组员提交任务报告，这种半强迫性质的ddl一定程度上能有效防止组员划水并且增加团队成员的参与感。  
而我作为主开发手，将各种功能划分为基础型、进阶型、配置型、魅力型四种类型，使用Markdown编辑器Bear记录功能的完成进度。  
![Bear中对各个功能进度的标记](http://pic.rhinoc.top/2019-06-21-8466E2C8-0018-45BE-9081-4A856FF3E1B7.png)

<figcaption class="image-caption">Bear中对各个功能进度的标记</figcaption>

当然，如果是较大型的团队，则需要更加专业的协同工具，这里推荐Slack和Teambition。

#### 开发工具

虽然在备赛学习过程中看到许多开发者都使用VS Code和JetBrains系列软件，但我们依旧采用了官方的微信开发者工具，因为微信开发者工具毕竟是微信官方专门为小程序开发的IDE，体验上来说更加原生，也方便从IDE的更新日志中了解到小程序的最新动向。  
![更新日志](http://pic.rhinoc.top/2019-06-21-82D3597C-017A-4020-B35E-B445F8168FC8.png)

但是由于微信开发者工具还不够完善，实际使用过程中出现过几次问题，这里一个小技巧就是——稳定版出问题换Beta版，Beta版出问题换稳定版。

#### 填坑与技巧

1.  微信小程序合法域名校验：可以使用云函数进行反向代理
2.  常用API接口：BAT都有在做NLP的接口、以及url2io的正文提取接口等等、更多接口提供商如易源数据等
3.  云开发云存储图片可以直接调用，但是加载速度比较慢，建议还是用七牛云CDN
4.  SVG图片的体积小而且矢量图更清晰

### 精修过程

这里的精修，一方面是指对小程序的操作流程中可能存在的Bug进行排查和修复，另一方面是对用户界面和交互逻辑进行更细致地精调。

#### 内测排查Bug

在这一过程中，我们在校园内开放了内测活动，聆听不同的声音，也从这些内测用户口中得到宝贵的意见和建议。在获得用户反馈这一过程中，我们发现用户特别懒于前往我们提供的反馈网址提交反馈，因此我们在小程序中加入了客服功能，用户在体验小程序的过程中遇到任何Bug或是有任何建议都可以不需要离开小程序就能够反馈给我们。

#### UI设计

我们也在比赛ddl前一周完成了对小程序Icon的绘制、UI的精调。  
![图标](http://pic.rhinoc.top/2019-06-21-7E8EE657-D322-4B37-81BA-39F312853E73.png)

有必要说一下Icon的设计理念，因为完成了Icon的设计后，UI的设计也就完成了一半。何出此言呢？因为小程序的界面配色要和Icon呼应，配色确定好了，可不就是完成了一半的设计嘛。

图标背景色使用Brandeis Blue（布兰迪斯大学蓝，蔚蓝色）和Solitude（孤独蓝，浅蓝）。布兰迪斯大学被称为全美最年轻的主要研究大学，而布兰迪斯大学蓝也被寄予“年轻”、“实践”、“应用性”的美好寓意。正如同「阅见」这款小程序一样，年轻而实用。孤独蓝则对应「阅见」小程序的Slogan——看见开放互联网未经过滤的样子，「阅见」希望每个人能作为一个独立的个体，去客观看待这个世界。

外形上，图标由中文汉字和圆弧形背景组成。蔚蓝色的圆弧象征地球（舒适区内），另一半的浅蓝色象征大气（舒适区外），「阅见」两字分别位于两种颜色上，寄予「阅见」能打破回音壁，让用户看到更全局的世界的美好愿景。

#### 发布之前的收尾工作

对于小程序来说，除了用户用的了看得到的功能，还有隐藏在功能和界面之下的东西，比如小程序的体积、打开的速度、边界条件的设定等等，这些是用户不容易感知到的，但无形中又影响着用户体验的点。

1.  减小小程序的体积：去除不需要的console.log等测试代码、代码文件压缩、图片尽量使用SVG格式。
2.  加快小程序的打开速度：其实在减小小程序的体积的操作里，就能加快程序的运行速度了，还有就是可以将引用的图片CDN加速。
3.  边界条件的设定：所有需要用户输入的地方，都需要边界条件的设定，比如用户输入RSS订阅链接时不小心输错成了标题，如果不做边界条件设定的话，小程序就会request一个不合法的网址，就可能造成小程序崩溃

## One-More-Thing-——-上线之后的规划

说实话，在做这个小程序之前，我一直没有找到称心如意的跨平台RSS阅读器，然后碰巧看到有这么一个比赛，就想着自己开发一个好用的RSS阅读器。开发过程中，也调研了很多国内外的相似产品，比如国内的轻芒阅读、国外的红板报、Feedly、Inoreader等等。资料查得越多，心就越凉，因为几乎都是RSS已死的论调。但既然选择了这个主题，一条路也要走到黑。所以我又去探究RSS没落的原因，归纳成如下几点：

1.  **订阅源规范不统一**：当前存在的Feed规范有RSS 0.91、1.0、2.0和ATOM等，不同源输出的XML格式不同，导致解析困难。
2.  **正文获取困难**：越来越多网站为了广告和引流停止输出RSS或者不输出正文，传统的RSS 阅读器无法正常显示。
3.  **使用门槛高**：传统RSS阅读器手动输入链接添加RSS操作麻烦。
4.  **无参与感**：RSS相当于提供了一种单向的服务，用户只能作为信息的被动接受者，没有参与感。
5.  **平台和内容提供方盈利困难**：RSS Feed不能给内容提供者带来流量和收益，提供者放弃RSS内容输出，也导致内容平台流失用户。

说白了，就是没有盈利去维持RSS的生态，所以我想，如果能够解决内容平台和内容提供者的盈利问题，是不是可以给RSS续一秒。

我们计划采用盈利补贴、竞价排名、数据反馈三种方式打通和内容提供者之间的壁垒，实现内容平台与内容提供者互利共赢。

*   **盈利补贴**：我们计划在小程序上线并积累一定用户后，在首页信息流和文章内投放广告。文章内广告的营收将按一定比例作为该文章内容提供者的补贴。即：优质的文章带来大量流量，广告投放将流量变现，变现的一部分作为对内容提供者的补贴。
*   **竞价排名**：并且，对于知名度不高的内容提供方，「阅见」可以作为除微信公众号、网站、今日头条外另一个平台帮助其推广。发现页面每个分类下展示的订阅源以及搜索建议将采用竞价排名形式，即前3个订阅源根据用户订阅热度排名，往后的4-10个订阅源采用竞价排名形式，一方面为「阅见」提供营收，一方面也可以增加内容提供方的曝光率。
*   **数据反馈**：由于「表态」功能的引入，「阅见」可以获得用户对特定文章的反馈，我们不希望这些反馈只是作为一个摆设，而希望用户的反馈能够达到内容提供方，帮助其提升内容质量，了解用户的心理。

Resser

Owner Repos

Resser Latest Version Download

# Use via CDN

Was this content helpful?

Recent Feedback

Resser

Owner Repos

Resser Latest Version Download

# Use via CDN

Was this content helpful?

Recent Feedback

Download README