我们的APP部分页面是远程加载的。
为了节约流量，我们希望通过html5的MANIFEST来实现页面的缓存和更新。
在PC浏览器上可以正确缓存和更新。在APP上确不行。
请问在APP上是否需要做额外的处理？
有没有这样的案例呢？
独自沉醉
- 发布：2015-08-19 10:00
- 更新：2015-08-20 16:55
- 阅读：3207
13 个回复
独自沉醉 (作者)
html缓存的最终的意义在于，实现服务器端更新，
就像当年B/S模式取代C/S模式一样。
我们也一直在寻找好的方案。PC端不存在流量限制。
但是手机不一样，传统的B/S模式太费流量了。
如果html5+能够优雅的实现缓存+动态更新，解决手机端流量问题。
html5主体页面和资源通过MANIFEST实现缓存+动态更新，内容则通过json动态获取。
那就太完美了。
当然，我认为目前的MANIFEST方案其实是不完美的。
因为，MANIFEST文件一旦更新。
所有缓存页面都要更新一次，但实际上服务器端可能只更新了一个页面或者资源。
如果能在MANIFEST文件中每条记录后面增加一个版本号，只更新版本号变更的页面或者资源。
才是真正的完美。
（当然，这是后话了，因为目前Hbudiler连MANIFEST都不支持。）
求解惑。
独自沉醉 (作者)
html5要想颠覆app。
我认为只是多端发布是不够的。
多端发布只是节约了人力成本，还不够颠覆，对用户来讲意义不大。
C/S 到 B/S模式的演进才是真正的颠覆。因为用户会真正的受益。
html5具备这样的潜力。
是不是我的想法太激进了，目前的技术和规范还实现不了？
DCloud_Android_ST
webview缓存是打开的默认为 LOAD_DEFAULT: 根据cache-control决定是否从网络上取数据
独自沉醉 (作者)
cache-control，并不能控制何时更新。
DCloud_Android_ST
这是安卓提供的API描述，目前没有相关案例提供给你
独自沉醉 (作者)
> DCloud_App_Array :
目前Webview默认使用的是系统默认缓存类型（不会离线缓存）
暂时还没有开发API设置缓存类型（后续会支持的）
对于这种需求，为了更好的用户体验，建议使用ajax请求数据来展现，而不是整体页面放到服务器。
2015-01-10 14:31
http://ask.dcloud.net.cn/question/2339
这个问题以前也有人问过，DCloud_App_Array回复以后会支持API设置缓存，
过去半年了，请问目前有这个计划吗？谢谢
枫桥居APP
我是用预加载方式远程创建的(为什么要远程创建webview,因为可以随时更新功能,不需要提交AppStore等待审核)
如何预加载呢?我们可以分析一下:当用户打开一个页面接下来肯定是要打开另外一个页面或者关闭当前页面.
既然这样那么就写一个initPage!当打开一个页面后创建一个隐藏的webview,当用户点击链接时候可以把这个webview拿来用;当用户关闭当前页面的时候把这个webview销毁.
具体实现可以看我之前发布的框架!和后续的枫桥居app版本.枫桥居APP实现还更复杂一点,实现了同时创建/销毁2个webview
独自沉醉 (作者)
我目前也是全部远程加载的。但是，每次打开APP都要去下载一次。
但实际上，index.html主页，mui.min.js这样的资源文件，不需要每次都去下载的。
而是版本升级后才去下载。不然太浪费流量了。
@枫桥，这个问题，你是怎么处理的呢？
枫桥居APP
@独自沉醉 js和css不会每次下载的,你多虑了,资源文件走的是浏览器的流程,浏览器会自动缓存.不信你可以打开app一个页面,然后打开飞行模式,然后刷新页面,会发现远程图片都还在,哪怕关了app重启远程图片都还在,不会重复加载的.
至于plus.webview.create(url)这个方式会不会自动缓存我就不知道了.但我也不希望它缓存,因为本地缓存了的话那我在远程改了webview用户本地还是访问不到,这样不如干脆打包到本地,失去了远程webview的意义.
如果想远程加载webview又想提升性能,我觉得目前为止唯一的好的方案就是预加载webview和回收旧webview,预加载webview可以放到后台去,用户感觉不出来
独自沉醉 (作者)
不管是html还是css，js。在我看来都是一样的：
你说的js，css不会每次都下载，那多久重新下载一次呢？
或许可以通过cache-control来配置过期时间。
但达不到，我服务器版本一升级，APP就立即更新的目的。
你说的不希望html缓存，那么，首先会浪费流量，其次，html每次打开app都更新了。
但css和js却是第二天才更新，那肯定有问题的（假设css和js明天才过期的话）
所以，我觉得：
要么html，css，js都不缓存，就是费点流量。（只缓存css/js，html更新了也没有用）
要么html，css，js都缓存，但是可以通过某种技术实现与服务器同步更新（html5的MANIFEST技术）
DCloud_heavensoft
缓存是个很不好控制的东西，灵活性、兼容性都有问题。
我们的解决方案不是缓存，就是真的存本地。
一、应用的HTML5、js、css
页面就是放到本地，升级通过wgtu方式升级，可以单独更新某个文件。参考http://ask.dcloud.net.cn/article/199
二、除了应用页面，里面引入的服务器端的图片要缓存在本地，有2种做法：
枫桥居APP
plus.downloader存在本地，然后img对象的src用js动态赋值指向到本地地址.当图片很多的时候即使已经缓存到本来了加载图片也特别慢，不知道是怎么回事。枫桥居app的列表有3张图片，一页有20条，就是说最大可能有60张图片。我做了个策略，先加载前6张图片（第一屏），然后3秒后加载其他的，还是很慢。所以我放弃了把图片缓存到本地。请指教。
2015-08-20 21:31
DCloud_heavensoft
回复 枫桥居APP: 36kr就是这么做的，没有感觉慢啊。
2015-08-21 02:08
枫桥居APP
回复 DCloud_heavensoft:所以可能是我的方法不对,需要注意什么
2015-08-21 09:14
尘岳two
图片的缓存webview会自己做的，不用管。
自己缓存数据就行了
独自沉醉 (作者)
这个问题，是我自己觉得html5规范，肯定能完美解决我想要的，既节约流量，又能让用户无感知的同步更新问题。
我今天又研究了下html5的MANIFEST技术，发现，跟我想象的不一样：
假设用户已经打开过index.html页面，浏览器缓存了index.html，然后服务器端修改了index.html。
当用户再次访问index.html的时候：
也就是说，服务器端的更新，用户第二次打开的时候才能看到。
达不到我想要的，服务器同步更新的效果。
是我对MANIFEST期望太高了。
所以，DCloud_heavensoft说的增量包升级的方式，应该是目前最好的解决方案了。
虽然会带来一定的版本管理的成本，用户也有感知。
但不用在去appstore审批了，升级所花费的流量也少。
刚才我测试了下通过wgtu包来增量升级，效果还蛮不错的。
感谢DCloud团队提供这么牛X的技术和平台，赞一个。