7款网络小说阅读器深度对比：开源vs商业应用 | 技术架构与功能分析

喜欢网络小说的读者如今有越来越多的工具来提升他们的阅读体验。从能聚合同人翻译站点章节的手机应用，到带有自有版权内容的官方平台，网络小说阅读器软件的生态相当多样。本文会从开发者的角度，对最相关的项目——无论是开源还是商业的——进行分析，并将各自的功能、架构和目标受众进行对比。我们也会讨论这些竞争对手如何与我们的项目（此领域的新进者）相比较，找出它们的优势、不足以及潜在机会。本文面向高级用户和潜在贡献者，可帮助他们了解实现细节、可扩展性，以及构建网络小说阅读器的最佳实践。

网络小说阅读器的概况

网络小说阅读器通常可分为两个类别：开源的社区驱动项目和商业平台或应用。以下分别概述这两大类别中的关键示例：

开源项目

Shosetsu（Android）
一个受 Tachiyomi 启发的可扩展轻小说阅读器，提供可高度自定义的阅读界面以及追更系统来跟踪新章节
(1)。
Shosetsu 使用插件/扩展（extension）模式，并搭配可修改的仓库来托管大量来源适配器
(2: Shosetsu - The extendable novel reader for Android. - Fossdroid)
(3)。
（注意：该项目于 2022 年被存档，意味着维护方面出现了挑战。）
LNReader（Android，React Native）
一个类似 Tachiyomi 的开源轻小说阅读器，使用 React Native 构建
(4)。
支持大量来源，甚至可集成 Novel Updates（知名同人翻译索引）来进行发现
(5)。
LNReader 提供诸如跨来源的全局搜索（尽管早期版本在这方面稍显迟缓
(5))和类似 Tachiyomi 的书库管理功能。该项目活跃度较高，并有社区（Discord 和 GitHub）共同协作，持续修复 bug 并拓展来源。
QuickNovel（Android）
一个注重下载速度、无广告的 FOSS（自由开源软件）阅读器
(6)。
QuickNovel 支持多个来源（但据用户反馈，比 LNReader 的来源数量要少一些），以搜索和下载速度快而知名
(7)，也可用作本地 EPUB 阅读器
(6)。
不过它没有自动更新新章节的机制，UI 也被部分用户认为不够友好
(7)。
NovelLibrary（Android）
一个较早的开源项目，宣称能"一站式阅读所有小说"
(8: NovelLibrary/README.md at master - GitHub)，
注重离线功能 —— 用户可下载小说并书签当前阅读进度
(9)。
NovelLibrary 内置热门作品推荐功能，并可在多个目录中搜索小说
(10)。
虽然曾经很有创新性，但在支持新站点以及现代功能方面，可能不如一些新应用完善。
NovelDokusha（Android）
一个用 Kotlin（Jetpack Compose）编写的现代化网络小说阅读器。可支持多个来源网站并可在多个小说数据库中进行搜索
(11)，
例如按书名或类别跨索引搜索。
亮点功能包括无限滚动阅读、自定义字体和字号、实时翻译以及可调语音的文字转语音（TTS）
(12) —— 支持后台播放章节语音。它也可读本地 EPUB、轻松备份并支持暗色模式
(13)，对高阶用户而言相当友好。
Miru Project（Android、桌面端、Web）
一个多功能开源应用（Flutter 构建），整合了视频、漫画及小说等内容
(14)。
对于小说，Miru 提供了类似 Tachiyomi 的扩展系统，允许社区维护不同来源。
它是跨平台的（Android、Windows、Linux 和 Web）
(15: Miru)
(16)，
展现了如何使用单一代码库在多设备上提供网络小说阅读功能。其范围虽广，但通过模块化设计了各类媒体类型，显示出良好的可扩展性。
WebNR（Web/PWA）
一个基于 Web 技术的现代化网文阅读器，使用 Next.js 和 TypeScript 构建
(17: WebNR - Web Novel Reader)。
与其他项目不同，WebNR 采用纯浏览器方案，无需安装即可使用。其主要特点包括：完全离线运行的 PWA 应用，注重用户隐私（无需登录，所有数据本地处理）支持多源导入（本地文件、URL、多个小说源）、提供跨源搜索和自动源同步、丰富的阅读体验（翻页/滚动模式、深浅主题、进度追踪等）

