企业官网建设流程全解析

目录

lw.Web2Android

一、lw.Web2Android 是什么？

二、为什么还要做一个 Web → APK 工具？

三、lw.Web2Android 的思路不太一样

四、实际使用有多简单？

生成 Android APK

五、它不是简单地把网页塞进 file://

六、企业内网项目也考虑到了

七、还有一个经常被忽略的问题：APK 签名

Package Name → Signing Identity

八、生成的不仅仅是一个 APK

九、和 Capacitor、Cordova、PWABuilder 有什么区别？

你的项目到底需要什么？

十、什么时候应该选 Capacitor？

推荐 Capacitor。

十一、什么时候适合 PWABuilder / Bubblewrap？

PWA

PWABuilder / Bubblewrap 非常合适。

十二、什么时候适合 lw.Web2Android？

给我一个 APK。

十三、它尤其适合这些项目

1. 企业内部系统

2. Android 工业平板

3. 展示类 App

4. 前端 Demo 快速交付

十四、为什么没有做 Native Bridge？

暂时不想做。

Small. Native. Focused.

十五、真正想解决的问题只有一个

Web → APK Packer

十六、项目目前仍然很年轻

十七、写在最后

lw.Web2Android

Web → APK

下载

不装 Android Studio，也能把 Vue / React 一键打成 APK：开源工具 lw.Web2Android

做 Web 开发的人，大概都遇到过这样的需求：

一个已经写好的 HTML、Vue、React 或 Vite 项目，客户突然说：

“能不能顺便给我打一个 Android APK？”

如果只是把现有网页放到 Android 里运行，这件事听起来似乎很简单。

但真正开始做，你很快就会发现事情变成了：

Android Studio、SDK、JDK、Gradle、Manifest、签名证书、zipalign、apksigner……

原本只是想：

把网页变成 APK。

最后却不得不搭建一整套 Android 开发环境。

于是，我做了一个小工具：

lw.Web2Android

一个专门解决Web → Android APK这件事的轻量级开源工具。

它的目标很简单：

不做 Android Studio 的替代品，不做跨平台大框架，也不试图把 Web 变成“原生 Android”。

只把“一个已经完成的 Web 项目，可靠地打成 APK”这件事做好。

一、lw.Web2Android 是什么？

lw.Web2Android 可以将：

• 普通 HTML / CSS / JavaScript 项目

• Vue

• React

• Vite 构建后的静态目录

• 其他前端框架生成的静态 Web

• 已经部署好的在线网址

直接打包成一个可以安装的 Android APK。

目前提供 Windows 10/11 x64 原生 GUI 和 CLI。

最重要的是：

最终用户不需要安装 Android Studio，不需要自己安装 Gradle，也不需要配置完整 Android SDK 和完整 JDK。

首次使用时，在 GUI 中初始化一次最小工具链即可。程序会在用户接受 Android SDK License 后，从官方源下载锁定版本的必要组件，以后直接复用。(GitHub)

截至 2026 年 8 月 18 日，当前公开版本为v0.2.3。GitHub Releases 已提供 Windows x64 发行包。(GitHub)

二、为什么还要做一个 Web → APK 工具？

其实类似的技术并不少。

我们已经有：

Android Studio、Cordova、Capacitor、PWABuilder、Bubblewrap……

这些项目都很成熟。

问题在于：

它们解决的问题，并不完全等于“我只想把一个网页打成 APK”。

比如 Capacitor，本身定位就是一个 Web 与原生平台融合的运行时。它可以让 JavaScript 调用 Java/Kotlin 原生能力，还有丰富的插件体系。

这非常强大。

但相应地，它的 Android App 也是一个标准 Android 工程。Capacitor 官方文档明确说明，Android 应用通过 Android Studio 配置和管理。通常需要：

npm install @capacitor/android npx cap add android npx cap open android

随后进入 Android Studio 继续管理 Android 项目。(Capacitor)

