By from Ars Technica | EchoKou 译，Logout 校，转载请注明 ifanr.com 译文链接。

Google 已经在为 Nexus One 推送 Android 2.2 官方更新，代号 Froyo。新版操作系统带来了极其可观的性能提升、好几个不错的新功能、一些用户界面上的小改进、并且还为开发者带来了一些实用的新 API。Froyo 上的新增内容填补了系统的一些缺憾，提升了 Android 系统相对于其它对手的竞争实力。

五月的 Google I/O 大会上，Google 工程副总裁 Vic Gundotra 在主题演讲中首次介绍了 Froyo。稳定平台，为 Nexus One 推出官方升级包所花的时间比预计的要长，现在用户已经可以 OTA 升级到新的版本。我们也进行了测试，看看跟以前的版本相比会怎么样。

批量程序升级

Android 2.2 带来了几样早就该推出的功能，应用程序管理和软件升级不再那么痛苦了。Google 的 Android Market 终于有了“全部升级”的按钮，可以把 Nexus One 上装的所有应用程序都升级到{zx1}的版本。解决了升级一个软件需要多次操作的繁琐过程，用户不用手动地逐个升级软件。

Android Market 新的“全部升级”按钮

批量升级仅在升级应用程序权限发生改变时才需要用户干预。如果新版本的应用程序需要访问其它功能，用户就要在升级进行之前进行批准。这是安全功能，以防程序在没有取得用户许可的情况下悄悄地增加权限。

左图：权限有变的软件打上了“手动”的标志

右图：批量升级过程会跳过需要手动升级的程序

Google I/O 上公布批量升级的功能以后，我就没再升级我的 Nexus One 上的程序，等着 Froyo 的新功能。本周我升级到 Froyo 以后，共检测到 22 个程序需要升级。因此我有机会好好体验这个功能。系统并行下载、安装程序，通知栏会显示进度条，用户可以看到每个程序所处的状态。

左图：批量升级显示在通知栏里 右图：批量升级时多个程序同时下载

两个程序下载失败（一次下载 22 个更新对我的 3G 网络来说也是困难了点），还有两个由于权限改变需要手动下载。下载失败的程序可以在{dy}次批量升级完成后，再次点击“全部升级”下载；需要手动下载的程序 就要通过传统的升级方法了。

你也可以在单个程序里设置 自动升级，不需要用户干预。查看已安装程序的相关信息，有个“允许自动升级”的选项框，勾选后就能实现自动 升级。对于容易引发安全问题的程序特别有用，能保证它们在{dy}时间升级到{zx1}版本。

为程序设置自动升级

对自动和批量升级的支持是 Android 2.2 系统里我最喜欢的功能。它的表现符合预期，解决了这个系统长期存在且最饱受诟病的问 题。

在 SD 卡上存储程序

N1 最失败的地方在于只为应用程序提供了 190MB 的内部存储空间——限制了可安装软件的数量。比如高画质游戏就可以很快吃掉所有存储空间。Android 特别需要支持在 SD 卡上安装程序。Froyo 总算是支持了这一功能，不过有些限制。

很遗憾，你不能在程序安装时进行选择。程序的开发者在编程时，就必须在 manifest 文件（也 就是描述程序的元数据的 XML 文档）里面 设置“installLocation”参数。如果项目的 installLocation 设置为“自动”，数据就会默认安装到内部存储空间，用户可以在安装后将其移动到 SD 卡上。如果参数设置为 “preferExternal”，程序就会默认安装到 SD 卡上。

Anroid Market 的用户界面目前没有为用户提供在安装时选择目标位置的功能。如果你想把程序安装到 SD 卡上，就要先安装到内部存储空间，在通过系统设置工具转移到外部存储卡。点击系统设置工具中的“应用程序”，选择“管理应用程序”，可以看到 N1 上安装的所有程序。

系统设置工具里的程序管理器

“On SD Card” 的标签页显示了所有安装在 SD 卡上的程序，选中“Downloaded”标签页中的程序就能看到它所占的存储空间以及“Move to SD card”按钮，点它就能将程序转移到 SD 卡里的加密区域。

将程序转移到存储卡上

外部存储的明显缺点是 SD 卡上的程序只有在手机加载 SD 卡的时候才能运行。用 USB 把手机以大容量存储的模式连到电脑上的时候，SD 卡上的软件也是无法访问的。受限于此，Google 的开发文档警告说长期运行的程序，比如后台服务、墙纸和 widget 应该禁止 SD 卡安装。

