统一的推送渠道对中国 Android 生态意味着什么

工信部电信研究院旗下泰尔终端实验室6月1日发布消息称,安卓统一的消息推送标准目前已取得阶段性成果,未来将由终端厂商提供系统级推送服务(类似APNS的唯一推送通道),确保App的推送消息接收。

这样一则消息在开发者圈子和喜爱 Android 平台的用户群体中得以快速传播,如果能顺利落地,这一举措不论对于开发者还是消费者都是有重大意义的。往小了说,这一标准能对于通知推送起到规范作用,往大了说,这可能是国内 Android 生态极为重要的转折点。

背景

由于一系列「众所周知」的原因,国内的推送服务没法使用 Google 倡导的 GCM 推送系统(现已更新为 FCM),国内的 Android 开发者只能使用自建的推送服务。但随着用户对于相关使用常识的普及,越来越多的用户选择杀死不常用的后台软件,自建推送服务的到达率日益下降。

有大厂背景的几款推送服务也因此应运而生,他们声称拥有极高的推送到达率,其原理很简单,就是将使用了其服务的全部应用关联在一起,只要有一个漏网之鱼就可以把旗下全部应用唤醒,以此保证使用其服务的应用全部运行在后台,以及时获得通知。

这样的做法的确保证了消息到达率,不过坏处也显而易见,不论重要不重要的应用全部存活在后台,导致系统资源消耗极大,所谓「Android 手机越用越卡」就是如此保活的恶果。用户和手机生产厂商为了解决这样的问题采用更严苛的后台限制措施,而推送服务提供商为了突破限制使用更极端的唤醒方式,Android 开发者为了保活明知推送服务的危害也只能选择加入唤醒链,这使得整个 Android 生态陷入一种恶性循环。

推送通知的混乱可以说是整个国内 Android 生态乱象的罪魁祸首

期望

而现在公布的这一推送标准,可能从根本上切断这种恶性循环。统一的推送标准,意味着消费者和开发者不用再进行躲猫猫式的明争暗斗,推送不再需要让软件留存在后台,用户也无须考虑后台限制。

对于开发者来说,这一标准可以不再需要考虑软件后台存活率,可以放心大胆的使用更新版本的 SDK 并利用新版 Android 特性提供更优秀的软件功能。同时,由于有了统一的推送标准,第三方推送服务不再有存在的意义,删除这部分的 SDK 可以大幅降低软件包体积以及请求的软件权限。

对于消费者来说,这一标准可能从根本上摆脱应用后台驻留的问题,Android 系统越用越卡的谎言也不攻自破。同时,后台驻留带来的电量快速流失问题也会得到极大的环节。由于有了官方的推送形式,如果开发者都能按照标准进行开发,用户可以获得更一致的通知体验,并且也不必再提心吊胆,操心后台驻留的问题,Android 平台的使用成本和门槛也将大大降低。

阻碍

愿景是美好的,但实际的落地过程恐怕不会如此一帆风顺,首要的问题就在于如何保证现有设备如何接入这样的系统。根据目前的消息,这样的标准需要手机厂商在系统中预置相应套件,那对于现有产品来说,这样的条件怕是很难落实,尤其是大环境下,各厂商懒于向旧设备提供系统更新,现有设备很可能完全无法从这样的标准中获益。而对于开发者来说,目前已出售的设备占据了市场的绝大部分份额,为了让这部分机器也能达到较高的通知到达率,在相当长的一段时间内还是很难将第三方推送服务抛弃,这样一来第三方推送服务带来的链式唤醒导致的一系列仍无法彻底解决。待到使用该平台的手机得到普及时,恐怕又是几年过去。

另外,如果该标准并非强制执行,必然会有部分开发者为了自己产品的保活而坚持使用第三方推送服务,不愿切换到新的推送标准,从而可能出现劣币驱逐良币的结果。类似前些年各种垃圾短信的狂轰乱炸,也是由工信部牵头,限制企业发布短信广告的能力,保证用户可以退订广告信息,但正所谓道高一尺魔高一丈,企业为了钻规定的空子、避免被退订,设置各种花式退订关键词,让用户几乎不可能退订成功,而这样的做法正在被越来越多的企业使用。

总结

无论如何,由国家牵头推动这样的事情必然是在 Google 入华难以实现的情况下最优的解决方案。正如广告短信这件事一样,虽然没能从根本上杜绝这样的情况,但起码改善了整个通信网络空间,给了用户更多的选择权。同样对于 Android 消息推送来说,这样的标准也不大可能完全改变中国 Android 生态的现状,但必然能防止这个生态继续崩坏,并很可能在可见的将来逐渐变得越来越和谐。

