iOS 8 に Apple の HTML5 への愛を見た
こんにちは、ゼノフィnakamuraです。
先週アップルが発表した iOs 8 のリリースに、私たちは非常に興奮しております。iOS 8 の正式リリースを手にして数日しか経っていませんが、いち早く世界中の Web 開発者コミュニティに最新のアップルのリリースについて徹底的にお伝えしたいと思っています。もちろん数週間、数ヶ月後にはここではカバーできなかった項目が発覚するのは承知ですが、既に分かっていることを少しでも共有できたらと思っています。
この記事は、今後iOS 8 がアップルのデバイスのベースラインとなることを見越して、HTML5 の現状を技術解析したものです。去年 iOS 7 にも似たようなレビュー記事を Web 開発者のために書きましたので、気になるかたはそちらもご覧ください。
iOS 8 の新機能は HTML5 開発を進めます
今回のアップグレードで加えられた機能について見ていきましょう。
Source: caniuse.com
これらの機能は全て素晴らしく HTML5 開発を進めるものに間違いはありませんが、その中でも特筆すべきは以下のものでしょう。
WebGL – 3D Canvas Graphics
ハードウェアアクセラレートした 3D グラフィックのサポート — 言うまでもありませんが、Web 開発者にとってこの機能はものすごく大きなものです。こういった機能はゲームで多くみることになりそうですが、アニメーションや画面切り替えなど、他にも使われるであろう場面はあります。何ができるようになるかを軽く見てみるには、 WebGL Sprite Particle デモをご覧ください。
CSS Shapes レベル 1
このめったに見ない機能は実は Chrome のみで使用可能でした。正確にはChrome for Android と Opera です。今回はついに iOS 8 内ではプレフィックスつきサポートされてました。CSS Shapes は、よりダイナミックにテキストをレイアウトすることができ、アプリケーションに Web ページというより、雑誌に近い感覚を与えてくれます。実際の例を見たい場合は、 Shapes from Adobe をチェックしてください。
HTML Templates
Web コンポーネントの基礎要素の 1つが最新の Android と iOS ブラウザで使用可能となりました。これは真にモジュラーな Web を作る上では大きな一歩であり、必要であったポリフィルを1つ減らし、よりたくさんの可能性が広がります。
Navigation/High Resolution Timing APIs ナビゲーション/ハイレゾリューション タイミング API
あまりエンドユーザーには一般的ではない機能かもしれませんが、合理的に動作するタイミング API により、よりプラットホーム間でのベンチマークや、パフォーマンステストが行いやすくなります。
IndexedDB
WebSQL は Android と iOS では利用できますが、現在 IE ではサポートはされていません。更には Web SQL 仕様はもうメンテナンスもされておらず、将来のバージョンではなくなってしまうことが予想されています。幸運な事に、IndexedDB は、iOS、Androido、Chrome for Android、Safari、IE Mobile そして部分的なサポートですが Blackberry 10 と IE 10/11 でも使う事ができます。
SVG フラグメント識別子
この機能は暗号のような難しい名前ではありますが、ものすごく強力であることを保証します。現在は IE 10、11 と IE Mobile、iOS 8 Safari と Chrom for Android に対応しています。SVG フラグメント識別子は強力なベクタースプライトシートを実現します。これは Web ゲームではもちろん重要になってきますが、ダイナミックアイコンやその他の UI 要素にも大きく関わってきます。
モバイル Web 開発者として、貴方は最新のブラウザのバージョンや機能を既に使っているでしょう。我々はアップルの有能なアップグレードシステムのおかげで、iOS 8 がすぐに全てのユーザーに届く事は知っています。もし貴方のアプリケーションが iOS デバイスだけをターゲットにしたものであれば、簡単に、IndexedDB, SVG Fragments や、新しいタイミング API でベンチマークする機能などは使えます。iOS 7 と同一性を保ちたい人や、複数のプラットホーム (Android、Windows Phone、BlackBerry)での開発を考えている人は、これらの新しい機能を Sencha Touch のビルトイン OS detection で使用できます。Sencha Touch はこれらの新しい機能をアプリケーション内で使用でるようにし、古いコードを自然に消していってくれます。
全く新しい WKWebView
iOS 8 のリリースにより、我々は喜びながらもちょっとした断片化に苦しんでいます。 iOS 8 は、2つのネイティブ Web ビューが組み込まれて出荷されています。 1つ目は、古き良き “UIWebView” で、今まで慣れ親しんできたものです。 これは、レガシーな用途のために保持されていて、幸運なことにアップルは iOS 7 の “UIWebView” を iOS 8 に強引に詰め込むことはせず、コア WebKit コードをアップグレードし、全く新しい Webビュー、”WKWebView” に適用しました。 iOS 8 に移行するにしたがって、ハイブリッドアプリを作成する時に、”WKWebView” を使うようになるでしょう。 Nitro JS エンジンを搭載した、我々のテスト結果によると “UIWebView” の 4倍ものパフォーマンスをみせています。これはハイブリッドアプリにとっては大きな影響をもたらすことでしょう。残念ながら現段階では、誰にでも影響を及ぼしてしまうような大きなバグもいくつかあります。これについては後半でも触れることにします。
朗報なのは、ハイパフォーマンスな新しい “WKWebView” は、 Web 開発という視点からみても正しい方向に向かっているということです。アプリケーション開発において JavaScript がボトルネックになることはまれで、アニメーションや DOM の再描画の問題の方が多くみられます。DOM コアへの劇的なブーストにより、”WKWebView” は Sencha Touch アプリケーションの性能を大きく改善していくと信じています。
全面的に向上したパフォーマンス
パフォーマンスのテスティングは必須であり、今回は興味深い結果も得られています。全体的に見れば、iOS 8 への移行は、誰にとっても良い事でありそうです。いくつか iOS 8 の方が結果が低かったスコア(Base64 と Code Eval でも) もありました。それらの結果が何を意味するか表を見ていきましょう。
注：これらのテストは全て5世代目の iPod Touch で行われました。その理由は、今後 iPhone 5S/6 と比べる時に、これらの結果が、iOS 開発においての最低基準値となり得るからです。
Source: http://octane-benchmark.googlecode.com/svn/tags/v1/index.html
残念なことに今回のテスト時は、Google Octane v2 は iOS Safari をクラッシュさせていたため、新しいテストを行うことはできませんでした。それでも、このテストは割と全体を把握できる結果が得られました。
表を見ると、iOS 8 がほぼ全てのテストで勝っていることがわかわります。ただ1つ負けたのは CodeLoad ですが、これはJavaScript エンジンが、巨大な JavaScript ファイルを読み込んだ時に、いかにはやく立ち上がるかを測ったものです。このテストで使われたコードは Closure と jQuery がベースになっていますが、こういったことの水準は保っていると言っても問題ないと思います。
Sencha で組み立てられたアプリケーションの場合、iOS 7 と比べた場合にアプリケーションの立ち上がりに少し遅延を感じるかもしれません。そういったアプリケーションは巨大な JavaScript ロードが前もって (順次ロードされるのではなく) 行われがちだからです。その他のテストでは、iOS 8 は iOS 7 にわずかにあるいは圧倒的に勝っています。
Source: http://dromaeo.com/?dom
Dromaeo の Dom コアテストは、実際は表よりも良い結果が得られています。Query での劇的な改善があまりにも印象が強く、Attributes、Modification や Traversal での改善は霞んで見えがちです。数字を見ると Attributes では 122％、Modification では 65％、Traversal では 48％もの改善が見られました。圧倒的な結果を残した Query は 308％増でした。
これは Sencha 開発者にとってはものごい朗報です。なぜなら DOM Query はたくさんの Sencha フレームワークで使用されているからです。
Source: http://dromaeo.com/?cssquery
DOM コアでの劇的な改善が確認できた後、我々はフレームワークレベルでの CSS セレクターのパフォーマンスブーストを見ました。Ext JS セレクターは iOS 8 Safari に移行するだけで、128％増でした。
注意すべきなのは、これらの CSS セレクターテストは現在 Ext JS 3.x を使ったものであり、フレームワークは Ext JS 5.x のリリースで劇的に改善されています。その結果、実際の改善点はよりよく感じられるでしょう。
Source: http://dromaeo.com/?dromaeo
純粋なコードのテストに移るとしましょう。ここではどんなアプリケーションも使用するであろう基礎的な JavaScript の機能を見ています。パフォーマンスでの若干の低下が、Base 64 文字列と、”new Function” やと “eval” によるのコードの展開で 見られます。しかし、一方の Arrays では大幅な増加も見られます (特に配列の生成で) 。開発者はあまり気にする必要もないですし、過去の Fastbook 記事で述べたように、JavaScript はどんなアプリケーションを作る上でも充分に速いです。現代の流動的なアプリケーションを作る上では、JavaScript より GPU との連嶺の方が重要です。
Source: http://ie.microsoft.com/testdrive/performance/fishietank/
この表が言うまでもなく、全てを語っていますね。Safari を iOS 7 から iOS 8 に切り替えるだけで、fps (1秒あたりのフレーム数) で78％も改善が見られました。Canvas に複数のアップデートがあったのは明らかで、我々の WebGL サンプルでもその結果は顕著に見られます。
Soutce: http://dromaeo.com/?cssquery
さあ、この表はあまりにも結果が歴然としすぎているかもしれません。いかに “WKWebView” が進歩したかがわかります。しかし、バグの項目まで飛んでいただけると、まだ “WKWebView” をハイブリッドアプリに使用できない状況や課題も見えてきます。
これらの数字や結果によって、より多くの開発者がアップルに “WKWebView” のバグを早急に直すようにと、つついてくれたらと願っています。バグさえなくなれば、これらの進化したパフォーマンスを全てのアプリに生かすことができます。先ほどと同様に、Dom Query は他の数字を霞ませています。”WKWebView” を使用した場合、Attributes では 208％速く、Modifications では 37％速く、Traversal では 249％速く、そしてクエリーではなんと 358％も lUIWebView” を使用した場合より速くなっていることがわかります。
Source: https://www.webkit.org/perf/sunspider/sunspider.html
Sunspider テストの結果はそれほどあからさまなものではないですが、改善点は見られます。iOS 8 Safari は iOS 7 Safari に比べて 14％増加していましたが、”UIWebView” は5％改善しました。小さな増分ですが、全て前向きな事であり、進んでいる方向は間違っていない事を証明しています。
Source: http://html5test.com/
このグラフでは、HTML5テストで出た生のスコアを見る事ができ、iOS 8 Safari が iOS 7 に比べてサポートされている機能で多くの改善があることが簡単にわかります。しかし、正確に結果を分析するのであれば、水面下での変化について考えなければこの結果については語れません。以下にいくつかの点をまとめました：
- Seamless iFrame は iOS 8 では削除されました
- IndexedDB は iOS 8 Safari と “WKWebView” に追加されました
- IndexedDBは iOS 8 “UIWebView” や、ホーム画面アプリには対応していません
- Objectstore ArrayBuffer は iOS 8 Safari と “WKWebView” で動きますが (HTML5 テストサイトではこの機能は動いているにも関わらず失敗したと表示されます。もし、正常に評価されていれば iOS 8 Safari は 440点でした)
- Objectstore ArrayBuffer は iOS 8 “UIWebView” や、ホーム画面アプリには対応していません
- WebGL 3D Graphicsは iOS 8 の Safari、 “WKWebView”、 “UIWebView” とホーム画面アプリに追加されました
- “UIWebView”、 “WKWebView”、ホーム画面アプリのユーザーエージェントは同一です
アップルは “UIWebView”、 “WKWebView”、Safari、そしてホーム画面アプリを同じレベルで機能が使えるように頑張ったとは思いますが、その差異は Sencha 開発者を苛立たせるものとなってしまうかもしれません。開発者はより一層、自分のアプリがどういったコンテクストで実行されるのかを気にしなければなりません。例えば：”UIWebView” とホーム画面アプリは、IndexedDB と Objectstore ArrayBuffer に対応していません。ユーザーエージェントは同じであるため、簡単に自分のアプリケーションがどこで提供されているかを知る事はできません。つまり、開発者は機能ごとに個別で探知するしかないのです。
バグ
私たちは、どんなソフトウェアもバグなしでリリースされることはあり得ないことを知っています。もちろん iOS 8 も一緒で、いくつかここで紹介しなければなりません。今のところ、3つの大きなバグがHTML5 開発者に影響し、すなわちSencha のお客様に影響してしまうことがわかっています。これらはもちろん Sencha アプリに限ったことではなく、たくさんの開発者達がここから数ヶ月間、努力して積み上げた物に影響を与えてしまいそうです。もし助けてくださるなら、各バグの下の Radar Bug Report のリンクをクリックし、アップルのバグレポーターまでお願いします。そこでは我々のバグを複製して送信することができるので、ハードデータやテスト結果が多ければ多い程バグの影響力を示すことができ、その分はやく直してくれることを期待できます。
WKWebView ローカルファイルローディング バグ
先ほど言った、最先端で革命的な Web ビューについてはまだ記憶に残っていますか？ 最速の Nitro JS エンジンを搭載して、全て新しくなったもののことです。実は…それが壊れているんです。このバグはセキュリティーに関する問題なのですが、”WKWebView” をローカルのファイルシステムからロードさせてくれません。つまりどういう事かと言うと、埋め込まれた index.html は、”WKWebView” にはアクセスできないということです。これは、オフラインやローカルファイルを使用する PhoneGap や Cordova アプリの機能を妨げるものとなっています。なので、現段階では “WKWebView” をアプリ内で使用したければ、ファイルをリモートサーバーからロードしなければなりません。例えば、”index.html” はロードできませんが、”http://www.google.com” は問題なく動きます。
Radar Bug Report: http://www.openradar.me/radar?id=5839348817723392
XHR Local File Access XHR ローカルファイルアクセス
現段階では、新しい “WKWebView” コードを使用したものは、XHR ローカルファイルが壊れる問題があります。これは Safari やホーム画面アプリ、また ”WKWebView” に埋め込まれたものが該当します。もし、Cordova や PhoneGap を使用しているのであれば、旧型の “UIWebView” に閉じ込められているため、このバグに苦しむことはありません。このバグ自体は XHR オブジェクトにローカルファイルをデバイスの外に送ることを禁じています。つまり、アプリケーションがフォトギャラリーやカメラを使用して画像を手に入れ、AJAX 経由でサーバーに送っていた場合、残念ながら iOS 8 ではうまくいかない模様です。何が起きるかというと、アプリケーションからは “send.” という信号を送ってから応答しなくなります。
Radar Bug Report: http://www.openradar.me/radar?id=5834555097350144
ホーム画面アプリでロック/解除時にタイミング機能を失う
貴方のアプリケーションがホーム画面 Web アプリであれば、残念な結果が待ってます。もちろんどんな Web アプリもユーザーによってホーム画面アプリにすることは可能なので、つまり技術的にはこれはリモート Web アプリを作っている人全てに影響を与えます。このバグは setTimeout(callback, 1) を呼び出すか、ボタンやイベントを経由してrequestAnimationFrame(callback) をすると簡単に再現できます。最初にアプリを開いた時に、全てのタイミング機能が正常に動いていることが確認できます。しかし、電話をロックし、後に解除してアプリに戻った場合、どのタイミング機能もコールバックできなくなっていることがわかります。これらはネイティヴなレベルで破損しています。リセットもできなければ、アプリが生き返ることもありません。死んでいるので最初から始めなければいけません。これらのタイミング機能は Senha Touch や Ext JS フレームワークにとっては、その他の JavaScript フレームワークやライブラリと同じくらい大事なものです。今すぐにアップルにかけつけ、彼等に全ての JavaScript 機能をいつも使える様に使いたいと伝えるべきです。
Radar Bug Report: http://www.openradar.me/radar?id=5895945212395520
もちろんいいニュースもあります。なぜなら、今のところ “WKWebView” アプリケーションに影響する問題しかおさえていないからです。もし貴方が Sencha Space を使用している、もしくは使用を試みたことがある場合、全く問題はなく、アプリも安全に作動します。Space を使えばセキュアなブラウザが用意され、管理された Web ランタイムの中にいます。もし、 Sencha Space を試したことがなければ、ここで試してみるいい機会かもしれません。
未来への展望
全般的に、iOS 8 のリリースにより、我々はアップルの iOS が向かっている方向に満足しています。それはパフォーマンスの向上や新機能が iOS 8 プラットホームで作られるアプリでのユーザーエクスペリエンスを高めるものに限定されているからです。しかし、アップルが今日解説したバグ問題を速やかに対処することも願っています。なぜなら、現状では iOS 8 の良さを Web 開発者が Sencha フレームワークを使っていても、その他の代案を使っていても、完全に生かせないからです。
Source: caniuse.com
より未来を見据えると、iOS 8 と Chrome for Android 間でのクロスオーバーを期待できそうです (例えば CSS Shapes や、srcset 属性、や SVG フラグメント識別子などでです) 。上記の画像ではわかりませんが、Chrome for Android は既に部分的に WebGL 3D Canvas グラフィックに対応していて、その部分的というのも、Chrome は使えるけど WebGL 3D を使う事のできない古い機種を含んだ場合の話です。
結論
iOS 8 は Web 開発者にとってみれば、様々な新しい機能が搭載され、パフォーマンスの向上もあり、HTML5 クロスプラットホーム開発も促進するので大変喜ばしいものだと思っています。
Sencha では、我々はつねに開発者を常に次世代の Web 開発の最前線にたてるようにサポートしたいと思っています。我々は常に最高で完全なるクロスプラットホームな解決策をユーザーに提供することに集中していて、そういったユーザーが驚くようなアプリケーションエクスペリエンスを各デバイスに提供することを望んでいます。我々はあなた方が我々と一緒にどんな発明をするか首を長くして待っています。また次回、お会いしましょう。
