Flash Player 10.1內部機制(第一部分) - Flash Player統一代碼庫及其挑戰

原文地址:http://blogs.adobe.com/xwlin/2010/04/flash_player_101_-_adobe_max_2009.html

演講人: Lee Thomason ([email protected])
翻譯: 林曉偉 ([email protected])

序言
時間: 本月21號 地點:北京國際會議中心。 Adobe即將迎來爲期2天的Flash平臺技術峯會, 我將有幸作爲Ely Greenfield輔助演講人蔘與<<Flash Player內部機制>>這一話題的演講和翻譯工作, Ely Greenfield是Apollo Integrated Runtime部門的Senior Principal Scientist, 他在2007年Adobe Max大會上曾經作過這個話題的非常精彩的演講,google上搜索到了一個參加07年Max大會的哥們對Ely本人及其演講的評論,"我認爲Ely的topic(Flash Player內部機制)在整個Max大會所有topic裏是最棒的..." "Ely就是那個傳說中閉着眼睛用三天的時間編寫了Flex Charting Framework大部分代碼的傢伙"...

Adobe 09年的Max大會仍然有Flash Player內部機制這一話題,不過演講者是Lee Thomason(另一個骨灰級牛人, Flash Player架構師, 外號Player Guy, 據說是Flash Player第一人), 這是一個非常有深度的話題, 演講速度很快,一個小時的時間涉及到了player架構方方面面儘可能多的技術, 在這裏我將他的大致演講內容總結翻譯一下, 供大家參考.

構建Flash Player
過去,手機版FlashLite和桌面版Flash Player是截然不同的兩個獨立產品,由兩個相互獨立的部門各自開發維護, FlashLite部門有自己的發展目標,產品定位及功能特性,項目的開發計劃也由自己來決定。這給兩個部門帶來了很多的緊張情緒和挑戰因此Adobe決定將這兩個部門合併,合併意味着即將發佈的Flash Player 10.1手機版和桌面版將基於同一代碼庫構建。

Lee在Max大會中提到大約20%的Flash Player代碼仍然是平臺相關的,這些代碼針對於Palm, ActiveX, OS X, Netscape等做特殊處理,不同平臺之間存在諸多差異因此實現100%的通用代碼庫是不可能的,但這仍然意味Flash Player代碼庫中80%的代碼是平臺無關的。

一個代碼庫,更多的Player類型.
統一player代碼庫更方便Adobe制定針對手機、瀏覽器、桌面等多種player的一致的發展戰略,同時這也給Flash Player部門和開發者社區帶來了新的挑戰。

第一個挑戰就是各平臺之間的處理能力(主要是CPU)以及內存大小相差迥異並且這種差距愈演愈烈.一個服務器的8核CPU和掌上設備Palm Pre的處理能力大相徑庭,而PC機瀏覽器平臺可以提供幾個G的內存但掌上設備只有20兆這將促使開發人員以截然不同的方式開發應用。注意:我們並不是說在PC瀏覽器上我們不需要考慮內存使用的問題,只是相比於掌上設備後者更爲顯著。

第二個問題也就是統一化界面面臨的屏幕大小和像素深度的設備差異。今天,越來越多的應用程序跨設備運行,因此深刻理解有限的屏幕如何佈局像素如何高效使用變得越來越重要。

LCD顯示器的像素深度(每平方英寸的像素數)要比手持設備小得多,這意味着一個40像素的按鈕在你的LCD屏幕上看起來很大但在Pre上卻太小了以至於無法使用。同樣的,即使是分辨率相同的兩種掌上設備像素深度仍然可能不一樣,iPhone 3GS的屏幕大小3.5英寸,分辨率320*480,像素深度爲163PPI,而同樣分辨率的Palm Pre屏幕大小隻有3.1英寸,像素深度爲186PPI。因此如果我們只是考慮分辨率設計UI的話,那麼player認爲大小一樣的兩個按鈕,在iPhone上的那個工作正常但在Pre上的那個就可能無法工作。

另一挑戰來自於不同設備所支持的用戶交互方式的多樣化,有的設備支持鍵盤鼠標,有的設備支持多點觸摸,等等,flash player需要理解不同的用戶輸入設備,我們做爲開發人員需要理解輸入設備多樣化會給我們開發應用帶來什麼樣的影響。在針對支持多點觸摸的設備開發應用的情形下,我們需要知道手指並不是一個可以精確定位到像素的輸入設備。Player要給我們提供最準確的相關信息,從最低層的原始數據到最上層的用戶操作比如擦除、輕按。

最後一個來自於戰略一致化的挑戰在於用戶對於應用的期待會根據設備的不同而發生變化。對性能和可用性的期待會基於用戶當前是在使用手機還是桌面瀏覽器而發生改變。在手機上,一旦有新的來電當前應用必須在10毫秒內關閉,如果player做不到這一點,那麼用戶就會失望。

Flash Player本身並不是戰勝所有挑戰的祕方良藥
以上分析的唯一結論是,我們不能寄希望於Flash Player解決所有的問題;事實上,作爲開發人員,我們要深刻理解應用的發佈平臺,同時要知道良好適用於一個用戶/設備組合的設計方案可能根本不適用於另一個。隨着我們開始着手針對越來越多截然不同的設備平臺進行應用開發,我們要始終把這些因素記在心裏。

以上是這個話題的第一部分,在第二部分,我們將探討執行模型和player體系架構,在第三部分,我們討論一下ActionScript的第二代虛擬機做了哪些改進,第四部分我們將深入Flash視頻和渲染系統。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章