「Flash Player 11.1」「AIR 3.1」公開、モバイル版はこれが最後

「Flash Player 11.1」「AIR 3.1」公開、モバイル版はこれが最後

Flash終了のお知らせだが、なぜAdobeがモバイルOSから撤退したのかの理由はあまり詳しく説明されていない。

出回っている記事のほとんどは、HTML5に負けましたとか、iOSが採用しなかったからとしか書いていない。つまりAdobeはバカだから負けましたぐらいにしか書いてなくて、負けたんだから当然バカだったんだろというニュアンス。

AdobeがモバイルOSでのFlashサポートを止めたのは、モバイルとPCのハード構成の違いに依るところが大きい。

PCにはハイパワーなCPUとGPUが搭載されている。プラグから電源が供給されているから、強力なプロセッサを使える。


モバイルでFlash Playerが使えなくなるわけ

Flashの動作はかなりのプロセッサパワーを消費するので、モバイルOSでそれをやってしまうと電池がもたなくなってしまう。

モバイル用GPUには、モバイルに特化して消費電力を抑えたものが出ているが、Flashはそういう新しい世代のモバイルGPUに最適化しにくいらしい。

その理由は、PC用のWebには古いVerのFlashもたくさん使われていて、それら古いVerとの互換性を確保するようにすると、最新世代のモバイルGPUでは動作保証が困難だからだそうだ。

つまりモバイル用Flashを提供して、PC用Webサイトで使われているFlashを使えるようにすると、消費電力が増えて電池がもたない。

消費電力を減らすために最新世代のGPUに最適化すると、古いVerのFlashが動かない可能性大なので、Flashを使ってあるPC用サイトが全部見れるわけではない。

省電力を取れば、既存Web資産との互換性が怪しくなり、互換性を確保すれば電力消費が厳しくなる。そういう手詰まりになってしまったということ。

完全に過去互換性と電力消費のコンフリクトを起こしたわけだ。


Webやアプリをモバイル目的に最適化するのか、デスクトップでのパフォーマンスを取るのかは、各ベンダーでも色々悩みの種のようで、電力を奔放に使えるハイパワーCPUの時代はもう終わりだと考えているところもある。

マイクロソフトの次期Windowsは8だが、8では従来のIntelアークテクチャのx86向けの他に、ARMアーキテクチャ用のバージョンも出すと言われている。

ARMアーキテクチャのコアは、ケータイやスマホのCPUに使われている。

スマホのCPUを作っているのは、クァルコムやテキサスインスツルメンツやサムスンやNVIDIAだが、その中核となっているコアはARMの技術で作られている。

MSはARM向けOSを出す見込みだし、AdobeはARMでは使い難い技術から撤退した。

時代はコンピュータでも車でもエコで、省資源省エネルギーじゃないと使えませんという時代になってきている。

来年はものすごい勢いでIT関連技術が変化しそうだから勉強し直さないといけないが、ホント時間がなくて困る。

「Flash Player 11.1」「AIR 3.1」公開、モバイル版はこれが最後


スマートフォンはAndroid、iOS、Windows Phoneの競争

単純に言うと、スマートフォンではブラウザの拡張を認めるAndroidと認めないiOS、Windows Phoneに分断されており、ブラウザ拡張としてのFlashは全くユビキタスではなくなってしまっているので開発リソースはAIRにつぎ込んだ方が賢明です。実際、AIRについては開発終了予定はなかったはずです。これはSilverlightの開発の主軸がOut of Browserにシフトしていることからも容易に想像がつきます。

MSもブラウザ拡張は認めない方向ですか。

アプリケーションサービスがクラウドベースになるにつれて、ローカルに追加モジュールを入れるよりは、ブラウザにプラグインを追加する方が妥当なのではないかと思っていましたが、OSベンダーの考え方はOut of Browserなのでしょうか?

In BrowserなのかOut of Browserなのかの路線がはっきりしないと、投資の方向性も絞り込めないので、気になるところです。

Windows 8でもMetro側ではブラウザプラグインを認めない方向ですし。恐らく、ブラウザプラグインがブラウザのセキュリティを下げてしまうことが問題ではないかと思います。

そして、クレームは間違いなくブラウザのベンダに来る。ここからのサポート工数が問題視されているのかなと思います。

Out of browserだとアプリケーションの起動を伴う分、責任範囲が明確化すると考えているのではないですかね。



なるほど、セキュリティの切り分けの問題ですか。確かにそれは大きな動機になりそうです。

しかしOut of browserだとOSのシェアを伸ばす必要があると思いますが、OSでデファクトスタンダードを取るより、ブラウザでデファクトスタンダードを取る方が時流に則っているように思えます。

Googleの戦略はそういうことだと思いますが、あくまでMSはハードにバンドルするOSでのシェアを握るということなんでしょうか?


デファクトスタンダードはない

ブラウザのデファクトスタンダードというのは難しいと思います。というのも、コンテンツの製作側からすると将来まで考えるとデファクトスタンダードよりもデジュールスタンダードを志向せざるを得ないところもあるからです。また、ブラウザがその性格上、ユーザの忠誠心をあまり見込めないという問題もあります。

従って、Googleにしてもブラウザのシェアはあまり重視していないと思います。現実問題、マネタイズを考えるとエッジであるブラウザのシェアよりもコアであるサーバ側の方が重要です。Googleに関していえば、Google App Engineのマネタイズがあまり成功していないのが問題でしょう。

スタートアップ企業ではGoogle App Engineは便利な特性が多いのですが、実作業ベースではメールなどに仕様上の罠が多いです。特に今でもそこそこの数のあるフィーチャーフォンを考えると絵文字対応を求めるクライアントは多いのですがGAEのメールサーバはメールの本文を見て文字コードを決める仕様のため絵文字関連はほぼ文字化けします。

MicrosoftがOut of browserを志向するのは業務アプリをある程度念頭に置くのと、昨今のスマートフォンの情勢にあるでしょう。つまり、スマートフォンではトラフィックの誘因の手段としてアプリが重要視されていること、業務アプリだと帳票系やデータエントリーでWiMAXの速度 機種 キャンペーンを比較してわかった。4月更新 WiMAXの比較の法則!とHTML5はまだ十分ではないことでしょう。


ITの世界でデジュールスタンダードはあまり聞かないので、妥当かどうかはちょっと判断つきません。

ブラウザのシェアよりは、サーバサイドの技術が重要という点には同意です。

フィーチャーフォンは日本独自のローカル仕様が多いので、いずれ下火になるだろうと見込んでいます。

スマホも今のようなスペック重視のなんでも入りの一方ではなく、機能限定で安く使いやすいものと、ハイスペック機とで住み分けにはなっていくでしょうし。

色々まだ様子見ですね。

ご意見参考になりました、ありがとうございましたww