如果你的目标是：

摄像头、蓝牙、定位、推送、原生插件、深度系统集成……

Capacitor 非常合适。

但如果你的需求只是：

“这是我的 Vue dist，帮我生成一个 APK。”

那么整套 Android Project 对一些用户来说就显得有些重了。

三、lw.Web2Android 的思路不太一样

lw.Web2Android 没有在每次打包时重新创建一个 Android Gradle 工程，然后：

Java/Kotlin ↓ Gradle ↓ Android Gradle Plugin ↓ DEX ↓ APK

而是提前准备一个非常小的 Android Runtime。

Runtime 编译完成后直接保存为预编译的：

classes.dex

真正打包用户项目的时候，流水线变成：

Manifest + res ↓ AAPT2 ↓ resources.apk ↓ Web Assets + 配置文件 + 预编译 classes.dex ↓ APK Assembler ↓ zipalign ↓ apksigner ↓ Signed APK

也就是说：

每次生成 APK，不需要重新编译 Android Java Runtime。

Web 项目本身也不会交给 Gradle。

这是 lw.Web2Android 和很多传统 Hybrid App 构建方案在设计思想上的一个明显区别。(GitHub)

四、实际使用有多简单？

以一个 Vite 项目为例。

首先：

npm run build

得到：

dist/

然后打开：

lw.Web2Android.GUI.exe

选择：

本地网页

然后填写：

应用名称 Package Name Version Name Version Code

再选择：

dist/

点击：

生成 Android APK

即可。

GUI 目前还提供：

• 横屏 / 竖屏 / 自动方向

• 全屏

• 本地网页

• 在线网址

• HTTP 内网支持

• 输出目录

• 后台构建

完整流程就是：

Web 项目 ↓ 前端 build ↓ 选择 dist ↓ 填写应用信息 ↓ 生成 APK

项目 README 中给出的 GUI 流程也是 5 个主要步骤。(GitHub)

五、它不是简单地把网页塞进 file://

这一点是我在设计时比较在意的。

有些最简单的 WebView 套壳程序会直接：

file:///android_asset/index.html

加载网页。

lw.Web2Android 没有采用这种方式。

本地页面通过 AndroidXWebViewAssetLoader加载，页面拥有类似：

https://appassets.androidplatform.net

这样的 HTTPS 风格 Origin。

因此本地 Web 仍然尽量按照正常浏览器的：

• Origin

• CORS

• Cookie

• HTTP / HTTPS

规则运行。

同时，lw.Web2Android 当前不提供addJavascriptInterfaceNative Bridge来绕过浏览器安全边界。(GitHub)

这也是项目目前很重要的原则：

Web 就尽量按照 Web 的规则运行。

而不是不断给网页增加几十个私有 Native API。

六、企业内网项目也考虑到了

还有一种很常见的场景：

前端是 Vue：

Vue / React

后台则可能是：

Spring Boot ASP.NET Django FastAPI Node.js

服务器就在公司局域网。

例如：

http://192.168.x.x:9000

这种场景在工控、MES、仓储、设备管理、内部 OA 中其实非常普遍。

lw.Web2Android 提供：

允许 HTTP（仅建议可信内网）

模式。

既可以直接打开一个内网 URL，也可以把 Vue 的dist放进 APK，再访问内网 API。

当然，在正式互联网环境中仍然建议优先使用 HTTPS；项目文档也明确提示，HTTP 流量可能被同网络设备监听或篡改。(GitHub)

七、还有一个经常被忽略的问题：APK 签名

很多“网页转 APK”Demo 第一次生成 APK 很简单。

真正麻烦的是第二次。

Android 应用升级要求：

Package Name 相同 + 签名身份一致

如果第一次 APK 使用证书 A：

com.example.app Certificate A

第二次却变成：

com.example.app Certificate B

那么新的 APK 就无法正常覆盖安装旧版本。

