const fileName = "test.zip"
const filePath = getContext().filesDir + '/' + fileName
// 检查是否存在旧文件，存在则备份
if (fileIo.listFileSync(getContext().filesDir).includes(fileName)) { 
    fileIo.renameSync(filePath, getContext().filesDir + '/test.bak.zip') 
}

2. 带进度的下载实现

用request.downloadFile发个下载请求，再用事件监听实时显示下载进度，失败和完成也会有对应的处理：

const task = await request.downloadFile(getContext(), { 
    url: 'http://www.test.com/test.zip', 
    filePath // 下载后保存的路径 
}) 
// 监听下载进度，更新进度条
task.on("progress", (current, total) => { 
    this.currentValue = current this.totalValue = total 
})
// 要是下载失败了，弹个框提示错误
task.on("fail", (error) => { 
    AlertDialog.show({ message: error.toString() }) 
}) 
// 下载完成后，关掉加载状态，给个成功提示 
task.on("complete", () => { 
    this.showLoading = false promptAction.showToast({ message: '下载成功' }) 
})

三、资源包解压与页面跳转

下载完之后，得把压缩包解压到本地目录，然后跳转到专门的Web页面，加载H5资源。

1. 解压实现

解压用的是zlib.decompressFile，解压路径就选应用的沙箱目录，解压成功后直接跳Web页面：

async decompressFile () {
    try { // 解压文件到沙箱目录 
        await zlib.decompressFile(this.filePath, getContext().filesDir) 
        // 解压成功后跳转到Web页面 
        router.pushUrl({ url: 'pages/webCase' }) 
    } catch(error) { 
        // 解压失败就弹框提示错误 
        AlertDialog.show({ message: error.message }) 
    } 
}

四、H5资源渲染实现

WebCase组件专门负责加载、渲染解压后的本地H5资源，关键实现看这里：

1. Web组件配置

用Web组件加载本地H5资源时，有个关键点得注意：要开本地存储权限，不然H5可能用不了localStorage这些功能。代码里这么配：

Web({ 
    controller: this.webController,
    // 加载解压后的index.html文件 
    src: "file://" + getContext().filesDir + '/test/index.html' 
}) 
.domStorageAccess(true) 
// 重点！得让H5能用上本地存储 
.width('100%') 
.height("100%")

2. 调试模式开启

开发的时候要调H5页面，所以在页面初始化的时候，把Web调试模式打开，方便查问题：

aboutToAppear() { 
// 开启Web调试模式，方便调试H5页面 
    webview.WebviewController.setWebDebuggingAccess(true); 
}

五、关键注意事项

本地存储权限别漏了：H5资源一般都要用到localStorage这类本地存储功能，必须设domStorageAccess(true)，不然H5运行的时候会报错。
文件路径得处理好：用getContext().filesDir拿应用的沙箱目录，确保资源存在应用自己的私有空间里，不会有权限问题。
异常处理要做全：下载和解压的时候，得把异常都捕获到，用弹窗跟用户说清楚错在哪，体验会好很多。
版本管理不能少：实际项目里得加个版本校验的逻辑，别让相同版本的资源包重复下载，省流量也省时间。这么一套流程走下来，应用就能实现H5资源热更新了——不用重新发版，就能更H5页面内容，给应用迭代加了不少灵活性。

JavaScript 究竟怎么跑

掘金前端

作者前端微白

2025年8月22日 17:13

那天深夜，我把一段看上去平平无奇的订单状态更新函数丢进预生产，结果线上 CPU 一路飙红、页面直接卡死。事后回溯，我们才意识到：看似同步几毫秒就能跑完的代码，在事件循环的显微镜下其实是一条彻底堵住主线程的巨蟒。

下面我就用最贴近业务的例子，带你走完这段“JavaScript 究竟怎么跑”的完整流水线，并给出我们后来能秒级止血的三板斧。

问题场景：一条把 10 万条订单一次性算完的“自杀”代码

