可穿戴时代的蓝牙耳机

9月5日的Motorola发布会,两款手机+两款可穿戴设备,其中除了众所周知的Moto X/G继任者及Moto 360之外,还有一款神秘的蓝牙耳机。为何蓝牙耳机也能会与另外三款明星设备相提并论?Motorola打算如何重塑人们印象中的蓝牙耳机呢?

蓝牙耳机虽然是历史最悠久的可穿戴设备之一,但却似乎在近年来的可穿戴设备大潮中被人们熟视无睹到几乎遗忘。很重要的一个原因是,无论用户还是厂商,都还没有改变蓝牙耳机就是用来『打电话』这种固化的认知。虽然最近几年蓝牙技术及Profile规范的发展衍生出了基于A2DP的立体声蓝牙耳机,这两年特别火的Apt-X codec又将蓝牙耳机的音乐音质发挥到了极致(尽管仍然很难讨好专业的耳膜)。但蓝牙耳机还是没能跳出『打电话』、『听音乐』这种完全无法挑动人们兴奋神经的用途。

智能手表的出现,让人们意识到,原来不用掏出手机就能解决很多短平快的需求。但是随着一大波智能手表已然进入了科技激进者的日常生活,他们才发现美好的愿望与现实的境况总是有那么一些不和谐的落差。在户外环境下效果一塌糊涂的语音识别让语音交互的美妙体验大打折扣,缺少Google Now式对话互动的搜索结果卡片让人抓狂于手表的袖珍屏幕,手腕上来电提示那个尴尬的『接听』选项让人恨不得全都拒接,比手机还不如的单手操控性让有车族更加无爱……

这一切不如意的源头,在于智能手表输入输出能力上的较大局限性:有限的显示和触控面积、较弱的麦克风收声能力、音频输出的缺乏。因此,即便是Android Wear在交互设计上全面向语音倾斜,但却仍然只能提供一个没有语音反馈的残缺体验。试想,当智能手表 + 蓝牙耳机,这一切将获得怎样的改观?骨传导技术可以有效保证户外吵杂环境下的语音识别,完整的对话式Google Now体验甚至让你都无须抬起手腕,无论来电还是通知都可以从容的选择接听或朗读,无论是驾车还是搭乘公交都再无顾虑…… 且慢,不知你是否意识到,上述的这些体验其实全都无需智能手表的存在!没错,与当代智能手机演进契合的蓝牙耳机,可能在很多方面远比智能手表对普通用户更加实用和便捷。

但是,为什么迄今为止都没有厂商推出这样一款『现代化』的蓝牙耳机呢?除了设计思考的惯性之外,技术上的限制和困难也成为大部分传统蓝牙耳机厂商迈不过的门槛。

首先是长时间佩戴的舒适性和美观度,传统的蓝牙耳机都是为短时佩戴而设计的,普遍无法舒适的长期佩戴。新生代的LG Tone系列、Moto Buds和三星刚刚发布的Gear Circle都尝试在不断改善持续佩戴的舒适度,但是迄今为止都没有哪一款蓝牙耳机的重量能降到项链类配饰的水平。从我个人佩戴LG HBS-730的感受来说,仍然无法完全习惯于长时间佩戴,最主要的因素就是重量。美观度也是蓝牙耳机长期佩戴的一项主要阻碍,LG Tone系列的最新一代已经设计为耳机线可完全隐藏收纳,而Gear Circle则主打磁性闭合为类似项链的效果。但即使是目前这一众看重设计的新生代蓝牙耳机,也都普遍显得太过臃肿。

其次是操控的便捷性。Google一直主打的『OK Google』开启语音交互的体验,在蓝牙耳机上还存在着较大的技术障碍,耗电是目前难以克服的问题。Moto X支持Touchless Control的大前提是它2200mAh的电池,而且当手机在封闭空间里时语音侦听是关闭的。对于电池不到200mAh的蓝牙耳机而言,这仍然是一个较大的耗电负担。如何有技巧性的解决这一瓶颈,是一个产品与技术的综合挑战。

尽管有很多困难,但我相信Motorola将带给我们一个满意的答案,拭目以待吧。

对Android Wearable SDK的猜想

【背景】

