Motorola 将带给我们一款怎样的3D手机?

9月4日的Motorola发布会,吸引眼球的不光是闪耀的明星Moto 360,更有颇让人期待和好奇的Moto X后继者。日前@evleaks在Twitter上用一张Moto X+1的高清谍照作为其收山之作,想必定有其出众之处。

【谜题】

很快就有媒体指出谍照正面多出来的开孔很可能是类似Amazon Fire Phone的人眼追踪传感器。更有新的传言指出Moto X+1将使用视差障壁技术的3D显示屏。假使真如其言,我们不禁疑惑,在HTC、LG和Amazon先后试水3D视觉手机都未能取得成功的今天,Moto又将拿出什么样的杀手锏重新证明3D视觉之于手机还能取得成功呢?

纵观过去那些不太成功的3D手机,虽然各有缺憾,但最重要的一个共通点无疑是 软件支持的匮乏 。没有App和游戏支撑的3D显示,也就只能当为日常使用的一个陪衬,偶尔增加一点气氛罢了。那么,在Google接手并改造后,今时这个擅长软硬结合的Motorola将如何破解这个难题呢?

【钥匙】

我的预测是,关键的钥匙还在Google手中,它早已摆在众人眼前,却鲜有人注意到它就在那里。

Elevation in Material Design

今年Google I/O上大放异彩的Material Design,尤其强调Paper的立体感,通过赋予界面中各部分不同的 『海拔(Elevation)』 ,让其跃然于纸上。这不正是3D的效果么?柔性阴影(Soft Shadow)的使用无非是为了在缺少3D展现能力的传统2D屏幕上营造出3D的既视感,显然没有直接展现3D景深来的真切了。

Soft Shadow in Material Design

再从实现层面来看,『海拔』这个属性,被深刻的植入Android L之后UI元素的基石——『View』之中。任何View,都具有elevation值。也就是说,一个普通的App开发者,只要遵循Material Design的基本原则设计UI,自然会赋予界面的组成部分不同的海拔,他们也许压根没有想过要针对3D视觉作什么优化,但却在潜移默化中被Google代入了3D视觉设计的理念。带有阴影的视觉效果,反而只是3D UI在传统屏幕上的一种视觉近似。

【线索】

天衣无缝的计划,也有漏出马脚的时候。Google的Android开发者博客已经急不可耐的透露出了太多的信息。

这篇文章通过着重介绍Google I/O 2014 App的Material Design实践,试图让开发者理解前后两版不同设计细节的差异性。但在当时读完这篇文章后,我却感觉其推崇的改动后的新设计有一种说不出的违和感。因为我在Google I/O会议期间就频繁使用了第一版,在我的手机上,其原本设计的视觉体验非常好(尤其是上滑时透明效果的淡出过渡),但升级到新版本后,那些改动的细节却给人一种强扭的体验。当然,对于没有深刻体验过第一版的使用者来说,很难体会到这种变迁,通常会自然的接受目前的设计。

Google I/O App in 3D

当两件事情联系在一起时,就豁然开朗了。很可能在第一版Google I/O App设计时,还没有可用的3D手机,所以自然是为2D展现而设计。当后来Android设计人员拿到尚未公开的3D手机后(不一定是Moto X+1,说不定是Nexus X呢),重新针对3D展现效果进行了细节的优化。于是乎那几个在2D下看起来违和的调整,一放到3D视角中,简直就是量身定制的优化~

【新纪元】

如此看来, Android L或许在深思熟虑之后慎重的开启了整个Android生态的3D纪元。 不仅基本界面设计3D化,连很多原本平面的系统UI,也改为了3D效果,比如多任务切换UI(强3D视觉)、通知栏(景深明显的双层设计)、锁屏界面(注意左右滑动时下方图标的景深变换)。而在2D下效果平平的波纹状(Ripple)反馈动画,可能让人觉得多少有那么一点『败笔』之嫌,但换到3D下,倘若真如Google I/O Keynote中所展现的3D动感波纹,那将是何等的惊艳!

