Android手机总是越用越慢 WHY??
来源:百度文库 编辑:超级军网 时间:2024/04/29 04:43:05
Android手机总是越用越慢 WHY??
根据第三方的调研数据显示,有77%的Android手机用户承认自己曾遭遇过手机变慢的影响,百度搜索“Android+卡慢”,也有超过460万条结果。在业内,Android手机一直有着“越用越慢”的口碑,这个现象甚至超出了硬件范畴——很多中高端Android手机在硬件参数上都优于同一代iPhone,但是它们仍然会在使用半年到一年的时间后进入“欠流畅”的状态——这无疑是一件令人困扰的事情。
然而,若是要回答这个问题,我们需要追溯到上个世纪,去寻找智能手机的起源。
西方历史及奇幻文学作品十分热衷于表达“血统”的设定,其传统文化认为血统可以决定天赋,并引出“命运是否被注定”的哲学思考。
比如大家比较熟知的《哈利波特》系列,解构之后就不难发现,这实际上是一部讲述格兰芬多与斯莱特林两支血统及其传人的厮杀史(哈利波特是格兰芬多的后代,继承了其勇气,伏地魔是斯莱特林的后代,拥有着其野心),而无处不在的预言(一个终将杀死另一个),也贯彻了西方惯有的宿命论情结。
到了科技行业,“血统”的定义被“基因”所取代,一个公司有着什么样的基因,决定了它的擅长领域.这种评价也被广泛接受,成为唯物时代独树一帜的唯心理念,并经受住了事实考验——当我们试图解释微软失落于互联网、Google败退于社交网络、百度止步于电子商务的原因时,都会由衷的感慨“原来剧本早在多年以前就已经写好了”。
同样,为什么Android手机的“卡慢”问题永远比iPhone要更加严重,它的答案也从一开始就注定了。
1965年,贝尔实验室、通用电气和麻省理工学院开始合作开发一套能够兼顾易用性和强大性的操作系统.经过六年时间的通力协作,贝尔实验室的一名软件工程师Ken Thompson在休假期间完成了一个名为Unix的系统编写,并最终成为贝尔实验室的母公司、美国电信巨头AT&T的商业产品,并启动了长达数十年的版权运作。尽管后来有着许多变种,但是从严格意义上来讲,Unix不是一个开源的操作系统。
1991年,一个芬兰的大学生、同时也是计算机黑客的Linus Torvalds,他对Unix十分着迷,但是买不起运行Unix需要的工作站,所以就尝试自己以同样的编程方式写了一个名为Linux的操作系统,并在自由软件之父Richard Stallman的精神鼓舞之下,将Linux加入到了自由软件基金(FSF)当中,允许所有人使用、拷贝、修改甚至销售Linux系统,同时承担开源义务,禁止把Linux封闭化的企图。
之所以要如此大费周章的讲述Unix和Linux两个操作系统的故事,是因为iOS和Android,正是分别基于Unix和Linux而衍生出来的作品。也就是说,是Unix和Linux的两种特性,造成了iPhone与Android手机在使用体验上的巨大差异。
乔布斯曾经邀请Linux的创始者Linus Torvalds到苹果工作,放弃Linux的开源,协助开发Mac OS封闭式的Mach内核,后者与乔布斯大吵一架之后明确表示拒绝。而从Mac OS开始,苹果就将操作系统的私有化视为企业战略,用乔布斯的话来讲,他是将iOS装进了iPhone这个盒子里,然后卖给了用户。
所以,iPhone之所以不会出现“越用越卡”的情况,是因为苹果公司对它的手机从硬件到软件拥有最高的管理权限.在封闭式的环境中,来自第三方的应用程序无法调用超过iPhone承受限度的指令,自然也不可能造成持续性的系统损伤。
反观Android手机,由于开源的公开条件,Google无法从代码这一端口约束第三方的应用程序,同时,由于Linux核心设定应用在调取系统功能时一定要取得ROOT权限,这也导致大量应用因为单一功能的实现需求而获得整个ROOT层面的支配,可以在Android手机的任意储存位置进行读写。这种高自由度无异于开启了潘多拉魔盒,让Android手机无法对恶意App事先设防。
这也是开源软件备受争议、且在商用领域遭到抵触的原因:它只关心是否授予了用户自由——这个自由也包括逾越边界的自由——而没有从最坏的出发点去考虑如何规避被滥用的风险。
尽管Google作为巨头,一直在尝试对产业链进行统一管理,但是当这条产业链日益庞大、连Google也只能扮演其中之一的角色时,Android的失控也就在情理之中了。比如,Android的最新版本通常需要花费超过一年半的时间,才能使激活它的Android手机占比超过50%,但是iOS 7只用了两个月,就让半数以上的iPhone都更新完毕。
另外,一款应用程序如果被苹果从App Store中惩罚出去,它就再也无法被安装到任何一款合法的iPhone里面,但是如果一款应用程序被Google驱逐出Google Play,但是它还是可以登录各种第三方应用市场,提供正常的下载和安装。
所以,Android的这种天生短板,又催生出了一个“手机调校”的市场,并带动了新的产业链。
“手机调校”的第一级,在于系统层。在Android 4.4以及之后的Android L的规划中,它将应用程序的运行模式由Dalvik换成了ART,其原理简单来说是“预编译”效果,即当一款应用程序在第一次被安装到Android时,它的字节码就已经被编译成为了本地的机器码,减少后续运行应用程序时的启动和执行时间。
根据Google自己公布的结果,在不同的性能测试App中,ART的速度对比Dalvik的平均提升幅度达到了80%,在某些项目中,ART的提升幅度甚至超过了1.5倍,这个结果可谓非常喜人。
这是Google希望从源头解决Android卡慢问题的努力,但是这只是对性能优化有着作用,无法解决因为应用程序违规调用资源而产生的问题。同时,由于在安装应用程序时进行了“预编译”,整个安装时间将会变长,安装完毕后生成的文件也会变大,比如最新的Google+安装包只有6.9M,但是它安装后的APK大小达到了28.3M,这对Android手机储存空间又存在过多占用的问题。
“手机调校”的第二级,在于ROM层。作为全球最大的Android市场,中国的许多手机厂商都以开发专用ROM来为销售产品添彩,大多数的ROM也都会考虑对Android系统进行优化,比如MIUI V6就宣称“引入多种Linux系统内核内存优化技术,提高应用运行效率”。
也就是说,与Google做的事情一样,ROM厂商主要的优化工作,也是对Linux动刀,打上各种补丁,使其底层语言能够更好的适配到各种手机终端上。
还是以MIUI V6为例,在介绍新特性时,其有这么一条:“ZRAM调度优化技术”。其实ZARM就是Linux内核里的一个内存模块,作用就是在内存中划出一个部分出来充当虚拟盘,来承载Linux的交换分区,将一些任务压缩容纳进去,使内存的使用率提高,让CPU来为内存服务(因为目前的智能手机普遍CPU过剩、而内存才是瓶颈)。
不过,ROM也是一把双刃剑,它对于Android底层系统的修改,以及它对于内存空间的占用,又都有增加手机负载的风险。
“手机调校”的第三级,在于应用层。大量应用程序在手机中发生的意外或故意占用事件,是造成Android手机越来越慢的最核心原因。过多的应用程序热衷于滞留在内存空间里、以及将大量碎片留在储存空间里,是带来麻烦的罪魁祸首。这也是为什么即时清理类应用得以逐渐成为Android手机标配。
Android系统有七类进程,分别是前台进程、可见进程、主要服务、次要服务、后台进程、内容供应节点、空进程。在没有安装清理类应用的时候,一部Android手机只能依赖系统默认的分配机制来自动调节内存使用,只要应用程序提出请求,大部分进程只要打开后都会被保留在内存当中。
这原本是为了让用户在再度激活这些进程时不需要重新载入、节省时间的初衷考虑,但是Android没有料到激烈的市场竞争会驱使应用程序产生“劣币驱良币”的趋势,很多开发者出于商业目的,在不需要留存在内存的情况下也想方设法的让应用程序保持潜在运行状态,一个两个还好说,但是一旦数量更多,Anrdoid手机就会频频卡顿和发热。
以目前全球用户规模最大的Android手机清理类应用“猎豹清理大师”为例,它清理的进程类型,主要放在后台进程、次要服务、内容供应节点和空进程:
后台进程(Hidden)——这个是最优先被扫描和识别出来的进程,因为大部分Android用户在切换应用程序时都不会使用返回键退出,而是直接按下Home键,前者会让应用进入空进程(占用资源相对较小),而后者则会保留为后台进程(占用资源相对更大),尤其是当游戏类App在后台运行时,它会和其他App争抢资源,而不会在乎那款App是不是用户正在使用。根据猎豹清理大师的统计,约有20%的常用App即使不运行时也在后台启动联网,主要是提交产品及用户使用信息、获取广告信息、查询是否升级等。
次要服务(Secondary Server)——比如某些企业套件、邮箱联系人、触控接口等,这些进程很多都是系统自带的,有些用户会使用,但是有些用户也可能不会使用或已经有了替代应用,所以猎豹清理大师的清理逻辑是基于用户行为和授权来建立(分为建议清理和深度清理两类);
内容供应节点(Content Provider)——这部分进程没有程序实体,仅仅提供内容给其他应用使用,比如日历供应节点、邮件供应节点等,除了占用内存资源之外,它还会占用网络,所以也会给Android手机造成不必要的负担;
空进程(Empty)——如果是通过返回键退出应用,大部分的应用也会在Android手机的内存里遗留一个空的进程,这个进程没有数据运行,但是会记录应用的历史信息,几乎没有任何价值,同样,这部分进程内容被干掉的优先级也很高。
除了对内存的过度消耗之外,Android手机也容易在储存中积累大量冗余数据,包括无法卸载的预装应用、卸载之后的残存文件以及使用应用的过程中产生的缓存。由于Android本身没有提供管理工具,即使将手机连接电脑之后也是如同Windows树状结构一样的文件夹包,用户很难独立判断哪些文件夹可以删除、哪些文件夹是系统必备的,最后也会导致手机尺寸空间愈来愈窄的情况。
“手机调校”的问题,可能又回带来用户操作的负担增加,其心理压力甚于行为压力。玩着手机还不忘隔三差五的使用清理功能,这种与iPhone相比“别具特色”的操作习惯,也是Android手机永远像一个半成品或工程机的原因。
http://news.mydrivers.com/1/318/318441.htm
Android手机总是越用越慢 WHY??
根据第三方的调研数据显示,有77%的Android手机用户承认自己曾遭遇过手机变慢的影响,百度搜索“Android+卡慢”,也有超过460万条结果。在业内,Android手机一直有着“越用越慢”的口碑,这个现象甚至超出了硬件范畴——很多中高端Android手机在硬件参数上都优于同一代iPhone,但是它们仍然会在使用半年到一年的时间后进入“欠流畅”的状态——这无疑是一件令人困扰的事情。
然而,若是要回答这个问题,我们需要追溯到上个世纪,去寻找智能手机的起源。
西方历史及奇幻文学作品十分热衷于表达“血统”的设定,其传统文化认为血统可以决定天赋,并引出“命运是否被注定”的哲学思考。
比如大家比较熟知的《哈利波特》系列,解构之后就不难发现,这实际上是一部讲述格兰芬多与斯莱特林两支血统及其传人的厮杀史(哈利波特是格兰芬多的后代,继承了其勇气,伏地魔是斯莱特林的后代,拥有着其野心),而无处不在的预言(一个终将杀死另一个),也贯彻了西方惯有的宿命论情结。
到了科技行业,“血统”的定义被“基因”所取代,一个公司有着什么样的基因,决定了它的擅长领域.这种评价也被广泛接受,成为唯物时代独树一帜的唯心理念,并经受住了事实考验——当我们试图解释微软失落于互联网、Google败退于社交网络、百度止步于电子商务的原因时,都会由衷的感慨“原来剧本早在多年以前就已经写好了”。
同样,为什么Android手机的“卡慢”问题永远比iPhone要更加严重,它的答案也从一开始就注定了。
1965年,贝尔实验室、通用电气和麻省理工学院开始合作开发一套能够兼顾易用性和强大性的操作系统.经过六年时间的通力协作,贝尔实验室的一名软件工程师Ken Thompson在休假期间完成了一个名为Unix的系统编写,并最终成为贝尔实验室的母公司、美国电信巨头AT&T的商业产品,并启动了长达数十年的版权运作。尽管后来有着许多变种,但是从严格意义上来讲,Unix不是一个开源的操作系统。
1991年,一个芬兰的大学生、同时也是计算机黑客的Linus Torvalds,他对Unix十分着迷,但是买不起运行Unix需要的工作站,所以就尝试自己以同样的编程方式写了一个名为Linux的操作系统,并在自由软件之父Richard Stallman的精神鼓舞之下,将Linux加入到了自由软件基金(FSF)当中,允许所有人使用、拷贝、修改甚至销售Linux系统,同时承担开源义务,禁止把Linux封闭化的企图。
之所以要如此大费周章的讲述Unix和Linux两个操作系统的故事,是因为iOS和Android,正是分别基于Unix和Linux而衍生出来的作品。也就是说,是Unix和Linux的两种特性,造成了iPhone与Android手机在使用体验上的巨大差异。
乔布斯曾经邀请Linux的创始者Linus Torvalds到苹果工作,放弃Linux的开源,协助开发Mac OS封闭式的Mach内核,后者与乔布斯大吵一架之后明确表示拒绝。而从Mac OS开始,苹果就将操作系统的私有化视为企业战略,用乔布斯的话来讲,他是将iOS装进了iPhone这个盒子里,然后卖给了用户。
所以,iPhone之所以不会出现“越用越卡”的情况,是因为苹果公司对它的手机从硬件到软件拥有最高的管理权限.在封闭式的环境中,来自第三方的应用程序无法调用超过iPhone承受限度的指令,自然也不可能造成持续性的系统损伤。
反观Android手机,由于开源的公开条件,Google无法从代码这一端口约束第三方的应用程序,同时,由于Linux核心设定应用在调取系统功能时一定要取得ROOT权限,这也导致大量应用因为单一功能的实现需求而获得整个ROOT层面的支配,可以在Android手机的任意储存位置进行读写。这种高自由度无异于开启了潘多拉魔盒,让Android手机无法对恶意App事先设防。
这也是开源软件备受争议、且在商用领域遭到抵触的原因:它只关心是否授予了用户自由——这个自由也包括逾越边界的自由——而没有从最坏的出发点去考虑如何规避被滥用的风险。
尽管Google作为巨头,一直在尝试对产业链进行统一管理,但是当这条产业链日益庞大、连Google也只能扮演其中之一的角色时,Android的失控也就在情理之中了。比如,Android的最新版本通常需要花费超过一年半的时间,才能使激活它的Android手机占比超过50%,但是iOS 7只用了两个月,就让半数以上的iPhone都更新完毕。
另外,一款应用程序如果被苹果从App Store中惩罚出去,它就再也无法被安装到任何一款合法的iPhone里面,但是如果一款应用程序被Google驱逐出Google Play,但是它还是可以登录各种第三方应用市场,提供正常的下载和安装。
所以,Android的这种天生短板,又催生出了一个“手机调校”的市场,并带动了新的产业链。
“手机调校”的第一级,在于系统层。在Android 4.4以及之后的Android L的规划中,它将应用程序的运行模式由Dalvik换成了ART,其原理简单来说是“预编译”效果,即当一款应用程序在第一次被安装到Android时,它的字节码就已经被编译成为了本地的机器码,减少后续运行应用程序时的启动和执行时间。
根据Google自己公布的结果,在不同的性能测试App中,ART的速度对比Dalvik的平均提升幅度达到了80%,在某些项目中,ART的提升幅度甚至超过了1.5倍,这个结果可谓非常喜人。
这是Google希望从源头解决Android卡慢问题的努力,但是这只是对性能优化有着作用,无法解决因为应用程序违规调用资源而产生的问题。同时,由于在安装应用程序时进行了“预编译”,整个安装时间将会变长,安装完毕后生成的文件也会变大,比如最新的Google+安装包只有6.9M,但是它安装后的APK大小达到了28.3M,这对Android手机储存空间又存在过多占用的问题。
“手机调校”的第二级,在于ROM层。作为全球最大的Android市场,中国的许多手机厂商都以开发专用ROM来为销售产品添彩,大多数的ROM也都会考虑对Android系统进行优化,比如MIUI V6就宣称“引入多种Linux系统内核内存优化技术,提高应用运行效率”。
也就是说,与Google做的事情一样,ROM厂商主要的优化工作,也是对Linux动刀,打上各种补丁,使其底层语言能够更好的适配到各种手机终端上。
还是以MIUI V6为例,在介绍新特性时,其有这么一条:“ZRAM调度优化技术”。其实ZARM就是Linux内核里的一个内存模块,作用就是在内存中划出一个部分出来充当虚拟盘,来承载Linux的交换分区,将一些任务压缩容纳进去,使内存的使用率提高,让CPU来为内存服务(因为目前的智能手机普遍CPU过剩、而内存才是瓶颈)。
不过,ROM也是一把双刃剑,它对于Android底层系统的修改,以及它对于内存空间的占用,又都有增加手机负载的风险。
“手机调校”的第三级,在于应用层。大量应用程序在手机中发生的意外或故意占用事件,是造成Android手机越来越慢的最核心原因。过多的应用程序热衷于滞留在内存空间里、以及将大量碎片留在储存空间里,是带来麻烦的罪魁祸首。这也是为什么即时清理类应用得以逐渐成为Android手机标配。
Android系统有七类进程,分别是前台进程、可见进程、主要服务、次要服务、后台进程、内容供应节点、空进程。在没有安装清理类应用的时候,一部Android手机只能依赖系统默认的分配机制来自动调节内存使用,只要应用程序提出请求,大部分进程只要打开后都会被保留在内存当中。
这原本是为了让用户在再度激活这些进程时不需要重新载入、节省时间的初衷考虑,但是Android没有料到激烈的市场竞争会驱使应用程序产生“劣币驱良币”的趋势,很多开发者出于商业目的,在不需要留存在内存的情况下也想方设法的让应用程序保持潜在运行状态,一个两个还好说,但是一旦数量更多,Anrdoid手机就会频频卡顿和发热。
以目前全球用户规模最大的Android手机清理类应用“猎豹清理大师”为例,它清理的进程类型,主要放在后台进程、次要服务、内容供应节点和空进程:
后台进程(Hidden)——这个是最优先被扫描和识别出来的进程,因为大部分Android用户在切换应用程序时都不会使用返回键退出,而是直接按下Home键,前者会让应用进入空进程(占用资源相对较小),而后者则会保留为后台进程(占用资源相对更大),尤其是当游戏类App在后台运行时,它会和其他App争抢资源,而不会在乎那款App是不是用户正在使用。根据猎豹清理大师的统计,约有20%的常用App即使不运行时也在后台启动联网,主要是提交产品及用户使用信息、获取广告信息、查询是否升级等。
次要服务(Secondary Server)——比如某些企业套件、邮箱联系人、触控接口等,这些进程很多都是系统自带的,有些用户会使用,但是有些用户也可能不会使用或已经有了替代应用,所以猎豹清理大师的清理逻辑是基于用户行为和授权来建立(分为建议清理和深度清理两类);
内容供应节点(Content Provider)——这部分进程没有程序实体,仅仅提供内容给其他应用使用,比如日历供应节点、邮件供应节点等,除了占用内存资源之外,它还会占用网络,所以也会给Android手机造成不必要的负担;
空进程(Empty)——如果是通过返回键退出应用,大部分的应用也会在Android手机的内存里遗留一个空的进程,这个进程没有数据运行,但是会记录应用的历史信息,几乎没有任何价值,同样,这部分进程内容被干掉的优先级也很高。
除了对内存的过度消耗之外,Android手机也容易在储存中积累大量冗余数据,包括无法卸载的预装应用、卸载之后的残存文件以及使用应用的过程中产生的缓存。由于Android本身没有提供管理工具,即使将手机连接电脑之后也是如同Windows树状结构一样的文件夹包,用户很难独立判断哪些文件夹可以删除、哪些文件夹是系统必备的,最后也会导致手机尺寸空间愈来愈窄的情况。
“手机调校”的问题,可能又回带来用户操作的负担增加,其心理压力甚于行为压力。玩着手机还不忘隔三差五的使用清理功能,这种与iPhone相比“别具特色”的操作习惯,也是Android手机永远像一个半成品或工程机的原因。
http://news.mydrivers.com/1/318/318441.htm
我看不懂,只是搬运一下;
Andorid更新了一个版本又一个版本,硬件从单核到双核到四核,系统流畅度总算基本能和iOS持平了。不过人们不禁会问,为什么都是基于Linux,两个系统会差别如此大?为什么iPhone 4用单核处理器就能实现的流畅度,Android要高端双核才能保证?近日,Android开发小组工程师Dianne Hackborn算是半官方回答了其中的一个缘由。
Dianne Hackborn表示,从界面UI本身的渲染而言,首先,Android从第一个版本就有使用图形硬件加速,例如通知栏拖拉,对话框的显示和切换等等。只不过在3.0之前的版本都不是采用完整的图形硬件加速。由于Android不是一个统一平台,各终端存在硬件差异,系统会自动调节动画的帧数。一个典型的例子就是,Nexus S可以实现到60fps的渲染,所以会足够流畅。但使用同样分辨率的里程碑,由于硬件(GPU)性能问题,它就无法提供足够的帧数来保证流畅了。这样,它的界面渲染帧数要低于60帧,我们使用起来就会偶尔感觉到“卡”。
而且,即使为UI开启硬件加速,OpenGL技术带来的内存开销会十分大,比如PowerVR的图形芯片,此时要消耗掉8MB内存,而UI程序本身都只要2MB内存,这太划不来了。所以,为了保证不同机型顺利运作,很多时候Android会采用CPU绘图运算代替硬件加速——注意,CPU还要干别的事情,让CPU来绘图只会拖慢速度。
在Android 4.0之前的版本,硬件加速是作为一个可选择的参数而存在(考虑到部分APP不支持)。但从4.0开始,这个选项将会被默认启用,开发小组已针对进行优化,即使不支持硬件加速程序运行也不会出现问题。
Dianne Hackborn最后表示,硬件加速不是提升流畅度的唯一手段。事实上Android开发小组已经使用很多技术例如改进渲染技术来提升流畅度,典型的例子就是Android 3.0的浏览器相比2.2有巨大进步。而随着4.0铺开,更多用户可以感受到这点。
Dianne Hackborn没有评价iOS是如何达到流畅的。不过大家注意,从iPhone 3GS开始,每一代iPhone的图形芯片(GPU)都相当强大(iPhone 3GS、iPhone 4、iPhone 4S的图形处理芯片均为同代手机最高水平),而且苹果iOS是封闭系统,我们猜测,苹果在这一方面并没有碰到Android那么多烦心事儿。
苹果A5处理器集成的PowerVR SGX543MP2图形处理器性能相当强大,几乎秒杀了Android阵营各类对手
而另一位软件工程师和前Google实习生Andrew Munn解释说是因为Android系统UI的框架设计的问题。
在iOS中UI渲染过程具有绝对的优先等级,当用户接触到iPhone的触摸屏后,iOS中所有的进程都将停止,系统会将所有资源用于渲染UI过程。而在Android系统中UI渲染过程的优先级别却没有那么高,也就是说当你触摸Android手机屏幕的时候,系统后台的程序并没有停止,仍然在继续运行之中,比如下载和查收短信,这样系统UI获得的资源就不够,这就是Android系统不流畅的原因。
由于这个原因,新发布的Galaxy Nexus,甚至配备四核处理器的话说EeePad Transformer Prime平板电脑都无法保证顺滑的操作体验,这些设备只能与3年前的iPhone顺滑程度相比,那么Android团队为什么不从根本解决这个问题呢?
实际上,Android的开发工作在第一代iPhone发布之前就已经开始了,原始Android原型体被设计成为使用键盘手机的设备,也就是黑莓手机的竞争对手。UI渲染优先级别在有键盘的手机上并没有那么重要。但是在iPhone发布之后,Android小组为了快速推出能与iPhone竞争的产品,迅速将Android改成触摸屏手机系统,但那时重写UI框架已经不可能了。因为如果这样Android应用市场中的所有程序将变得不可用,这种关系将一直处于恶性循环之中。难怪乔布斯在传记中表示Android是偷来的产品,哪怕苹果倾家荡产也要将其消灭。
自苹果收购了乔布斯的NeXT之后,花了六年把它打磨成了Mac OS X;又在2005年左右花了两年半时间,基于它制造了iOS。从各种意义上来说,iOS是一个传统技术的操作系统。它有一个基于微内核Mach的 Darwin内核,有一个叫做Cocoa Touch的运行时,用的是Objective-C这个C语言的超集。而Android在Linux内核之上,集成了一个Java虚拟机Dalvik,整 个应用层跑在虚拟机之上,而开发语言用的是Java。
事实上双方的选择都是很有道理的。苹果有Mac OS X十年基础,当然会选择自己最精通的技术,把iOS打造成一个传统系统,也可以无缝链接Mac OS X的开发者资源。而谷歌没有任何操作系统经验,为了要争取最大的开发者资源,他们选择了世界上最大的Java社区。虽然起点相同,但走出的第一步方向就已 经截然相反。
究其根底,只在于Java只有自动内存回收,而Objective-C自动与手动内存回收均可(注意iOS只有手动内存回收)。这小小的区别导致,谷歌只 能做一个Java虚拟机,而苹果可以继续他们在Mac OS X上的经验。而这个行为导致了两者在系统流畅性上的最大区别。Java由于只有自动内存回收,系统会在任意时间停掉所有进程开始回收内存,这个过程是人类 可以感受到的数百毫秒。而iOS由于可以手动管理内存,可以在用户操作的间歇由程序员进行回收,用户不会在频繁使用过程中感受到停顿。在日常使用中这个停 顿其实是可以忍的,但是在游戏过程中这个停顿是不可以忍的,比如想像一下一只愤怒的小鸟在空中停顿了零点几秒再继续飞行。
谷歌事实上意识到了这个问题,于是它在Android 2.3版本中大修了这个问题并将之作为一个特性大书特书。且抛开2.3的普及性不谈,单说这个大修的行为,也并没有修好这个问题。于是谷歌抛出了第二个在 开发上的修补:引入C/C++ NDK。可以说到了这一步, Android整个内核往上的应用层才有了与iOS抗衡的实力,可惜时间已经过去了近四年,iOS积累了十五年,Android刚刚起步。
而在内核之下呢?基于微内核Mach的Darwin 对比 当今服务器主流Linux又如何?当年Linux创始人曾经与某位牛人吵过一场著名的架,正是关于微内核与内核对比,Linus一直到现在都认为微内核只 是纸上谈兵而在现实中解决不了实际问题。在这场吵架之后的岁月,坚持内核的主流系统只剩下Linux一家,而微内核系统已经延展到了基于SVR4的IBM AIX/HP-UX,GNU/Hurd,Mac OS X,Blackberry QNX,Windows(是的,你没有看错)。Time will tell,这句话从来都没有错。Android三方ROM所困扰的驱动问题,正是Linux内核的最大局限,植根于骨子的病是治不好的。
Andorid更新了一个版本又一个版本,硬件从单核到双核到四核,系统流畅度总算基本能和iOS持平了。不过人们不禁会问,为什么都是基于Linux,两个系统会差别如此大?为什么iPhone 4用单核处理器就能实现的流畅度,Android要高端双核才能保证?近日,Android开发小组工程师Dianne Hackborn算是半官方回答了其中的一个缘由。
Dianne Hackborn表示,从界面UI本身的渲染而言,首先,Android从第一个版本就有使用图形硬件加速,例如通知栏拖拉,对话框的显示和切换等等。只不过在3.0之前的版本都不是采用完整的图形硬件加速。由于Android不是一个统一平台,各终端存在硬件差异,系统会自动调节动画的帧数。一个典型的例子就是,Nexus S可以实现到60fps的渲染,所以会足够流畅。但使用同样分辨率的里程碑,由于硬件(GPU)性能问题,它就无法提供足够的帧数来保证流畅了。这样,它的界面渲染帧数要低于60帧,我们使用起来就会偶尔感觉到“卡”。
而且,即使为UI开启硬件加速,OpenGL技术带来的内存开销会十分大,比如PowerVR的图形芯片,此时要消耗掉8MB内存,而UI程序本身都只要2MB内存,这太划不来了。所以,为了保证不同机型顺利运作,很多时候Android会采用CPU绘图运算代替硬件加速——注意,CPU还要干别的事情,让CPU来绘图只会拖慢速度。
在Android 4.0之前的版本,硬件加速是作为一个可选择的参数而存在(考虑到部分APP不支持)。但从4.0开始,这个选项将会被默认启用,开发小组已针对进行优化,即使不支持硬件加速程序运行也不会出现问题。
Dianne Hackborn最后表示,硬件加速不是提升流畅度的唯一手段。事实上Android开发小组已经使用很多技术例如改进渲染技术来提升流畅度,典型的例子就是Android 3.0的浏览器相比2.2有巨大进步。而随着4.0铺开,更多用户可以感受到这点。
Dianne Hackborn没有评价iOS是如何达到流畅的。不过大家注意,从iPhone 3GS开始,每一代iPhone的图形芯片(GPU)都相当强大(iPhone 3GS、iPhone 4、iPhone 4S的图形处理芯片均为同代手机最高水平),而且苹果iOS是封闭系统,我们猜测,苹果在这一方面并没有碰到Android那么多烦心事儿。
苹果A5处理器集成的PowerVR SGX543MP2图形处理器性能相当强大,几乎秒杀了Android阵营各类对手
而另一位软件工程师和前Google实习生Andrew Munn解释说是因为Android系统UI的框架设计的问题。
在iOS中UI渲染过程具有绝对的优先等级,当用户接触到iPhone的触摸屏后,iOS中所有的进程都将停止,系统会将所有资源用于渲染UI过程。而在Android系统中UI渲染过程的优先级别却没有那么高,也就是说当你触摸Android手机屏幕的时候,系统后台的程序并没有停止,仍然在继续运行之中,比如下载和查收短信,这样系统UI获得的资源就不够,这就是Android系统不流畅的原因。
由于这个原因,新发布的Galaxy Nexus,甚至配备四核处理器的话说EeePad Transformer Prime平板电脑都无法保证顺滑的操作体验,这些设备只能与3年前的iPhone顺滑程度相比,那么Android团队为什么不从根本解决这个问题呢?
实际上,Android的开发工作在第一代iPhone发布之前就已经开始了,原始Android原型体被设计成为使用键盘手机的设备,也就是黑莓手机的竞争对手。UI渲染优先级别在有键盘的手机上并没有那么重要。但是在iPhone发布之后,Android小组为了快速推出能与iPhone竞争的产品,迅速将Android改成触摸屏手机系统,但那时重写UI框架已经不可能了。因为如果这样Android应用市场中的所有程序将变得不可用,这种关系将一直处于恶性循环之中。难怪乔布斯在传记中表示Android是偷来的产品,哪怕苹果倾家荡产也要将其消灭。
自苹果收购了乔布斯的NeXT之后,花了六年把它打磨成了Mac OS X;又在2005年左右花了两年半时间,基于它制造了iOS。从各种意义上来说,iOS是一个传统技术的操作系统。它有一个基于微内核Mach的 Darwin内核,有一个叫做Cocoa Touch的运行时,用的是Objective-C这个C语言的超集。而Android在Linux内核之上,集成了一个Java虚拟机Dalvik,整 个应用层跑在虚拟机之上,而开发语言用的是Java。
事实上双方的选择都是很有道理的。苹果有Mac OS X十年基础,当然会选择自己最精通的技术,把iOS打造成一个传统系统,也可以无缝链接Mac OS X的开发者资源。而谷歌没有任何操作系统经验,为了要争取最大的开发者资源,他们选择了世界上最大的Java社区。虽然起点相同,但走出的第一步方向就已 经截然相反。
究其根底,只在于Java只有自动内存回收,而Objective-C自动与手动内存回收均可(注意iOS只有手动内存回收)。这小小的区别导致,谷歌只 能做一个Java虚拟机,而苹果可以继续他们在Mac OS X上的经验。而这个行为导致了两者在系统流畅性上的最大区别。Java由于只有自动内存回收,系统会在任意时间停掉所有进程开始回收内存,这个过程是人类 可以感受到的数百毫秒。而iOS由于可以手动管理内存,可以在用户操作的间歇由程序员进行回收,用户不会在频繁使用过程中感受到停顿。在日常使用中这个停 顿其实是可以忍的,但是在游戏过程中这个停顿是不可以忍的,比如想像一下一只愤怒的小鸟在空中停顿了零点几秒再继续飞行。
谷歌事实上意识到了这个问题,于是它在Android 2.3版本中大修了这个问题并将之作为一个特性大书特书。且抛开2.3的普及性不谈,单说这个大修的行为,也并没有修好这个问题。于是谷歌抛出了第二个在 开发上的修补:引入C/C++ NDK。可以说到了这一步, Android整个内核往上的应用层才有了与iOS抗衡的实力,可惜时间已经过去了近四年,iOS积累了十五年,Android刚刚起步。
而在内核之下呢?基于微内核Mach的Darwin 对比 当今服务器主流Linux又如何?当年Linux创始人曾经与某位牛人吵过一场著名的架,正是关于微内核与内核对比,Linus一直到现在都认为微内核只 是纸上谈兵而在现实中解决不了实际问题。在这场吵架之后的岁月,坚持内核的主流系统只剩下Linux一家,而微内核系统已经延展到了基于SVR4的IBM AIX/HP-UX,GNU/Hurd,Mac OS X,Blackberry QNX,Windows(是的,你没有看错)。Time will tell,这句话从来都没有错。Android三方ROM所困扰的驱动问题,正是Linux内核的最大局限,植根于骨子的病是治不好的。
前半段还象那么回事,后边·······
说的是1楼
前半段还象那么回事,后边·······
说的是1楼
搬运一下:
下面是第三位谷歌内部工程师的关于Android图形系统的一些观点。
1. Android 一直在使用硬件加速。实际上从1.0版本之后,所有的窗口元素的合成与显示都是通过硬件完成的。
2.这意味着许多你所看见的动画都是被加速过的:按钮的显示、通知栏下拉的阴影、不同Activity之间的切换动画、弹出窗口以及提示框的显示和隐藏等等等等。
3.Android以前使用软件方式(与硬件加速相对应)来控制各个窗口元素的渲染,例如下图的UI,其中包括四个窗口组件:状态条、壁纸、桌面上的的启动器、以及菜单。如果其中一个元素更改了自身的内容,例如高亮一个菜单条目,对于3.0之前的版本,系统使用软件方式来绘制新的内容,然而并非所有的元素都需要被重新绘制,同时各个窗口元素的拼接也是通过硬件方式完成的。类似的,任何窗口的移动:例如菜单的上下运动是完全通过硬件方式渲染的。
4. 现在我们来关注窗口元素的内部渲染,实际上为了达到每秒60帧的FPS,你并不一定需要硬件加速。帧速取决于要显示的像素的数量以及CPU的速度。比如说,二儿子完全可以以60FPS的速度在它800*480分辨率的屏幕上完成任何普通的原生UI动画,例如列表的滚动等,完全没有问题。而最初的Droid系列却很难达到这样的速度。
5.在Android3.0中可以实现窗口的”完全”的硬件加速绘制。而在Android 4.0中也没有引入更多的功能。 从3.0开始,如果在你的应用中设置了一个标志允许硬件加速,那么此时所有的窗口的绘制都会交给GPU来完成。在Android 4.0中最主要的改变就是:在面向Android4.0或更高版本的应用中,硬件加速是被默认开启的,再也不需要在配置文件中设置 android:handwareAccelerated=”true”.(而我们不允许之前的应用默认打开硬件加速,是因为光靠硬件加速,无法很好的完成某些特殊的绘制操作;同时在应用需要其中一部分UI更新的时候,会影响其的一些表现。对于目前现有的很多应用,强制开启硬件加速,会明显的中断应用的运行)
6.硬件加速并不如大家所认为的那样完美。例如在基于PVR驱动的设备上(比如二儿子跟三儿子),光是在进程中开启OpenGL就得占用8M的RAM。对比一般进程的2M的开销实在是巨大。RAM是有限的,一大部分被拿去绘制,那么其他正在运行的进程就会因为缺少内存而出问题,比如降低应用间切换的速度。
7.由于OpenGL的额外开销,我们最好不要过多的使用其进行绘制。比如我们现在在做的一些工作,就是为了让Android 4.0能在不使用硬件加速的情况下流畅的在二儿子上使用:这样我们就不需要在系统进程中浪费8MB的内存用,也不需要在手机进程中浪费额外的8M内存,或者是在系统UI进程中的8MB内存 等等等等。相信我,你不会注意到用OpenGL来绘制一些类似状态栏或是华丽的动画是完全没有好处的。
8.硬件加速并非流畅UI的“解药”。我们为了UI的流畅尝试了很多不同的方法,比如说在1.6中引入的对前台/后台进程的调度策略,在2.3中的对输入系统的重写,”严厉模式”的使用,并发的垃圾回收机制,载入器等等。如果你想达到60fps的帧速,你只有20毫秒的时间来处理每帧的内容。这时间实在不长,光是在UI进程中读取存储卡的操作产生的延时就会大于这个时限,尤其是在写操作的时候。
9.举些最近发现的一些影响UI流畅度的例子:我们注意到在二儿子上,使用4.0时列表的滚动就不如使用2.3时流畅。而导致这个现象的原因则是计时器的轻微漂移:有些时候应用正在接收触摸事件并在屏幕上绘制,而在上一个动作还没完成的的时候,就接受到下一个事件并开始绘制,导致它丢失了当前这帧。尽管发生这种现象的时候,帧速能达到稳定的60FPS.(当然,这个问题已经修正)
10.当人们比较Android跟IOS上浏览器的滚动流畅度的时候,他们所看见的差别并非开没开启硬件加速所导致。 最初的时候,Android使用了一种完全不同的渲染策略,并做了一些折中:网页被转换成一个”显示列表“,持续的在屏幕上进行绘制,而非使用块(Tiles)的形式。它有一个优点:就是在滚动或是缩放的时候不会发生有的块还没被渲染出来的现象(译者注:早期的IOS上这种现象非常明显,快速滚动到底部时要等一会网页才会一块一块的绘制出来)。 而这个方法的不给力之处就在于页面复杂的时候,帧速就明显低了。例如Android3.0,浏览器中现在开始使用块的方式进行渲染,于是它可以在滚动或是放大的时候保持一个稳定的帧速,自然也会出现新的块没有被立即渲染出来的情况。 而每个块都是以软件方式绘制的,我相信在IOS中也是这样的。(在3.0之前的版本中,没有开启硬件加速,基于块的策略也可以使用。而且如我之前提到的,二儿子可以很容易的达到60FPS)
11.硬件加速不能如大家所想奇迹般的让绘制的问题统统消失。GPU的性能就是一个很重要的限制。最近一个很有趣的例子:基于英伟达的Tegra2的平板可以很容易的以60FPS的速度访问2.5次1280*800分辨率的屏幕中的任何一个像素。现在考虑到在Android 3.0中切换到所有应用列表的情形:你需要绘制背景(1x 所有的像素)、接着是快捷方式和桌面小工具(假设内容不多,花费0.5x),接着是所有应用的黑色背景(1x),接着是所有应用的ICON(0.5x)。显然,我们已经超过了原先的预算了,而此时我们还没完成各个独立窗口元素的拼接并做最后的显示。想要取得60FPS的动画,Android 3.0以及后续版本使用了一系列的小技巧。 其中主要的一个就是: 它将所有的窗口元素平铺在一个层中,而不是挨个拷贝到CPU的缓存中。但即使是这样,我们已然超出预算,幸好我们使用另一个技巧:因为Android中的背景是一个独立的窗口元素,我们可以将它设置的比屏幕更大来放置整幅位图,现在,用户开始滑动,背景跟着运动,此时并不需要任何特殊的绘制,仅仅是移动窗口即可,而由于这个窗口是在一个平铺层上,我们甚至不需要用GPU来将这个窗口元素组织到屏幕中输出。
12.随着屏幕分辨率的不断升高,能否达到60FPS跟GPU的速度尤其是内存总线带宽息息相关。事实上,如果你想要提升硬件的效力,特别注意要提升内存总线的带宽。很多时候CPU(特别是带有完美的NEON指令集的CPU)会比内存总线块的多。
有些人认为盖世兔已经有了一个非常流畅的UI并指出他们已经超越三儿子并做了很多改进。事实上,大家忽略了很多设备的差异,盖世兔的屏幕是480*800而三儿子是720*1280。如果二儿子在它480*800的屏幕上都能达到60FPS,拥有更NB的CPU的盖世兔必须得同样流畅嘛。 而两者之间最大的差别就是三儿子需要同时绘制2.4倍于盖世兔的像素。这相当于在单核上提升到2.4倍的速度。(需要指出 在UI渲染的时候,多核是没有意义的,因为渲染必须要在一个进程中完成,无法并行)
这就是为什么硬件加速非常重要:随着像素的提升,GPU通常能更好的处理图像的运算。事实上,这是我们在Android中引入硬件加速的最大动力。在720*1280的屏幕上,现有的ARM CPU达到60FPS很吃力,但是通过GPU渲染就不同了。同样,在与盖世兔的比较中,同时打开没有硬件加速的应用,在三儿子中无法达到盖世兔同样的60FPS,是因为它得渲染2.4倍于盖世兔的像素。
在最后,还得提及GPU的另外一个优势:许多绘制的效果变得更加容易。比如你要以软件形式绘制一个位图,你除了设置一个位移,不能做任何事。仅仅是缩小就得花上相当多的时间进行渲染。而在GPU中,此类转换则相当容易。这就是为神马新的默认主题Holo使用硬件加速绘制背景。而在没有开启硬件加速的应用中,此类背景会自动去掉~
下面是第三位谷歌内部工程师的关于Android图形系统的一些观点。
1. Android 一直在使用硬件加速。实际上从1.0版本之后,所有的窗口元素的合成与显示都是通过硬件完成的。
2.这意味着许多你所看见的动画都是被加速过的:按钮的显示、通知栏下拉的阴影、不同Activity之间的切换动画、弹出窗口以及提示框的显示和隐藏等等等等。
3.Android以前使用软件方式(与硬件加速相对应)来控制各个窗口元素的渲染,例如下图的UI,其中包括四个窗口组件:状态条、壁纸、桌面上的的启动器、以及菜单。如果其中一个元素更改了自身的内容,例如高亮一个菜单条目,对于3.0之前的版本,系统使用软件方式来绘制新的内容,然而并非所有的元素都需要被重新绘制,同时各个窗口元素的拼接也是通过硬件方式完成的。类似的,任何窗口的移动:例如菜单的上下运动是完全通过硬件方式渲染的。
4. 现在我们来关注窗口元素的内部渲染,实际上为了达到每秒60帧的FPS,你并不一定需要硬件加速。帧速取决于要显示的像素的数量以及CPU的速度。比如说,二儿子完全可以以60FPS的速度在它800*480分辨率的屏幕上完成任何普通的原生UI动画,例如列表的滚动等,完全没有问题。而最初的Droid系列却很难达到这样的速度。
5.在Android3.0中可以实现窗口的”完全”的硬件加速绘制。而在Android 4.0中也没有引入更多的功能。 从3.0开始,如果在你的应用中设置了一个标志允许硬件加速,那么此时所有的窗口的绘制都会交给GPU来完成。在Android 4.0中最主要的改变就是:在面向Android4.0或更高版本的应用中,硬件加速是被默认开启的,再也不需要在配置文件中设置 android:handwareAccelerated=”true”.(而我们不允许之前的应用默认打开硬件加速,是因为光靠硬件加速,无法很好的完成某些特殊的绘制操作;同时在应用需要其中一部分UI更新的时候,会影响其的一些表现。对于目前现有的很多应用,强制开启硬件加速,会明显的中断应用的运行)
6.硬件加速并不如大家所认为的那样完美。例如在基于PVR驱动的设备上(比如二儿子跟三儿子),光是在进程中开启OpenGL就得占用8M的RAM。对比一般进程的2M的开销实在是巨大。RAM是有限的,一大部分被拿去绘制,那么其他正在运行的进程就会因为缺少内存而出问题,比如降低应用间切换的速度。
7.由于OpenGL的额外开销,我们最好不要过多的使用其进行绘制。比如我们现在在做的一些工作,就是为了让Android 4.0能在不使用硬件加速的情况下流畅的在二儿子上使用:这样我们就不需要在系统进程中浪费8MB的内存用,也不需要在手机进程中浪费额外的8M内存,或者是在系统UI进程中的8MB内存 等等等等。相信我,你不会注意到用OpenGL来绘制一些类似状态栏或是华丽的动画是完全没有好处的。
8.硬件加速并非流畅UI的“解药”。我们为了UI的流畅尝试了很多不同的方法,比如说在1.6中引入的对前台/后台进程的调度策略,在2.3中的对输入系统的重写,”严厉模式”的使用,并发的垃圾回收机制,载入器等等。如果你想达到60fps的帧速,你只有20毫秒的时间来处理每帧的内容。这时间实在不长,光是在UI进程中读取存储卡的操作产生的延时就会大于这个时限,尤其是在写操作的时候。
9.举些最近发现的一些影响UI流畅度的例子:我们注意到在二儿子上,使用4.0时列表的滚动就不如使用2.3时流畅。而导致这个现象的原因则是计时器的轻微漂移:有些时候应用正在接收触摸事件并在屏幕上绘制,而在上一个动作还没完成的的时候,就接受到下一个事件并开始绘制,导致它丢失了当前这帧。尽管发生这种现象的时候,帧速能达到稳定的60FPS.(当然,这个问题已经修正)
10.当人们比较Android跟IOS上浏览器的滚动流畅度的时候,他们所看见的差别并非开没开启硬件加速所导致。 最初的时候,Android使用了一种完全不同的渲染策略,并做了一些折中:网页被转换成一个”显示列表“,持续的在屏幕上进行绘制,而非使用块(Tiles)的形式。它有一个优点:就是在滚动或是缩放的时候不会发生有的块还没被渲染出来的现象(译者注:早期的IOS上这种现象非常明显,快速滚动到底部时要等一会网页才会一块一块的绘制出来)。 而这个方法的不给力之处就在于页面复杂的时候,帧速就明显低了。例如Android3.0,浏览器中现在开始使用块的方式进行渲染,于是它可以在滚动或是放大的时候保持一个稳定的帧速,自然也会出现新的块没有被立即渲染出来的情况。 而每个块都是以软件方式绘制的,我相信在IOS中也是这样的。(在3.0之前的版本中,没有开启硬件加速,基于块的策略也可以使用。而且如我之前提到的,二儿子可以很容易的达到60FPS)
11.硬件加速不能如大家所想奇迹般的让绘制的问题统统消失。GPU的性能就是一个很重要的限制。最近一个很有趣的例子:基于英伟达的Tegra2的平板可以很容易的以60FPS的速度访问2.5次1280*800分辨率的屏幕中的任何一个像素。现在考虑到在Android 3.0中切换到所有应用列表的情形:你需要绘制背景(1x 所有的像素)、接着是快捷方式和桌面小工具(假设内容不多,花费0.5x),接着是所有应用的黑色背景(1x),接着是所有应用的ICON(0.5x)。显然,我们已经超过了原先的预算了,而此时我们还没完成各个独立窗口元素的拼接并做最后的显示。想要取得60FPS的动画,Android 3.0以及后续版本使用了一系列的小技巧。 其中主要的一个就是: 它将所有的窗口元素平铺在一个层中,而不是挨个拷贝到CPU的缓存中。但即使是这样,我们已然超出预算,幸好我们使用另一个技巧:因为Android中的背景是一个独立的窗口元素,我们可以将它设置的比屏幕更大来放置整幅位图,现在,用户开始滑动,背景跟着运动,此时并不需要任何特殊的绘制,仅仅是移动窗口即可,而由于这个窗口是在一个平铺层上,我们甚至不需要用GPU来将这个窗口元素组织到屏幕中输出。
12.随着屏幕分辨率的不断升高,能否达到60FPS跟GPU的速度尤其是内存总线带宽息息相关。事实上,如果你想要提升硬件的效力,特别注意要提升内存总线的带宽。很多时候CPU(特别是带有完美的NEON指令集的CPU)会比内存总线块的多。
有些人认为盖世兔已经有了一个非常流畅的UI并指出他们已经超越三儿子并做了很多改进。事实上,大家忽略了很多设备的差异,盖世兔的屏幕是480*800而三儿子是720*1280。如果二儿子在它480*800的屏幕上都能达到60FPS,拥有更NB的CPU的盖世兔必须得同样流畅嘛。 而两者之间最大的差别就是三儿子需要同时绘制2.4倍于盖世兔的像素。这相当于在单核上提升到2.4倍的速度。(需要指出 在UI渲染的时候,多核是没有意义的,因为渲染必须要在一个进程中完成,无法并行)
这就是为什么硬件加速非常重要:随着像素的提升,GPU通常能更好的处理图像的运算。事实上,这是我们在Android中引入硬件加速的最大动力。在720*1280的屏幕上,现有的ARM CPU达到60FPS很吃力,但是通过GPU渲染就不同了。同样,在与盖世兔的比较中,同时打开没有硬件加速的应用,在三儿子中无法达到盖世兔同样的60FPS,是因为它得渲染2.4倍于盖世兔的像素。
在最后,还得提及GPU的另外一个优势:许多绘制的效果变得更加容易。比如你要以软件形式绘制一个位图,你除了设置一个位移,不能做任何事。仅仅是缩小就得花上相当多的时间进行渲染。而在GPU中,此类转换则相当容易。这就是为神马新的默认主题Holo使用硬件加速绘制背景。而在没有开启硬件加速的应用中,此类背景会自动去掉~
谣传太多了。
目前投入实际应用的操作系统没有一个是微内核的。
OS X的Mach本身经过重大改良,只能说吸取了一部分微内核的概念。
Windows也是如此,从2000开始就不是微内核。
真正微内核的Hurd效率非常低,多年难产,估计只能作为一个研究项目了。
目前投入实际应用的操作系统没有一个是微内核的。
OS X的Mach本身经过重大改良,只能说吸取了一部分微内核的概念。
Windows也是如此,从2000开始就不是微内核。
真正微内核的Hurd效率非常低,多年难产,估计只能作为一个研究项目了。
实际上很多性能问题可以通过简单增加内存解决,现在1G和2G内存价格相差并不大,走入3G、4G指日可待。
实际上很多性能问题可以通过简单增加内存解决,现在1G和2G内存价格相差并不大,走入3G、4G指日可待。
功耗呢?大量swap操作引起的flash损伤和碎片化呢
功耗呢?大量swap操作引起的flash损伤和碎片化呢
hillsboro1 发表于 2015-3-3 10:51
功耗呢?大量swap操作引起的flash损伤和碎片化呢
功耗会增加一点,但内存功耗很低。
内存大了,swap就少了,而且我都不太清楚安卓这样的移动操作系统有没有打开swap选项。
功耗呢?大量swap操作引起的flash损伤和碎片化呢
功耗会增加一点,但内存功耗很低。
内存大了,swap就少了,而且我都不太清楚安卓这样的移动操作系统有没有打开swap选项。
功耗会增加一点,但内存功耗很低。
内存大了,swap就少了,而且我都不太清楚安卓这样的移动操作系统有没 ...
内存功耗并不算低,android 的天生缺陷就会导致flash 碎片化,和windows一个德行
内存大了,swap就少了,而且我都不太清楚安卓这样的移动操作系统有没 ...
内存功耗并不算低,android 的天生缺陷就会导致flash 碎片化,和windows一个德行
楼主讲了半天,也没有讲到点子上,那些用苹果机的装了几个 APP,那些安卓的装了多少APP。这个上差了 几条街吧。
hillsboro1 发表于 2015-3-3 10:55
内存功耗并不算低,android 的天生缺陷就会导致flash 碎片化,和windows一个德行
安卓的核心是Linux,对外存的碎片化控制较好。
另外2000以后的Windows,碎片化控制得很差吗?
退一步说,这其实是另一回事了。
内存功耗并不算低,android 的天生缺陷就会导致flash 碎片化,和windows一个德行
安卓的核心是Linux,对外存的碎片化控制较好。
另外2000以后的Windows,碎片化控制得很差吗?
退一步说,这其实是另一回事了。
安卓的核心是Linux,对外存的碎片化控制较好。
另外2000以后的Windows,碎片化控制得很差吗?
退一步说 ...
linux就没碎片控制,flash,ssd,硬盘一视同仁,log swap ,开放的文件系统meta,随处可见的碎片带来海量的写操作,emmc不慢不可能
另外2000以后的Windows,碎片化控制得很差吗?
退一步说 ...
linux就没碎片控制,flash,ssd,硬盘一视同仁,log swap ,开放的文件系统meta,随处可见的碎片带来海量的写操作,emmc不慢不可能
hillsboro1 发表于 2015-3-3 11:02
linux就没碎片控制,flash,ssd,硬盘一视同仁,log swap ,开放的文件系统meta,随处可见的碎片带来海量 ...
Linux文件系统编写者泪奔。。。
linux就没碎片控制,flash,ssd,硬盘一视同仁,log swap ,开放的文件系统meta,随处可见的碎片带来海量 ...
Linux文件系统编写者泪奔。。。
Linux文件系统编写者泪奔。。。
你写文件系统会关心什么样的ssd或者 emmc吗,windows无时不在的update更不在乎你用的是不是ssd。
你写文件系统会关心什么样的ssd或者 emmc吗,windows无时不在的update更不在乎你用的是不是ssd。
江湖野郎中 发表于 2015-3-3 10:57
楼主讲了半天,也没有讲到点子上,那些用苹果机的装了几个 APP,那些安卓的装了多少APP。这个上差了 几条街 ...
您不差几条街,找几个权威的例子看看。
楼主讲了半天,也没有讲到点子上,那些用苹果机的装了几个 APP,那些安卓的装了多少APP。这个上差了 几条街 ...
您不差几条街,找几个权威的例子看看。
这些材料感觉比较老,近一年来安卓在效率上改进很多,我手头的小牛2(4.4),并没发现所谓越用越慢的毛病。
根本问题还在于安卓和iOS机制不同,随着iOS逐步增强后台管理,两者差距会越来越小,事实上现在用户使用感觉并无特别差异。
根本问题还在于安卓和iOS机制不同,随着iOS逐步增强后台管理,两者差距会越来越小,事实上现在用户使用感觉并无特别差异。
hillsboro1 发表于 2015-3-3 11:15
你写文件系统会关心什么样的ssd或者 emmc吗,windows无时不在的update更不在乎你用的是不是ssd。
你太低估Linux内核编写者的水平了,SSD不是什么特殊的东西,内核会针对硬件进行读写策略调整。
Windows Update跟SSD啥关系?
你写文件系统会关心什么样的ssd或者 emmc吗,windows无时不在的update更不在乎你用的是不是ssd。
你太低估Linux内核编写者的水平了,SSD不是什么特殊的东西,内核会针对硬件进行读写策略调整。
Windows Update跟SSD啥关系?
你太低估Linux内核编写者的水平了,SSD不是什么特殊的东西,内核会针对硬件进行读写策略调整。
Windows ...
windows update 数据量大,频繁非常损害 ssd,导致flash扇区严重碎片化。chsdsk这样的东西在硬盘时代是好东西,flash上就不是啦。
内核能做的东西并不多,所有linux程序动辄写个var log,根本不顾及ssd的感受
Windows ...
windows update 数据量大,频繁非常损害 ssd,导致flash扇区严重碎片化。chsdsk这样的东西在硬盘时代是好东西,flash上就不是啦。
内核能做的东西并不多,所有linux程序动辄写个var log,根本不顾及ssd的感受
您不差几条街,找几个权威的例子看看。
楼主自己所说
Android手机总是越用越慢 WHY??
楼主的几个理由是有影响,但有太多的APP自启影响大吗?
高手兄自己不看帖,不要回复我了。
楼主自己所说
Android手机总是越用越慢 WHY??
楼主的几个理由是有影响,但有太多的APP自启影响大吗?
高手兄自己不看帖,不要回复我了。
hillsboro1 发表于 2015-3-3 11:30
windows update 数据量大,频繁非常损害 ssd,导致flash扇区严重碎片化。chsdsk这样的东西在硬盘时代是好 ...
是不是扯远了?
即使谈论桌面服务端Windows,在NTFS的管理下,已经不需要刻意整理碎片,那是FAT时代的事了。
内核对不同外存有不同的策略,像var log,已经是应用层的事情了,写到外存上去,核心的优化无需用户关心。
SSD更多关心同一块扇区怎么避免反复读写,尽可能把读写均匀分散到整个盘面,而不是减少读写。
限制应用的外存是没有意义的。
windows update 数据量大,频繁非常损害 ssd,导致flash扇区严重碎片化。chsdsk这样的东西在硬盘时代是好 ...
是不是扯远了?
即使谈论桌面服务端Windows,在NTFS的管理下,已经不需要刻意整理碎片,那是FAT时代的事了。
内核对不同外存有不同的策略,像var log,已经是应用层的事情了,写到外存上去,核心的优化无需用户关心。
SSD更多关心同一块扇区怎么避免反复读写,尽可能把读写均匀分散到整个盘面,而不是减少读写。
限制应用的外存是没有意义的。
我稍微查了一下,4Gbit的内存颗粒功耗最大400mw,2G内存的话,需要4颗,但内存很少有全速运行的,所以从1G升到2G增加不了多少功耗,特别跟CPU、屏幕相比。
壮东风 发表于 2015-3-3 11:53
我稍微查了一下,4Gbit的内存颗粒功耗最大400mw,2G内存的话,需要4颗,但内存很少有全速运行的,所以从1G ...
内存都是全速的,这还跟不上cpu速度呢
多个内存就会挤占pcb面积,让系统设计制造成本飙升
壮东风 发表于 2015-3-3 11:53
我稍微查了一下,4Gbit的内存颗粒功耗最大400mw,2G内存的话,需要4颗,但内存很少有全速运行的,所以从1G ...
内存都是全速的,这还跟不上cpu速度呢
多个内存就会挤占pcb面积,让系统设计制造成本飙升
hillsboro1 发表于 2015-3-3 11:55
内存都是全速的,这还跟不上cpu速度呢
跟不上CPU是指标上的,大部分时间访存要求不高,内存并不工作。
内存都是全速的,这还跟不上cpu速度呢
跟不上CPU是指标上的,大部分时间访存要求不高,内存并不工作。
水果不卡但用不起。老婆大人和孩子的水果4,4s,5,5s等屏幕小,费眼。水果6家里人还舍不得买。
安卓和平板(米三两个,荣耀X1一个,三孙T320一个)几个都是2G的,用了一年了,基本不卡,偶尔卡管理软件清理一下还凑活。
撸你妹1520从来没卡过,屏幕超级满意,其它一般。
水果不卡但用不起。老婆大人和孩子的水果4,4s,5,5s等屏幕小,费眼。水果6家里人还舍不得买。
安卓和平板(米三两个,荣耀X1一个,三孙T320一个)几个都是2G的,用了一年了,基本不卡,偶尔卡管理软件清理一下还凑活。
撸你妹1520从来没卡过,屏幕超级满意,其它一般。
是不是扯远了?
即使谈论桌面服务端Windows,在NTFS的管理下,已经不需要刻意整理碎片,那是FAT时代的事 ...
你说的是硬盘碎片,我说的是ssd内部flash的碎片
即使谈论桌面服务端Windows,在NTFS的管理下,已经不需要刻意整理碎片,那是FAT时代的事 ...
你说的是硬盘碎片,我说的是ssd内部flash的碎片
hillsboro1 发表于 2015-3-3 12:02
你说的是硬盘碎片,我说的是ssd内部flash的碎片
SSD对碎片并不在意,并非关注点,电路寻址,不像机械硬盘需要寻道。
安卓可能都没开swap,这个我回头查查。
你说的是硬盘碎片,我说的是ssd内部flash的碎片
SSD对碎片并不在意,并非关注点,电路寻址,不像机械硬盘需要寻道。
安卓可能都没开swap,这个我回头查查。
SSD对碎片并不在意,并非关注点,电路寻址,不像机械硬盘需要寻道。
安卓可能都没开swap,这个我回头查 ...
内部碎片会导致ssd控制器寻找目标扇区低效。
用一个粗人的话就像农村的厕所,随处大小便,导致后来的人无处下脚。
安卓可能都没开swap,这个我回头查 ...
内部碎片会导致ssd控制器寻找目标扇区低效。
用一个粗人的话就像农村的厕所,随处大小便,导致后来的人无处下脚。
hillsboro1 发表于 2015-3-3 12:17
内部碎片会导致ssd控制器寻找目标扇区低效。
用一个粗人的话就像农村的厕所,随处大小便,导致后来的人 ...
电路寻址非常快,其实机械硬盘找到扇区也很快,慢的是磁头移动和盘面转动。
安卓有swap,但回到刚才的问题,加大内存会大大减少交换,是最简单的加速办法。
内部碎片会导致ssd控制器寻找目标扇区低效。
用一个粗人的话就像农村的厕所,随处大小便,导致后来的人 ...
电路寻址非常快,其实机械硬盘找到扇区也很快,慢的是磁头移动和盘面转动。
安卓有swap,但回到刚才的问题,加大内存会大大减少交换,是最简单的加速办法。
电路寻址非常快,其实机械硬盘找到扇区也很快,慢的是磁头移动和盘面转动。
安卓有swap,但回到刚才的问 ...
flash用久了会有失效扇区,emmc控制器要识别这些扇区,通过ecc 吧这些扇区内容转移到好扇区,标记,下次不要写这些扇区,随着坏扇区越来他越多,这个工作时间会越来越长
安卓有swap,但回到刚才的问 ...
flash用久了会有失效扇区,emmc控制器要识别这些扇区,通过ecc 吧这些扇区内容转移到好扇区,标记,下次不要写这些扇区,随着坏扇区越来他越多,这个工作时间会越来越长
楼主讲了半天,也没有讲到点子上,那些用苹果机的装了几个 APP,那些安卓的装了多少APP。这个上差了 几条街 ...
笑话,也许Android总的应用数量多于iOS,但是对个人而言,还真没有Android用户普遍装应用数大于iOS用户的。或者正如前面所说,很多Android应用其实是作为系统弥补手段出现的,例如清内存,清垃圾,省电等。如果这些都算是应用更多了,那恰恰是Android不如iOS的实证。
笑话,也许Android总的应用数量多于iOS,但是对个人而言,还真没有Android用户普遍装应用数大于iOS用户的。或者正如前面所说,很多Android应用其实是作为系统弥补手段出现的,例如清内存,清垃圾,省电等。如果这些都算是应用更多了,那恰恰是Android不如iOS的实证。
平时没事重启一下手机 推送更新就更新一下,内存快满了 把东西存到电脑上一点。
牛头不对马嘴. ios内核对linux内核有优势吗? 内核层面两者同一层次, 而且linux明显要比ios内核适用度大多了
hillsboro1 发表于 2015-3-3 11:02
linux就没碎片控制,flash,ssd,硬盘一视同仁,log swap ,开放的文件系统meta,随处可见的碎片带来海量 ...
请先了解一下linux的文件系统再说. ext文件系统和windows不是一码事, 压根没有碎片这一说. 世界上那么多linux服务器, 你看谁整理过碎片?
linux就没碎片控制,flash,ssd,硬盘一视同仁,log swap ,开放的文件系统meta,随处可见的碎片带来海量 ...
请先了解一下linux的文件系统再说. ext文件系统和windows不是一码事, 压根没有碎片这一说. 世界上那么多linux服务器, 你看谁整理过碎片?
hillsboro1 发表于 2015-3-3 10:55
内存功耗并不算低,android 的天生缺陷就会导致flash 碎片化,和windows一个德行
内部文件系统都是ext的, 哪里来的碎片, android系统层面上没缺陷
内存功耗并不算低,android 的天生缺陷就会导致flash 碎片化,和windows一个德行
内部文件系统都是ext的, 哪里来的碎片, android系统层面上没缺陷
请先了解一下linux的文件系统再说. ext文件系统和windows不是一码事, 压根没有碎片这一说. 世界上那么多l ...
搞清楚我说的是什么再说,ssd内部的flash碎片是导致所有系统变慢的根本原因,ssd和机械硬盘作业原理根本不同,不明白就不要跳出来
搞清楚我说的是什么再说,ssd内部的flash碎片是导致所有系统变慢的根本原因,ssd和机械硬盘作业原理根本不同,不明白就不要跳出来
hillsboro1 发表于 2015-3-3 12:55
搞清楚我说的是什么再说,ssd内部的flash碎片是导致所有系统变慢的根本原因,ssd和机械硬盘作业原理根本 ...
那个手机内部存储器用的不是flash? 这不是原因.
搞清楚我说的是什么再说,ssd内部的flash碎片是导致所有系统变慢的根本原因,ssd和机械硬盘作业原理根本 ...
那个手机内部存储器用的不是flash? 这不是原因.
那个手机内部存储器用的不是flash? 这不是原因.
就是因为手机内部是flash,而android系统写入量非常大,远超ios才导致会变慢。
就是因为手机内部是flash,而android系统写入量非常大,远超ios才导致会变慢。
hillsboro1 发表于 2015-3-3 13:15
就是因为手机内部是flash,而android系统写入量非常大,远超ios才导致会变慢。
android系统写入量超过ios? 没有依据的东西别瞎说, 任何一个操作系统都不可能进行大量写的, 你以为不费cpu资源, 不费电啊.
hillsboro1 发表于 2015-3-3 13:15
就是因为手机内部是flash,而android系统写入量非常大,远超ios才导致会变慢。
android系统写入量超过ios? 没有依据的东西别瞎说, 任何一个操作系统都不可能进行大量写的, 你以为不费cpu资源, 不费电啊.
笑话,也许Android总的应用数量多于iOS,但是对个人而言,还真没有Android用户普遍装应用数大于iOS用户的 ...
大哥,我不是说 哪个应用 更多更好 的。
只是说 那些乱装应用的,。
说个比喻,我隔壁 对我说 他的电脑 太卡了,我去一看,老天,三款杀毒,二个卫士 一个管家 全装了。
这能不卡吗?
大哥,我不是说 哪个应用 更多更好 的。
只是说 那些乱装应用的,。
说个比喻,我隔壁 对我说 他的电脑 太卡了,我去一看,老天,三款杀毒,二个卫士 一个管家 全装了。
这能不卡吗?
android系统写入量超过ios? 没有依据的东西别瞎说, 任何一个操作系统都不可能进行大量写的, 你以为不费 ...
懒得和你说了,苹果自己的flash控制器,自己的cache自己的os ,自己的gpu 自己调度自己的内存,大部分操作可以在内存和emmc cache,gpu vram直接找到平衡,不需要直接物理写入flash,要写的也可以聚合写,android能?
懒得和你说了,苹果自己的flash控制器,自己的cache自己的os ,自己的gpu 自己调度自己的内存,大部分操作可以在内存和emmc cache,gpu vram直接找到平衡,不需要直接物理写入flash,要写的也可以聚合写,android能?