抱着美好未来，转转hybrid app web静态资源离线系统实践
2024-02-07 05:52:21
前言痛点
现今本团队内的端内web应用，均是由webpack构建打包而成的单页或多页web应用，前端工程构建完成的结果是这样的画风：
{
"js": [
"./dist/bundle1.js",
"./dist/bundle2.js",
"./dist/bundle3.js",
"./dist/bundle4.js",
],
"css": [
"./dist/style1.css",
"./dist/style2.css",
"./dist/style3.css"
],
"image": [
"./dist/image1.png",
"./dist/image2.png",
"./dist/image3.png"
]
}
可以看出其静态资源中，不乏体积几百k~几m不等，而这些静态资源均是通过网络进行加载的，一旦网络较差或无网络环境，则会出现难以想象的loading效果。
再者，端内web应用的大小(体积)动辄几十m上百m，也会让人叹为观止，导致安装转化率与活跃使用情况大打折扣。
以下罗列了我们面临的一些痛点问题：
- 加载慢，hybrid web App所依赖的资源，都会通过网络来加载。一旦网络不佳，加载体验就比较差。
- 浪费流量，每次请求资源时都会浪费流量。
- 安装包过大，hybrid app体积会很大，影响用户下载安装和卸载安装体验。
- hybrid app安装卸载导致资源重新下载，这就意味着用户只要重新安装一次hybrid app，可能就会重新下载一遍资源，无论是多安装还是卸载都会影响用户体验。
离线方案
1. 方案一
直接将全部的文件打包进apk中，这样用户只要安装了一次应用，便可以不再下载资源了，但是该方案的弊端很明显，一旦资源有所更新，用户只能通过重新安装应用来获取，那么app安装卸载频繁的用户将会收到极大的影响。
2. 方案二
将web资源打包成h5 hybrid App，如react native、flutter，并且通过本地存储机制实现资源离线存储，但是该方案对于有抽屉导航的应用难以满足要求，尤其是更新有资源时，经常出现无法替换资源的问题，且开发和维护成本较方案三更高。
3. 方案三
实现一个独立于App的资源离线存储平台，优点是：
- 资源有更新可以随时推送给客户端，不会出现无法替换资源的问题。
- 客户端可以通过异步请求拉取资源，开发和维护成本较方案二更低。
遇到的问题
1. 资源版本管理问题
资源更新后，服务器需要通知客户端更新，但更新的资源版本如何保证在用户的所有设备上都生效呢？客户端只有在从服务端拉取资源时才能知道，但是客户端如何知道需要更新呢？
解决方案：我们为每一个资源指定一个版本号，通过对比资源版本号是否最新来决定是否替换本地资源。
2. 资源的兼容性问题
客户端可以运行在不同的设备上，而不同的设备可能拥有不同的屏幕分辨率和操作系统版本，如何确保资源在所有设备上都能够正常显示和使用呢？
解决方案：我们在打包资源时，会对资源进行适当的处理，以确保其能够在所有设备上正常显示和使用。
3. 资源的安全性问题
资源离线存储在客户端设备上，如何防止被他人窃取和篡改呢？
解决方案：我们对资源进行了加密处理，以确保其安全性。
4. 资源的更新问题
资源更新后，如何确保客户端能够及时获取更新的资源呢？
解决方案：我们实现了资源更新机制，当资源有更新时，服务器会通知客户端更新，客户端可以通过异步请求拉取更新的资源。
未来展望
未来，我们将继续优化资源离线存储平台，使之更加稳定、高效和安全。我们还将探索新的资源更新机制，以确保客户端能够更加及时地获取更新的资源。
结语
资源离线存储平台的建设，使我们的web资源可以离线存储在客户端设备上，从而解决了加载慢、浪费流量、安装包过大、hybrid app安装卸载导致资源重新下载等问题。