如果 Moto X+1 还不足以撬动整个硬件生态,那么下一代的Nexus手机倘若也如目前众多传闻所言,乃Motorola代工,那么就很可能是Moto X+1的姊妹作,其标志性的3D视觉也将成为下一代主流手机的指引设计了。

距离9月4日只有1周多的时间了,就让我们拭目以待Moto X+1能否开启Android生态的3D纪元吧!

微信收费事件背后被广泛忽略的技术细节

作为一个横跨通信与互联网两大行业的从业者,前四年的核心网经验和后五年的互联网经验让我不得不感慨一个非常遗憾的现实:通信与互联网两大行业本来可以有珠联璧合的技术协同,为移动互联网提供近乎零耗电零流量的PUSH机制,但由于两个行业之间长期以来的价值观隔阂和互防心态,导致如今的手机PUSH技术不仅为用户增加了显著的电量消耗,还对移动运营商的基础设施造成了完全不必要的信令压力。微信与运营商的纷争正是这种冲突集中爆发的结果。

看到不少来自两个行业的专业分析,通信行业的专家谴责微信过于频繁的心跳和短包导致“信令风暴”,而互联网人士则往往站在用户与道德的制高点上对移动运营商挖苦讥讽,双方都很少探究这个问题的深层次技术和利益矛盾。这里我不妨提一提有些大家没有真正重视的技术细节。

为什么使用同样PUSH技术的Apple和Google等巨头,没有被运营商卯上,唯独单单拿微信下手?大家也许会认为这是运营商欺软怕硬,拿Apple和Google没办法。其实从实际数据上来看(下面将提到),微信确确实实产生了远超Apple和Google的信令需求。难道是因为腾讯技不如人,被逮着了尾巴?其实不然,我们曾经也在PUSH技术上投入了较多的分析研究,其中一项发现或许可以解释各种原委。根据分析,一般当基带空闲超过一定时间后,运营商的IP网关会自动释放(关闭)连接。目前各家所使用PUSH通道的实现原理虽然同为『长连接慢心跳』,但这个『慢』字却有很大的文章。Google在Android系统中使用蜂窝(2G/3G)网络连接GCM的PUSH通道时,默认采用的心跳周期是28分钟,这才是所谓“慢”的含义 —— 尽可能降低心跳的频度,从而达到尽量省电的目的。但这个放诸全球绝大部分地区借行得通的规则,到了中国大陆,就出现了问题。以中移动的2.5G网络为例,经过粗略测试,大约5分钟左右的基带空闲,连接就会被释放,这就是为什么微信Android版本选择以『5分钟』为周期发送连接心跳。可能有人会有疑问了,『那Google以28分钟发送心跳,岂不是在中移动的2.5G网络下无法保持PUSH长连接?』事实上,确实如此,这也是为什么Google的PUSH通道经常『迟到』。当我们活跃使用手机时,由于基带往往并不会闲置,所以部分掩盖了问题的本质。另外,当连接到Wi-Fi时,宽带的网关一般没有空闲释放机制,所以长连接会得到保持,这也进一步减少了我们平时遭遇的PUSH迟到。

『5分钟』的心跳周期到底是什么概念?可以理解为,每部安装了微信的Android设备每天发送近300条短信(其实占用的信令资源还远超这个数量);还意味着每天你的手机将被从待机省电状态唤醒近300次,每次相当于打一个几秒钟的电话。粗略测算,一般的Android手机每天有超过15-20%的电量被消耗在发送过度频繁的心跳上。其实,这都还远不是最糟糕的事情。由于众所周知的原因,大陆行货渠道发售的Android手机都无法使用Google的PUSH通道,原本每个手机中只需要建立的唯一共享的PUSH通道,被人为分裂,以至于每一个声称为用户提供实时通知的国内App,基本都在重复上面微信所做的行为。当你的手机中同时安装了多个这类App时,无论手机的耗电,还是运营商的信令负担,都要数倍于上述情形。

