在基于IE多標(biāo)簽瀏覽器中的偽沙箱問題就不說了，最嚴(yán)重的是cookie的問題。使用FileReference.upload的方式上傳文件，http請求中附帶的cookie信息不一定是當(dāng)前瀏覽器進(jìn)程的cookie，在Firefox、chrome等非IE瀏覽器中非常嚴(yán)重，可能傳輸?shù)氖荌E中的cookie。即便是IE，也可能傳輸?shù)腸ookie內(nèi)容和當(dāng)前頁面的cookie記錄不符合。這直接導(dǎo)致服務(wù)器端在收到文件之后的安全驗(yàn)證中失敗。而對于阿里巴巴這樣的大型網(wǎng)站，有比較成熟的javaweb框架，要去掉對cookie的依賴非常麻煩。于是結(jié)果就是，首先我們只有在用戶使用IE系瀏覽器的時(shí)候才使用Flash上傳，其次我們隔三岔五的還會收到使用IE的某些客戶的投訴，在花費(fèi)了大量的時(shí)間排查之后，我發(fā)現(xiàn)是由于cookie的問題導(dǎo)致上傳失敗。這個(gè)bug已經(jīng)存在很多年，但是隨著Flash從9升級到10，許多版本過去了，問題依然沒有被解決。對于閉源的Flash，我們非常被動(dòng)。

　　2.性能

 

　　相對于現(xiàn)今數(shù)碼相機(jī)的像素量，5MB的大小限制非常保守。但大于5M的時(shí)候，在一些低配置的電腦上，讀取文件內(nèi)容的時(shí)候就會發(fā)生瀏覽器假死現(xiàn)象。假死很容易導(dǎo)致瀏覽器崩潰，所以我們采取了保守的限制——5MB。

 

　　另外一個(gè)性能消耗是將BitmapData編碼成JPEG文件的時(shí)候。Adobe提供了JPEGEncoder，但由于是Array實(shí)現(xiàn)的，所以性能是個(gè)問題。編碼一個(gè)2880×2880的圖片在一臺中等配置的電腦上大約需要15秒時(shí)間。

 

　　3.圖片質(zhì)量

 

　　Flash內(nèi)置的最好的圖片縮小算法（用BitmapData.draw，并將smoothing參數(shù)設(shè)為true），在縮小圖片的時(shí)候容易產(chǎn)生鋸齒。因此我改寫了Jacwright提供的縮小算法，圖片質(zhì)量的問題解決，但代價(jià)是性能又降低了一些。

 

　　4.安全限制

 

　　Flash10.0之后，增加了一個(gè)安全限制——當(dāng)URLLoader以標(biāo)準(zhǔn)文件上傳的方式發(fā)送POST請求的時(shí)候，需要由用戶的UI操作（鼠標(biāo)點(diǎn)擊或按鍵事件）觸發(fā)。因?yàn)槲覀儗τ脩舻膱D片做了處理，已經(jīng)無法再通過FileReference上傳，只能通過URLLoader。這個(gè)安全性限制規(guī)定每次發(fā)起一個(gè)上傳文件的URLLoader請求，都必須讓用戶點(diǎn)擊一下鼠標(biāo)才可以。如果用戶選擇了20張圖片，就要點(diǎn)擊20次鼠標(biāo)。這顯然是無法接受的。因此我們放棄了用標(biāo)準(zhǔn)文件上傳，采用普通post形式。代價(jià)是失去了對上傳進(jìn)度的跟蹤，不知道文件上傳的百分比；同時(shí)服務(wù)器端也需要改造。