このレビューノートでは、Crosswalkと呼ばれる興味深いプロジェクトに関する2つの記事の短いサイクルを続けます。 その中で、Crosswalkプロジェクトのバージョン14.43.343.17から何が変わったのか、そして今それを使用することがより便利になったかどうかについてお話します。
Crosswalk Projectは、HTMLアプリケーション用のオープンソーステクノロジー上に構築されたランタイムであることを思い出させてください。 Crosswalk Projectの基盤はGoogle Chromiumです。 Crosswalk Projectもオープンソースプロジェクトであり、 BSDライセンスの下で配布されています。 一般に、まだAndroidの初期バージョンをサポートしている場合、これはシステムAndroid WebViewの代わりになります。
次のリンクで以前の記事を見つけることができます。
Crosswalkの変更。
バージョン14からバージョン20まで、プロジェクトに多くの変更と改善が加えられました。すべてをリストするのは意味がありません。 あなた自身がリリースノートでそれらに慣れることができます 。
私に最も興味のあるものだけをリストします。
- Chromium 50にリベース
- AndroidでのCrosswalk Webviewの外部拡張機能のサポート
- XWalkViewでタッチイベントをインターセプトする機能を追加します
- onReceivedLoadErrorが発生すると、ダイアログの代わりにトースト通知がユーザーに表示されます(ユーザーはエラーに対応するために何もできないため)
- XWalkViewを非同期で初期化する新しいヘルパークラスXWalkInitializer
- サイズの最適化(ProGuard for Crosswalkを有効にしてAPKサイズの圧縮、LZMAサポートなど)
また、プロジェクトに対して多数の修正が行われ、最も重要な修正がリストされています。
追加の詳細。
以前の記事で、以前のバージョンのCrosswalkのいくつかの問題とその解決策について説明しました。 それらの多くがプロジェクト自体で解決されており、今では「タンバリンと踊る」必要はありません。
XWalkCookieManagerクラスとXWalkSettingsクラスは、それらにより適したパッケージに移動されました 。
org.xwalk.core.internal.XWalkCookieManager; → org.xwalk.core.XWalkCookieManager org.xwalk.core.internal.XWalkSettings → org.xwalk.core.XWalkSettings
XWalkSettingsは、XWalkViewオブジェクトのメソッドから直接使用できます。 また、XWalkView自体がユーザーエージェントを返すことができます。 今、これらすべてのために、反射の使用に頼る必要はありません。
リソース要求を処理するためのCrosswalk(XWalkResourceClientクラス内)への新しい呼び出しを追加しました :
public XWalkWebResourceResponse shouldInterceptLoadRequest(XWalkView view, XWalkWebResourceRequest request)
標準のWebViewのAndroid API 21を使用した非常に便利でアクセス可能な呼び出しの類似物:
public WebResourceResponse shouldInterceptRequest (WebView view, WebResourceRequest request)
これで、リクエストが行われたメソッドであるGETまたはPOSTを簡単に見つけることができます。
また、コンテンツ画像を取得するための特別なメソッドがXWalkViewに追加されました :
public void captureBitmapAsync(XWalkGetBitmapCallback callback)
onBackPressed()メソッドが正しく呼び出され始め 、setOnTouchListener(OnTouchListener l)メソッドを使用する機会が現れました。 そのため、ディスパッチメソッドでボタンクリックとタッチイベントをインターセプトする必要はありません。
APIの最新バージョンおよび以前のすべてのバージョンに関するドキュメントは、 こちらをご覧ください 。
新しいバージョンのいくつかの問題。
現時点では、 リポジトリで利用可能な最新バージョンは 20.50.533.12 ですが 、最後から2番目のバージョン19.49.514.5とは異なり、API 16に等しいminSdkVersion値を既に持っています。Crosswalk19は、API 14以降のAndroidのすべてのバージョンを引き続きサポートします。
Crosswalk 16についてはまだ述べられているという事実にもかかわらず:「Androidサポートライブラリ(support-v4、support-v7など)は、Crosswalkにバンドルされなくなりました...」。 バージョン16から最後の20まで、support-v4ライブラリのインポートが誤って登録されているため、プロジェクトでこのライブラリの特定のバージョンを使用し、プロジェクトを最新バージョンで自動的にビルドしたくない場合は、Crosswalkをプロジェクトに追加するときに除外する必要があります:
compile('org.xwalk:xwalk_core_library:19.49.514.5') { // avoid pulling incorrect version of support library exclude group: 'com.android.support', module: 'support-v4' }
Crosswalk Lite、アセンブリのサイズを縮小します。
以前の記事では、Crosswalkを追加するときにアセンブリのサイズを大きくするという重大な問題については言及しませんでした。 Crosswalk自体は、x86とarmv7の2つのアーキテクチャを対象としています。 したがって、それぞれのライブラリのサイズは〜20Mbです。 ユニバーサルビルドをビルドする場合、オーバーヘッドは約40Mbになります。
余分なサイズで状況を改善するには、2つの方法があります。アーキテクチャごとに個別のapkを構築するか、Crosswalk-Crosswalk Liteの軽量バージョンを使用します。 Crosswalk Liteは、 ライブラリの機能の一部を放棄することで問題を解決する試みです 。
以下に、LiteサイズとCrosswalkの通常バージョンのより正確なデータを示します。Crosswalk Lite 10-15Mb vs. 横断歩道20Mb。
ただし、限定された機能セットに加えて、Crosswalk Liteには多くのマイナス点があります。
- アクティビティはXWalkActivityから継承する必要があります。
- アプリケーションはXWalkApplicationから継承する必要があります。
- 初期化は特別な方法で非同期に実行する必要があり、最初の起動時にライブラリ自体が解凍され、ユーザーにそれに関するメッセージが表示されます。
残念ながら、現在入手可能なCrosswalk Lite 17.46.460.1の最新バージョンは、エラーで開始することを拒否しました(2つの先行バージョンのように):
W/XWalkInternalResources: org.xwalk.core.R$styleable.ButtonCompat is not int. E/SysUtils: ApplicationContext is null in ApplicationStatus A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 22829 (osswalkembedded)
したがって、サイズを縮小する唯一の実際の方法は、アーキテクチャごとに個別のビルドをビルドすることです。
GitHubで利用可能な更新されたテストプロジェクトにサンプルが追加されます 。
結論
最新バージョンでは、前述したものを含め、以前のリリースの欠点を多く考慮しています。 また、既にCrosswalkを使用している場合は、必ず新しいバージョンにアップグレードする必要があります。
ただし、別の質問が残っています。 現在、CrosswalkはシステムWebViewの優れた代替品として機能しますか? 古いバージョンのAndroid(Jelly BeanとKitKatのAndroid 4バージョンを含む)をサポートしている場合は、明らかにCrosswalkが役立ちます。 Android 5以降のみをサポートする予定の場合、その答えは明らかではありません。
Androidの5番目のバージョンでは、Google PlayのシステムWebViewの更新が利用可能になり(そして、新しい便利なAPIリクエストが登場しました)、Androidの7番目のバージョンでは、Google Chromeアプリケーションは標準のシステムコンポーネントを置き換えるように設計されています。 追加のライブラリがどれだけ必要かを言うのは困難です。 おそらく、一部のプロジェクトでは、OSのすべてのバージョンでの動作の完全な識別が、サイズの増加と別のライブラリを更新する必要性を上回ります。