WebNR 展示了另一种技术路线：利用现代 Web 技术（如 IndexedDB 存储、Web Speech API）来实现原生应用级别的功能，同时保持轻量级和跨平台特性。这种方案虽然在某些性能方面可能不及原生应用，但在易用性（一键即用）和可访问性方面具有优势。

商业及闭源解决方案

官方网络小说/网文平台
像 Webnovel（起点国际版） 和 Wattpad 这样的应用拥有海量原创或授权内容。
Webnovel 的应用是该类别下载量最高的之一
(18: What is the best website/app to read almost every novels? - Reddit)，
具有完善的阅读体验：离线阅读、评论等。但这些平台是封闭生态系——只能访问它们自带（如官方授权翻译或用户原创）的内容，不会聚合外部站点的小说，更多面向只阅读该平台作品的休闲读者。
Tapas 和 Radish
这两者与 Wattpad 类似，主要提供原创或授权的连载小说。它们的应用拥有丰富的功能（定制化阅读器、社区互动、订阅等），但同样无法从外部站点抓取内容。对于想一次性获取网络上多家同人翻译小说的读者而言，这类应用并不全面。
通用电子书阅读器
传统电子书阅读器（Kindle、Google Play Books、Moon+ Reader 等）也可用来阅读网络小说，只是需要用户手动获取 EPUB/PDF 文件。
它们在渲染和功能（书签、词典、同步等）上表现优秀，但无法直接从网络小说站点获取内容。用户必须手动下载或转换文件，所以虽然在阅读体验方面不错，却不满足网络小说粉丝对聚合更新的需求。
带广告的聚合类闭源应用
在各大应用商店中也有不少闭源的 Android 应用，用来爬取网络小说站点（与上面提到的开源方式相似），但通常由某些公司或个人开发并通过广告获利。例如，Webu – Web Novel Reader 标榜其为"一体化的"小说追更应用
(19: Webu - Web Novel Reader - Apps on Google Play)，
以及 Light Reader、Fizzo Novel、MReader 等应用，提供大量人气小说并具备精美的界面。
但其缺点往往是广告过多，且可能存在版权或法律风险，也缺乏透明度。与开源项目不同，若某个来源出现故障，用户无法自行扩展或修复，资深用户往往更倾向于使用社区驱动的阅读器以获得更多控制权。

功能对比

为了更好地理解这些阅读器的差异，让我们从内容来源、阅读体验、离线能力、可扩展性和其他高级功能方面，一一对比它们，并说明我们的项目计划如何突出自身优势。

内容来源与聚合

网络小说阅读器最重要的特性之一，就是能从多个翻译站点获取内容并保持更新。开源阅读器在这方面通常表现出色：

