题图来自elandroidelibre.com
Android早已是全球最大、用户最多的移动操作系统,不过它离全球最好用还差得很远。
大家随手就能举出些曾经历过的糟心体验,如手机卡顿!电量不禁用!广告弹窗老是出现!不过很少有人会追根寻底的去问为何如此,Android原生设计是怎样的?官方有修正吗?有民间大神来做补丁方案吗?
可能很少有人会知道,其实你对Android的印象已经远远落伍,它的问题很多都有了相应解决之道。下边宅客君将告诉大家,Android的不好用是因为什么?现在的Android又是怎样?
手机卡顿
从技术角度来说,卡顿主要有三方面原因:Android应用采用Java语言,相比iOS的Object C它更耗费硬件资源;Android设备过于分散,至少一半以上是中低档机型;Android对前台进程没有提高优先级,后台过多容易抢占更多资源。
虽然“天生卡顿”,但经过几年的艰难努力,现在最新Android设备已经很少出现卡顿问题了。来看看这个问题是怎样被改善的。
早期的Android版本(v1.5+)没有进程管理,当每次多开了几个应用,大家都会用atk等第三方工具来杀后台。
Android 2.3加入了进程管理,终于可以用系统设置来关闭应用,不过只能一个一个的关。这时已有许多工具类应用支持一键清内存。
Android 4.1-4.4的“黄油计划”以及后续改善,对小内存设备做了极大优化,桌面切换效果绚烂些也很流畅。这也是得益于硬件更迭的加快,从单核到双核、四核升级的时间只在2013一年多的时间内就完成了。
Android 4.4里开发了一个新的应用运行环境ART,切换到ART后,应用打开、切换变得非常流畅,可以媲美“黄油计划”后的桌面切换效果。不过ART需要开发者去做应用兼容,目前大部分主流应用做出了兼容性更新。
其实在2013-14年,硬件的性能已经可以让Android足够顺畅,但我们还是能听到一些卡顿抱怨。原因在微信(游戏大家有预期,反而不会那么抱怨),如果你的微信好友和群稍微多些,它将逐渐吞噬掉这台设备的内存,清理工具也只能些许缓解状况。微信变成了现在很多人升级设备的理由。
电量不禁用
移动设备的电量不禁用,但Android这点特别明显。很容易比较,3000mAh电池的Android手机使用时间和1500mAh的iPhone差不多,有时还不如。
不过这已经是很大进步了,因为现在的Android系统效果比以前丰富的多,还能一直开着Wi-Fi、蓝牙和GPS。Android的耗电优化分为两方面:硬件、软件。硬件端大概在2013年左右完成优化,此前“开着Wi-Fi”和“不开Wi-Fi”电量差别在10%以上,而现在开不开差别不大。
软件端主要是待机后后台应用还在工作,比如联网检查新消息。iOS上所有消息推送都使用苹果官方的推送服务,Android上由于Google的GCM不强制使用以及在国内不可用,大家都是用自己或合作方的推送服务。打个比方,同样三个应用接收消息,苹果上一次推送完成,Android上要三次推送。部分厂商在ROM中增加了“对齐唤醒”可以让Android一次推送完成,不过它被认为可以绕过。
推送服务泛滥变成现在Android耗电的最大由头。这时“一键清后台”就有了新的意义,从开始的缓解卡顿变成现在的省电,把后台一清,就一了百了。
其它
Google一直着力改善Android的体验,不过它更着重基础体验,比如卡顿、续航。在其它方面则余力不足,比如广告弹窗横飞、权限滥用、应用缓存文件,这些让第三方安全应用有发挥余地,LBE安全大师、360手机卫士、腾讯手机管家即基于此。
这部分不再是Android征服硬件,而是移动安全公司与广告公司之间的战斗。
广告弹窗插件前几年更泛滥,手机的通知栏几乎全是这些信息。还曾经出现一些奇葩事情,某个应用内的广告插件平时不启动,但微信启动时它就弹广告,让用户以为是微信在弹窗。后来几乎上规模的广告插件都被识别,由于效果不佳,现在的广告插件收敛很多,只做用户信息收集和固定展示。
权限滥用也很可怕。最早版本的微信会自动上传用户通讯录,这就是一起很典型的例子。目前应对方式还是使用权限管理软件,大多安全应用都有集成。
应用缓存清理这点看似很小,但想想猎豹清理助手以及美国上市的猎豹移动就知道这块绝对是个痛点。
从现在看,Android不好用主要还是软件端的体验,硬件端已经足够。Android系统的过于开放让它拥有最多的用户,但也使得这个系统的最弱端被无限放大。广告弹窗、权限滥用在塞班时代也有,但那时并不是问题,塞班的用户大多能自己折腾。如果下次在果粉的场子上,可以跟对方科普下,Android早已今非昔比了。
本文大部分观点采访自LBE安全大师创始人张勇。
。
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/industrynews/66508.html