2012年5月1日火曜日

SDK 2.0.1でも描画問題への対処は必要(1)

このブログでは、Titanium Mobileを使った際の画面表示の問題と格闘してきました。少し前の投稿では、リリースされたSDK 2.0.1GA2を使うことで、最大の問題だったImageViewやLabelが変な位置に表示される症状が、直ったとの速報を書きました。あれから使い続けていますが、症状は1回も発生していません。直っているのは確実なようです。

描画関係では他にも問題があり、その1つ1つが直っているのか、直っていないなら同じ対処方法で大丈夫なのか、1つずつ見直したいと思います。まずは、Viewのレイアウト変更への対処を取り上げます。

 

以前の投稿「Viewはshowしたときに描き直されるもの?」で、レイアウトを変更したときの対処方法を書きました。おさらいすると、問題は、hideしていたView上にあるImageViewやLabelの画像やテキストや位置を変えた後、showすると変更前の状態が一瞬だけ表示されることでした。フラッシュバック症状と呼んでいます。対処方法は、Viewの透明度を限りなく透明に設定してからshowし、setTimeoutで遅れて透明度を不透明に戻す方法でした。

まず調べたのは、SDK 2.0.1GA2でも、UI部品を変更する前の状態が一瞬表示されるフラッシュバック症状が出るかどうかです。setTimeoutの遅延時間を極端に短い1に設定して、シミュレータ上の動作を見てみました。結果は、前と同じです。SDK 2.0.1GA2でも、同様のフラッシュバック症状が出ました。つまり、この部分の動きは変わっていないということです。

ただし、何も対処していないわけではありません。SDK 2.0からは、プログラムの作り方で対応するように、新しい機能が追加されています。the UI Layout Systemが更新され、UI部品の大きさに関するデフォルト値が変わりました。同時に、描画での作業終了を考慮した機能が追加されています。それぞれのUI部品ごとに、複数プロパティを変更するときの処理を1つとして扱い、全部が終ったら描画する形も可能になりました。具体的な方法が2つ用意されていて、まずupdateLayout関数では、複数のプロパティを一度に指定できます。もう1つのstartLayout関数とfinishLayout関数はペアで使い、この間にプロパティの変更処理を入れます。

さらに、描画内容を生成し終わるまでの待つ機能が加わっています。それがpostlayoutイベントで、変更するViewやUI部品にイベント処理を加えれば、setTimeoutで処理を遅らせる必要はありません。setTimeoutで遅らせる方法では、少し余裕を持った待ち時間を設定するため、全体として処理が遅くなります。ところがpostlayoutイベントで知らせる方法だと、描画内容を生成し終わったら始められますから、無駄な待ち時間は生じないはずです。

SDK 2.0.1での変更点は、Appceleratorの開発者向けドキュメントに記述してあります。興味のある方は「Transitioning to the New UI Layout System」を読んでみてください。

 

開発中のアプリで、SDK 2.0.1GA2での改良を反映させてみました。フラッシュバック症状は前と同様に出ますから、時間を遅らせて表示させる処理は必要のままです。ただし、実現方法としては、setTimeoutで遅延させる方式から、postlayoutイベントで処理を開始する方式へと切り替えます。これで無駄な待ちが少しは減るでしょう。まずは、これまで実施していたsetTimeoutによるコードです。

// 修正前(setTimeoutを使用)
view1.hide();          // view1を非表示にします
view1.opacity = 0.001; // view1を限りなく透明にします
label1.top = 40;       // view1上のUI部品のプロパティを変更して、画面上のレイアウトを変えます
label1.left = 30;
imgView.top = 120;
...
view1.show();                  // view1を再表示します
setTimeout(resetOpacityF, 50); // 50ms後に、不透明に戻すfunctionを起動させます
// この関数は、ここで終了

function resetOpacityF(){      // 時間差攻撃で、view1を不透明に戻します
    view1.opacity = 1;
}

これを、処理内容は同じまま、postlayoutイベントで処理するコードに切り替えます。具体的には、次のように作ります。

// 修正後(postlayoutイベントを使用)
view1.hide();          // view1を非表示にします
view1.opacity = 0.001; // view1を限りなく透明にします
label1.top = 40;       // view1上のUI部品のプロパティを変更して、画面上のレイアウトを変えます
label1.left = 30;
imgView.top = 120;
...
view1.show();                  // view1を再表示します
view1.addEventListener('postlayout', resetOpacityF); // イベント処理を設定します
// この関数は、ここで終了

function resetOpacityF(){      // postlayoutイベントで、view1を不透明に戻します
    view1.removeEventListener('postlayout', resetOpacityF); // イベント処理をクリアします
    view1.opacity = 1;
} 