支持的来源：
我们的项目也会通过插件系统针对广泛的小说网站提供支持。
像 LNReader 已经支持数十个站点，还能利用 Novel Updates（同人翻译社区的索引）来搜索发现作品
(5)，
这让用户一次搜索就能知道哪家站点有此作品，省去了浏览器里"开 50 个标签页找小说"的麻烦
(20: lnreader vs shosetsu - compare differences and reviews? - LibHunt)。
相比之下，QuickNovel 支持的站点更少（更专注核心站点）
(7)，用速度来换取对来源广度的牺牲。
Shosetsu 也因为其社区贡献的多样化来源扩展而有可观的来源量
(3)。
我们的项目目标是在来源覆盖度上与这些工具持平或更优，同时确保对小众或新站点的兼容性，并提供便捷的方法来新增来源。
书库管理 & 更新：
所有这些开源应用都提供收藏/书架功能来跟踪并显示小说更新。
例如，Shosetsu 的更新系统会追踪整本书的新章节
(1)，
LNReader 和 NovelLibrary 也能让用户把小说加入书库，并在有新章节时进行通知或突出显示。
QuickNovel 的弱点是缺少自动提醒更新功能
(7)，
用户可能需要手动刷新或借助外部渠道获知更新。
我们的项目计划将坚实的更新跟踪作为核心功能——可能实现推送通知或后台检查，让用户不错过任何一章。此外，我们也计划整合类似 LNReader 那样的 Novel Updates 功能，方便读者从一个集中索引平台上发现并追更。
搜索与发现：
发现新小说方面，NovelLibrary 率先尝试了为用户推荐热门或高评分小说
(10)。
我们也可在项目中添加"发现"板块，例如提供精选书单或多来源的热门作品榜单。
同时，全局搜索功能则是必不可少的：LNReader 的全局搜索功能在面对"一口气搜索多站点"时，早期版本速度不佳
(5)，但正在逐步优化。
我们会采用高效的搜索策略（如并行请求，带有节流与结果缓存），确保即使要搜索 50+ 个站点，也能迅速响应。

阅读体验与自定义

资深读者会在阅读器中花费大量时间，因此界面的可定制和功能丰富度至关重要：

UI 可定制：
几乎所有成熟的阅读器都具备如字体大小、亮度调节、主题等基础功能。
Shosetsu 强调其高度可定制的阅读器
(1)，
NovelDokusha 进一步拓展至自定义字体和无限滚动阅读
(12)。
我们的项目也会提供多种阅读模式（分页或连续滚动）、字体及行距调节、日/夜主题，以及用户自定义色彩方案。对于站点格式不统一的问题，我们还会考虑先进排版设置或 CSS 调整功能，让用户在遇到排版混乱的章节时也能统一处理。
实时翻译（Live Translation）：
NovelDokusha 的一个突出功能就是实时翻译
(12)，
很可能是调用在线翻译 API，将原文即时翻译成用户语言（对于想阅读生肉的读者很有帮助）。大多数竞争者尚未实现此功能；若我们也能在项目中实现，将为喜欢看原版/生肉的读者带来全新体验。这需要处理 API 限制及保留文本格式等挑战，但潜在收益巨大。
文本转语音（TTS）：
许多资深读者会在通勤或做其他事时用听的方式"读"小说。NovelDokusha 内置 TTS，可后台播放，并能调节声音
(12)。
其他阅读器大多没有原生的 TTS——用户需依赖系统的辅助工具。
我们计划将 TTS 作为一等功能，利用平台自带的 TTS 引擎（或可选更高品质的付费 API，如 Google Wavenet）来朗读任意章节，并提供语速和声音的控制。这样不仅提升可访问性，也能强化差异化卖点。
用户界面与使用体验（UX）：
就整体界面设计而言，LNReader（基于 React Native）被认为简洁，而一位 Reddit 用户觉得 QuickNovel 的界面"没那么友好"
(7)。
虽然 UI 偏好见仁见智，但我们的项目目标是提供现代且直观的界面，同时支持响应式设计，让应用在手机或桌面端都能自然使用。
选择 Flutter 或 React（若使用 web 端）等技术可实现流畅的动画及一致的多端体验，就像 Miru 那样跨平台
(16: Miru Project: A versatile application that is free, open-source, and ...)。
我们将注重细节（如记住滚动位置、无缝章节切换、界面简洁等），让资深用户感受到高效且愉悦的阅读过程。

离线阅读与下载

这类应用的另一大吸引力在于可离线保存章节，特别是某些同人翻译站点不稳定的情况下：