所以 lw.Web2Android 没有每次随机生成一个新的证书。

而是按照：

Package Name → Signing Identity

保存签名身份。

例如：

com.example.demo

第一次生成 APK 时建立签名身份。

以后：

1.0.0 1.1.0 1.2.0 2.0.0

只要 Package Name 不变，就继续复用同一个证书。

这样才是一个真正可以长期维护的 Android App。

当前实现使用 RSA 3072 签名身份，在 Windows 本地通过 DPAPI 保护私钥，同时支持导出密码保护的 PFX/P12 做离线备份。(GitHub)

这件事情看起来不像“一键打包”那么吸引眼球，

但如果真的拿它做长期项目，我认为：

签名身份管理比再增加十个按钮更重要。

八、生成的不仅仅是一个 APK

一次成功构建后，除了：

MyApp-1.0.0-android.apk

还会生成：

APK.sha256 *.release.json *-RELEASE.md

分别用于：

• 文件完整性校验

• 机器可读发行信息

• 人类可读发行记录

项目自身的 Windows Release 同样提供 SHA256SUMS。

这意味着这个工具的目标并不是：

“能生成 APK 就行。”

而是希望逐渐把：

Build → Sign → Verify → Release

这条链路做好。(GitHub)

九、和 Capacitor、Cordova、PWABuilder 有什么区别？

这里需要说明：

lw.Web2Android 并不是要替代它们。

这些项目解决的是不同问题。

简单做一个对比：

Capacitor 官方说明其 Android App 通过 Android Studio 管理，并支持 JavaScript 与 Java/Kotlin 原生代码通信。(Capacitor)

Cordova 当前 Android 文档则列出了 Android SDK、JDK、Gradle 等构建要求，其 Android 项目使用 Gradle 构建。(Apache Cordova)

Bubblewrap 采用 Trusted Web Activity 技术，把 PWA 运行在支持 TWA 的浏览器环境中；网站所有权通常通过 Digital Asset Links 验证。如果验证失败，会退回 Custom Tab。(Chrome for Developers)

PWABuilder 的 Android 打包底层也使用 Bubblewrap/TWA，并且更偏向“把一个已有 PWA 发布到 Android 应用商店”的场景。(PWA Builder Blog)

因此它们之间并不存在简单的“谁更好”。

真正应该问的是：

你的项目到底需要什么？

十、什么时候应该选 Capacitor？

如果你的应用需要：

蓝牙 GPS 摄像头深度控制 推送通知 原生文件系统 Native SDK 支付 SDK 大量 Android API

那么：

推荐 Capacitor。

因为这些本来就是它的优势。

十一、什么时候适合 PWABuilder / Bubblewrap？

如果你已经有一个完善的：

PWA

并且网站已经：

• 部署在线

• 配置 Web App Manifest

• 配置 Service Worker

• 拥有自己的域名

• 希望通过 TWA 发布到 Google Play

那么：

PWABuilder / Bubblewrap 非常合适。

TWA 本身就是为了让 PWA 在 Android 中获得接近独立应用的体验而设计的。(Chrome for Developers)

十二、什么时候适合 lw.Web2Android？

如果你的需求是：

我已经有一个 Vue 项目。

或者：

我已经有一个 React 项目。

或者：

我有一个内部管理系统。

甚至只是：

我有一个 index.html。

然后你希望：

给我一个 APK。

而且：

我不想为了这件事安装 Android Studio。

那么这正是 lw.Web2Android 想解决的场景。

十三、它尤其适合这些项目

我认为下面几类需求会比较适合：

1. 企业内部系统

例如：

MES WMS 设备管理 生产看板 仓库管理 内部 OA 数据采集

本来就是 Web 系统，只是希望员工手机或 Android 平板以 App 形式启动。

2. Android 工业平板

很多工业项目最终运行在：

10 寸 Android 平板 工业 PDA 手持终端 触摸屏

前端其实完全可以使用 Vue / React 开发。