记 DIY 之路的第一步:Magic Mirror

今年一月份看到了 Max Braun 发布在 Medium 上的文章:My Bathroom Mirror Is Smarter Than Yours ,当时真的在心里 「Wow」 了出来,效果相当惊艳。心里一直对此念念不忘,想着自己也要做一面这样酷炫的镜子。苦于一直没有时间,直到最近才能凑出一定时间真正考虑 DIY 一面自己的 Magic Mirror。

硬件方面相对比较容易解决:一面单向镜、一个显示器、一块液晶面板驱动板、一台能运行 apk 程序的 Android 设备、一根 HDMI OTG 线。软件方面 Max 并没有将自己开发的软件开源出来,而其他效仿其制作的 Magic Mirror 应用(如「Home Mirror」和「Wall Mirror」)又从视觉效果上较 Max 做的相去甚远。

无奈,还是我自己来制作这面镜子的 UI 应用吧。

在此之前,我还没有完完整整的进行过一个应用的开发。最多只是在别人的 Android 工程里进行小修小改。这次准备做的 Magic Mirror 需要进行网络连接、API 请求和数据解析和调用系统数据等一些功能,这都是之前没有涉及过的部分。虽然实际上难度不大,但对于一个只自学了一部分 Java 的我来说还是有点困难。

开发过程细节不表,总归在开发过程中遇到了一些困难,不过总算是依靠我强大的 Google 能力一一解决。UI 方面也没有自己重新设计,完全使用了 Max 的那一套设计。虽然代码写的可能蹩脚低效,但起码做出来了不是吗?现在,我将它上传到了 Github:MagicMirror 。目前具有的功能主要是显示时间、日期、当前位置的温度、天气状态、一天内的天气变化状况和新闻 RSS 显示,未来可能还会加上 Calendar Events 的显示支持等功能。

欢迎所有人 Fork 并且 Pull Request,将它做的更好更完善。

Google Photos 导航模式重设计

前阵子刚刚更新的 Google Photos 加入了 Bottom Tab Navigation,激起了用户大量反馈,或积极认为这样做相比之前的 non-indication 的 ViewPager 滑动切换更加直观并且方便单手操作,或消极认为此举是把用户当弱智并且占用了15%左右的有效显示高度。

显然两种观点都有一定的道理。对于用数据说话的商业产品,商业公司显然希望应用主打的功能更易发现、更易进入、更多点击率。而对于用户而言,一方面如果应用的操作不便于日常使用是完全不合理的,另一方面为了方便使用而占据大量的屏幕控件也是令人反感的。

平衡用户与开发商之间的利益是困难的。尤其在目前应用内导航模式缺乏的时候,做好易用性与高效性之间的取舍是一个应用交互好坏的重中之重。就我个人而言,我很反感为了 Bottom Tab Navigation 的形式,认为这样的设计有碍屏幕内真正对用户有用的显示空间,使得内容的呈现不足。

因此我自己对 Google Photos 的导航模式进行了一定的重设计。我将 Tab 栏与 App Bar 合并,将展示及切换 Tab 的任务放置在了应用的顶部,同时保留旧版中的滑动切换手势。

将 Tab 栏放置于顶部的原因主要有三:1. Google Photos 对品牌展示的需求很小,因此 App Bar 不需要展示应用的名称或 Logo;2. 使用两条固定栏占用的屏幕空间过大,压缩在一条内可以明显增加屏幕实际显示高度,这对于以展示图片为主要功能的 Google Photos 是必要的;3. Google Photos 应用内的三个 Tab 栏内除 Assistant 栏存在右滑去除卡片的滑动操作(与该栏左滑切换至其他 Tab 的滑动操作不冲突)之外没有其他的横向操作手势,因此保留滑动操作亦可提高应用的单手操作效率,同时由于存在 Tab 栏的 Indication,用户可以方便的查看当前所在 Tab 以及附近的其他 Tab。初次使用的用户亦可通过点击顶部 Tab 实现切换操作,并可以在左右滑的动画的引导下学习滑动手势。

除了导航模式之外,我还将 Assistant 页的添加操作全部置于页面上,原因是该页在大多数情况下内容较空,并且所有可以添加的内容种类并不多。原版已经在页面上显示创建四种内容而将另两种放置于需要点击“添加”按钮弹出的 Bottom Sheet 里不合逻辑。