2012/03/04

Ext JS 4.1 パフォーマンスチューニング

SenchaのブログでExt JS 4.1のパフォーマンスチューニングの記事が出てたので簡単に訳してみた (抄訳)。原文ではチューニングのためのTipsのほかに、Ext JS 4.1で新たに追加された性能測定ツールPage Analyzerの話もあるが、長くなるのでそっちは省略してTipsだけを要約して紹介する。

 原文:Optimizing Ext JS 4.1-based Applications
 Ext JS 4.1 beta 3のダウンロード:Download Ext JS 4



Ext JS 4.1でパフォーマンスが改善されたが、Ext JSベースのアプリケーションの性能を最大限に引き上げるには、アプリケーションの側でもExt JSの性能改善をうまく利用するようなコードを書く必要がある。以下、性能向上のためのTipsを紹介する。

  1. イベントリスナーの使い方に注意する
    たとえばストアで初めてデータを取得した時のためにloadイベントを使うと、ストアがデータを取得するたびにloadイベントが発行されてしまう。リスナーにsingle:trueを設定してイベントが最初の1回だけ呼ばれるようにすれば、性能が大幅に向上する。

    listeners: {
       load: onFirstLoadData,
       single: true
    }

    afterrenderイベントも注意が必要だ。このイベントはDOM要素がすべて生成された後で呼ばれる。レンダリング後に要素を変更するとレンダリングのフローが再度実行されてしまうため、アプリケーション性能が低下する。beforerenderイベントを使ってレンダリング実行前にクラスとスタイルを調整し、1回で正しくレンダリングされるようにするとよい。

    レンダリング後に実行しなければならないコードがあるとすれば、要素のサイズを必要とする場合だろう。そのようなときは、Ext JS 4.1で新たに提供されたboxreadyイベントが使えるかどうか検討すべきだ。このイベントはコンポーネントのサイズが決定した後で実行される。

  2. doLayoutとdoComponentLayoutの呼び出しは避けよ

    はっきり言って、この2つのメソッドは高価なのでできる限り呼び出さないほうがよい。4.0より前のバージョンのExt JSでは、doLayoutはコンポーネントとコンテナに対する処理が終わり、レイアウト計算に行く準備ができたことをフレームワークに通知するために使われていた。Ext JS 4.0でさえ、DOMを直接操作したり、ある種のバグを回避するのに、これらのメソッド呼び出す必要があった。

    Ext JS 4.1では、レイアウト計算の実行を開始する方法が変わり、これらのメソッド呼び出しが必要になるケースはほとんどなくなった。Ext JSのバグを回避するためにこれらのメソッド呼び出しが必要になる可能性はあるが、そのときはバグを修正するので報告してほしい。

    バグ以外でこの2つの呼び出しが必要になる唯一のケースは、アプリケーションコードでDOMを直接変更した場合である。フレームワークは変更を検知できないため、変更の影響が及ぶ部分のレイアウトを更新するためにこれらのメソッドの呼び出しが必要になる。

  3. コンテナの階層数を減らす

    すべてのコンテナは初期化、レンダリング、レイアウトを実行する。このため不要なコンテナを外せば外すほどアプリケーションは高速化する。たとえばコンテナが子コンテナを1個だけ持ち、子コンテナの中に複数のコンポーネントがある場合、子コンテナはなくしてしまったほうがよい。

  4. パネルの代わりにコンテナを使う

    パネル (Panel) は重いので、可能ならコンテナ (Container) を使ったほうが良い。

  5. ボーダーレイアウトのネストは避ける

    以前のバージョンでは、同一のリージョンに2つ以上コンポーネントを配置したいときや、Centerリージョンの上に2つのNorthリージョンを置きたいときは、ボーダーレイアウトをネストしなければならなかったが、今ではボーダーレイアウトはNorthリージョンを2つ持つことができるようになっている。

    Ext JS 4.1では、リージョンは動的に追加できるようになった。これまでのように事前にリージョンをすべて追加しておき、不要なリージョンを非表示にするといった処理は不要になった。またリージョンの優先度を指定するためのweightプロパティも使えるようになった。

  6. DOMのRead/Writeを減らす

    Ext JS 4.1では、レイアウトとDOMとの間のインタラクションをチューニングし、可能な限りDOMの読み書きを減らしている。アプリケーションコードを書くときも同じようにすべきである。もともとDOMの読み込みは遅いのだが、これに書き込みも混ざるとレイアウトの再計算が発生してしまい、オーバヘッドはさらに大きくなる。レンダリング後のコンポーネントの変更をさけるため、beforerenderイベントでスタイルとクラスを操作するようにすべきである。setStyle、addCls、removeClsなどのDOM要素を直接操作するようなメソッドは使用すべきでない。パフォーマンス向上のためには原則として、DOMの書き込み時に読み込みと書き込みを一括でおこなうようにすべきである。

  7. Ext.suspendLayoutsメソッドとExt.resumeLayoutsメソッドを使って余計なレイアウト計算を抑止する

    Ext JS 4.1では、新たにExt.suspendLayoutsメソッドとExt.resumeLayoutsメソッドが追加された。2つのアイテムを2つのコンテナに追加するような場合、レイアウトとレンダリングが複数回実行されてしまうが、Ext.suspendLayoutメソッドを呼び出してからアイテムを追加すれば、個々のアイテム追加時にはレイアウトの再計算は実行されなくなる。追加が終わってExt.resumeLayoutsメソッドを呼び出したときに、フレームワークは初めてレイアウトとレンダリングを実行する。

    レイアウトの再計算処理が実行されるのはアイテムの追加時だけではない。コンポーネントとコンテナに対して何か操作したり変更したりすれば、レイアウト処理が実行される。パフォーマンスに問題があるアプリケーションはユースケースを精査して、余計なレイアウト計算が実行されないようにすべきである。

