2018年12月24日月曜日

Android TVでFrameに接続してみて分かった、使用ブラウザのパフォーマンスへの影響度

🎅このエントリは Nutanix Xi Frame アドベントカレンダー の24日目です🎄

皆さんこんにちは。この記事は12/24の22:55に書き始めました。
アドベントカレンダー担当日だというのに、未明には子供が吐き気を催し深夜の大洗濯祭り、日中は年末の大掃除、夕方には子供がサンタさんからプレゼントされたNintendo Switchのマリオパーティに参戦、ということで気が付いたらこの時間でした。

そんな中、深夜の大洗濯祭りと並行して、洗濯機が回っているのを待ちつつ午前3-4時ごろに白目になりながら行った検証について書きたいと思います。

何をしてみたか

一言でいうとこちらのシリーズ、弊社大阪のCitrixに自信ニキであるYusuke Mizuta氏の試していた検証と同じような話です。


ただし今回私が試したのはAndroid TVです。具体的にはシャープさんの2017年式AQUOS。

ちょっと躓いたところとTips

この機種に搭載されているAndroid TV、通常のスマートフォンやタブレットに搭載されているAndroidとは別OS扱いになっているようで、Google PlayはあるもののすべてのOSが普通にインストールできるわけではありませんでした。

Frameにアクセスするためのアプリケーションといえば、HTML5対応Webブラウザなのですが、Chrome・Firefox・Edge・Opera等の有名どころは軒並みAndroid TVに非対応なのです。ググると過去にChromeがAndroid TV対応した時期もあったようなのですが、少なくとも2018/12/24時点ではNGになっていました。

で、Android TVでは非対応アプリケーションが全く動かないのかというと、必ずしもそうではありません。Android用のアプリケーションはAPKという形式のフォーマットでパッケージングされているのですが、これを入手すればGoogle Playを介さなくともアプリケーションのインストールが可能です。企業で独自のアプリを開発し、社内配布する際の手段と同じですね。

ただし[開発元不明のアプリを許可する]といった趣旨の設定をオンにする必要があるため、うっかり怪しいものをインストールしないように注意する必要がありますし、あくまで自己責任の範疇となります。

通常、Google Playで配信されているアプリケーションのAPKは配布されていませんが、APKをダウンロードできる外部サービスがあったりします。しかし、私個人の感覚としてはそのようなサイト経由で配布されるAPKを使うのはセキュリティ的に怖いなと思ったので、別の方法をとることにしました。その方法とは、APKファイルを自身の所有する別のAndoroid端末から取り出す方法です。

Androidのファイルマネージャーアプリのいくつかには、[アプリケーションをバックアップする]といった趣旨の機能が搭載されており、これはインストール済みアプリケーションのAPKファイルをバックアップフォルダに保存する、といった動きをします。この方法で入手したAPKをクラウドストレージサービスにアップロードし、Android TVにダウンロードして開くことでインストールすることができました。(とはいえこの方法も自己責任で…)

Android TVで正式に使えるWebブラウザはPuffin TVというものがあります。APKをダウンロードする際にはこれに活躍してもらいました。また、Puffin TVからFrameに接続してみた結果も後述します。

やってみた

まずはChrome。わりと快適に動きます。

次にFirefox。Chromeよりさらに快適。しかしタブが邪魔…。

次にEdge。前の2つよりちょっと厳しい…。

最後にPuffin TV。これは…無理だ。レイテンシもめちゃめちゃ大きい(左下参照)

※テレビにiPhoneのカメラを向けて朦朧としながら撮った動画を Satoshi Komiyama に見せたら、手振れ補正版を作ってくれました。感謝。

どうしてこうなった?

すべて同じ端末から接続しているのに、何故こうも違うのでしょうか?FrameはHTML5対応ブラウザならなんでも対応できるのではなかったのか??とお考えのかたもいらっしゃるかと思います。

実は、H.264による画面転送を使用しているFrameにおいては、端末の性能や回線品質だけではなく、ブラウザのビデオデコーディング性能もユーザーエクスペリエンスに大きく影響します。そして、Frameのメニューバーに表示されているレイテンシの値は、回線遅延だけでなく、ビデオデコーディング処理により発生している遅延も含めた、ユーザーの操作に対する遅延全体を計算して表示しているものなのです。

もう少し具体的に

各ブラウザの内部的な仕組みと併せて、パフォーマンスに影響を与えている要素を説明します。

Chrome

Googleのプロプライエタリな技術であるPNaCLというハードウェアアクセラレーションが利用可能な場合、それを利用してデコードを行います。ミッドレンジPCやMacBook、Chromebook等であれば10ms以内でのデコードが期待できます。ハイエンドPCやMacBook Proであれば2ms以内でのデコードが可能です。Android等のPNaCL非対応のデバイスであれば、純粋なJavaScriptデコーディングを行いますが、それでもChromeの処理は非常に高速です。

Firefox

Firefoxがサポートする、JavaScriptのローレベルサブセットであるasm.jsによる最適化の恩恵を受けることができます。最近のPCやMacであれば5-10msぐらいでのデコードが期待できます。ここ5-6年以内に発売されたレベルのPCであれば特に問題なく、優れた性能が得られるはずです。

Safari

GoogleのPNaCLやFirefoxのasm.jsに相当するものはありませんが、AppleのJavaScriptエンジンは非常に高速で、Macbook Airなら10ms以内程度、Macbook Proならば5ms以内でのデコードが期待できます。

Internet Explorer 11 やEdge

JavaScriptエンジンの性能は許容可能ではありますが、他の主要ブラウザに比べると見劣りします。特に性能の低いデバイスでは顕著で、デコードに100msを要する場合もあります。この場合、Frameが表示するレイテンシの値も高くなり、Frameプロトコルはフレームレートを落とす形での最適化を図ります。


と、詳しく色々書いたりますが、公式ドキュメントに書いてあります。
ドキュメント読むの大事ですね!

今回は以上です!今年の私の担当分、おわり!メリークリスマス🎉