hectorqin and Claude Opus 5.5
fbb7298bf0
perf(web): split the reader and admin screens out of the first load
...
client.js was one 1.48 MB bundle (413 kB gzip) because the build assumed the
Android shell loads from file://. It no longer does: WebHost serves the
bundle from https://appassets.androidplatform.net/ via WebViewAssetLoader,
the service worker precaches every emitted file, and the server serves any
file under assets/ (caching hashed names forever).
- The reader, media library/task/item admin pages and source editor pages
load on first visit (app/router/lazy-pages.tsx); wrappers keep the page
names, so the route tree and its tests read unchanged.
- Chunks are content-hashed; the entry stays client.js and CSS stays one
index.css, so no host-facing name changes and no unstyled flash.
- A tab running an old client after a deploy gets "应用已更新 · 重新加载"
instead of a dynamic-import error.
- ui:review now opens a book and asserts the reader chunk loads and renders.
client.js: 1478 kB -> 777 kB (gzip 413 -> 231 kB).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-10-22 13:04:18 +08:00
hectorqin
2aaa4280c7
refactor(web): migrate client to React architecture
2026-10-03 12:12:30 +08:00
hectorqin
0b7f901db5
chore(server): change default listening port to 5888
2026-09-24 14:50:13 +08:00
hectorqin
e3cabf4b1f
feat(web): add PWA installation and offline app shell
2026-09-24 06:34:21 +08:00
cnb.dQC5J6ohAGA
13d474b098
feat: 修改配置
2026-09-17 17:27:28 +08:00
cnb.dQC5J6ohAGA
be606c0184
fix
2026-09-17 13:42:22 +08:00
cnb.dQC5J6ohAGA
c18664f1e3
feat(reader): 按窗口读取、真机可编译的 Android 壳，以及分章契约的收口
...
两件事：把 PR #8 里那四项合并进来（A 选项），然后把 issue 里一直没落地的
「一次只取一章」从服务端契约一路做到客户端。
## 一、PR #8 的四项（Android 外壳最值钱）
- Android 原生整页图渲染：NativePageView + 桥接 v2（renderPage/hidePage）。
只画整页图，EPUB 永远留在 WebView；画不了就返回 false 回退，不出现空白页。
- 离线队列：脏集合语义固定为契约，补上「请求在途时位置被改写」的三条用例。
- TXT 编码探测：GB18030 与 Big5 都解一遍再按损坏证据评分选优。
原来「先 GB18030 失败再 Big5」永远走不到第二步——两者字节范围重叠，
同一串字节通常两边都能解出合法字符，繁体书会整本乱码。
- 格式嗅探：magic number 优先于扩展名，并明确拒绝非书籍的媒体容器。
## 二、Android 壳第一次真的编译通过
上一轮说「没有 JDK/SDK，只写了契约」，这一轮补上了环境并真的编译。
编译立刻暴露三处——都是只有编译才能发现的：
- colors.xml 的注释里写了 --reader-paper。XML 禁止注释中出现双连字符，
AAPT 直接拒绝整个文件。Android 壳此前从未构建过，所以从未发现。
- NativePageView.kt 用了 Uint8Array。那是 JavaScript 类型，Kotlin 里不存在；
桥接的另一侧是 ByteArray。
- AndroidManifest.xml 引用了 @mipmap/ic_launcher，而资源里没有这个文件。
三条都让 :app:assembleDebug 失败，也就是说这个 APK 此前根本产不出来。
现在是 BUILD SUCCESSFUL，产物 3.6MB。
## 三、分窗读取：从契约做到客户端
服务端：
- /manifest 省略 group 现在等价于 group=0。原来省略意味着「发全部条目」，
于是一本 1200 章的书在它最需要快的那个请求（打开书）里收到 1200 条记录，
等于分窗对不传参的客户端完全失效。要完整结构用 ?group=all。
- /toc 在没有 OPF 标题映射时回落到章节自身的第一个标题。手作 EPUB 大量
没有标题映射，原来整本目录会读成「第 1 章 … 第 300 章」，等于没有目录。
- 扫描时的 spine 读取不再解析 NCX 与 nav：扫一遍全库本该只读一次包文档。
- 尾部 Range（bytes=-N）在超过 8MB 时退化为整包响应并撤回 Accept-Ranges。
前向流无法跳到文件末尾，服务这种请求意味着为三个字节读完整个 400MB 漫画包。
客户端：
- 新增 formats/remote-zip.ts：走 HTTP Range 的只读 ZIP，让浏览器端也能不下整本书。
- 新增 formats/windowed.ts：分窗文档。分窗是传输边界，目录必须完整，两者分开
—— 合在一起就是原来目录面板显示「第 1 章 – 第 40 章」的原因。
- reader-screen 接上 /toc，并且点击目录项会先取对应窗口再跳。
## 验证
server: 133/133（typecheck + test + build）
web: 179 vitest + 29 node:test（typecheck + test + build）
android: BUILD SUCCESSFUL，app-debug.apk 3.6MB
shell: 契约双向校验 + 渲染模式词表校验通过
2026-09-16 19:51:38 +08:00
cnb.dQC5J6ohAGA
ca68a03e5d
merge: 解决 auto/init-server-scaffold-81b3 与 main 的冲突
...
两个分支各自演进：一侧引入格式注册表、H5 客户端与 Android 外壳，另一侧
引入漫画目录书与逐页取图。冲突集中在扫描器、metadata、library 路由和 web
客户端，逐项按「两边能力都要保留」的原则合并。
合并后修复了 4 个被冲突掩盖的真实缺陷：
- scanner 同时保留了两套目录书实现，类型检查与测试均无法通过；改为统一
走格式注册表，目录书在文件遍历之前发现，其内容不再重复入库。
- /manifest 的 files 对漫画目录书返回的是文件夹路径，客户端无法逐页取图；
改为由 manifest 派生真实页路径。
- 单个文件端点只认 book_files 行，漫画目录书的每一页都 404；改为目录书
额外认领其目录下的路径，并修正路径归一化使穿越尝试仍被拒绝。
- 目录书判定只看图片数量，会把夹着一本书的目录整体吞掉；改为注册表驱动
的判定，含书籍文件的目录始终是书架。
同时修复了 web 端两套测试运行器互相无法执行对方用例的问题（vitest 与
node:test 混跑会静默跳过），以及 web 侧 5 处类型错误。
Ref: #9
2026-09-16 18:04:11 +08:00
CodeBuddy
d0a475919d
feat(web): H5 客户端，精排 epub 渲染 + 多格式阅读
...
用户的三个问题在这里落地：
1. 「H5 是一个完整的客户端」——同一份构建产物既由服务端托管（`/` 直接
就是完整阅读器），也可被 Android 外壳打进 assets 复用，两种宿主只差
一个 serverUrl。
2. 「纯 H5 时 epub 等资源是否需要 iframe 或 shadow DOM」——用 shadow DOM，
但不是为了隔离出版方样式（那做不到也不该做：书必须能给自己排版）。
它挡的是反方向：客户端自身的 CSS 不会漏进书里。iframe 只在 PDF 那一处
用，因为 PDF 需要自己的浏览上下文，理由写在 render/container.ts 里。
3. 「Android 端 epub 用 H5 渲染，其他类型用原生」——按 kind 分流，
capabilities() 明确声明：reflowable 走 WebView，paged/document 在
Android 交回原生。理由写进 reader-view.ts：WebView 每页一个合成层，
300MB 的画册在一台中端机上就是 OOM。
服务端同步配合的两处：
- 资源流式下发 + HTTP Range
- epub 按包内路径寻址、items/manifest 分窗
前端无框架：渲染热路径是命令式 DOM 操作，引框架只会把"最小覆盖 CSS"
的策略搞复杂；最终产物 35KB（gzip 10.7KB）。
2026-09-16 14:45:04 +08:00
hectorqinandClaude Opus 5.5
cnb.dQC5J6ohAGA
CodeBuddy