目前为止，我找到的{wy} 支持 SD 卡安装的程序是由 MHGames 开发的游戏 Jewels。我用程序管理器测试了一下，实际表现和宣传并无二致。对于程序开发人员来说，虽然让将程序支持转移到 SD 卡上很简单，但仍需时间进行适应并为自己的程序增加此功能，因为还不太清楚外部程序运行的效率和稳定性。Google 称运行 SD 卡上的程序并不会影响性能。

支持外部程序存储是 Android 的一项重要的功能更新，不过我不太确信它能够xx解决 N1 糟糕的内部程序存储空间所带来的问题。

叠接（Tethering）

Android 2.2 内置了 USB 和 WiFi 叠接，你可以将 3G 手机的连接共享给其它设备。在系统工具>网络设置的选项框里勾选”WiFi Hotspot”，一个蓝色的 WiFi 图标就出现在通知栏里，下拉通知栏点击相关条目就可获得热点设置。能够设置 SSID，支持 WPA2 加密，不支持 WEP。

左图：Android 2.2 网络设置 右图：启动 WiFi 叠接

左图：通知栏里的 WiFi 叠接 右图：配置 WiFi 叠接

我测试了通过 N1 的 WiFi 来叠接我的 SmartQ 平板，能够正常工作，不需要其它设置。但之前测试 EVO 4G 时我们发现通过 WiFi 进行叠接很耗电。WiFi 叠接表现不错，但并不适合长时间使用。USB 叠接表现的也很好，不想消耗手机过多电量的时候通过 USB 也是个不错的选择。

主屏幕

Android 的主屏幕也得到了好些不错的用户界面增强。底部用来打开所有程序列表的按钮两侧各增加了一个按钮，分别用来快速启动拨号程序和浏览器。这是个不错的界面增 强，很好地利用了屏幕底部的空白部分。

这样就可以腾出两格来放别的图标。新底栏的另一个好处是你在任何一屏下都可以方便地拨打电话、浏览网页。

改进后的 Android 主屏幕

Google 还增强了主屏的搜索 Widget。 该 Widget 在同一界面中提供网络搜索、程序搜索和联系人搜索。新版搜索 Widget 可以将结果限定在单一类型中。例如，如果你只想搜索安装的程序，点击搜索框左边的图标，在弹出框中选择“Apps”。在将搜索 Widget 添加到主屏幕的时候，也可以选择默认的搜索类型。

左图：Android 搜索功能改进 右图：搜索程序

我经常使用搜索栏寻找已 安装的程序，有时候速度慢得让人郁闷。把默认搜索设置为程序搜索以后，发现速度快了许多，对我来说更有用。这一步是正确的方向，Google 仍可以在搜索功能上做更多优化。我希望在程序列表打开后按搜索键，系统可以默认搜索程序（这是 Google 应该从 HTC Sense 的用户体验中学到的一个长处）。

Flash

Adobe 的 Flash 浏览器插件在之前的移动环境下一直没能真正被用起来。速度和稳定性差、安全性不高、耗电的缺陷让它几乎不可能成功。Flash 的效率在 Linux 设备下特别差，而 Adobe 对 Linux 的支持也很不上心。

Froyo 之前，Android 设备基本没法使用真正的 Flash 插件。一些手持设备厂商提供了 Flash Lite 支持，但无法兼容标准的 Flash 内容。Adobe 总算是收拾了一下烂摊子，打算扫清 Flash 要在手持设备上获得成功所面临的障碍。

Flash 的 10.1 版本有了重要改进，今年早些时候已经在桌面平台上发布。Adobe 之前说智能手机等硬件资源有限的平台也会很快获得升级插件，Froyo 用户可以在 Android Market 上找到 Flash 10.1 的 beta 版插件，但不支持 2.2 之前的系统。

在 Android 2.2 上安装 Flash

我在 Nexus One 上安装了 Flash 10.1 beta 版，看看 Adobe 是否所言不虚。经过大量测试后，我发现它能够正常使用，能以正常的速度播放传统 Flash 内容。我经常里浏览的一些必须使用 Flash 的网站都能正常工作：

左图：安装 Flash 后即可在 Zombo.com 上完成所有操作

TROLOLOLOLO

Android 上的 Flash 在触屏操作和浏览器整合方面做的相对较好。它的表现满足了我的期望，但重度 Flash 内容下还是很勉强，例如肯尼迪总统图书馆的“We Choose the Moon”。

安装完 Flash 之后我{dy}个测试的就是流媒体视频，很遗憾，不能播放 Hulu 上的任何视频，但对移动设备的限制是 Hulu 方面的问题。

不支持 Hulu 视频