批量下载与格式：
QuickNovel 的核心功能就是下载小说，甚至能整合成 EPUB
(6: LagradOst/QuickNovel: Android app for downloading novels - GitHub)。
大多数开源阅读器也支持离线保存章节或整本作品。NovelLibrary 当初的诞生就是因为开发者找不到能离线下载和设置阅读进度的应用
(9: Light Novel Reader with download and bookmark features - Reddit)。
因此我们也会支持批量下载（比如一次下载若干章节或整本），或导出为 EPUB/PDF 等常见格式，方便用户归档或在其他设备上阅读。
离线书库管理：
下载完章节后，应用应合理管理存储空间。Tachiyomi 的图片存储方式较为高效；对于纯文本，我们会考虑使用轻量级数据库或文件存储缓存章节，并在阅读时进行必要的预加载。
对超长章节的阅读，我们也要避免一次性加载过多内容以致占用大量内存。可采用按需加载和占位符技术（无限滚动中只渲染当前与附近章节）。
对于可能拥有数百上千章节的用户，这就需要一个强大的缓存和数据访问层来保证流畅度。
同步与备份：
目前大多数解决方案都缺乏云同步。像 LNReader 或 Shosetsu 通常只有手动备份（导出 JSON 或 SQLite），NovelDokusha 虽提供了易用的备份/还原
(13: nanihadesuka/NovelDokusha: Android web novel reader - GitHub)，但依然是手动操作。
在我们的项目中，或许可以实现可选的账号同步功能，把阅读进度和收藏列表同步到多设备（可考虑注重隐私的云端服务或自建服务器）。对于开发者和高级用户来说，这将相当有吸引力：例如，可在手机上阅读，然后在平板或电脑上继续无缝衔接。
当然实现同步会增加复杂度（服务端、冲突解决等问题），因此也可以作为一个可选功能提供给有需要的人。

可扩展性与对开发者的友好度

因为这是篇面向开发者的分析，比较各解决方案的可扩展性以及如何吸引贡献者就非常重要。项目能否成功，很大程度上取决于是否能够调动资深用户与开发者共同拓展新的来源和功能。

插件/扩展式架构：
Shosetsu 与 Tachiyomi 开创了针对不同来源的扩展包思路。Shosetsu 允许开发者把扩展托管在仓库中，用户可在应用中加载
(3)，
这样把来源代码与核心应用解耦——这是我们也计划采用的最佳实践之一。
LNReader 同样支持多来源插件（他们维护了一个独立的 lnreader-plugins 仓库）。
借鉴类似架构，我们的项目也能很好地扩展：有新的来源或内容格式时，社区可以新增扩展，而无需更新整个主应用。我们会提供一个清晰的 API 或 SDK，方便开发者编写站点解析器（定义如何获取书籍列表、章节、解析文本等），再打包供应用使用。这种模式在开源社区中已经被证明是行之有效的
(3)。
开源贡献模式：
提及的所有开源项目都在 GitHub/GitLab 上开放代码，并接受 Issue 或 Pull Request。Shosetsu 团队曾欢迎外部帮助，LNReader 也因为社群接力而维持活跃度。
我们的项目同样会积极吸引开发者参与：提供完整文档（如如何新增来源、项目架构说明），并采用一个相对易上手的技术栈来降低门槛。
例如，如果使用 Web 技术栈（TypeScript/Node 做爬虫，Electron/React 做前端），可能更易吸引那些热爱网络小说的前端/全栈开发者；
或若采用移动端方案（Flutter 或 React Native），则能同时吸引对移动开发感兴趣的人，而不限于 Android-Kotlin 专家。
我们的目标是打造一个包容的开发者社区，让有一定编程能力的小说爱好者能轻松贡献。
模块化与代码架构：
以现有项目为例：LNReader（React Native）主要用 JavaScript 编写，可能利用 Redux 做状态管理，并使用 MMKV 做存储
(4: LNReader/lnreader: Light novel reader for Android. - GitHub)；
NovelDokusha 则是 Kotlin + Jetpack 组件；
Miru 使用 Flutter/Dart，借助 Flutter 原生的 UI/业务分层来做扩展（适配不同媒体类型），扩展多半也是用 Dart 或桥接方式实现。
不同技术选择影响可扩展性和优化难度。
我们的项目会采用清晰的分层架构：一层处理数据抓取（如一组来源模块），一层处理核心逻辑（书库、更新等），再一层做界面展示。如此不仅便于维护和测试，也能让新功能（例如新增书签系统或推荐界面）独立开发。我们会使用依赖注入等方式，使替换或升级不同组件变得简单。对贡献者而言，这是一个结构化而易于扩展的项目，而非一团散乱的代码。
性能与可扩展性：
可扩展性并不仅仅与代码结构有关，还在于如何在内容和用户规模增长时保持顺畅。LNReader 早期在全局搜索 ~30 个来源时速度很慢
(5)，这随着来源数量增加会愈发明显。
我们会在架构上考虑可扩展性——例如并行请求时的并发限制与超时、缓存搜索结果，以及让用户自定义是否在全局搜索中包含全部来源。
对于内存与存储的使用，也需在拥有数百本小说、上千章节的场景下进行性能测试，以确保应用依旧流畅。还要考虑离线优先的设计——如果来源网站暂时不可用或被封，应用应能稳定工作。
我们可采用诸如失败重试机制或多镜像源来提高鲁棒性。从以往应用的局限中，我们学到不少经验，会在这些方面力图改善。
可跨平台的同步架构：
如前所述，提供同步可是一大特色。技术上，可能需搭建一个简易服务器或使用第三方云服务（如 Firebase/Cloud Firestore）来存储用户的书库元数据（不会存储实际内容，以免牵涉版权问题）。
在安全与隐私上，我们也可以让用户自己选择存储方式（如 WebDAV、Dropbox 等）来托管同步数据，类似一些 RSS 阅读器（Feedly 或 Nextcloud）的做法。对社区开发者来说，这也是可扩展点：可以做不同云存储后端的插件。对高级用户而言，这也满足了他们对数据控制的需求。

