Android更新成了老大难?请向Windows看齐!

标签:WindowsAndroid更新

访客:22390  发表于:2014-08-29 16:04:04

【导读】尽管Android系统构架松散,一旦发布新版本的操作系统,运行Android系统的手机当天就可以获得相关的安全性及重大更新补丁。遗憾的是,当阅读完所有关于Android系统的评论文章后,我们发现上述美好场景短时间内不会发生。

Android更新成了老大难?请向Windows看齐!

Android系统的升级更新速度较两年前已经有所加快,至少对于从主流厂商购买的明星款智能手机来说是如此。我们有大量的数据表明Android系统更新速度得到了提升,甚至如果系统更新升级很大程度影响着您的购买选择,我们可以告诉您该坚持买哪些运营商、哪些厂商的产品。

但是你一定更希望根本不需要知道这些的情景。如果Android的更新速度不再是个问题,那么你就不用再去另读个几千字的关于Android系统更新速度的文章。我们花了太多的时间去讨论Android系统生态碎片化问题,又看着它一天天蹒跚学步,但是再往下走,就要换个走法了。

庞大的Android用户似乎所憧憬的是这样的画面:手机使用着来自不同厂家生产的各种不同种类的CPU、GPU、屏幕以及其他部件,创造着每年数百亿的销量。这些手机的系统被差异化定制,附加外部应用和增值服务,形成了各自的特色。此外,尽管Android系统构架松散,一旦发布新版本的操作系统,运行Android系统的手机当天就可以获得相关的安全性及重大更新补丁。遗憾的是,当阅读完所有关于Android系统的评论文章后,我们发现上述美好场景短时间内不会发生。

在我看来,Android系统需要借鉴的正是被认似乎已经过气了的Windows系统。

暂缓ARM平台之痛
不同芯片在x86电脑平台中共享同一指令集,它们通过标准化的驱动和接口连接着规范化的控制器和外围设备。这使得操作系统知道如何与所有外围设备进行交互。有些外围设备需要安装驱动才能正常工作,但如果新型的CPU或者主板问世,你可以轻而易举的获得最新的Windows或Linux系统安装介质,不加思索地使系统运转起来。

x86架构这样做的目的是尽可能简单的阐述这个复杂的问题,而ARM芯片并不是这样运行的。在ARM上,不同的SoC(系统级芯片)使用同一套指令集,而供应商用各自特殊的方法让SoC来处理其他问题。长期以来,由于处理问题方法有很大的相异性,这使得系统的运作一定要使用定制的Linux系统内核。Linux内核的开发者Linus Torvalds这样精辟的评论到:“整个ARM简直就像是屁股上的痔疮”。

Windows RT和其他最新发布的Linux内核很大程度上修复了这个问题,其所用方法是在操作系统和硬件间添加足够多的提取层,以便操作系统可以运行在大多数ARM的SoC上。ARM公司也意识到的这个问题,并且推出了专门针对服务器市场的统一ARM平台。

然而,这些改进还没有使用在Android系统上。Linux内核3.7最先与ARM技术支持达成了一体化协定,而Android4.4(以及Anddroid L预览版系统)使用的内核版本是3.4,而Google也并没有推出自己开发的可替代的ARM平台其他版本内核。这使得OEM(原始设备制造商)和SoC(系统级芯片)的制造商承担了保证Android系统在不同硬件上运行的大部分工作,也正因为这个,制造商们没有更多剩余精力集中改进买对用户的实际功能。

从市场份额来看,Android已经成为世界上最大的ARM平台,这是兼容Windows和Linux系统的普通计算机硬件生产厂商远远达不到的份额程度。鉴于此,Google显然应该处理这个久悬未决的问题。

与一劳永逸的整体式操作系统更新说拜拜
Android系统原本就是模仿iOS的系统升级模式而建,iOS系统的升级会为你带来高水准、用户友好的新特性,新的API(应用程序接口),新的图形驱动或其它硬件设备驱动以及最新的固件升级。而这些都只要一次性大升级到iOS7.0或7.1系统版本就可以全部完成。苹果手机的这种模式可以行得通,主要是因为它对大部分为其提供硬件的各层次软件开发商有绝对的控制权。控制权的来源在于苹果手机本身仅需要少量设备,而这些设备中大部分部件都是可以通用的(如蜂窝、WiFi适配器以及GPU等等)。

