Repository navigation
refactor(native): one implementation of the resumable-download decisions - #688
Conversation
Android, iOS and Harmony each implemented the same resume decisions around a partial archive and its `.resume` sidecar, and they had drifted: only Harmony refreshed the sidecar with the final size after a complete transfer (so the other two re-downloaded a chunked archive whose process died between download end and unzip), only Android capped the sidecar read at 64KB, and the three Content-Range parsers disagreed on trailing text and signs. cpp/patch_core/resume_plan.h now makes every decision: read and validate the sidecar, plan the request (complete / resume with Range, Accept-Encoding: identity and If-Range / fresh), classify the response (complete / restart / httpError / write with append, base, total, encoded, persistSidecar) and build the sidecar text. The downloaders keep only the IO: Android through JNI (ResumePlan.java), Harmony through NAPI, iOS directly. All three refresh the sidecar after a complete unencoded transfer, cap it at 64KB and accept digits only in Content-Range. cpp/patch_core/tests/resume-plan-vectors.json (66 cases, including every Content-Range case the removed JVM and Harmony tests covered) pins the behaviour; test-patch-core.sh replays it. JNI and NAPI tables are generated from scripts/contract.ts; android/lib is rebuilt with NDK 28.2. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
Bump package.json and harmony/pushy/oh-package.json5 together, with the bilingual release notes. Ships everything since 10.60.0: the shared native round engine (#673-#681), the cross-platform alignment and fixes (#664, #666, #671, #687, #688), the JS client fixes and split (#667, #684, #685), the bounded host prepareBundle (#669), the generated cross-platform contract (#683, #686) and the trimmed npm package (#670). Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
架构审查剩下的结构项:把断点续传的决策下沉到 C++,三端改为调用同一份实现。
为什么
三端的下载器各自实现了同一套续传决策,并且已经出现了漂移:
parseInt会接受200abc这种末尾带杂字符的写法,Android 的Long.parseLong会接受+100这种带符号的写法。改了什么
cpp/patch_core/resume_plan.h负责全部决策:Range、Accept-Encoding: identity和If-Range请求头。三端只保留 IO、单次重试、进度和限额:Android 经 JNI 的新类
ResumePlan,鸿蒙经 NAPI,iOS 直接调用。三端统一的行为:下载完成且未编码时用最终大小刷新 sidecar;sidecar 读取上限为 64KB;Content-Range只接受纯数字。cpp/patch_core/tests/resume-plan-vectors.json共 66 个用例,锁定上述行为,其中包含被删除的 JVM 与鸿蒙测试里的全部 Content-Range 用例,由test-patch-core.sh回放。JNI 和 NAPI 的绑定表由scripts/contract.ts生成。android/lib下的.so已用 NDK 28.2 重新编译。共 18 个文件,新增 457 行、删除 576 行。
验证
SANITIZE=1 ./scripts/test-patch-core.sh通过,66 个续传向量全部通过。新文件在三端 release 参数下都能干净编译:Android 关 RTTI、iOS C++20、鸿蒙 C++17。.so重编后verify-android-so.js和check-binary-strings.js通过。testReleaseUnitTest编译了改动后的 Java 代码,JVM 单测全部通过。RCTPushyDownloader.mm做语法编译,没有错误也没有警告。pushy.cpp通过,鸿蒙类型检查也通过。bun lint通过,包括生成器的一致性检查;bun test456 个用例全部通过。🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need.Summary by CodeRabbit