现有方案的痛点及改进方向

没有哪种方案是完美的。通过探究当前阅读器面临的痛点，我们可避免或改进这些不足。

维护与持久性：
维护来源适配器通常是社区阅读器的最大挑战。网站频繁改版，志愿维护者难免会疲于更新。Shosetsu 已被存档、LNReader 也曾在主开发者忙碌时出现 bug
(7)。
为缓解此问题，我们将让社区更容易贡献修复：为那些小型 DOM 改动提供类似配置脚本的方式，或采用更具韧性的爬虫框架。
此外，我们会保持在相关社区（论坛、Discord 等）中积极活跃，吸引更多新人参与维护。
或许还能开发一个插件健康度系统（标记哪些来源失效/过时），让用户和开发者都能及时知晓并优先修复。
法律与合规问题：
许多开源阅读器在版权翻译问题上处于灰色地带。Tachiyomi 就曾因内容提供方的法律威胁而调整仓库
(21: Tachiyomi is dead, migrate to forks · forum | osu! - ppy)。
虽然我们的项目专注技术本身，但必须意识到这些风险。我们本身不会托管任何内容，只提供抓取功能；并可能采用类似 Tachiyomi 的去中心化扩展分发模式，让社区自行托管来源列表，以免因某个站点引发整站下架。
这是现有方案都面临的微妙问题，我们会在贡献者准则（如是否接受某些敏感来源）上进行说明，以减少被突然叫停的风险。
用户体验缺口：
一些用户在尝试了 QuickNovel、Shosetsu 后仍找不到想要的功能
(22: Need LN reader app recommendations - Lemmy.World)。
例如 TTS、无需下载即可快速预览章节等。我们已计划把 TTS 视为重点，但也可考虑内置浏览器模式，让用户浏览尚未被支持的站点，然后在站点可用时再自动导入。
此外，对于小说元数据处理，目前 Novel Updates 的集成虽有帮助，但大多数应用并不会在界面中展示更丰富的说明（作者信息、社区评分等）。
我们可将这些元数据一并聚合（比如 Novel Updates 的 API），让用户在书库里就能看到小说的简介、作者和社区评价，为阅读带来更多背景信息。这将让我们不仅仅是"爬虫阅读器"，也会成为完整的小说管理工具。
性能局限：
在老旧设备或大型书库中，一些阅读器的性能仍是瓶颈。全局搜索可能卡顿，加载数千章节也会导致崩溃。
为避免 LNReader 早期或其他项目遇到的情况，我们必须从一开始就关注性能：把繁重任务放在后台线程，避免 Java/Kotlin 中常见的内存泄漏，并为那些想要极简模式的用户提供选项（关闭动画或自动更新等）。
如果用 RN 或 Electron 这些高层框架，我们还要警惕其性能开销，可对关键功能使用原生模块或进行优化。
我们也会做大规模模拟测试（大量小说与章节），在开发过程中就进行性能剖析（Android Profiler、Chrome DevTools、Flutter DevTools 等），及时定位并解决瓶颈（例如低效的正则或数据库查询）。
此外，通过 Novel Updates 之类的 API 或 RSS 进行搜索可减轻对多家站点的重复抓取
(5)，这是我们会借鉴的最佳实践。
可扩展性 vs. 简易性：
过度复杂的扩展流程可能吓跑普通用户。Tachiyomi 的一些分支被戏称为"极客的玩具"，需要手动安装扩展、逐个配置。
我们希望在增强可玩性的同时，也能兼顾新手：开箱即带最常用的来源或能"一键获取"热门扩展，就像"应用商店"一样，而无需用户自己找 GitHub 地址、下载 apk 扩展等。
这在 UX 与架构上都有挑战（比如动态加载代码或规则），但若能解决，便可大幅扩大受众面，同时也不失对技术用户的吸引力。