虽然我向来不惮以最坏的恶意揣测国内的垄断巨头,但在这个事情上,中移动或许确有它的苦衷。正如很多技术文章中所言,2G网络的基础结构和协议并未针对IP传输优化,其服务IP链路的信令承载能力相对较弱,而TD-SCDMA又长期得不到真正的发展,导致中移动的2.5G网络承受了超龄超载的负荷。刻意缩短空闲连接的释放超时,可能原本是期望能起到节省信道资源的目的,没想到聪明反被聪明误,这一限制性的举措让互联网应用不得不以远高于正常的频率发送心跳以维持PUSH长连接,结果大大加重的信令负担,给本就脆弱的2.5G网络雪上加霜,而且更给用户的手机造成了远超常规PUSH技术的电量消耗,造成了如今这一『三输』的格局。

其实,不光是微信,整个移动互联网行业都在努力解决PUSH机制目前所面对的各方面问题。包括Google、Apple这样在整个行业举足轻重的巨头,都仅仅在OSI通信协议的4层以上作各种努力,目前几乎所有的PUSH机制都基于『TCP长连接慢心跳』方式实现。虽然『慢心跳』如果得以正常工作,可以在一定程度上降低手机基带模块的工作频度,但无论互联网行业在技术上再如何标榜“PUSH”相比“PULL”的流量优势,但在OSI的下三层来看,基带模块所承受的负担和“PULL”仍然没有本质差别。这就决定了耗电问题不可能从互联网技术层面彻底解决。事实上,在移动通信网络中,信令是一种天然的最佳PUSH载体,它不需要任何IP层的收发包(也就不需要TCP连接)就能实现秒级的实时性,最重要的是它没有任何额外的电量负担,手机完全只需处于正常的待机状态。可惜移动运营商只会将其运用在一本万利的SMS(及WAP PUSH)服务,压根不可能无偿提供给互联网产业使用。结果,互联网行业选择了虽然不用付费,但却代价高昂的『TCP长连接』,只为让用户享受到免费的通知服务。这种两大行业置用户体验于不顾的分庭抗礼,已经相持近10年,而当互联网终究开始以免费服务反噬移动运营商的SMS甚至语音业务时,运营商再也坐不住了…… 但与其饱受信令风暴的折磨,不如主动免费开放信令通道作为更高效的PUSH通道给互联网产业使用,再以『免费增值』的思路构建有QoS保障的VIP PUSH服务。不仅可以大幅度节约信令资源,更能以用户体验的提升打造核心竞争优势和增值空间。能否走出这样一条转折的道路,就看运营商是否愿意转变思维了。

注:由于iOS系统的相对封闭性,暂时未能测定Apple的Push通道APNS在2.5G网络下的长连接心跳周期。欢迎了解的朋友补充测试数据。


UPDATE:更正微信Android版在中移动2.5G网络下的心跳周期为5分钟(此前测定的2.5分钟存在偏差)

活用通知栏,改善Android应用运行期体验

Android引以为傲的最为成功的UI设计之一,就是它灵活而强大的下拉通知栏,甚至连对UI有自己独到理解的Apple,都心甘情愿效仿这一设计。

不过大部分应用开发者对通知栏的运用理解上存在一些局限,以至于没有充分发挥出这一神器对App应有的价值。比较常见的理解是,通知栏是主要是用来展现Push通知,以及在用户关闭App期间通过后台服务推送信息给给用户。这确实是目前通知栏最常见的使用场景,但却在思维上将其局限于App运行期以外的交互方式。

为什么通知栏就不可以是App运行期间的一种交互形式呢?对于运行期的交互途经,一般开发者首先联想到的是Activity的范畴,需要通知时使用Dialog和Toast。其实通知栏作为一种应用运行期的交互方式,具有『低骚扰』、『节省界面空间』和『长留存』三个相当明显的体验优势。

下面就举几个典型的运用场景加以说明。

(1)App版本升级通知