Android团队早在去年初启动开发的4.3版本,就已经开始为可穿戴设备优化Android OS及其SDK了。Bluetooth 4.0 LE (Smart)的支持是一个毋容置疑的信号;而NotificationListenerService从AccessibilityService中的脱离,可以看作是Android为在第三方设备的通知投射扫清了障碍。Android 4.4的瘦身和内存优化更是直指512M内存级别的低配置设备,已经为嵌入可穿戴设备铺平了道路;而传感器事件的硬件级批量聚合及新的计步传感器支持更是将Android的野心袒露无疑。其它诸如Immersive Mode和Translucent System UI(榨干受限的显示面积)、Enhanced notification access(更全面的通知信息及Actions交互的支持)、Storage Access Framework(集中存储和远程访问)等等新特性中都能找到可穿戴设备的端倪。

在上周的SXSW上,Sundar Pichai宣称将会在2周内发布Android Wearable SDK,想必整个工程已经进入了最后的收官阶段。那么我不妨斗胆来预测一下几天后即将面试的Wearable SDK到底会长什么样。

【概貌】

Sundar Pichar在SXSW上也提到了他们认为的智能手机与可穿戴设备间的协同关系:『手机为中枢,穿戴皆IO』。(……smartphones became tiny computers, wearables are becoming nexuses of an array of sensors.)这说明Google不单单是希望把搭载了Android系统的可穿戴设备纳入生态,而要让『率土之滨,莫非王臣』。这也迎合了整个可穿戴生态的两条发展主线:提供富交互的完备设备 和 仅采集数据(及提供简单反馈)的哑设备。即便是未搭载Android系统的Pebble也好,Gear 2也罢,只要看作是手机的IO,就逃不出Android生态。

Google在可穿戴设备领域的处女作可谓是倾城的惊艳,但Google Glass很长时间以来只提供了非常受限的云端接入接口,让本就已经稀缺的开发人员抓狂不已,甚至于直接转向了root社区。好在Google最终在去年11月发布了Glass DevKit的早期预览版,开启了Glass本地App的大门。虽然Glass的交互迥异于目前常见的手腕类穿戴设备,但其SDK的设计思想则是非常明确而一致的,即基于目前Android SDK的更上层Addon SDK。考虑到离下一个Android大版本发布(Google I/O)至少还有3个月的这一时间点,相信这也将会是Wearable SDK第一版的基础形态。

SDK中可能会包含哪些有意思的设计呢?还是循着Sundar Pichar的线索顺藤摸瓜吧。『We want to develop a set of common protocols by which they can work together…… they need a mesh layer and they need a data layer by which they can all come together.』这里面传达了两个重要的信息:互操作性协议、数据交换标准。前者让彼此间的IO更加顺畅互通,后者可助任何数据为任何App所用。于是整个SDK的面目便可窥见一斑了。

【互操作性】

互操作性协议解决的典型场景便是Pebble这样的设备如何与Android App更方便的互通。Pebble SDK提供了一个私有的解决方案 —— Pebble端的Watch App(C语言开发)及其SDK提供的通信封装。这带来了一个Google最不希望面对的问题 —— 生态的分裂(Fragmentation)。因此,Wearable SDK需要以一个非常Android化的方式解决这个问题。除了已被广泛使用的『Notification Listener Service』外,我猜想中新的答案可能会是『Widget』和『Remote Sensor』

『Widget』是从Android诞生早期就支持的唯一一个天然适合于可穿戴设备的前瞻设计,基于预定义受限面积的周期或事件驱动的渲染,然后将渲染好的位图传递给另一个负责展现widget的画布主体,后者可以接收简单的点击和手势交互,并将其反馈给提供widget的应用,触发新一轮的重绘。原先App与Launcher间的互操作性,在Android 4.2开始已经拓展到了锁屏界面(Lock Screen Widget),如今又可以无缝的过渡为App与穿戴设备间的桥梁。更重要的是,目前数不尽的带有Widget的App就可以摇身一变成为『可穿戴设备友好』的App了。Wearable SDK需要做的只是搭建起这样一个延伸性的透传协议。至于Android 4.2开始支持的『Secondary Display』多屏联动机制,也许不会出现在早期的Wearable SDK中,但有望成为未来面向具有大尺寸显示界面和高速无线连接能力(如Bluetooth 3.0 HS)的穿戴设备更灵活的媒体显示解决方案。