2012/02/26

Flexの将来

Adobeがモバイル向けFlash Playerのサポート停止とFlex SDKのオープンソースコミュニティへの寄贈を発表して以来、いろいろな情報や憶測が錯綜していたが、先週改めてAdobeから「FlexについてのAdobeの見解と今後の関わり方」(Adobe's view of Flex and its commitments to Flex in the future)という文書が公開されていたようなので、以下に簡単に要約してみた。



Flexの位置づけとAdobeが果たす役割

  • Adobe Flexは大規模なエンタープライズアプリケーション開発に適したアプリケーションフレームワークであったし、それは今後も変わらない。HTMLの進化は早いが、今後数年間はまだFlexが最適なソリューションである可能性がある。
  • Adobe Flex SDKはApache Flexプロジェクトに寄贈し、Apache Flex SDKになる。
  • Apache FlexプロジェクトはFlex SDKのメンテナンスとエンハンスをおこなう。一方Adobeは、開発ツールとFlashランタイム (Flash PlayerとAIR) をサポートしていく。
  • AdobeはApachにFlex SDKと関連技術を寄贈するとともに、フルタイムのFlex SDKエンジニアチームも提供する。Flexに従事するAdobeのエンジニアの人数は減るが、開発コミュニティと協力することでFlexに関わるアクティブなエンジニアの総数は増える。

Apacheに寄贈されるもの

  • Flex SDK
    これにはコアSDK、オートメーションライブラリ、AIR SDKのバイナリファイル、ドキュメント、仕様書、まだリリースしてないSparkコンポーネント群が含まれる。
  • Falcon Compiler
    現在開発中の次世代ActionScriptコンパイラ。
  • Falcon JS Compiler
    JavaScriptを出力ターゲットとした実験的なASコンパイラ。
  • Mustella
    AdobeがFlex SDKのテストのために開発・利用していたテスティングフレームワーク。
  • BlazeDS
    後に出てくるようにLCDSは寄贈されない。
  • Flex SDKのエンジニアチーム
    重大なバグとセキュリティ問題については過去のFlex SDKに対しても対応する。

今後もAdobeが自社開発を継続するもの

  • デスクトップブラウザ向けFlash Player
    デスクトップ向けFlash Playerは開発継続、モバイルブラウザ向けは開発停止。
  • Adobe AIR
    デスクトップとモバイルの両方でAIRをサポートする。
  • Flash Builder
    Apache Flexを利用したアプリケーション開発をサポートする。Apacheに寄贈したFalconコンパイラもいずれ取り込むかもしれない。一方、Apache Flex SDKのサポートを強化するため, デザインビュー, データ中心開発ツール、Flash Catalystワークフローは今後リリースするバージョン4.xでなくなる予定。
  • Flash Professional
  • AIR for Linux SDK
  • LCDS (LiveCycle Data Service)
  • LCCS (LiveCycle Collaboration Service)

Apacheに寄贈するかどうか現在検討中のもの

  • TLF (Text Layout Framework)
  • BlazeDS.NET
  • Gravity
  • FXG (Flash XML Graphics)
  • Squiggles
  • OSMF (Open Source Media Framework)

開発停止するもの

  • Flash Catalyst(Adobe CSにも同梱されなくなる)

Flashランタイム(Flash Player/AIR)の今後について

  • Flash Player 11.2とAIR 3.2を2012年第1四半期にリリースする。これらはいずれもSDK 4.6でビルドしたアプリケーションに対してテストをおこなう。今後リリースするFlash PlayerとAIRもFlex SDK 4.6で動作するようにテストをおこない、5年間は後方互換性を維持する。
  •  Flex SDK 4.6以前のバージョンについては、今後リリースするFlash Player / AIRでも動作することをAdobeが保証するが、これからリリースされるApache Flex SDKについてはApache Flex Projectが互換性と動作保証について責任を持つ。 
  • これまではFlexアプリケーションのニーズに応えるためにFlash PlayerとAIRに機能を追加してきたが、今後はAdobeのFlashプラットフォームのビジョンを実現するために機能強化していく。Apache Flexプロジェクトが新機能を利用することもあるだろうが、Apacheプロジェクトのためだけにランタイムに新機能を追加することはない。


以上。

2012/02/25

Flah Playerのロードマップ

先日Flash Playerのロードマップ(Adobe roadmap for the Flash runtimes)が発表された。簡単に言うと、今回のロードマップで表明されたのは以下の2点だ。

(1) Adobeは今後、ゲームと高品質ビデオ向け機能の開発に注力する。
(2) 同時にアーキテクチャと言語にも改善を加え、Webと各種モバイルデバイスで最高のエクスペリエンスを提供していく。

ただし、ゲームとビデオ分野にフォーカスすると言っても、既存のコンテンツが動かなくなるとか、これら以外の分野でFlashが使えなくなるということではない。今後の開発とバグ修正に当たって、これらの分野の優先度が高くなるということである。ロードマップの原文は英語だが、ここのページは日本語でよくまとめられているので、時間がなければこっちだけ見れば十分だろう。

ゲームでもなくビデオでもないビジネスアプリケーション開発者としてはあまりありがたくない方向性だが、内容をよく見てみると必ずしもゲームとビデオ一辺倒というわけではなく、最悪の事態は免れたという印象だ。一時はこのままレームダック化してしまうかもと思ったが、マルチスレッド対応などコアな言語機能のエンハンスなども計画されており、順調に行けばこのまま現役で存続しそうだ。

ちなみにこれとは別に先週公開された「FlexについてのAdobeの見解と今後の関わり方」(Adobe's view of Flex and its commitments to Flex in the future)という文書では、Adobeは相変わらず「Flexは企業アプリケーションおよびデータ中心アプリケーション開発にベストなソリューション」と謳っている。ゲームとビデオにフォーカスしたランタイム上で動作する企業アプリケーションとなって妙な気分になるが、とりあえず深いことは考えないことにしておこう。



2012/02/22

Flash Playerのバージョン確認方法

Flexアプリケーションを開発していると、ときどき今実行しているFlash Playerのバージョンが確認したくなることがある。そんなときに便利なのが、AdobeのFlash Player の状況確認ページだ。単にブラウザでこのページにアクセスするだけで、インストールされているFlash Playerプラグインのバージョンがわかる。

このページを開くと下のような画面が表示される。ちょっとわかりにくいが、ページの中ほどの「Flash Player のバージョンを確認」というセクションに「Version Information」という欄があり、そこに「You have version 11.1.102.62」とあるのがバージョン番号だ。どういうわけかここだけ英語になっている。


バージョン番号の右側に赤い大きな文字で「最新バージョンは11.1.102.62です」のように現時点での最新版のバージョン番号も表示してくれるので、インストールされいてるFlash Playerが最新版かどうかもわかる。

気をつけなければならないのは、これはブラウザのプラグインとしてインストールされているFlash Playerのバージョンだということ。なので、Internet ExplorerとFirefoxで異なるバージョンのプラグインを使っていると、表示されるバージョンは当然違ったものになる。

このページの難点は、今使っているFlash Playerがデバッグ版かリリース版かがわからない点だ。一般のユーザーであればデバッグ版を使うことはあり得ないので問題ないが、アプリケーション開発者の場合はこの2つの違いが区別できないと困る。そういうときは、本ページの本家本元である英語版のページに行けば良い。

Flash Playerのバージョン確認ページ(英語サイト)
Check the status of Flash Player version

こちらには下のように日本語版のページにはない開発者用の情報が追加されていて、Flash Playerのバージョンのほか、デバッグ版とリリース版の区別、OSの種類とバージョン、Video/Audio/ローカルファイル入出力がそれぞれサポートされているかどうかまでわかる。というわけで、じつのところ日本語ページではなく英語ページだけ使えばいいだろう。

2012/02/12

AndroidでiCloudのメールを使う方法

今朝スタバでカプチーノを飲んでいるうちに突然思い立って、スマフォ(SharpのIS03)でiCloudのメールを読めるようにしてみた。

IS03には「PCメール」というメーラーがあり、これを使うと複数のアカウントのメールを読み書きできる。すでに2つのアカウントを設定していたのでiCloudもすぐできると思ったら意外に難航したので書いておく。

最初にApple公式の「iCloud:メールサーバの情報」を見てアカウント情報を設定し、受信(IMAP4)のほうはすんなり行ったのだが、送信(SMTP)のほうはどうやっても「サーバに接続できません」のようなメッセージが出てきてしまってうまくいかない。ちょっと検索して調べてみると、PCメール側の設定を"SSL"ではなく"TLS"にするとうまくとのこと。さっそくやってみると、確かにつながった。それにしてもApple公式のページには"SSL"と書いてあるのに、PCメール側は"TLS"とはどういうことだろうと思ってちょっと調べたところ、どうやら以下のようなことらしい。

まずSMTPでセキュアな通信をする場合、大きく分けて2つの方法がある。1つは最初からセキュアな通信路を確保してその上でSMTPを使う方法(以下、SMTPsと表記)、もう1つはまず通常通りSMTPセッションを開始し、その後STARTTLSコマンドを送信して同じポート上でセキュアな通信に移行する方法(以下、STARTTLS)だ。SMTPsでは通常、465番のポートを使うのに対し、STARTTLSでは普通どおり25番または587番のポートを使う。

問題なのは、この2種類の方法の呼称がちゃんと決まってないことだ。iCloudのメールサーバはSTARTTLSなのだが、Appleはこれを"SSL"と呼んでいるのに対し、IS03のPCメールは"TLS"と表記している。だからPCメールで"TLS"を設定するとうまくいく。一方、PCメールの設定項目で"SSL"を選ぶとSMTPsになるので、当然ながら接続に失敗する。世の中ではほかにも"SMTP over SSL"とか"SSL/TLS"などの呼び名も使われているが、いずれもどちらの通信方法なのかはっきりしない。結局メール設定時によくわからないときは、"SSL"であれ"TSL"であれ(あるいはそれ以外であれ)、とにかくそれらしい設定項目すべてを試してみるのが良いようだ。

ちなみになんでこんなに呼称が混乱しているかというと、そもそもSSLがTLSに名称変更されたという経緯があるのに加え、STARTTLSにしろSMTPsにしろ結局どちらもTLSを使うことにあるようだ。SSLはversion 3.0までは"SSL"と呼ばれていたが、その後"TLS"に改称された。このためよく"SSL/TLS"と表記されるが、一方で"SSL"という呼称も根強く残っている(もしかしたら実際にversion 3.0以前のSSLを使っているケースもあるのかもしれない)。なお、wikipediaのSTARTTLSの記事によると、メジャーなプロバイダーではGoogle(GMail)とApple(iCloud)がSTARTTLSを使っているとのこと。

参考文献
  1. メールの送受信でSSLを利用して暗号化する(@ITの記事)
  2. SSL versus TLS versus STARTTLS
  3. Bug 350314 - STARTTLS is called TLS in user preferences (remaining IMAP/POP3 case)
  4. STARTTLS (wikipedia)

2010/09/21

Flash Player 10.1.85.3 リリース

10.1.82.76以前のバージョンのFlash Player の重大なセキュリティ脆弱性を対策したFlash Player 10.1.85.3 がリリースされた。

最新版のFlash Playerのダウンロードはこちら

脆弱性の内容についてはこちら

脆弱性については9/13に発表されていたようだ。当初は9/27の週にセキュリティアップデートを出す予定だったが、前倒しでリリースされたらしい。なお、リリースノートを見る限り、今回修正されたのは上記セキュリティ脆弱性のみ。

2010/09/16

Flash Player "Square" リリース!

次期 Flash Player のプレビュー版、コードネーム "Square" がリリースされた。こちらを見ると、今回のリリースの目玉は64ビットOSサポート(Windows、Mac、Linux同時対応!)と、Internet Explorer 9βのハードウェアアクセラレーションレンダリングへの対応らしい。って、Internet Explorer 9は今日ベータ版が発表されたばかりだ。対応が早い!!!

とはいえ、Flash Playerチームのブログを見ると、「ここ数ヶ月、MicrosoftのIEチームと協力してやってました」とあるので、実際にはそれほど驚くことでもないのかもしれない。

ところで今回のIE 9対応だが、新たなGPUサポート機能のおかげでIE 8のときよりレンダリングが35%以上も高速化されるらしい。 wmode="transparent"のときのレンダリングもかなり速くなるみたいなので、今悩まされているwmode="opaque"のときのスクロールの遅さも、もしかしたら大幅に改善されているかもしれない。

 もっともIE 9ではHTML 5もサポートされるので、IEBlogのコメント欄なんかを見ると、「これでFlashも要らなくなる」といった意見もあるようだ。実際には、HTML 5が普及するにはずっと時間がかかるだろうから、Flashはそう簡単にはなくならない。IE 8以前のブラウザだってしぶとく残るだろうし、Webサイトがどこもかしこもvideoタグやcanvasタグを使うようになるのはさらに先だろう。