HiYngaの随记

先说一下为什么最后不是只停在 PWA#

我一开始的方向，其实并不是直接去看 PakePlus。

而是先回到博客本身，把 PWA 这一层补齐。

因为从工程角度看，PWA 本来就是最贴近现有静态博客体系的一条路。

• 不需要重做内容系统
• 不需要单独维护一套移动端前端
• 不需要引入原生开发链路
• 对现有 Astro 站点改动也相对可控

这条路我自己当然还是认可的。
而且站点本身做了 PWA 之后，基础体验也确实会更完整。

但问题也恰恰在这里。

PWA 这套东西更像是一个能力层，不是一个结果层。

也就是说，站点具备了 PWA 能力，并不等于用户最后就一定能很稳定、很顺手地把它当成一个桌面应用来用。

安装入口要不要弹。
用户能不能找到这个入口。
不同环境下安装后的表现稳不稳。
是不是所有人都愿意走这条路径。

这些其实都不完全由我控制。

所以我最后没有停在“站点已经支持 PWA”这个状态。

我更想把结果再往前推一步。

让它真正变成一个用户在手机桌面上可以直接点击进入的博客入口。

在博客里补的这层 PWA，解决的到底是什么#

先说清楚一点。

我这次不是绕开 PWA，而是先把 PWA 做了，再决定继续往前补一个壳方案。

因为这两层解决的问题不一样。

PWA 这一层，主要解决的是站点本身的安装态能力。

• manifest.webmanifest
• 图标资源
• 独立启动模式
• 一定程度的缓存和更新策略
• 更接近应用形态的浏览器访问体验

这些东西都很有价值。
而且对 Astro 这种站点来说，也很适合先做。

我自己在这边补的配置，核心也差不多就是这些方向。

• manifest
• apple-touch-icon
• icon-192 / icon-512
• display: standalone
• start_url
• scope
• theme_color
• background_color
• registerType: autoUpdate

另外缓存策略我也单独收了一遍。
页面导航走 NetworkFirst，脚本样式这些资源走 StaleWhileRevalidate，字体和图片再按各自场景做缓存。

这一层的意义不是让我把博客做成彻底离线的应用。
而是让它先具备一个现代安装态网站该有的样子。

但我自己最后还是觉得，这还不够。

因为它还没有真正解决“用户怎么更方便地在手机桌面进入我的博客”这个问题。

所以又补了一层 PakePlus 的桌面壳策略#

后面我继续看方案的时候，思路就越来越清晰了。

我不需要原生客户端。

我也不想再维护第二套前端。

我需要的只是一个非常轻的壳。

这个壳做几件事就够了。

• 有独立图标
• 有独立名称
• 可以直接放手机桌面
• 点开后就是我的博客
• 入口尽量简单，不再依赖用户自己理解浏览器安装逻辑

这时候 PakePlus 反而就挺合适。

因为它并不是让我把博客内容重新塞进一个复杂客户端。

它更像是在现有在线站点外面包一层应用外壳。

这正好符合我现在这个博客的情况。

• 博客本身已经响应式
• 手机浏览器里已经能正常看
• 我不想改内容结构
• 我不想新增第二套维护体系

所以最后就变成了一条很务实的路径。

先把站点该有的 PWA 能力补齐。
再用 PakePlus 直接把线上博客地址打成桌面壳 APP。

这样做完之后，浏览器访问和桌面访问这两条线就都具备了。

用户如果愿意走 PWA，可以走。
如果不想折腾安装过程，直接装我打好的壳 APP 也行。

怎么跟网站更新配合#

这里我觉得也是最值得说明白的一点。

很多人一看到 APK，第一反应就是。

那以后我每次发文章，是不是都得重新打一次包。

其实不是。

因为我这次走的不是“把博客静态文件内置进 APK”的离线方案。
我走的是“直接把线上网址作为应用入口”的壳方案。

也就是说，这个 APP 包里真正固定下来的东西，主要是这些。

1
APP 壳
2
  -> 图标
3
  -> 名称
4
  -> 包名
5
  -> 启动配置
6
  -> 入口网址 https://ynga.kingcola-icg.cn

真正承载博客内容的，还是我线上的这个站。

所以内容同步逻辑其实很简单。

1
我改博客源码
2
-> git push
3
-> 线上站点重新部署
4
-> https://ynga.kingcola-icg.cn 内容更新
5
-> 手机里的壳 APP 再次打开时访问的还是这个网址
6
-> 用户看到的自然就是新内容

所以你更新的不是 APK，你更新的是网站本身。
壳 APP 只是换了一种更直接的访问方式。

什么时候才需要重新打包 APK#

只有壳层配置变了的时候。

比如这些情况。

• 改 APP 图标
• 改 APP 名称
• 改包名 App ID
• 改启动页
• 改权限
• 改壳层里一些交互配置

这种变化不属于博客内容更新。

它属于应用包本身配置变化。

这时候才需要重新 Publish 一次，重新生成新的 APK。

