Flash真的適合做網站應用嗎？
兩年前，我們開發了一套基于Flash的文件(主要是圖片)上傳RIA應用，提供給阿里巴巴的用戶使用。如果你使用過Wordpress或flickr上傳圖片，你應該已經用過類似的產品。這個程序基于YUI Uploader開發，增加了一個實用的功能——在客戶端先將圖片縮小，再上傳到服務器。用戶用數碼相機拍攝的照片往往有600萬以上的像素，但產品圖片放到阿里巴巴網站上 顯示，并不需要這么大的像素，通常等比例縮小到1024×1024之內就可以了。借助于Flash對圖片先縮小再上傳的技術，我們在沒有增加服務器投入的情況下，將原先上傳圖片的尺寸限制由250KB/張提升到了5MB/張。同時，Flash上傳還比傳統HTML表單方式上傳有更好的體驗，例如可以多選一 批文件同時上傳、可以實時展示上傳進度、選擇文件時可以過濾非圖片文件。
這個組件獲得了很大的成功。上線后不久，阿里巴巴網站上用戶的圖片上傳數量由日均1萬張左右上升至日均15萬張左右。但在這個上傳應用投入應用的兩年中，我們遇到了各種問題。
1. bug
在基于IE多標簽瀏覽器中的偽沙箱問題就 不說了，最嚴重的是cookie的問題。使用FileReference.upload的方式上傳文件，http請求中附帶的cookie信息不一定是當 前瀏覽器進程的cookie，在Firefox、chrome等非IE瀏覽器中非常嚴重，可能傳輸的是IE中的cookie。即便是IE，也可能傳輸的 cookie內容和當前頁面的cookie記錄不符合。這直接導致服務器端在收到文件之后的安全驗證中失敗。而對于阿里巴巴這樣的大型網站，有比較成熟的 java web框架，要去掉對cookie的依賴非常麻煩。于是結果就是，首先我們只有在用戶使用IE系瀏覽器的時候才使用Flash上傳，其次我們隔三岔五的還 會收到使用IE的某些客戶的投訴，在花費了大量的時間排查之后，我發現是由于cookie的問題導致上傳失敗。這個bug已經存在很多年，但是隨著Flash從9升級到10，許多版本過去了，問題依然沒有被解決。對于閉源的Flash，我們非常被動。
2.性能
相對于現今數碼相機的像素量，5MB的大小限制非常保守。但大于5M的時候，在一些低配置的電腦上，讀取文件內容的時候就會發生瀏覽器假死現象。假死很容易導致瀏覽器崩潰，所以我們采取了保守的限制——5MB。
另外一個性能消耗是將BitmapData編碼成JPEG文件的時候。Adobe提供了JPEGEncoder，但由于是Array實現的，所以性能是個問題。編碼一個2880×2880的圖片在一臺中等配置的電腦上大約需要15秒時間。
我用Vector改寫了這個類，時間縮短為3.5秒左右。使用Alchemy，時間進一步縮短到1.5秒左右。但還是不夠安全，所以***采用了異步Vector的方式，延長編碼的時間，以保證程序的穩定性。(評測在這里)
3.圖片質量
Flash內置的***的圖片縮小算法(用BitmapData.draw，并將smoothing參數設為true)，在縮小圖片的時候容易產生鋸齒。因此我改寫了Jacwright提供的縮小算法，圖片質量的問題解決，但代價是性能又降低了一些。
4.安全限制
Flash10.0 之后，增加了一個安全限制——當URLLoader以標準文件上傳的方式發送POST請求的時候，需要由用戶的UI操作(鼠標點擊或按鍵事件)觸發。因為 我們對用戶的圖片做了處理，已經無法再通過FileReference上傳，只能通過URLLoader。這個安全性限制規定每次發起一個上傳文件的 URLLoader請求，都必須讓用戶點擊一下鼠標才可以。如果用戶選擇了20張圖片，就要點擊20次鼠標。這顯然是無法接受的。因此我們放棄了用標準文件上傳，采用普通post形式。代價是失去了對上傳進度的跟蹤，不知道文件上傳的百分比;同時服務器端也需要改造。
改變
最近，我們做了一個決定：開發一個類似功能的ActiveX控件，替代Flash作為圖片上傳的主要解決方案。ActiveX的優勢是性能，不足之處在于只 能在Windows+IE瀏覽器中使用，但實際上我們的Flash上傳目前也只能在IE中使用。Flash真的適合像阿里巴巴這樣的網站使用嗎?閉源和性能是Flash***的問題。但在HTML 5被廣泛支持前，Flash和傳統Ajax還是我們最主要的富客戶端應用開發技術，相對于ActiveX、 Silverlight、JavaFX、Gear等技術來說，Flash還是有安裝率優勢的。目前Flash依然是我們很重要的RIA技術。
但是HTML 5完全到來的那一天，現在很難說。
原文鏈接：http://news.cnblogs.com/n/97560/
【編輯推薦】