Android系统原本设计的升级模式正是如此,即每次用户界面改进和细节的变动都要通过一次大的、整体性的更新升级来完成。由于Android系统结构松散的架构方式,难免存在不同部分的更新延迟。比如由于基带固件问题,或合作运营商许可问题,OEM定制皮肤,内置应用问题等等,这些问题都可以导致系统整体更新进程的延迟。由于Android系统普及的速度又快,范围又广,使用Android系统的硬件又杂又千奇百怪,想要保持这种整体式更新升级的速度和效率就难以实现了。

正当Gingerbread和Ice Cream Sandwich不断大量推陈出新他们的应用更新和UI改进时,不难看出,距离整体式更新的终结已经不远了。虽然事态似乎在好转,但Android系统仍被作为一个完整的平台对待。基于此,如前文所述,只有不到三分之一的Android设备可以连接到Google及其合作伙伴强势推出的光芒耀眼的智能手表,因为他们并没有升级到Android4.3或4.4版本系统。

正如上文中提到的那样,Google正在另辟蹊径:很多性能更新已经被结构成零散的碎片,分布于多个各自独立的应用中。任何经Google许可的设备,只要符合最基本的软件环境要求(视是否需立即接入Google服务而决定,一般为Android4.0、Android4.1版本),都可以直接获取像Chrome,Gmail这样的应用的更新,而不必等待OEM,SoC制造商滞后的配合以整个系统的更新了。Google Play Service也可以直接为一些新特性和API(应用接口)提供安全补丁,而不需要等整个Android系统版本升级。甚至更重要的像键盘和应用启动器这样操作系统级别的应用更新模块,现在也可以从Google Play上直接下载安装更新了。

这是个好开始,但更重要的是接下来的路要怎么走。如今,很多像诸如消息中心、快捷设置菜单、应用切换、屏幕显示美化和可选项操作之类的Android系统核心模块还是要随着Android系统版本的升级才能更新,既不能个性化设置也不能随意更改,更不能通过应用下载而更新升级。Google当前的第一要务就是在OEM和其他第三方有着开足马力开发各自的Android版本系统之时,考虑如何将这一整大块的Android系统解构分散,并将这些小模块放入Google Play应用商店中。如前文所述,一些公司已经开始通过Google Play来升级他们自己的启动器和应用了,那么为什么不让他们对UI的其他部分做同样处理呢?这样,OEM们既有了他们自己的外观可以与其他公司保持差异性,又可以使用户们享受到更多的选择权和弹性。

这样的模式同样适用于API(应用程序接口),而事实上部分API已经采用了通过Google Play Service来进行升级的办法。一旦开始使用这种方法,就会有更多的原来只能通过整体性升级Android系统才能获取的新性能,被解构成小模块并被加入Google Play应用商店,比如像Android L系统新添加的相机应用接口和KitKat新推出的SD卡安全性能强化组件等。最大的问题在于不破坏现有应用情况下可以调整和增加什么性能改进。以支持新版本OpenGL ES的成像API为例,它需要SoC厂商的驱动更新,而这些驱动更新还是随着整个系统整体大升级的过程才能实现。


WP等已经做到了这一点
接下来以Windows Phone为模板来看看Google将怎样对Android开刀。一般情况下,OEM和运营商们在核心OS基础上加以改造以添加自己的内置应用,检验基带固件版本是否可用。而Windows Phone的用户们只要免费注册Microsoft开发者计划,不必经历系统更新延迟的等待,就可以获得像Windows Phone 8.1系统这样庞大、重要的性能更新包。OEM和运营商可以将新添加个性化设定、基带固件验证和其他基础性性能设定,作为软件的“最终”版本推出。

换句话说,正如Windows电脑系统一直以来运行的那样,Microsoft发布的Windows Phone性能和安全性更新,并不需要像所有SoC厂商和OEM为Android系统更新所做的那样,可笑而多此一举地对每个手机都进行一次整体升级。就像为Windows Phone的个人应用提供高效更新那样,只要硬件配置跟得上操作系统的要求,Microsoft可以始终让手机像新的一样,而不用理会OEM是否已经停产。

随着Android 系统日臻完善,最终Google也可以让Android 系统像Windows Phone一样。尽管Google Play提供更新的推出冲撞了以定制化为利的OEM的利益的谣言并存着,确定无疑的是Google的确想全面操控手机操作系统平台。目前Google已经加强了对诸如Android Wear、Android TV、Android Auto这样的Android分支平台的控制。最终的发展趋势必然是电话-平板二合一的Android系统版本,新系统将可以由Google提供更新而几乎不需要OEM和运营商插手。正如Windows电脑系统多年来一直运行的那样(以及稍逊色的Windows phone系统)。

这样以来,OEM的负担将得到减轻,用户得到的体验也将提高,我们最终也将不再需要读写讨论Android更新问题。(via 猎云网)

评论(0)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");