其它几个受欢迎的视频网站能正常显示。例如在 CBS 网站上可以正常观看“星际迷航”。即使在 3G 连接下，视频也能流畅播放。播放的时候还可以切换到全屏模式。

Froyo 达到了以前所有 Android 手机都未达到的高度

Android 的浏览器嵌入 Flash 内容后，似乎在页面滑动流畅性方面有些影响。页面滑动变卡了，特别是有多个 Flash 元素的时候。幸运的是浏览器可以设置为默认不播放 Flash 内容，路径是浏览器设置>插件配置，选择不启用插件，或设置成“on-demand”模式。

将浏览器设置成“on-demand”模式后，Flash 条目不会默认加载，你可以看到它占据的空间，点击以后才能显示 Flash 内容，很像桌面浏览器屏蔽 Flash 广告的模式。在移动设备上这种模式特别好用，保证只有当用户需要观看 Flash 内容的时候，才让 Flash 消耗资源。

Flash 界面下的拖拽释放和鼠标悬停操作在 Android 上面也能用。悬停需要点儿技巧，但基本上只需要把手指放下，移动到你想要停的位置就可以。我一开始担心在全屏模式下显示播放控制的时候，会不小心把视频暂 停，但实际上不会。悬停菜单有点问题，特别是目标很小的时候。

在 N1 上使用多点放大时，Flash 媒体也会随着页面其他部分一起放大缩小。其它触摸手势，比如平面拖动也能正常工作。但当 Flash 内容有鼠标悬停识别区域的时候，就无法识别手势了。

N1 的 Flash 遇到的{zd0}问题是，xx文字输入的时候，屏幕键盘无法呼出。似乎没办法在纯触屏 Android 设备上的 Flash 里输入文本。希望正式版能解决这个问题。文本选择在需要的时候能正常工作，但无法进行复制。

新的 10.1 版本没有解决 Flash 遇到的全部技术问题，但它让插件能在移动设备上方便地用起来。应当将 Flash 排除在智能手机之外的论断在 Flash 10.1 出现后显得不那么令人信服。关心 Flash 对效率和续航能力影响的用户可以在“on-demand”的模式下使用，确保不需要的时候 Flash 不会耗费资源。

性能

虽然 Android 是 Java 系统，但并非基于传统的 Java 虚拟机。Google 创建了自己的字节码格式以及高度定制的 Dalvik 运行环境引擎。系统使用托管运行环境而非本地代码在移植性和安全性方面有好处，但牺牲了性能。由于 Dalvik 运行环境是按照传统的编译器所设计，因此对性能的影响非常大。

Android 2.2 引入了 just-in-time(JIT) 编译，显著提升了效率和执行速度。JIT 是运行环境的组件，在程序执行的时候可以自动把字节码转换成原生代码，让运行速度更快。虽然表现还不能和纯本地的 C/C++ 代码相比，但足以明显地提升 Android 程序的响应速度。

JIT 没有用于之前的 Android 系统，因为开发者曾担心会对内存占用和启动速度造成影响。他们希望能够确保 JIT 不会对用户体验的其它方面造成负面影响。他们的努力带来了回报，根据 Android 工程师 ，新的 JIT 能让一些计算量大的 Android 程序获得 2-5 倍的运行速度提升。并且在启动速度方面并没有损失，每个进程的内存占用 也只比前多 100k。

主观地说，Android 2.2 整 体上感觉更快更平滑。我之前使用过的有些程序在切换标签或加载列表时会有明显的延迟，现在整体表现更好。虽然我不确定这是否和 JIT 有关，但在多任务的流畅性方面我也看到了明显的进步。切换程序比以前更快更顺利。

浏览器是 Froyo 带来的另一个显著进步。JavaScript 执行速度明显加快，使得重度 JavaScript 网站有了更好的体验。为了详细测量进步有多大，我在 Froyo 升级前后进行了 JavaScript 性能测试：

可以看出，提升幅度很大。如果有兴趣可以看 。

云端通信

Android 有 daemon 维持与 Google 服务器的后台通信。永远在线的连接用来提供某些 Google 应用，比如日程的推送功能。在 Android 2.2 上，Google 对第三方程序开放了 (C2DM) 服务以实现第三方推送。

C2DM 架构允许外部网络服务以 OTA 的形式将推送通知发送到 Android 手机上。提起推送通知，你可能会想到弹出的气泡，气泡中包含着文字信息。C2DM 的魔力在于它比传统方式智能太多了，允许云端通知触发 Intent——由 Android 程序提供的可编程操作。

Intent 是 Android 进程间通信（IPC）系统的重要组件。你可以用 Intents 启用程序的某个活动（activity），也可以加载一些数据。