如果不需要大量 Android 原生能力，就没有必要把整个团队拖进 Android 开发体系。

3. 展示类 App

例如：

产品展示 电子手册 离线说明书 展厅终端 教育课件 交互 Demo

静态资源直接打入 APK 即可。

4. 前端 Demo 快速交付

有时一个 Web Demo 已经开发完成。

客户只说一句：

“给我一个 APK，我装到手机看看。”

这可能就是 lw.Web2Android 最典型的使用场景。

十四、为什么没有做 Native Bridge？

有人可能会问：

为什么不加 JS 调 Android？

为什么不加几十个插件？

为什么不支持蓝牙、定位、扫码、NFC、推送？

不是不能做。

而是：

暂时不想做。

因为一旦开始增加这些能力：

Camera Bridge Bluetooth Bridge GPS Bridge File Bridge Notification Bridge Native Plugin System

项目很快就会变成另一个 Hybrid App Framework。

而 Capacitor、Cordova 已经在这个方向积累了多年。

再做一套意义并不大。

所以 lw.Web2Android 目前更愿意坚持：

Small. Native. Focused.

小。

原生。

专注。

十五、真正想解决的问题只有一个

Web 技术今天已经足够强大。

很多管理系统、工具软件、内部平台甚至工业软件，其 UI 本来就是：

HTML CSS JavaScript Vue React

问题并不一定是：

“怎么重新写一个 Android App？”

而可能只是：

“怎么把我已经写好的东西，以 Android App 的形式交付？”

lw.Web2Android 就是在尝试回答这个问题。

它不是新的前端框架。

不是新的 Android 框架。

也不是 Android Studio。

甚至严格来说，它都不想成为一个“大工具”。

它只是一个：

Web → APK Packer

选择网页。

填写应用信息。

点击生成。

得到 APK。

事情到这里结束。

十六、项目目前仍然很年轻

需要强调的是：

lw.Web2Android 目前仍处在0.x 阶段。

当前版本是 v0.2.3。(GitHub)

现在已经完成的核心能力包括：

• 本地 Web → APK

• 在线 URL → APK

• Windows 原生 GUI

• CLI

• 最小 Android 工具链初始化

• 预编译 Android Runtime

• APK 资源组装

• zipalign

• apksigner

• Package Name 签名身份复用

• PFX/P12 密钥备份

• SHA256

• Release Metadata

• 构建日志

• Runtime 日志

• React/Vite 真实项目 CI 验证

项目 CI 还会实际构建真实 React/Vite 项目，并继续验证 APK 的签名、对齐、内部资源、Runtime 入口和签名身份复用，而不仅仅检查 C++ 是否能够编译。(GitHub)

后续还有很多细节值得继续完善。

但我的目标不会是：

功能越来越多。

而是：

功能保持克制，但现有功能越来越可靠。

十七、写在最后

我越来越觉得：

软件并不一定功能越多越好。

有时候真正好用的工具，反而应该有明确边界。

lw.Web2Android 的边界就是：

你负责把 Web 做好。

剩下的 APK 打包、Android Runtime、资源组装、签名和发行，让工具处理。

如果未来它最终能够做到：

下载 ↓ 解压 ↓ 选择 Web ↓ 点击生成 ↓ 得到 APK

同时保持：

稳定 轻量 可重复 可升级 可验证

那我认为它就已经完成自己的使命了。

如果你正好有一个：

HTML / Vue / React / Vite 项目，

又正好需要：

Android APK，

可以试试：

lw.Web2Android

GitHub 项目：

https://github.com/lxw112190/lw.Web2Android

欢迎 Star、Issue，也欢迎实际项目测试和反馈。

如果你发现某个真实 Web 项目打包后运行异常，也非常欢迎提交最小复现。

比起继续增加几十个功能，

我现在更希望把：

Web → APK

这一件小事，

认真做好。

下载

完整发布包下载