tinic on FP8 GC

tinic的文章

總工程師出面說明 flash player 8 garbage collection 比較有說服力

flash 7 –> flash 8 無痛移轉大法

今天正式移到 flash 8 上工作，把正在進行中的案子拿來重新compile一次看出現那些錯誤，結果如預料中，都是remoting的部份找不到適當的class，簡單整理移轉手續：

1、將flash 7的 mx.remoting.* classes移到 flash 8下面：

OLD: C:\Documents and Settings\user_name\Local Settings\Application Data\Macromedia\Flash MX 2004\en\Configuration\Classes\mx\remoting

NEW: C:\Documents and Settings\user_name\Local Settings\Application Data\Macromedia\Flash 8\en\Configuration\Classes\mx\remoting

2、將 flash 7 mx.rpc.* 移到 flash 8下面：

OLD: C:\Documents and Settings\jx\Local Settings\Application Data\Macromedia\Flash MX 2004\en\Configuration\Classes\mx\rpc

NEW: C:\Documents and Settings\jx\Local Settings\Application Data\Macromedia\Flash 8\en\Configuration\Classes\mx\rpc

就這兩個手續，接者就可以在flash 8上開發程式囉！

當然如果早先你有對mx.* 系列的class動過手腳的話，這部份就要靠diff/merge小心的編進去，不過就如前幾篇文章所言，這次mm並沒有對元件做太多的變動，所以理論上只要用 auto merge整合進去應該就行。

setTimeout() 終於內建了

setTimeout是許多語言都有的function, 功能類似 setInterval()但只會執行一次，這也是javascript內建的語法，可是奇怪的是號稱 為ECMAScript家族一員的actionscript卻從來沒見著過這個指令。

現在 flash 8終於有內建這個function, 再也不用從 com.richtech.Tools 內匯入自家釀照的method了。

不過 flash 8 的 setTimeout() 與 clearTimeout() 不幸的卻沒記載在help與 online doc中，下面簡單說明它的用法：

從上面的語法中可以知道 setTimeout()接受三個參數，分別是function名稱、delay秒數與參數；並且就像setInterval() 一般也接受另一個型式的參數，也就是第一個變成 scope，這種語法在某些情況下非常好用，但大部份人應該用第一種就夠了。

setTimeout()執行後會傳回一個數字，做為clearInterval()的reference，不過一般用到的機會應該比較少，因為它不像setInterval()會不斷的重覆執行下去，只會跑一次就停，就算不人工clearTimeout()應該影響也不大。

另外要注意的是 setTimeout()與clearTimeout()無法在外部的class檔使用，因為沒寫入intrinic class (toplevel.as)裏面，變通方法是用

_global.setTimeout()
_global.clearTimeout()

mm實在很愛偷用 _global藏東西啊~這種手法在flex裏更為明顯，只是這麼廣泛的使用 global variables 難保不會有天大爆炸哩....

最後，使用 setTimeout() 就跟 setInterval()一樣要留意作用範圍，不然有可能發生：

1、要執行的function找不到

2、要移除的timeout沒生效

再探 flash memory leak 問題

flash VM 有不少memory leak問題是大家早就知道的事，通常比較明顯的症狀是記憶體不斷被吃掉，有時一個flash 程式甚至可以吃到1GB左右的ram(如果你有裝那麼多的話)，而比較確切的証據是virtual memory快速的消失，但實體 memory不會有太大變動。

＊memory leak的2個原因

會發生這種事主要的原因有兩個

1、flash VM 的 garbage collection設計不良：flash player 7是採用 reference counting的方式在記錄那些物件該在每一次的GC中被移掉(例如已用不到的object, variable, movieclip...)，但麻煩的地方在於flash的程式中都是 passing by reference，因此往往一個物件生成後，會被許多其它物件以reference的形式保存起來，結果這就造成VM在做GC時基本上什麼也不敢移除，這樣東加名加，當物件一多時，memory leak就來了。