『Remote Sensor』,顾名思义,就是不在当前设备上的传感器。由于大量可穿戴传感单元的涌现,弥补了智能手机本身传感器的可触达边界,毕竟穿戴在身上的设备才能更准确的采集心跳、血压等生理指标,而各类借助现代传感技术的奇特探头才能满足人们日益多元化的对身周环境的感知需求。但持续传输的能耗问题是拦在Remote Sensor发展道路上的主要障碍,毕竟Android 4.4提供的Sensor Batch机制在降低耗电的同时是以牺牲实时响应能力为代价的。真正的救星是近几年方兴未艾的SensorHub技术,通过一个低功耗设计的可编程嵌入式芯片,先行采集和缓存传感器数据,并进行相对有限的实时分析,当预置条件满足时才激活主CPU进行处理。例如Moto X引以为傲的X8体系。再看可穿戴领域的传感器单元设计,只需将SensorHub前移至传感器单元内,单元与手机之间维持Bluetooth LE连接,SensorHub只在必要的时候通过这个连接通知手机和传输数据,而手机则可以在有需求时向传感器单元主动请求数据回传。得益于Android良好的传感器框架设计,以上Remote Sensor机制只需在现有Android框架下通过Sensor Agent over Bluetooth LE以虚拟传感器的形式提供,在上层App看来和手机本身的传感器并无二致。

【数据交换】

互操作性的分裂问题得到解决,并不意味着广大开发者就可以轻松的开发支持可穿戴传感器单元的App了。眼下的局面是,Kickstarter和Indiegogo上大量涌现的智能传感器众筹项目都是各自为阵,这些团队都不得不投入大量精力自己为其产品开发智能手机App,结果还往往不尽如人意;另一方面,传统App开发者似乎都只能隔山观火,既下不了场,也捞不到汤。这种维度的分裂正是由于移动OS平台上传感器数据规范化缺失和领域技术与应用层面间的断层所造成的。幸运的是,衔接开发者,正是Google在Android中所一贯擅长的。

Wearable SDK正应担起这付扁担,一方面定义更广泛和通用的原始传感器数据协议,另一方面提供高阶抽象的虚拟传感器框架,将这种基于数据整合和领域算法的抽象能力开放给社区和学术界,让更多拥有领域经验的专家和开发者进来衔接『专业数据』与『高阶应用』两个位面,培育出众多高质量的虚拟传感器。如此一来,才能让生态的两端更融洽的衔接,让更多的生活类和生产力App也能与可穿戴设备的蓬勃发展相互促进。

【结语】

YY了这么多,其实都是作为一个Android资深开发者兼可穿戴设备控的一些美好愿望。不过相信在汲取了Android发展历程中的坎坷之后,Google不会在这个新的领域让我们失望。就让整个社区一起迎接即将到来的Wearable SDK吧。

【题外话】

补充一个身为Geek的不切实际的畅想,Android Accessibility框架所蕴含的抽象展现和交互代理能力其实有非常大的潜力成为衔接传统App与可穿戴设备异化交互的玄铁重剑。但亟需提升Android整体体验的Google,想必是不会在Wearable SDK中祭出这件难以驾驭的武器了。好在Android生态的开放性并不阻碍Geek社区朝着这条道路挺进,也许在不久之后,我们就能看到一个可以在智能手表上操控手机端任意Android App的利器了。

CyanogenMod的商业化或源于对Motorola的恐惧

这是去年底我在Google+上写的一篇短文


Moto X推出已逾半载,CM却几乎无法打入其用户群,即使XDA论坛上的Moto X开发板块也门可罗雀。因为Moto X近乎原生态的Android体验和超迅速的Android版本升级跟进,大大降低了超级用户对CM的渴望,而这个群体正是CM的主打力量。

我也是其中的一员,至今仍在使用Moto X的原厂4.4 ROM,除了上述原因之外,还有几个无法抗拒的理由:

1. Moto X主打的三个实用特性:Touchless Control、Active Display和Twist to Camera,全部依赖Moto自有的专利架构——X8体系,再加上CSR提供的蓝牙音质增强技术Apt-X。CM作为开源社区,几乎不可能取得商业授权,也无法以合法的理由集成这些闭源特性实现。其它厂商的机型则尚未形成如此强烈的特性壁垒,三星、HTC、索尼的超级用户大多并不太在意失去原厂的特性。

2. Moto X在底层优化上比CM走的更远。包括Bionic和Dalvik虚拟机的性能优化,采用了高通的私有优化,据称比AOSP的Dalvik性能表现更佳。(XDA上对此有一些深入的讨论)。同样,这些也是CM作为非盈利性开源社区所无法吸纳的。

3. Xposed框架,加上最近很火的GravityBox模块,大大加速了CM社区Moto X用户的叛逃,因为CM的很多人性化UI优化都可以在原厂ROM + GravityBox下实现。(Moto X贴近AOSP的ROM实现对GravityBox的兼容性更佳)