很多App的升级通知都在启动阶段通过弹出对话框提示用户,用户确认后就开始下载并安装,在此过程中用户只能眼巴巴的等待下载完成。这是一个不太友好的用户体验,尤其是对工具类App而言。如果用户冲着一个急迫的待解需求打开App,这时候弹出升级提示,一方面很容易打断用户当前的使用意图,如果用户确认升级则迟迟无法解决当时的急迫需求;另一方面,如果用户吃一堑长一智,为了尽快解决需求,而关闭升级提示对话框,那么开发者希望以此推动用户升级App的效果就大打折扣了。

这时候活用通知栏,就可以很好的化解上述矛盾了。通过异步检测新版本,并创建一个通知栏消息,既能告知用户有新版本可升级(Ticker在顶栏的滚动显示效果),又不必阻断用户当前想要完成的操作。即使用户急于解决当时的需求而忽视了升级消息,在关闭App后,升级通知仍然滞留在通知栏中,可以有效的二次提示用户进行升级。如果非Play Store渠道安装的App,与之配合的最佳交互实践是:在用户点击该消息后,通过DownloadManager在后台下载安装包,待下载完成后创建另一条通知消息,用户点击再触发安装(升级)流程。这样引入的是一种很轻的交互,不会在低配置机型上因再次启动App界面带来的响应迟缓感。

(2)交互频繁场景下的非关键通知

这一点在游戏中体现的尤为典型,如果在用户的紧张操作过程中,需要给用户一些不急迫的非关键性消息(例如获得头衔、好友邀请),通过通知栏来递送就有不可取代的明显优势了。过去的交互设计习惯中,往往需要引入App内的『状态栏』来显示这类消息。这样做的缺点很明显,不仅增加开发成本,占用宝贵的屏幕空间,而且多条消息也难以实现堆叠,其实状态栏的职能用通知栏来取代是非常适用的。

与之相关的一个讨巧的通知栏使用技巧是:创建一条只含Ticker文字的通知,短时间后移除,就可以达到在通知栏滚动显示一些不需要保留的即时性消息,类似过往对『状态栏』的典型使用场景。

另外,活用同ID通知的『替换』,可以将多条消息合并提供给用户,节省通知栏的空间占用,给用户留下一个谦和的体验感受。而对于仅在运行期间有意义,不需要在App不活动时保留的消息,请记得在onPause()中移除,留给用户一个洁净的通知栏。

(3)『随叫随到』的信息区

很多互联网App的设计中,都不乏『个人信息(User Profile)』之类常驻界面信息区,开发者往往习惯在界面上开辟一小块区域显示这类信息,点击(头像)可以进入个人资料界面。

对于一些无需较强账户认知的App(如资讯类、工具类)而言,持续占用一块屏幕区域,哪怕是ActionBar上的一个按钮,对UI设计也是奢侈的。这时,不妨考虑利用Sticky的Notification(通过 Service.startForeground() 激活),Icon用于显示用户的头像,右侧的双排文字区合理排布用户的关键信息或状态。即使觉得默认的布局不够灵活,也可以定制自己的Layout以容纳更多的信息单元,并在有限的显示面积内支持简单的交互。如果支持Jelly Bean,还可以运用更为体验友好的大尺度和富媒体通知样式,以及可定制的交互按钮(Actions)。

Tip:别忘了在应用onPause()时移除这个Sticky通知。

当然,对于这种非常规的UI设计思路的认同,可能就仁者见仁智者见智了,不过一旦采用了这种设计,就需要给用户做好积极的引导,以免用户因习惯的原因而找不着这个入口。

(4)隐形通知

这应该是Google Now首次引入的一种通知体验设计模式。通过使用最低的Priority(Jelly Bean)或全透明的Icon(ICS及更早版本),使该通知在用户未下拉开通知展现区时呈现出一种『隐形』的效果。

这种通知一般展现一些优先级非常低,不需要用户显式关注的消息,但可以给用户形成一种暗示,『当我需要这类信息时,可以拉开通知栏试试看,它应该就在那里』,即使用户不再需要这些信息,也可以随时『挥之即去』(ICS+)。

