カスタム検索
ラベル Javascript の投稿を表示しています。 すべての投稿を表示
ラベル Javascript の投稿を表示しています。 すべての投稿を表示

2009年1月27日火曜日

Air(Flex)か〜ら〜のHTMLか〜ら〜のJavascript

AirのHTMLタグから、パッケージに含んだファイル(とかローカルファイルとか)を読み込む方法



var file:File = new File("app:/html/index.html");
var src = new File(file.nativePath).url;
html.location=src;

<mx:HTML id="html" />


パッケージ内にあるJavaScriptは相対パスで読めます。
HTMLとinclude.jsが同じ場所にあるとすれば以下のように。

<script src="include.js"></script>


JavaScriptが全然別のドメインとかでもひっぱてきて使えちゃいますよ。

<script src="http://hoge.jp/outer.js"></script>

なんでJavaScriptのコアをどっかにおいておけばアプリ本体を更新せずにサーバのJSを置き換えて更新も出来ちゃう。

でもってAirからHTMLでロードした中のJavaScriptの実行方法
htmlのcompleteイベントからdomを取得出来るので、、、

private function loadCompleteHandler(e:Event):void {
dom=e.currentTarget.domWindow;
}
<mx:HTML id="html" location="{src}" width="100%" height="100%" complete="loadCompleteHandler(event)" />


domの直下にスクリプトがバインドされているので、それを実行すればオッケィ

html.functionName();

2008年1月22日火曜日

Ext-JS 2.0 速度検証(フォームapplyTo,transform編)

前回のサンプルに近い適当なフォームを用意して 100個作成と applyTo と transform で作ってみました。

ext-base
11712ms

・・・で、FireFoxがハングします(´・ω・`)
早くもないしちょっぴりショック、、、

で、気をとりなおして Safari でも計測

Safari
1306ms

            スポポポポポポーン!!!
      。     。
        。  。 。 。 ゚
       。  。゚。゜。 ゚。 。
      /  // / /
     ( Д ) Д)Д))


Safariはやいなー、JSの実行もエレメントの追加/削除もFirefoxとは比べ物にならない早さ・・・
ただComboBoxがうまくtransformできませんでした(´・ω・`)
(セレクタの位置が変な所にいってしまいます)

うーん、JavaScriptでダイナミックにフォームを作るのはもう少し様子見で・・・

Ext-JS 2.0 速度検証(FormPanel)

Javascriptのコンパイル(圧縮)で計測に使ったJSの重い処理ですが、
Ext-JS1.1を使ってダイナミックにフォームを作ってます。

Ext-JS2.0では早くなったのか検証してみました。(同じ処理をしているわけでないので比較にはならないですが、、、)

まず公式サンプルのフォームを使ってテストしてみます。
リンク先の Form 1 - Very Simpleです。

このフォームを100個作成してかかった時間をはかっています。(FireFoxで行いました)

ext-base
10488ms
10768ms
11003ms
10428ms
10556ms

jQuery 1.1.1
10824ms
10961ms
10877ms
11029ms
11118ms

yui-utilities 2.2.0
10778ms
10793ms
10547ms
10954ms
10502ms

prototype 1.5.0
10840ms
10502ms
10507ms
10852ms
10898ms

変わらんですね〜、んでは$()が300%早くなったという噂のjQuery1.2.2を使ってみましょう、、、

jQuery 1.2.2
10856ms
11147ms
11139ms
11134ms
11140ms

・・・(#^ω^)ピキピキ

せっかくなんでやたらと快適な Safari3 でも試してみました。

safari(ext-base)
5874ms
5845ms
5885ms
5902ms
5881ms

  。 。
 / / ポーン!
( Д )

・・・えーっと、ってことはブラウザのエレメントの追加/削除が単純に重くてJavascriptが悪いって事ではないのかな
(Firefox最近やたらと重いんだよなぁ、、、拡張もたいしていれてないのに、微妙になってきたなぁ)

次回は、dom操作が少ないと思われる、既存のフォームからext-formへapplyしていった場合の速度を計ってみたいと思います。

2008年1月8日火曜日

Javascriptの圧縮(gzip編)

まずは容量比較から

通常状態(788kb)
yuicompressor(718kb)
yuicompressor+gzip(196kb)

おー、だいぶ変わりましたね。

続いて読込み/スクリプト実行速度の計測です。

1770ms / 3856ms
1790ms / 3798ms
1690ms / 3797ms
1820ms / 3738ms
1620ms / 3793ms

ローカルだと違いが出ませんでしたが、容量はあきらかにへっているので、実運用では有効に働きそうですね。
ただローエンドなクライアントでgzipの処理がどの程度負荷になるのか気になるところです。

2008年1月7日月曜日

Javascriptのコンパイル(圧縮)

Javascriptの圧縮をYUI Compressorでテストしてみました。
圧縮によるクライアントへの受信速度と、圧縮されたスクリプトの実行速度の計測です。

対象となるのは、サイズばらばらのJavascript16ファイル(全788kb)を表示、
JavaScriptにて約1000のエレメントを追加するページ。

無圧縮(788kb)でのロード時間 / スクリプト実行時間
1530ms / 3776ms
2360ms / 3751ms
2650ms / 3789ms
2290ms / 3754ms
1500ms / 3789ms

圧縮時(718kb)のロード時間 / スクリプト実行時間
2480ms / 3818ms
1980ms / 3766ms
2520ms / 3788ms
1480ms / 3761ms
2470ms / 3713ms

か、かわんねぇ〜・・・ローカルで動かしてるから通信速度が遅いほど効果はあると思います。
とりあえず圧縮してもスクリプト自体の実行速度は同じ、と(当たり前か)
(容量があんまりかわってないのは元々圧縮されたものが多いため)

というわけで次回は+gzipで計測してみます。