相信正是CyanogenMod的社区领袖们看到了Moto所带来的巨大威胁,以及可能由此引领的未来其它Android厂商发展思路的转变。才不得不采取商业化并加速自身品牌的建设,甚至直接参与设备打造,向更广泛用户群体的渗透。只有这样,才能有机会抗衡Moto及幕后的Google。

这不能不说是开源社区所面对的最大不幸,它把社区ROM的最大软肋暴露的体无完肤,也显现出Google未来Android战略的重要转变。

解决Cisco AnyConnect VPN客户端的DNS优先级问题

Cisco AnyConnect VPN的客户端是一个工作于并行隧道(Split Tunnel)模式下的VPN软件,它可以方便的同时使用内外网两不误。它通过连接VPN后动态激活平时禁用的VPN虚拟网络适配器,并根据远端网关的配置应用相应的DNS和路由配置,实现了与默认网络环境无缝并行。但正是在其上述设计中的一个理想假设,为“中国特色”的互联网环境下使用它埋下了一个隐藏很深的问题。

如果你所连接的VPN网络本身是与Internet连通的,而且DNS也可解析外网的网址,由于AnyConnect会将VPN网络适配器的优先级提升到最高,因此远端的DNS配置会取代本地网络(例如家里的宽带网络)。如果你的本地网络和远程网络是同一接入线路,倒还感觉不到这之中的差别。但如果其中一个是电信线路,另一个是联通(网通)线路,你就会遇到一个很悲惨的状况:本地网络访问国内主要网站的速度会显著降低,因为DNS对大型网站CDN的解析结果是和你现有路由完全不同的线路,想象一下在你的联通(网通)宽带下访问电信线路的网站,那种感觉……

继续阅读解决Cisco AnyConnect VPN客户端的DNS优先级问题

Google Buzz的解读误区

Google发布Buzz后,网络上迅速出现了大量对Buzz的评论,有正面的,有负面的,有炒作概念的,有跟着起哄的,甚至引发了大家对Gmail安全的担忧。这其中不乏一些对Buzz的误读,所以,在这里以我个人的理解来解释一下。

“Google Buzz是Twitter杀手!”

这是大多数媒体最喜欢的炒作方式,又一个Killer App出现了,于是编辑们都兴奋了,又可以赚足眼球了。事实上,Google Buzz和Twitter总体来看并不是一个层面上的应用,还构不成真正意义上的Killer。一些冷静的分析还是看的比较清楚,Google Buzz其实主要针对的是FriendFeed,因为它们都是聚合平台,让不同源头的信息聚合在一起。Buzz相对于FriendFeed的最大进步在于,它除了聚合信息之外,还创造性的利用Social Graph来聚合人际关系。

当然,Google Buzz除了聚合功能外,自身也充当了一个简单的信息源,可以在Buzz上发表富媒体信息。但事实上,你有自己充分的选择权,完全可以保持原有的习惯,在WordPress上写Blog,在Twitter上唠叨几句,这些信息最终都会自动被汇总到Buzz中来。

“我们不需要又一个社交网络”

当你迫不及待的跑来Buzz上兴奋的吼了几句后,才意识到它和Twitter也没多少差,反而在这里找不到Twitter上那种“振臂一呼,Follower百应”的成就感了。没过多久,你就会逐渐淡忘掉Buzz。这是因为,你把Buzz当成了一个和Twitter、Facebook、MySpace一样的社交网络。“又一个新的SNS,我不得不又一次花费时间从头建立我的关系网络。”其实这不奇怪,不光是你,连Microsoft也这么认为

本质上,Buzz并不想打造一个新的社交网络,恰恰相反,它的目的是推进一系列开放标准,使用户不必在各个SNS维护一个又一个彼此独立的关系网络,使人际关系得以重用和汇聚,进而构造起一个去中心化的Social Graph,不依附于某一个特定的SNS。

Buzz倡导运用XHTML Friends Network (XFN) 和 Friend of a Friend (FOAF) 挖掘和汇聚用户既有的关系网,实现SNS间的互操作性。如果各个开放SNS都能响应这一号召的话,那么将来我们就再也不用担心自己的人际关系被锁死在某个SNS中,甚至还可以借助新的SNS发现原有SNS中漏掉的好友。

“Buzz让信息的回复和评论更加破碎了”

这一点确实是目前不争的事实,因为无论你从Twitter往Buzz同步也好,还是打算反过来从Buzz发布到Twitter,你都得面对一个问题,回复和评论的不同步。你很可能因为只在Twitter上读消息而遗漏了Buzz里别人的评论,或许在习惯了Buzz后,又冷落了Twitter上的Followers。在Web应用越来越多的引入“聚合(Aggregation)”功能后,这个问题逐渐凸显出来。Google Buzz现在没有解决这个问题,但这只是因为目前的Buzz还尚不完整。Buzz的API文档中有一节“Coming Soon”,其中提到了Buzz未来对这一问题的解决之道——Salmon