例如，Android 程序可以使用标准 Intent 在用户的默认浏览器中加载网页，给特定地址写邮件，启动后台服务或完成 Intents 系统里可见的任意数量的服务。

C2DM 基本只提供将外部网络服务以简单的方式通过互联网，将 Intents 通过互联网播送给 Android 设备。感觉上好像是一种对网络透明（network-transparent）的 IPC 通道。这是一种非常聪明的概念，提供了很大的灵活性。

第三方网络服务通过 C2DM 推送通知到 Google 服务器上的时候，通知将会转交给适当的设备。到达设备时，Android 系统决定由哪个注册程序接收通知中的 Intent。系统将 Intent 转给程序，如果程序当时不在运行状态， 便会自动启动。

接收方程序中的 Intent 接收器代码只决定如何响应 Intent。对推送通知来说没有标准模式——全看编程者如何实现已注册接受相应 Intent 的程序。程序可以被设计为以文本形式通知给用户，也可以直接在后台动作。

C2DM 提供的灵活性为推送通知开创各种可能的形式，包括传统的信息提示。最近的 Google I/O 大会上{dy}次介绍 C2DM 的时候，Google 演示了把地图路线从桌面电脑上的浏览器上直接发送到手机——自动打开地图程序，显示所需的路线。演示借助 Chrome 插件将 Intent 传送出去，通过 Android 设备上的地图软件编译 C2DM 后接收。

第三方网络服务通过启动 POST 请求到 Google 服务器上的 REST API 终点来发送 C2DM 推送通知。必须提 供注册 ID，Google 才能知道哪个设备应该收到信息。依赖 C2DM 的 Android 程序也必须将注册 ID 发送到对应的第三方网络服务上。

随着开发者逐渐开始利用 C2DM 的好处，Android 手机的很多信息传递和网络同步活动很可能会变得更透明。会减少对远程服务的轮询，可能会延长电池续航时间。

C2DM 服务仍然非常新，关于它的能力范围还有很多问题没有得到回答。如果开发者想在自己的软件中使用推送，就要通过 Google Code 网站的。你还必须提供自己的网络服务来发送通知并接收设备上的注册 ID。所幸的是就算没有自己的服务器，用 App Engine 也可以很快上手。

备份

Google 在 Android 2.2 上推出了新的云端备份服务，希望能为那些丢失手机数据，或者想把设置和程序数据转移到新设备的 Android 用户提供便利。备份服务对普通终端用户不可见，支持这一功能的程序将在后台透明地运行。

程序开发者可以增加“backupAgent”，并在程序的 manifest file 里注册，此后就可以让程序支持云端备份。有“onBackup”和“onRestore”功能的 agent 会自动被系统调用。备份功能将数据串行成所支持的格式，交给负责在云端存储的备份管理器。安装程序后，恢复功能会在有备份数据可用时被唤醒。

程序开发者用以生成备份 agent 的上层 API 让真实存储机构xx虚化，让它作为实现细节隐藏起来。备份管理器默认使用 Google 的云存储放置所有备份数据，但备份管理器也可以更改，就是说设备制造商可以使用其它后端存储解决方案。

用户购买新设备，安装程序后，备份管理器就会检查是否需要云端存储里是否有兼容所安装程序的备份数据。如果有可用的数据，就会通 过“onRestore”功能传给程序 agent。允许程序重新加载上一个设备上保存的备份数据。备份可以在没有任何用户干预的情况下工作。

像 C2DM 一样，云备份服务要靠用户的 Google 账户标识设备。备份数据也和 Google 账户绑定。Google 警告备份数据不能“on demand”访问，并且不能用于一般的存储或同步。

这功能当然需要在 Android 2.2 下运行，且需要程序本身的支持。所以可能需要一段时间才能走上轨道、真正发挥作用。

结论

Android 2.2 是一次增补式的更新，但仅靠效率提升一点就让它成为 Android 狂热者的重要升级。提升的响应速度和更平滑的界面过渡大大提升了用户体验。

几个新功能——特别是批量升级——提供了立即可用的明显好处。其它功能，如 SD 卡程序存储和云备份，可能要在 Android 开发者大量应用后才能体现真正的价值。我对云端信息服务特别有兴趣——这应该能够极大的丰富 Android，为程序开发社区开启创新之门。

Google 积极的开发努力将 Android 快速向前推进。和两年前相比，系统更成熟了。2.2 版本新增的 JIT 大大解决了 Android 的效率问题，赋予了它前所未有的竞争力。Google 正在向 3.0 迈进，用户界面似乎会有大革新，我们很有可能看到更多创新。