Google 即时通讯应用Google,负责按顺序处理 Channel 中的事件

摘要谷歌近日宣布,刚刚发布不到两年的 Google Allo
宣布将暂停开发,团队资源会转入到另一个项目中。引言网上曾流传过一份
Google 的数字坟墓,列举了那些已经停止运营的 Google
产品,里面不乏一些曾经备受瞩目的项目:Google Reader、Project Tango
等。不过要说 Google「抛弃」最多的,还是要数通讯软件。从最早的 Google
Talk 到最新的 Google Allo,Google
在即时通讯上做了无数尝试,但始终都未能形成一个统一形态,与苹果
iMessage、Facebook Messenger、WhatsApp 抗衡。最近,刚刚发布不到两年的
Google Allo 宣布将暂停开发,团队资源会转入到另一个项目中,不过这次
Google 没有再推出一个新的聊天软件,而是把新功能并入到默认的 Android
Messages
应用中,目的是用新的「Chat」服务来代替手机默认的短信。让短信像微信一样好用简单得说
Chat
并不单指一款应用,而是在传统短信系统上升级的另一种服务标准,你可以将它理解为一种解决方案,让
Android 手机的默认短信像微信、WhatsApp
这些社交软件一样好用。传统的短信是基于 SMS
服务,还没智能手机概念的时候,短信才是那个我们每天无法离开,在它身上花费无数时间、精力和金钱的应用,2005
年仅中国移动用户就发送了超过 3000 亿则短信。在微信、QQ
这类即时通讯软件出现后,丰富的多媒体信息自然是要更吸引人,而且资费更便宜,短信逐渐成为可有可无的东西。大多数人现在唯一用得到短信的地方就是接收验证码,也因为
SMS
标准的安全性问题,人们的收件箱基本被垃圾短信淹没。即使短信已经过时、有更好的替代品,但一直没有退出历史舞台,原因很简单,SMS
标准几乎支持市面上所有手机,不管低档还是高端、 Android 还是
iOS、智能机还是功能机,它不需要打开就能随时接收数据。也就是说在任何情况下,你都可以用短信和他人流畅交流,在一些特殊的场景这至关重要。短信无法被完全替代,但它毫无疑问是需要升级的。这件事为何是由
Google 来牵头呢?说得现实一点,这是 Google
在即时通讯上的一次「赌博」,也是现实状况下仅有的选择之一。屡战屡败的
Google 即时通讯应用Google
的通讯软件实在太多、太乱了,我们试着盘点一下它在这一领域曾经做过的尝试:2005
年 8 月,Google Talk 发布。2013 年 5 月,Google 环聊发布,取代 Google
Talk。2016 年 1 月,GoogleMessenger 发布。2016 年 5 月,Google
推出聊天应用 Allo,以及视频聊天应用 Duo。2017 年 2 月,Google Messenger
更名为 Android Messages,成为 Android 默认的短信应用。2017 年 3
月,Google 环聊向企业用途转型。2018 年 4 月,Google Allo
暂停开发,团队转而研究短信新标准 Chat。目前 Google
重点关注四个通讯产品:环聊、Allo、Duo 和 Android
Messages。环聊正在向企业用途转型;Allo
体验不错,但短时间内难以获得大量用户;Duo
主打视频聊天,也是单打独斗;Android Messages 拥有 Android
系统的预装优势,最有可能成功。苹果的 iMessage 就是这样做的,内置在
iPhone 中可以轻易获得大量用户。WhatsApp
是与电话号码绑定,而不需要支付电话费用。Facebook Messenge 则是直接利用了
Facebook 强大的社交关系链。大家都有各自稳定的增长渠道,可惜的是 Google
却没有。虽然 Android
已经是全球第一大系统,但它是开源的,不可控的,连三星都在推出自己的默认短信应用「挖墙脚」。我们之前体验过Google
Allo,它功能强大,还加入了很多 Google 在人工智能上的应用。不过 Google
Allo 却未能获取大量用户,目前仅有 5000 万用户,相比之下
WhatsApp、Facebook Messenger、中国的微信都已经是十亿级的应用。Android
系统绝对是 Google 最强大的底牌,但也许正因为这样,Google
才愈发谨慎地使用这张王牌。像 iMessage
一样强推预装不是不可以,但这可能会带来运营商的抗议,他们不会喜欢在
Android 手机上有这么一个可以取代短信的服务。因为据估计,目前每年还有 8
万亿条基于 SMS
的短信发出,这是一个巨大的、不可放弃的市场。综合各种因素,Google 选择用
Chat 来升级现有的 SMS 短信系统,也就成了一个合理而必然的选择。Android
是个开放的系统,SMS 短信系统需要升级,这也符合运营商的利益。那么新的
Chat 具体会有什么不同呢?Chat 成功的可能性有多大?前面说过了,Chat
区别于传统的 SMS 标准,它基于 RCS,也就是融合信息解决方案。Chat 会取代
SMS,成为短信的新标准,在默认的 Android Messages 中自动启用。用户在使用
Chat
时,他们将可以获得和聊天软件类似的体验,比如发图、发视频、文件传输、位置共享,还有群组等功能。如果收件人没有启用
Chat 或者不是 Android 手机,内容将转为普通短信,这和 iMessage
的做法相同。不过需要注意的是,Chat 并不能算作是 Google
的服务,它是基于运营商的。这个通用的 RCS
标准需要三方合作:操作系统提供商、设备制造商、运营商。Google
只是推动者之一,支持这项标准的还有微软,以及 11 家 OEM 制造商、55
家运营商。GSMA 估计,到 2021 年这将是一个 740 亿美元的市场。在 Google
负责这项工作的是 Sabharwal,他是 Google Photos 团队的负责人。Sabharwal
提到,Chat 并不是一个短时间内见成果的项目,Google
的目标是在未来几年内,为 Android
用户提供这种高质量的信息。尽管考虑了种种因素,但 Chat
的推行还是存在一些阻碍,因为它还是基于运营商,所以无法做到端对端的加密,不能保障安全性。由于
Google 对 Android
的把控还不够强,说服运营商、设备制造商存在一定的阻碍,「百花齐放」的中国安卓生态就是个例子。其次,关于资费问题也一定会和运营商的想法有出入,该免费还是收费?收多少?这都是问题。Google
这次做 Chat
称得上是一次「赌博」,功能重复、各自为战的战术很难取胜,Google
急需一个全面的通讯工具来进一步深入人们的生活。Google Allo
在产品上表现不错,但如果任由其缓慢爬升,结果也许又是一样。不如把其经验、资源抽离出来,放到用户量更广的
Android Messages 上。Google
的野心够大,只是能不能成功还要看合作伙伴配不配合。另外,即使是升级了现在的短信系统,Chat
真能动摇根基深厚的社交应用吗?美国的
Facebook、中国的微信,这几乎是人们无法离开的应用了,Google 的 Chat
即使做成,可能也只是对现有社交场景的一种补充吧。