架构思路与最佳实践

让我们更深入地探讨不同项目在技术层面的构建方式，以及我们打算遵循哪些最佳实践：

技术栈：
开源小说阅读器覆盖多种栈。Shosetsu 等传统项目常用原生 Android（Java/Kotlin），能充分利用 Android 的 SQLite 和 WebView/Jsoup 做解析；
LNReader 用 React Native（JS/TS），主要开发目标在 Android 上；
Miru 用 Flutter/Dart，可一套代码多端打包；
而 WebNR 则展示了纯 Web 技术栈（Next.js/TypeScript/IndexedDB）的可能性，通过 PWA 实现接近原生的体验。
选择何种栈会影响性能、跨平台以及贡献者来源。
内容解析与缓存：
所有这些应用本质上都是"特化的浏览器"，会抓取并解析小说站点的 HTML。
最佳实践包括使用成熟的 HTML 解析库（Java/Kotlin 的 Jsoup、Node.js 的 Cheerio 等），并对内容做清洗（移除广告、脚本、不相关元素）。
Tachiyomi 的扩展 often 采用一些通用辅助类，这也是我们要做的：提供一套解析框架，让扩展开发者无需重复造轮子。
在缓存策略上，由于小说章节多为纯文本，体积不大，可以更激进地存储到本地。
要注意章节更新时的缓存失效（可能使用 etag 或 last-modified，如果站点支持；否则只能靠用户刷新）。
另一个最佳实践是将章节内容存成统一格式（纯文本或简化 HTML），以便在阅读器里统一排版，不受站点原始 CSS 干扰。我们从 Shosetsu 等项目得知，阅读界面应尽量独立于站点的样式。
性能优化：
随着来源与书库规模增大，性能调优愈加重要。LNReader 通过并行与限制全局搜索频率来提升效率
(23: Releases · LNReader/lnreader - GitHub)。
我们可考虑更高级的方法：建立搜索索引，在后台定期爬取更新并索引标题/关键词，这样用户搜索时能迅速匹配（当然这对维护规模要求很高）。
或者给用户提供选择，只搜索部分常用站点以减少负载。
在 UI 方面，使用列表虚拟化技术处理大量章节避免卡顿，或通过高效的 Diff 算法来更新列表。
我们还会利用 (Android Profiler / Chrome DevTools / Flutter DevTools) 做性能监控，找出像"慢正则或低效数据库查询"这种瓶颈并及时修复。
集成 Novel Updates 或 RSS 等聚合接口也可减少对各站的大规模抓取
(5)。
这些都是成熟项目证明有效的最佳实践。
可扩展性与大规模用户：
如果我们的项目大获成功，成千上万用户同时抓取同个站点，可能对小站形成类似 DDoS 的流量。
我们可以尝试分时或缓存热门内容：例如同一热门作品，重复搜索可从公共缓存获得，而不是每个客户端都直接爬取。
这就涉及到客户端 + 云端的混合架构，会增加复杂度，但对提升用户体验与减轻站点压力有帮助。
从代码角度看，可扩展性也意味着分开维护站点扩展，网站一旦改版，只需更新对应扩展而不必升级整个应用。Tachiyomi、Shosetsu 等都这么做
(3)，
这是长线发展的关键。
跨平台同步架构：
前面谈过同步是潜在差异化亮点。在架构层面，我们可用一个轻量级后端或第三方云来存储用户书库元数据（避免存储真实章节），或允许用户自定义第三方存储（类似 RSS 阅读器的做法）。
安全和隐私是重点，可让用户自带云盘（WebDAV、Dropbox 或 Nextcloud 等）进行同步。
对开发者来说，这也是可扩展点：有兴趣的社区成员能编写"X 云存储插件"，让更多人受益。
总之，此举可满足"手机-平板-电脑"多端无缝阅读的需求。