// 🔍 这段循环在测试环境只有 200 条订单，表现良好
export function bulkCalcFee(orders) {
  return orders.map(o => {             // ①
    let fee = 0;
    for (let sku of o.skus) {          // ②
      fee += sku.price * sku.qty * complexTax(sku.category);
    }
    return { id: o.id, fee };
  });
}

行①：Array.map 是同步的，它会把 10 万次complexTax 一股脑压进调用栈，主线程寸步难行[1]。
行②：complexTax() 本身又包含 4 层if-else，栈帧越叠越高，堆内存跟着膨胀。

解决方案：把重计算切成“宏任务”+“空闲切片”

我们做的第一件事，就是把每 256 条订单拆成一个 chunk，然后借助浏览器/Node 里的事件循环让出控制权。

// 🔍 chunkSize 根据经验值在浏览器里 16～256 效果最佳
export async function bulkCalcFeeAsync(orders, chunkSize = 256) {
  const results = [];
  for (let i = 0; i < orders.length; i += chunkSize) {
    const slice = orders.slice(i, i + chunkSize);
    results.push(...slice.map(calcSingle));   // 同步计算一小块
    await new Promise(setTimeout);            // 把余下推到下一轮宏任务
  }
  return results;
}

解释第 8 行：await new Promise(setTimeout) 不是“延迟 0 ms”，而是在宏任务队列里插入一个空任务，让浏览器/Node 有机会去清空微任务、更新 UI，随后再拉取下一轮 chunk，从而把一次 200 ms 的卡顿拆成 50 次 4 ms 的微抖动。

原理剖析：同步海啸→宏任务大坝→微任务分洪

把上面的修复逻辑画成文字版时序图，就能看清事件循环的三层闸门：

        ┌-----------┐
同步代码 │ calcSingle│
一次性    │ (4 ms)    │
跑完      └-----┬-----┘
                ▼      <-- 调用栈瞬间拉满
        ┌---------------┐
宏任务    │ setTimeout(fn,0)│
缓冲      └-----┬-----------┘
                ▼      <-- 让出主线程，界面可滑动
        ┌---------------┐
微任务    │ 更新进度条    │
插队      └-----┬-----------┘
                ▼
        浏览器重渲染

微任务队列总是在当前宏任务末尾一次性清空，因此进度条动画不会因为多次宏任务而闪烁；这也是我们把进度回调放到 queueMicrotask 而不直接丢 setTimeout 的原因。

应用扩展：三种可落地的“任务分片”战术

场景	战术	关键 API / 配置
浏览器端列表渲染	切片 + requestIdleCallback	`await new Promise(requestIdleCallback)`
Node 端批量查询	使用 Node 自带 `setImmediate`	`setImmediate(() => nextChunk())` 比 `setTimeout` 少一次 timer 阶段
Web Worker 大计算	真·多线程	`new Worker('./heavy.js')` 把整块计算挪走，主线程 0 ms

举一反三：三个变体，照着就能抄

搜索联想 每次用户按键盘就触发 200 ms 的拼音匹配？ → 用 AbortController 在上一个宏任务未完成时直接取消，减少重复计算。
Excel-like 表格公式自动重算 公式链可能深度 20 层？ → 把依赖拓扑转成 DAG，每个节点用微任务更新，让 UI 先刷出绿色“计算中”图标。
Canvas 实时渲染热力图 10 万个坐标点？ → ImageData 拆成 1 k 点一组，利用 requestAnimationFrame 在浏览器每次重绘前只刷一部分像素，肉眼根本看不出分段。

最后我们给那段“肇事函数”加了道保险：在编译阶段接入 types/bundlesize 把循环次数写进类型注解，一旦测试用例出现 >5000 条数据直接 Type Error，提前把性能雷埋掉——这比上线后回滚便宜太多。

JavaScript 不是“跑得慢”，而是“把异步写成同步就会堵”。事件循环把一切都准备好了，缺的是我们给主线程留的那口喘息。

纯前端用 Next.js 本地实现 SSE 流式传输