摘要近日,苹果开源了一款基于事件驱动的高性能跨平台网络应用程序开发框架
SwfitNIO,它有点类似 Netty,但开发语言使用的是
Swift。1、SwiftNIO是什么SwfitNIO
实际上是一个底层工具,用于开发高性能的网络应用程序,作为“每连接一个线程”的替代方案。为了提升性能,SwfitNIO
使用了非阻塞 IO,这从它的名字就可以看出来。非阻塞 IO 与阻塞式 IO
非常不一样,因为不管是往网络上发送数据还是从网络上接收数据,应用程序都无需等待,系统内核会在有可操作的
IO 时通知 SwfitNIO。SwfitNIO 并不会提供类似 Web
框架那样的解决方案,而是致力于为上层框架提供底层的构建块。在开发 Web
应用程序时,大部分开发者不会直接使用 SwfitNIO,他们会从 Swift
生态系统众多的 Web 框架中选择一个。不过,这些框架中的大部分都使用了
SwfitNIO。2、受支持的平台SwfitNIO 的目标是支持所有可以运行 Swift
的平台。目前,SwfitNIO 可以在 macOS 和 Linux 上运行,包括:Ubuntu
14.04+macOS 10.12+3、基本架构SwfitNIO 包含了几种基本构建块,所有的
SwfitNIO
应用程序都是由这几种组件组成的。EventLoopGroupEventLoopChannelChannelHandlerBootstrapByteBuffer▶
EventLoopPromise 和 EventLoopFutureEventLoop 是 SwfitNIO 最基本的 IO
原语,它等待事件的发生,在发生事件时触发某种回调操作。在大部分 SwfitNIO
应用程序中,EventLoop 对象的数量并不多,通常每个 CPU 核数对应一到两个
EventLoop 对象。一般来说,EventLoop
会在应用程序的整个生命周期中存在,进行无限的事件分发。EventLoop
可以组合成 EventLoopGroup,EventLoopGroup 提供了一种机制用于在各个
EventLoop 间分发工作负载。例如,服务器在监听外部连接时,用于监听连接的
socket 会被注册到一个 EventLoop 上。但我们不希望这个 EventLoop
承担所有的连接负载,那么就可以通过 EventLoopGroup 在多个 EventLoop
间分摊连接负载。目前,SwiftNIO 提供了一个 EventLoopGroup
实现(MultiThreadedEventLoopGroup)和两个 EventLoop
实现(SelectableEventLoop 和
EmbeddedEventLoop)。MultiThreadedEventLoopGroup 会创建多个线程(使用
POSIX 的 pthreads 库),并为每个线程分配一个 SelectableEventLoop
对象。SelectableEventLoop 使用选择器(基于 kqueue 或
epoll)来管理来自文件和网络 IO 事件。EmbeddedEventLoop 是一个空的
EventLoop,什么事也不做,主要用于测试。▶
Channels、ChannelHandler、ChannelPipeline 和 ChannelHandlerContext尽管
EventLoop
非常重要,但大部分开发者并不会与它有太多的交互,最多就是用它创建
EventLoopPromise 和调度作业。开发者经常用到的是 Channel 和
ChannelHandler。每个文件描述符对应一个 Channel,Channel
负责管理文件描述符的生命周期,并处理发生在文件描述符上的事件:每当
EventLoop 检测到一个与相应的文件描述符相关的事件,就会通知
Channel。ChannelPipeline 由一系列 ChannelHandler 组成,ChannelHandler
负责按顺序处理 Channel 中的事件。ChannelPipeline
就像数据处理管道一样,所以才有了这个名字。ChannelHandler 要么是
Inbound,要么是 Outbound,要么两者兼有。Inbound 的 ChannelHandler
负责处理“inbound”事件,例如从 socket 读取数据、关闭 socket
或者其他由远程发起的事件。Outbound 的 ChannelHandler
负责处理“outbound”事件,例如写数据、发起连接以及关闭本地
socket。ChannelHandler
按照一定顺序处理事件,例如,读取事件从管道的前面传到后面,而写入事件则从管道的后面传到前面。每个
ChannelHandler 都会在处理完一个事件后生成一个新的事件给下一个
ChannelHandler。ChannelHandler
是高度可重用的组件,所以尽可能设计得轻量级,每个 ChannelHandler
只处理一种数据转换,这样就可以灵活组合各种
ChannelHandler,提升代码的可重用性和封装性。我们可以通过
ChannelHandlerContext 来跟踪 ChannelHandler 在 ChannelPipeline
中的位置。ChannelHandlerContext 包含了当前 ChannelHandler
到上一个和下一个 ChannelHandler 的引用,因此,在任何时候,只要
ChannelHandler 还在管道当中,就能触发新事件。SwiftNIO 内置了多种
ChannelHandler,包括 HTTP 解析器。另外,SwiftNIO 还提供了一些 Channel
实现,比如 ServerSocketChannel(用于接收连接)、SocketChannel(用于 TCP
连接)、DatagramChannel(用于 UDP socket)和
EmbeddedChannel(用于测试)。▶ BootstrapSwiftNIO 提供了一些 Bootstrap
对象,用于简化 Channel 的创建。有些 Bootstrap
对象还提供了其他的一些功能,比如支持 Happy Eyeballs。目前 SwiftNIO
提供了三种 Bootstrap:ServerBootstrap(用于监听
Channel),ClientBootstrap(用于 TCP Channel)和 DatagramBootstrap(用于
UDP Channel)。▶ ByteBufferSwiftNIO 提供了 ByteBuffer,一种快速的
Copy-On-Write 字节缓冲器,是大部分 SwiftNIO
应用程序的关键构建块。ByteBuffer
提供了很多有用的特性以及一些“钩子”,通过这些钩子,我们可以在“unsafe”的模式下使用
ByteBuffer。这种方式可以获得更好的性能,代价是应用程序有可能出现内存问题。在一般情况下,还是建议在安全模式下使用
ByteBuffer。▶ EventLoopPromise 和
EventLoopFuture并发代码和同步代码之间最主要的区别在于并非所有的动作都能够立即完成。例如,在向一个
Channel 写入数据时,EventLoop
有可能不会立即将数据冲刷到网络上。为此,SwiftNIO 提供了
EventLoopPromise和
EventLoopFuture,用于管理异步操作。EventLoopFuture实际上是一个容器,用于存放函数在未来某个时刻的返回值。每个
EventLoopFuture对象都有一个对应的
EventLoopPromise,用于存放实际的结果。只要 EventLoopPromise
执行成功,EventLoopFuture 也就完成了。通过轮询的方式检查 EventLoopFuture
是否完成是一种非常低效的方式,所以 EventLoopFuture
被设计成可以接收回调函数。也就是说,在有结果的时候回调函数会被执行。EventLoopFuture负责处理调度工作,确保回调函数是在最初创建
EventLoopPromise 的那个 EventLoop
上执行,所以就没有必要再针对回调函数做任何同步操作。4、SwiftNIO
的设计哲学SwiftNIO
的目标是要成为强大的网络应用程序开发框架,但并不想为所有的层次抽象提供完美的解决方案。SwiftNIO
主要专注在基本的 IO
原语和底层的协议实现上,将其他层次的抽象留给广大的社区去构建。SwiftNIO
将成为服务器端应用程序的构建块,但不一定就是应用程序直接拿来使用的框架。对性能有很高要求的应用程序可能会直接使用
SwiftNIO,减少上层抽象所带来的开销。SwiftNIO
可以帮助这些应用程序在提升性能的同时降低维护成本。SwiftNIO
还为某些场景提供了有用的抽象,高性能的网络服务器可以直接使用这些抽象。SwiftNIO
的核心仓库提供了一些非常重要的协议实现,比如
HTTP。不过,我们认为,大部分协议的实现应该要与底层的网络栈分开,因为它们的发布节奏是很不一样的。为此,我们鼓励社区自己去实现和维护他们的协议实现。实际上,SwiftNIO
提供的一些协议实现最初就是由社区开发的,比如 TLS 和
HTTP/2。5、相关资源源码托管:
文档:
SwiftNIO:聊天客户端:
客户端:
服务器端:
服务器:

摘要北京时间 3 月 21 日,Oracle 官方宣布 Java 10 正式发布。这是 Java
大版本周期变化后的第一个正式发布版本,非常值得关注。引言北京时间 3 月 21
日,Oracle 官方宣布 Java 10 正式发布。这是 Java
大版本周期变化后的第一个正式发布版本(详见这里),非常值得关注。你可以点击以下地址即刻下载:
9 月,Oracle 将 Java 大版本周期从原来的 2-3
年,调整成每半年发布一个大的版本。而版本号仍延续原来的序号,即 Java
8、Java 9、Java 10、Java
11…..但和之前不一样的是,同时还有一个版本号来表示发布的时间和是否为
LTS(长期支持版本),比如 Java 10 对应 18.3。如下示例:/jdk-10/bin$
./java -versionopenjdk version “10” 2018-03-20OpenJDK Runtime
Environment 18.3 (build 10+46)OpenJDK 64-Bit Server VM 18.3 (build
10+46, mixed mode)需要注意的是 Java 9 和 Java 10 都不是 LTS
版本。和过去的 Java
大版本升级不同,这两个只有半年左右的开发和维护期。而未来的 Java
11,也就是 18.9 LTS,才是 Java 8 之后第一个 LTS 版本(得到 Oracle
等商业公司的长期支持服务)。这种发布模式已经得到了广泛应用,一个成功的例子就是
Ubuntu Linux 操作系统,在偶数年 4 月的发行版本为
LTS,会有很长时间的支持。如 2014 年 4 月份发布的 14.04 LTS,Canonical
公司和社区支持到 2019 年。类似的,Node.js,Linux kernel,Firefox
也采用类似的发布方式。Java
未来的发布周期,将每半年发布一个大版本,每个季度发布一个中间特性版本。这样可以把一些关键特性尽早合并入
JDK 之中,快速得到开发者反馈,可以在一定程度上避免 Java 9
两次被迫推迟发布日期的尴尬。下图为 2017 年 JavaOne 大会时,Oracle
公开的未来 Java 版本发布和支持周期图。Java 10 新特性这次发布的 Java
10,新带来的特性并不多。根据官网公开资料,共有 12 个 JEP(JDK Enhancement
Proposal 特性加强提议),带来以下加强功能:JEP286,var
局部变量类型推断。JEP296,将原来用 Mercurial 管理的众多 JDK
仓库代码,合并到一个仓库中,简化开发和管理过程。JEP304,统一的垃圾回收接口。JEP307,G1
垃圾回收器的并行完整垃圾回收,实现并行性来改善最坏情况下的延迟。JEP310,应用程序类数据
(AppCDS)
共享,通过跨进程共享通用类元数据来减少内存占用空间,和减少启动时间。JEP312,ThreadLocal
握手交互。在不进入到全局 JVM 安全点 (Safepoint)
的情况下,对线程执行回调。优化可以只停止单个线程,而不是停全部线程或一个都不停。JEP313,移除
JDK 中附带的 javah 工具。可以使用 javac -h 代替。JEP314,使用附加的
Unicode
语言标记扩展。JEP317,能将堆内存占用分配给用户指定的备用内存设备。JEP317,使用
Graal 基于 Java 的编译器,可以预先把 Java
代码编译成本地代码来提升效能。JEP318,在 OpenJDK
中提供一组默认的根证书颁发机构证书。开源目前 Oracle 提供的的 Java SE
的根证书,这样 OpenJDK
对开发人员使用起来更方便。JEP322,基于时间定义的发布版本,即上述提到的发布周期。版本号为$FEATURE.$INTERIM.$UPDATE.$PATCH,分别是大版本,中间版本,升级包和补丁版本。部分特性说明1.
var 类型推断。这个语言功能在其他一些语言 (C#、JavaScript) 和基于 JRE
的一些语言 (Scala 和 Kotlin) 中,早已被加入。在 Java
语言很早就在考虑,早在 2016 年正式提交了 JEP286
提议。后来举行了一次公开的开发者调查,获得最多建议的是采用类似 Scala
的方案,“同时使用 val 和 var”,约占一半;第二多的是“只使用
var”,约占四分之一。后来 Oracle 公司经过慎重考虑,采用了只使用 var
关键字的方案。有了这个功能,开发者在写这样的代码时:ArrayList myList =
new ArrayList()可以省去前面的类型声明,而只需要var list = new
ArrayList()编译器会自动推断出 list
变量的类型。对于链式表达式来说,也会很方便:var stream =
blocks.stream(); … int maxWeight = stream.filter(b -> b.getColor()
== BLUE) .mapToInt(Block::getWeight) .max();开发者无须声明并且 import
引入 Stream 类型,只用 stream 作为中间变量,用 var
关键字使得开发效率提升。不过 var
的使用有众多限制,包括不能用于推断方法参数类型,只能用于局部变量,如方法块中,而不能用于类变量的声明,等等。另外,我个人认为,对于开发者而言,变量类型明显的声明会提供更加全面的程序语言信息,对于理解并维护代码有很大的帮助。一旦
var 被广泛运用,开发者阅读三方代码而没有 IDE
的支持下,会对程序的流程执行理解造成一定的障碍。所以我建议尽量写清楚变量类型,程序的易读维护性有时更重要一些。2.
统一的 GC 接口在 JDK10 的代码中,路径为
openjdk/src/hotspot/share/gc/,各个 GC 实现共享依赖 shared 代码,GC
包括目前默认的 G1,也有经典的 Serial、Parallel、CMS 等 GC 实现。3.
应用程序类数据(AppCDS)共享CDS 特性在原来的 bootstrap
类基础之上,扩展加入了应用类的 CDS(Application Class-Data Sharing)
支持。其原理为:在启动时记录加载类的过程,写入到文本文件中,再次启动时直接读取此启动文本并加载。设想如果应用环境没有大的变化,启动速度就会得到提升。我们可以想像为类似于操作系统的休眠过程,合上电脑时把当前应用环境写入磁盘,再次使用时就可以快速恢复环境。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章

网站地图xml地图