鸿蒙6/鸿蒙NEXT WebView套壳APP源码

鸿蒙6/鸿蒙NEXT WebView套壳APP源码

本文使用AI生成!


一、事情的起因(真实踩坑)

我之前一直在做一个网页项目,但因为业务展示的原因,需要打包成 APP 使用。

在鸿蒙 4.2 的时候,这件事其实非常简单:

  • 找一个安卓 WebView 套壳 APP
  • 用 MT 管理器改一下 URL
  • 直接就能用了

整个流程几乎是“无脑操作”,而且这个方案稳定跑了一年多,没有任何问题


二、问题爆发:升级鸿蒙 NEXT 后直接炸了

直到今年(2026),我换了新手机(Mate80ProMax),系统直接升级到了 鸿蒙 6(HarmonyOS NEXT)

问题就来了。

虽然可以通过“卓易通”兼容运行之前的安卓壳子,但是:

文件上传直接废了

具体表现是:

  • <input type="file"> 还能点
  • 但是:
    • ❌ 不能调用相机拍照
    • ✅ 只能从本地相册选图片

原来是可以选择相机或文件上传的:

在这里插入图片描述

新版点击选图,直接跳转文件页面:

在这里插入图片描述

这对我来说是致命问题,因为我的业务是需要现场拍照上传的。


三、为什么会这样?(踩坑分析)

我后面查了一圈 + 问 AI,大概原因是:

👉 鸿蒙 NEXT 出于隐私安全考虑:

  • 不再允许 WebView 直接调用系统相机
  • H5 的文件选择需要宿主应用手动拦截
  • 再由原生代码去:
    • 调起相机 / 相册
    • 拿到结果
    • 回传给网页

简单说就是:

👉 以前安卓是“自动帮你做”,现在鸿蒙是“你自己写一套流程”

四、我尝试过的几个方案(全踩坑)

方案1:找现成鸿蒙 WebView 套壳

结论:

❌ 没找到能用的

要么:

  • 不支持文件上传回调
  • 要么压根不是鸿蒙 NEXT 原生

方案2:反编译原来的安卓壳子改

思路是:

  • 找 WebView 相关代码
  • 修改文件选择逻辑

问题:

❌ 太麻烦,而且不一定能编译成功

方案3:前端绕过(JS 调相机)

比如:

  • 用 H5 API 直接调用摄像头

问题:

❌ 如果壳子没权限,一样没用

五、为什么必须解决?

有朋友可能会说:

那你用旧手机不就行了?

问题是:

  • 我现在要频繁改网页功能
  • 必须实时验证在 APP 里的效果
  • 总不能天天带两台手机开发吧…

👉 这完全不现实


六、最终决定:自己写一个鸿蒙原生壳

被逼无奈,我直接上手:

✅ 用 ArkTS 写了一个 HarmonyOS NEXT 原生 WebView 套壳应用

于是这个项目就诞生了👇


七、这个项目能做什么?

简单说一句话:

👉 改一个 URL,就能把网页打包成鸿蒙 APP

目前已经做了这些功能:

  • ✅ WebView 全屏加载网页
  • ✅ 支持 JS / DOM Storage / 图片访问
  • ✅ 文件上传支持(相机 + 相册)
  • ✅ 返回键拦截(网页返回 + 双击退出)
  • ✅ 启动页(Splash)
  • ✅ 权限自动申请(相机 / 相册)
  • ✅ 沉浸式体验(隐藏导航条)

八、最关键:文件上传问题已解决 ✅

重点来了:

👉 现在可以正常:

  • 📸 直接拍照上传
  • 🖼️ 相册选择上传

也就是把鸿蒙 NEXT 缺失的那一段:

“WebView → 原生 → 相机 → 回传”

👉 全部补齐了


九、项目地址

👉 GitHub:项目地址

https://github.com/ZhaoYuLiOfficial/HarmonyOS6-WebView-Shell 

👉 Gitee:项目地址

https://gitee.com/ZhaoYuLiOfficial/HarmonyOS6-WebView-Shell 

(如果对你有帮助,欢迎点个 Star ⭐)


十、总结

这次踩坑最大的感受就是:

👉 鸿蒙 NEXT 对安全收得很紧,但开发成本确实上来了

以前安卓一句话能搞定的事情:

现在需要自己补一整套逻辑。

不过好处是:

  • 权限更清晰
  • 行为更可控

🤝 交流 & 反馈

如果你也在做类似的项目,或者遇到类似问题:

  • 欢迎留言交流
  • 也可以提 Issue 一起讨论

本文使用AI生成,大神们轻点喷,大学生第一个开源项目呜呜

Read more

谈谈你对 AI Code Assistant(如 GitHub Copilot)的看法,它如何改变开发者的工作流?