结语

构建一款同时满足休闲读者和技术用户需求的网络小说阅读器，既富挑战又具价值。我们通过对现有解决方案——从 Shosetsu、LNReader、QuickNovel、NovelDokusha 等开源项目，到商业平台——的深入分析，看到了许多对我们自己的项目具有借鉴意义的地方。在内容覆盖广度、定制化阅读体验和现代可扩展架构方面，依然有提升空间，也存在清晰的差异化机会。

对开发者和潜在贡献者而言，我们的项目将以可扩展和透明为核心，采用插件式来源系统
(3)、模块化架构以及跨平台技术来打造一个易于上手、可持续的代码库。对高级用户而言，像实时翻译、TTS 这样的功能
(12)
会带来更丰富的阅读方式，而云同步、丰富的元数据等潜在功能也能进一步完善体验。

总的来说，网络小说阅读器在社区创新的推动下持续成熟。从 Shosetsu 等传统的原生应用，到 WebNR 这样的现代 Web 解决方案，每种技术路线都有其独特优势。通过对现有阅读器优劣的学习，我们希望做出一款既能补足功能短板、又能推动社区建设的开源工具。诚挚邀请对网络小说充满热情的开发者加入我们，共同打造一个真正让数百万小说爱好者受益的阅读器，无论他们想要在线还是离线、手机还是桌面，都能获得流畅灵活的阅读体验，充分利用现代 web 与软件开发的力量。

参考资料：
本文对功能和特性的讨论，主要基于各项目的官方文档及用户社区的讨论。核心参考包括 Shosetsu
(1: Shosetsu | F-Droid - Free and Open Source Android App source)
(3: Sources - Shosetsu)，
LNReader
(5: lnreader vs QuickNovel - compare differences and reviews? - LibHunt)，
QuickNovel
(7: What is LNReader? : r/animepiracy - Reddit)，
NovelLibrary
(10: Download Novel Library (MOD) APK for Android)，
NovelDokusha
(12: README.md - nanihadesuka/NovelDokusha - GitHub)
(11: NovelDokusha - IzzyOnDroid F-Droid source)，
Miru
(14: miru-project/miru-app - GitHub)，
以及其他文中引用的资源。这些参考可为想进一步了解实现细节和功能的读者提供更多信息。