之所以现在没有推出Salmon支持,我猜想,一方面是由于这个规范尚处在Draft阶段,另一方面它无法从Google单方面实现,因为信息源和聚合者都必须遵从Salmon协议,才能完整的实现评论同步。这个事情倘若让任何一家其它互联网公司来推,可能都收效甚微,但由Google Buzz倡导,其影响力就不可同日而语了。因此,Google在完成Salmon的支持前,先放出Roadmap来,让大家都意识到Google开放的心态和坚定的决心,这样Salmon才有机会得到广泛的认可和支持。

所以,就如同Wave对大多数人来说也不过尔尔,只有当你透过API去洞察其背后所希望表达的真正意图后,才能深刻理解Google每一款产品的前瞻和愿景。在大多数人被Buzz的优雅与便捷所打动时,我更看重的是它将对整个SNS生态圈所产生的深远影响,和它在推动开放和标准化上的显著贡献。

[好消息] 动感地带的网外短信终于可以计入套餐内免费短信数了!

以前发往联通、电信小灵通的短信不仅不能计入套餐内的免费短信,而且还收取比移动网内普通短信更高的费用。

从今年元旦起,工信部要求各运营商统一网内外短信资费,因此移动用户往国内任何手机或小灵通发送短信的费用都统一为0.1元。那么更让人关注的是,动感地带的套餐内免费短信是否也包含网外短信呢?就这一点,中国移动给出了一个很模糊的回答——请参见各套餐的说明……

去移动网站上查了一下,各套餐的资费说明均已更新,至少我目前所用的动感地带套餐已经将网外短信纳入套餐内的400条免费短信了,以后就可以毫无顾忌的随时给家人的小灵通发短信咯!

话说这400条也不是那么容易用完的……

在Windows 2008下安装RamDisk

去年新买的PC配置了4G内存,虽然64bit的Windows Server 2008可以完整的访问到全部内存空间,但事实上大部分时候,仍然有相当容量的内存是处于闲置状态的,因此安装一个RamDisk来加速临时文件的存取可以更好的利用硬件资源。

RamDisk现在有很多不同的版本,虽然功能都差不多。我选择了CCF的gavotte所开发的版本,免费、小巧,而且设置很方便,不像某某收费的RamDisk,还不能调整容量。

gavotte提供了64bit的版本,但如果你想安装在Windows Server 2008下,则不得不面临一个麻烦。由于微软强制要求“关键驱动”必须通过数字签名,所以安装后RamDisk后你会发现你的Windows无法启动了,它会提示“有驱动程序未通过数字签名,Windows拒绝启动”。这时你唯一的选择只能在刚启动时按F8,选择“禁用驱动程序签名强制”,从而可以顺利的进入Windows。但是,总不能每次启动时都得盯着屏幕,抓住短暂的时机抢按F8吧……

好在就有这么一个神奇的软件,可以帮你自动完成上述启动过程中的特殊步骤,完全不必人工干预,它就是“Ready Driver Plus”。借助它,RamDisk终于可以在Windows Server 2008下完美使用了。虽然引入了一点安全风险,但作为Power User的你,应该不用担心这一点吧?(话说XP下没强制驱动签名不也照样裸奔嘛~)

开发人员的月光宝盒 —— 基于CPU的“时光倒流”技术畅想

一. 重现罕见问题——开发人员永远的痛

但凡做过程序调试的开发人员,一定都有过面临难以重现的问题时仰天兴叹的经历,祈祷老天赐予传说中的“月光宝盒”,从而逆转时光揪出那引发程序错误的元凶!

即使在错误跟踪技术经历长足发展的今天,哪怕是经过周密故障跟踪机制加持的代码,程序员仍然对那些难以重现的问题提心吊胆。错误跟踪机制再先进,也难以完整记录整个程序的运行轨迹和任何过去时刻的系统状态。数据覆盖的不可逆决定了程序执行的单向性,就像时间之箭,谁也不能让它转向。但时间的单向性并不意味着过去的时光不能从头来过,就像“月光宝盒”虽然不能使你回身飞上万丈绝壁,但却可以将你带回过去的某一时刻,让后面的历史重新来过。

二. 挑战时间之箭,已逝历史也能重历?

继续阅读开发人员的月光宝盒 —— 基于CPU的“时光倒流”技术畅想