背景
由于手上的Android app需要改版,用户流量越发增加,H5活动页面、展示页面也陆续地增加。所以打算基于native实现缓存方案加速。
架构
我们的架构是hybrid app,只有首页是native实现的,下面的几个条目作为H5的入口。
(为避免广告嫌疑,已经屏蔽相关字眼)
解决方案
上网查了一下hybrid app的H5加速方案,详见:http://trock.lofter.com/post/117023_e8e175
方案一:使用manifest,但是坑比较多,而且也不是最好的方案,一个文件改,所有都要更新。
方案二:打包下载前端资源,Android本地的解压。然后native和H5用spdy协议请求页面。Android可以实现增量更新。
我的疑惑
关于方案二是具体实现方法,我在网上搜索不到,而且很疑惑:
1.前端资源打包,是在服务器上发生的吗?
2.客户端如果知道有更新,对比md5,但不是说下载打包好变成一个zip包吗?那它怎么样去识别个边页面的更新?
或者我的理解完全错了?
有经验的同学请指教,谢谢!
大家讲道理2017-04-17 17:28:08
私にはハイブリッド APP の開発経験はありませんが、WebView + ページの形式で提示することを選択する機能がたくさんあります。
このトピックの目的は、アクセス トラフィックを減らすことです。WebView 自体にキャッシュ メカニズムがあり、パッケージをリソースと比較する必要があるのかわかりません。画像が変更されたということは、ページ全体のリソースを再度ダウンロードする必要があるということではないでしょうか?
私の側はローカル HTML ページとネットワーク画像の形式なので、ローカル HTML ページのみを更新する必要があるたびに、画像または CSS と JS はバックエンドに残っています。 WebView は適切なキャッシュを実行します。対象のハイブリッド アプリケーションの開発形態がわからないため、公開するのは簡単ではありません。
PHPz2017-04-17 17:28:08
私はフロントエンド開発を担当しています。
クライアントの同僚と相談し、2 つの解決策を得ました。
① バックエンドは頻繁に更新されないページをパッケージ化し、クライアントはそれらを解凍します。
② 頻繁に更新されるページについては、バックエンドがリストを送信します。リストにはファイル名、バージョン番号、md5 が含まれます。クライアントはこのリストをダウンロードし、差分操作を実行し、特定のルールに従ってファイルのダウンロード、置換、削除を行います。
バックエンドの同僚に相談したところ、次の情報が得られました:
このアプリの主な業務はバックエンドにあり、改訂後でも現在のトラフィック レベルは 5 の 1000qps には程遠いです。そのため、現在のリソースが CDN 経由で実行されなくても大丈夫です。この段階ではフロントエンドのパフォーマンスの最適化はあまり必要なく、ファイル ディレクトリとコードの再構築の方が重要です。
包括的なソリューション:
この段階では、パフォーマンスの最適化についてあまり考慮する必要がないため、クライアントの同僚から得たソリューションは後で実装される可能性があります。 @zzxxasp クラスメートが言及した解決策は、WebViewキャッシュを使用することで十分です。 @TIGERB の CDN ソリューションと組み合わせることもできます。