但如果你只是：

• 发新文章
• 改样式
• 调整页面结构
• 改 SEO
• 更新图片

这些都还是网站层面的事情。

网站部署完，壳 APP 再次打开看到的就是新的。

这也是我觉得这条路特别适合个人博客的原因。

因为你不会为了“多一个手机入口”，把内容维护成本整体抬上去。

具体怎么做的#

过程其实没有想象中复杂。

先准备 GitHub Token，然后在 PakePlus 里做云端打包。

我最后走的是 classic token 那条路。
权限只用了三项。

• repo
• workflow
• user

然后在 PakePlus 里把基础配置填掉。

• App Name
• Website URL
• App ID
• Version
• Icon

这里我最关键的一个选择，就是 Website URL 直接填线上博客地址。

也就是：

https://ynga.kingcola-icg.cn

而不是传本地构建出来的 dist。

因为一旦你传的是本地静态产物，后面每次网站内容更新，逻辑就会往“重新打包应用”那边走。
但如果你直接填线上网址，博客内容更新就完全回到了原来这套自动部署链路里。

这对我来说才是最省事的。

所以从操作层面看，整个过程其实并没有那么“工程化”。

更像是给一套已经在线、已经能正常工作的博客，再补一个更稳定的桌面入口。

适合什么样的网站#

我觉得特别适合下面这类项目。

• 本身已经是响应式网站
• 手机浏览器里体验已经不错
• 主要诉求是手机桌面入口
• 内容更新频繁，但不想每次重打包
• 不想维护第二套前端

如果你现在手里是一个 Astro 博客、一个静态文档站、一个个人作品集，甚至一个轻量工具站，只要它本身在手机浏览器里已经能正常用，这条路通常都很顺。

但如果你一开始的目标就是。

• 要上正式应用商店
• 要深度原生能力
• 要复杂通知、推送、后台任务
• 要做完全脱离网页的客户端体验

那这条路就不是终局。

那种场景还是得往 Capacitor、原生应用、或者更完整的移动端方案上走。

所以我对 PakePlus 的定位很明确。

它不是让我把博客变成真正意义上的原生客户端。

它是让我在“几乎不改现有网站结构”的前提下，再补一个手机桌面壳方案。

这个价值已经很够了。

看清现实边界#

比如安卓这边，APK 私下分发和自己安装都不难。
拿到安装包，打开未知来源安装权限，装上就行。

但它毕竟不是应用商店分发逻辑。
所以你也要接受，这个入口更适合个人使用、朋友体验、小范围分享，而不是按正规商店产品那种方式去理解。

另外这类壳 APP 最容易让人误解的一点，就是把“内容同步”和“安装包更新”混成一件事。

它们其实完全不是一回事。

内容同步，靠的是你网站本身更新。

安装包更新，靠的是你重新打壳。

把这两件事分开想，整条链路就会很清楚。

我后面如果只是正常写文章，正常改页面，那我还是继续按现在这套：

本地改 -> git push -> 自动部署

手机里的壳 APP 打开就能跟着看到新的内容。

如果哪天我想换图标、换名称、换包名，再重新发一个新的 APK 就行。

安卓端下载#

我这边目前已经放了安卓端安装包，仅限个人使用体验。
如果你只是想直接在手机桌面装一个能打开我这个博客的壳 APP，可以直接下载这个 APK。

苹果端这边我现在还没有提供可直接下载的安装包，所以目前先只有安卓端可以直接下载安装来看。

最后整理一下链接#

如果你也想照着这条路自己跑一遍，可以参考下面这些链接。

• PakePlus 官方站：https://pakeplus.com/zh/
• PakePlus 下载页：https://pakeplus.com/download
• GitHub Token 获取说明：https://pakeplus.com/zh/guide/token
• 创建项目：https://pakeplus.com/guide/creat
• 基础配置：https://pakeplus.com/guide/config
• 手机端配置：https://www.pakeplus.com/guide/phone
• 自定义打包：https://pakeplus.com/guide/custompack
• Token 无效排查：https://www.pakeplus.com/question/invalid
• APK / IPA 安装说明：https://pakeplus.com/question/phone
• PakePlus GitHub 仓库：https://github.com/Sjj1024/PakePlus
• PakePlus-Android 仓库：https://github.com/Sjj1024/PakePlus-Android

结语：没有破坏原来的博客维护方式#

这一点我自己还挺在意的。

因为很多看上去“功能更完整”的方案，最后真正把人拖住的，往往不是功能本身。

而是它多出来的维护负担。

我现在这套博客，最舒服的地方一直都是简单。

• Markdown 写文章
• Astro 出站点
• git push 做部署

我这次加的 PWA 和 PakePlus 壳方案，最后也尽量保持了这个方向。

不是为了把简单的东西重新做复杂。

而是在尽量不增加新负担的前提下，把它在手机端变得再顺手一点。

能浏览器里看。

也能方便直接从手机桌面点开。