Mather 最近的时间轴更新 Mather 最近的时间轴更新 |
MatherV2EX 第 176453 号会员，加入于 2016-06-08 01:56:47 +08:00 |
Mather 最近回复了
2022-11-25 12:57:37 +08:00 回复了 karott7 创建的主题 › 程序员 › 做 App + H5 混合应用的请进，想听听看看 |
@july1995
Android 的 webview 实现，使用腾讯浏览服务（ X5 内核），有专门的 TBS Studio 工具能帮助开发者分析和优化网页的设计，主要功能有网页 Inspector 调试，网页性能分析等。
iOS 端在打包 APP 时候，开启调试模式，使用 Mac Safari 进行联机调试，具体可百度搜索“safari 调试 webview”。
--------------------------
参考资料
腾讯浏览服务： https://x5.tencent.com/
TBS Studio： https://x5.tencent.com/tbs/guide/debug/season1.html
Android 的 webview 实现，使用腾讯浏览服务（ X5 内核），有专门的 TBS Studio 工具能帮助开发者分析和优化网页的设计，主要功能有网页 Inspector 调试，网页性能分析等。
iOS 端在打包 APP 时候，开启调试模式，使用 Mac Safari 进行联机调试，具体可百度搜索“safari 调试 webview”。
--------------------------
参考资料
腾讯浏览服务： https://x5.tencent.com/
TBS Studio： https://x5.tencent.com/tbs/guide/debug/season1.html
2022-11-25 12:11:39 +08:00 回复了 karott7 创建的主题 › 程序员 › 做 App + H5 混合应用的请进，想听听看看 |
利益相关，暂不能透露具体是哪款 APP 。
先说说背景：
项目因为原生实现某种功能难度较大，加上投入、历史遗留等其他因素限制，选择了“App + H5 ”混合应用的混合式方案对 APP 中的业务实现进行改造升级。改造项目进行时，对这个主题做了思考。
项目经过两年的几次迭代，分别试过楼主所说的两种方案：
• “webview + http 缓存”
• “离线包”
上面两种方案，我们在日活跃 5k 左右的项目上实验了两年左右。
最后因为“内容可控”和要“快速修改”的要求，和面对“网络劫持”的问题，选择了“离线包”方案。
---------------------------------------------
在项目完成后，我对方案做了技术总结，分析了它们的优劣：
• 在线服务，“webview + http 缓存” 方案
项目研发时，我们不约而同地想到在线服务的加载形式，即客户端使用域名的形式访问提供加载资源的 HTTP 服务器。
在线服务与 Web 应用程序别无二致，使得我们有更多的时间投入到设计应用生命周期和程序 API 中去。
可是随着项目上线若干个月，在线服务存在的缺陷便暴露出来：
- 没有预加载：首次打开的体验很差，所有文件都要从网络请求
- 缓存不可控：缓存的大小和策略由系统 webview 控制。缓存的清理逻辑不可控，往往加-载缓存几张图片后，重要的 HTML/JS/CSS 缓存就被清除了
- 网络劫持：页面被运营商或其他第三方劫持，将长时间缓存劫持的页面，导致整个功能失效
• 离线加载，楼主的“离线包”方案
离线加载方式能较好的解决在线服务存在的若干问题。
离线加载方式把功能模块的页面和资源打包在客户端中，Webview 组件加载本地资源文件，避免了联网因素的产生。 亦可将页面文件压缩成离线包，在自定义时机把离线包下载下来，做解压、校验等工作，达到在线更新 /热更新的效果。
- 离线包：前端项目构建产出的文件打包成 zip 格式，并以 ${project}_${date}_${verison}.zip 命名方式交付至客户端，存放在 App 项目内作为资源引用，称为离线包。
- 下载包：与离线包的产出相似，下载包定义为某个离线包的迭代版本，文件将存放于服务器或 CDN 上，便于客户端需要时下载。
---------------------------------------------
总的来说选哪个方案，考虑方案的优劣，最终要从投入产出比来考虑，以及面向立项中主要问题出发，才能解决实际问题。
从生产中解放出来，陪陪你爱的人，做些美好的事情。
先说说背景：
项目因为原生实现某种功能难度较大，加上投入、历史遗留等其他因素限制，选择了“App + H5 ”混合应用的混合式方案对 APP 中的业务实现进行改造升级。改造项目进行时，对这个主题做了思考。
项目经过两年的几次迭代，分别试过楼主所说的两种方案：
• “webview + http 缓存”
• “离线包”
上面两种方案，我们在日活跃 5k 左右的项目上实验了两年左右。
最后因为“内容可控”和要“快速修改”的要求，和面对“网络劫持”的问题，选择了“离线包”方案。
---------------------------------------------
在项目完成后，我对方案做了技术总结，分析了它们的优劣：
• 在线服务，“webview + http 缓存” 方案
项目研发时，我们不约而同地想到在线服务的加载形式，即客户端使用域名的形式访问提供加载资源的 HTTP 服务器。
在线服务与 Web 应用程序别无二致，使得我们有更多的时间投入到设计应用生命周期和程序 API 中去。
可是随着项目上线若干个月，在线服务存在的缺陷便暴露出来：
- 没有预加载：首次打开的体验很差，所有文件都要从网络请求
- 缓存不可控：缓存的大小和策略由系统 webview 控制。缓存的清理逻辑不可控，往往加-载缓存几张图片后，重要的 HTML/JS/CSS 缓存就被清除了
- 网络劫持：页面被运营商或其他第三方劫持，将长时间缓存劫持的页面，导致整个功能失效
• 离线加载，楼主的“离线包”方案
离线加载方式能较好的解决在线服务存在的若干问题。
离线加载方式把功能模块的页面和资源打包在客户端中，Webview 组件加载本地资源文件，避免了联网因素的产生。 亦可将页面文件压缩成离线包，在自定义时机把离线包下载下来，做解压、校验等工作，达到在线更新 /热更新的效果。
- 离线包：前端项目构建产出的文件打包成 zip 格式，并以 ${project}_${date}_${verison}.zip 命名方式交付至客户端，存放在 App 项目内作为资源引用，称为离线包。
- 下载包：与离线包的产出相似，下载包定义为某个离线包的迭代版本，文件将存放于服务器或 CDN 上，便于客户端需要时下载。
---------------------------------------------
总的来说选哪个方案，考虑方案的优劣，最终要从投入产出比来考虑，以及面向立项中主要问题出发，才能解决实际问题。
从生产中解放出来，陪陪你爱的人，做些美好的事情。
Select Language