AI Code Assistant深度剖析:从GitHub Copilot看开发者工作流的革命性变革 摘要/引言 开门见山:当AI成为你的编程搭档 想象一个场景:你正专注于解决一个复杂的业务逻辑问题,手指悬停在键盘上,准备编写一个数据处理函数。突然,IDE中弹出几行灰色的代码建议——正是你脑海中即将实现的逻辑,甚至连你没考虑到的边界条件处理都已包含在内。你轻轻按下Tab键,代码瞬间补全,仿佛有一位无形的搭档在你耳边低语:“这样实现如何?”。这不是科幻电影中的场景,而是 millions of 开发者正在经历的日常——AI Code Assistant(人工智能代码助手)已从概念走向现实,深刻重塑着软件开发的 landscape。 作为一名拥有10年+开发经验的工程师,我亲历了从"查手册编程"到"Stack Overflow复制粘贴"再到"AI协同编码"的三次范式转变。2021年GitHub

一文看懂:AI编程工具深度对比:Cursor、Copilot、Trae与Claude Code

一文看懂:AI编程工具深度对比:Cursor、Copilot、Trae与Claude Code

AI编程工具深度对比:Cursor、Copilot、Trae与Claude Code 引言 在人工智能技术蓬勃发展的今天,AI编程工具已成为开发者提高效率的重要助手。从早期的代码补全插件到如今能够理解整个代码库的智能助手,AI编程工具正在不断进化。本文将对当前主流的AI编程工具——Cursor、GitHub Copilot、Trae和Claude Code进行全面对比,帮助开发者选择最适合自己的工具。 主流AI编程工具概述 Cursor Cursor是一款基于VSCode的AI驱动代码编辑器,它最大的特点是能够理解整个代码库的上下文,提供智能的代码补全和重构建议。Cursor默认使用Claude-3.5-Sonnet模型,即使是OpenAI投资的公司,也选择了Claude模型作为默认选项,这足以说明其在代码生成领域的优势。 GitHub Copilot GitHub Copilot是由GitHub与OpenAI合作开发的AI编码助手,集成在VSCode、Visual Studio等主流编辑器中。它基于OpenAI的模型,能够根据注释和上下文自动生成代码,是AI编程工具

5分钟部署麦橘超然Flux,低显存设备也能玩转AI绘画

5分钟部署麦橘超然Flux,低显存设备也能玩转AI绘画 1. 为什么你值得花5分钟试试这个Flux控制台 你是不是也遇到过这些情况: * 想试试最新的Flux模型,但显卡只有8GB甚至6GB,一加载就报“CUDA out of memory”; * 下载完模型还要手动配置路径、改代码、调参数,折腾两小时还没看到一张图; * 网页版用着方便,但担心隐私泄露、生成被限速、图片被缓存; 别再纠结了——麦橘超然 - Flux 离线图像生成控制台,就是为这类真实场景而生的。它不是又一个需要编译、调参、查文档的实验项目,而是一个开箱即用的本地Web服务:模型已打包进镜像,float8量化技术让DiT主干网络显存占用直降近一半,Gradio界面简洁到连提示词输入框都标好了占位符,连SSH隧道怎么转发都给你写好了命令。 更重要的是,它真的能在你的旧笔记本、远程小内存服务器、甚至实验室里那台只配了RTX 3060的工位机上跑起来。本文不讲原理推导,不堆术语,就带你从零开始,5分钟内完成部署、打开浏览器、输入第一句描述、亲眼看到AI画出赛博朋克雨夜街道——所有操作一步接一步,复制粘贴就能

2026年用豆包降维普AIGC查重率的正确姿势(附完整指令)

2026年用豆包降维普AIGC查重率的正确姿势(附完整指令)

我用豆包改了3天论文,AIGC率从61%只降到了43% 考虑用豆包降维普AIGC的同学,先听我说完这个教训。 上个月我的论文维普AIGC检测结果61.4%,学校要求20%以下。我第一反应就是用豆包来改写,毕竟免费嘛。于是我把论文分成十几段,一段一段喂给豆包,让它“用更自然的方式重新表述”。改了整整3天,信心满满再测一次:43.2%。降了18个百分点,离达标还差23个百分点。 后来我才搞明白,不是豆包不行,是我的用法有问题。直接让AI改AI写的内容,改出来的还是AI风格。就好比让一个说普通话的人模仿方言,怎么模仿都带着普通话味儿。 这篇文章就把我后来摸索出来的正确用法整理出来。附上完整的指令模板,直接复制就能用。 为什么直接让豆包改写效果差 先搞清楚问题出在哪。豆包本身也是一个大语言模型,它生成的文本天然就带有AI的统计特征。你让它“重新表述”一段话,它输出的内容在词汇选择、句式结构、过渡方式上跟原文风格高度一致。维普检测引擎看的就是这些统计特征,所以改来改去AIGC率降不下去。 我做过一个对比实验。同一段500字的AI生成文本,分别用三种方式处理: 第一种,直接让豆包