2、程式本身寫作不良：在之前的文章中曾提過「清垃圾之重要」，許多人(99%的設計師與70%的as coder)寫程式時並沒有順便清垃圾的觀念，例如用完的變數就隨手delete 刪掉，或是已用不到的movieclip就用 unloadMovie(), removeMovieClip()移除，而這些沒拿掉的變數、物件與MC就是吃掉memory的元兇。

更糟的是，當flash 程式的生命週期變長時這個問題會更嚴重，以往做個game或片頭動畫甚至是全flash的網站，通常都只會在browser內存在幾分鐘(因為game一下就玩完了、片頭動畫可以按skip跳過而全flash的網站十個有二十個做的usability很糟因此user會直接關掉閃人), 在生命週期很短的情況下，就算有memory leak的情況也難以嚴重到造成大問題。

但當flash成為一個platform而用於application時，這個問題就嚴重許多，因為通常app的生命週期都會很長，短則十分鐘，長則一整天都開者(例如像word, outlook)，這種情況下memory leak就有可能造成很嚴重的後果，例如讓電腦當掉或吃光cpu資源最後user只好重開。

對於這件事，macromedia其實不是不知道，下面是在list上看到的一段qoute:

We contacted MM and after several phone conference calls and sending
them a bunch of source we were informed that the Flash player was not intended to run as an application for long periods of time.

沒錯，看到這段時我跟你一樣嚇出一身冷汗，這個回答就好比toyota跟你說：呃，我們的altis並不是設計來高速行進，因此如果你開超過80km/h而出車禍就不是我們的錯囉....

＊現行的解決方案

不過好在這件是發生在flash player 7 非常早期的時後，而這個問題在flash player 8 也已獲得很好的解決，方法就是採用其它vm做GC 的方式，不用要reference counting而是用total collection來記錄每個物件的狀態，並且讓GC發生的頻率更多也更有效率。

當然有一點還是要記得，VM內建的GC是最後一道防衛，並不代表寫程式的人就可以隨心所欲放任用不到的東西散亂一地，能夠養成隨手清垃圾的習慣長遠來看一定還是會有好處的(至少可能不會再有一堆莫名其妙的infinite loop)。

同時按照過去新player發表的記錄來看，通常要四到八個月的時間新版player的 penetration率才能到達90%以上，這代表從現在到年底甚至明年三四月這段期間，大部份人仍然會使用flash player 7 (也就是有memory leak問題的版本)，因此與其等待天堂靠近，不如自已走過去吧 ‧

不過另一件值得高興的事是這次mm也推出了新的線上安裝方式，下載速度更快，出錯機率更少，同時由於flash player 8實在有者太多吸引人的feature sets，因此應該可以引誘一般使用者更有意願下載安裝(例如為了看到即時的bitmap 影像效果，或是使用檔案上下傳的功能 -- 個人推測不出一個月就會有人寫個flash版的相簿管理程式，做到類似 picas 的事，像這樣的應用就非常需要 flash player 裏的 upload/download 功能了。)

amfphp 改裝技巧

patrick 在 Hacking AMFPHP into submission: Caching這篇文章簡單介紹了amfphp的運作原理，主要是下面這個流程：

Deserialization ->Headers -> DescribeService -> Authentication -> BatchProcess -> Debug ->Serialization

其中最重要的部份就是解答了如何將mysql的query resultset做cache以加快反應速度並減少連線次數。

目前看來最直接的方法是從app/Gateway.php 內的 registerActionChain 與 registerFilterChain 這兩支method下手，先extend出來後再加進需要的code，感覺上不是很難，而且用這個方法可以動手腳加料的地方還很多，似乎是值得嚐試的選擇。

但另一方面我則比較偏向在server端用某種database abstraction 機制來完成cache，這樣做一次可以用在很多地方，通用性高一點。