虽然Google Now将隐形通知使用于后台服务中,但我们完全可以将其借鉴到App运行期间,发挥其无干扰的价值。比如用于展示不希望干扰用户的相关推荐、最近的非重要App事件、频繁更新的状态、游戏中的『任务指引』等。

同样记得要在onPause()时清理不需要留存的隐形通知。

 

将通知栏纳入App运行期的交互体验,是一种相对另类的设计思路,如果运用得当,不仅可以省下不少开发工作量,还能给用户一种略带惊艳的舒适体验。同时,需要保持清醒的是,通知栏也是一种相对紧张的资源,尤其是被国内大量常驻类App无条件霸占之后,如何掌握好通知的使用与滥用间的平衡点,也是需要一定设计智慧的。

S60第三版的Field Test也能实现锁频

最早用N-Gage时,zg曾写过一个和Field Test功能相似的NetMon,可以支持锁频,很好用。当年在峨眉山旅游时就曾经通过锁频保证了手机上网的稳定性

此前也下载过一个S60第三版的FTD(Field Test,通信网络现场测试工具),不过一直没捣腾懂这个界面怎么用。这次升级E90固件,重新安装了新版本的FTD才总算搞懂了这个玩意儿的用法。

启动FTD后,在很多页面中都能看到BTS test OFF,表示当前未开启“锁频”功能。激活锁频只需要在上述任何一页中,从菜单选择“Execute”,然后输入频段号即可。当前的频段号在第一页中的FreqCh栏里显示着。输入3333即可关闭锁频,回到正常状态。

小技巧:切换到0(或者其它任何无信号的频段)即可达到当年葛优在《手机》中开机强行拔电池的效果——“暂时无法接通”(或者“不在服务区”)。;)

N-Gage将迎来一系列EA的新游戏

看来Nokia和EA的关系还不是一般的铁,当初第一代N-Gage上EA就投入了大量的心血。要知道那时候开发Symbian程序可不是现在这么容易,没有POSIX,没有STL,还得屈就于那100MHz主频的CPU。

今天EA宣布将在第二代N-Gage平台上发布一系列EA游戏产品的移植版本,包括:

FIFA 09
Spore Origins
Need for Speed: Undercover
Tomb Raider: Underworld
Sims 3
……(只写了几个我喜欢的,其它看不上,没见过的都被我直接忽略了)

Nokia E90支持H.264视频加速的尴尬真相

在去年E90刚到手的时候,我曾经尝试分析过E90的视频播放硬件加速能力,当时试图用内置的RealPlayer播放器播放全屏尺寸的H.264未果。后来又看到网上很多关于E90视频转换的文章,不过都没有提到过如何转换支持内屏全尺寸播放的H.264视频

今天,在试用Badaboom之余,我又顺便深入测试了一次E90的H.264视频播放能力。经过多番对比测试,最终得出一个残酷的结论:

E90并不支持使用内置的RealPlayer播放器借助硬件加速播放内屏全尺寸(800×352)的H.264视频。

继续阅读Nokia E90支持H.264视频加速的尴尬真相

Symbian S60下的Google日历同步工具——CalSync

http://s60addons.com/calsync/

虽然仍在beta阶段,但也比以前用的GooSync.com要强多了,至少Todo List可以被正常同步。而且比用SyncML协议的速度要快那么一点。

但据我测试,仍然有bug:在手机上删除的Todo条目似乎不能正常同步删除Google日历中的条目,等再次同步时,CalSync又会将它同步下来,并且变成一个全天的备忘事项。

E90 Firmware亚太版7.40.1.2已上线

可通过如下官方网址查询:http://europe.nokia.com/A4305060

我的E90已刷为新加坡版Product Code:0544485,Nokia Software Updater上明确的显示出当前的最新版本是7.40.1.2:

E90 Firmware 7.40.1.2

E90中文Firmware虽然更新晚了欧洲版本不少,但现在终于也可以享用到A-GPS和更稳定的浏览器了! 🙂