setTimeoutの代わりとして、postlayoutイベント処理関数をaddEventListenerでViewに加えています。これで描画内容の生成終了待ちとなります。postlayoutイベントが発生すると、設定したイベント処理関数の実行が始まり、まず最初にremoveEventListenerでイベント処理関数を削除し、本来の処理を開始します。以上のように、ほとんど前と同じままで、変更が完了してしまいました。

 

view1をshowした直後にpostlayoutイベント処理を追加し、そのまま待ちます。本来ならshowする前にイベント処理を追加すべきなのですが、描くのに時間がかかるためでしょう、これでも問題なく動きました。さらには、UI部品の変更を1つにまとめる変更もしなければならないのですが、それをする前に試しに動かしたら、正常に動いてしまいました。すぐにremoveEventListenerを実行しているためでしょうね。アプリの動作としては、フラッシュバック症状が発生せず、とくに副作用もありません。こんなに簡単に動いて良いのでしょうか、と疑問に思うぐらい簡単に動きました。

本来であれば、UI部品の箇所も一緒に変更して公開すべきでしょう。でも、簡単な変更でも正常に動いたので、これも面白い情報だと思って公開しました。完全ではない変更でどのように動くかも、意外に貴重な情報となるからです。期待どおりに動かなかったケースで、こういう完全でない変更での動きが、解決方法を見付けるヒントになったりしますので。

 

動いたのを確認しただけでは、ちょっと満足感が不足です。postlayoutイベントが発生するまでの時間はどの程度なのか、やはり気になりますよね。そこで、イベント発生までの時間を計測してみました。addEventListenerの直前に時刻を計り、removeEventListenerの直後にも時刻を計って、差を求めるだけです。イベント処理の追加と削除を含めたのは、これらの処理も含めた経過時間を知りたかったからです。計算した時間差を表示する機能を加えて、実際に実行してみました。

描画内容を生成する時間は、UI部品の種類や数や変更内容によって左右されます。計測結果は、あくまで今回のアプリの場合です。postlayoutイベントを使った箇所は2つで、両方とも測定しました。1番目の箇所は、変更するUI部品の数が6つで、4つがLabel、2つがImageViewです。6つとも位置を変更し、それぞれの値であるテキストと画像も毎回変更します。たまにですが、一部のUI部品で位置だけ変更しない場合もあります。こうした条件のアプリをシミュレータ上で計測したところ、最低では0、最高で41の値となりました。数値の単位はミリ秒で、マシンは現行の13インチMacBook Air(Core i5 1.7GHz Dual)です。発生頻度が一番高いのは0で、全体の3割ぐらいを占めていました。0を含めた一桁台が全体の半分程度ありました。数値が極端に大きいときは、画像をメモリーに読み込んでいるとか、ガベージコレクタが動いているとか、特別な条件なのでしょうか。原因は不明です。

2番目の箇所は、変更するUI部品が半分の3つで、2つがLabel、1つがImageViewです。これらへの変更内容は1番目と同じですが、透明度を変更する処理が加わっています。上記のサンプル・コードは、この2番目の箇所のものでした。計測すると、50〜52と値はほぼ一定でした。このようにバラツキがほとんどないのが普通だと思います。1番目の箇所でバラツキが生じた理由が分かりません。

同じ計測を、実機でも試してみました。初代iPadで実行すると、1箇所目は最低が6で、最高が62でした。全体的に値が大きくなっています。頻度としては小さな値の比率が大きく、とくに一桁が半分程度を占めるという変な結果となりました。バラツキの傾向も非常に似ていて、シミュレータが正常に機能していることを証明した感じです。まあ、当たり前の結果でしょう。2番目の箇所もシミュレータと似ていて、値は56〜67とバラツキは小さいです。1番目の箇所と同様に、シミュレータよりも少し遅くなっています。

余談ですが、setTimeoutでは50に設定していたので、最高が67という結果では、修正前の50という値が小さすぎたのかも知れません。しかし、実機でかなり使いましたが、描画の問題は出ませんでした。postlayoutイベントが発生するタイミングに多少の余裕があるのか、描画内容としてギリギリだと目立たないのか、その辺は分かりません。修正前の50という値は、単なる偶然ですが、一番遅い初代iPadによる実機での動作としては絶妙な値だったのでしょう。

 

計測結果では、片方の描画は非常に短い時間が多くなりましたが、実機を触っている限り体感できません。もともと短い時間なので、少しぐらい減っても体感できないのでしょう。今回の修正により、固定した時間だけ遅らせるのではなく、実際の描画内容生成が終わるまで待つ形になりました。処理としては、より良い形になっています。あまりにも簡単な修正でしたが、最適化された形となりました。今後も、似たような状況では、postlayoutイベント処理を使うでしょう。

UI部品の変更は、次の投稿で書きます。また別な症状の確認も残っていますから、それは後でということで。

0 件のコメント:

コメントを投稿