原文地址：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视频和渲染系统。