移动 APP 网络优化概述

2018-1-9 评论(14) 分类:技术文章

一般开发一个 APP,会直接调用系统提供的网络请求接口去服务端请求数据,再针对返回的数据进行一些处理,或者使用AFNetworking/OKHttp这样的网络库,管理好请求线程和队列,再自动做一些数据解析,就结束了。

但对于一些大型 APP,还会想针对网络的一些问题进行进一步优化,包括:

  1. 速度:网络请求的速度怎样能进一步提升?
  2. 弱网:移动端网络环境随时变化,经常出现网络连接很不稳定可用性差的情况,怎样在这种情况下最大限度最快地成功请求?
  3. 安全:怎样防止被第三方窃听/篡改或冒充,防止运营商劫持,同时又不影响性能?

对基于浏览器的前端开发来说,网络这块能做的事情很少,但对于客户端 APP 来说,整个网络请求过程是自由控制的,可以做很多事情,很多大型 APP 都针对这三个问题做了很多网络层的优化,一些新的网络层协议像 HTTP2 / QUIC 也是在这些方面进行了不少优化,在这里边学习边整理,大致列举一下常见的做法。

速度

正常一条网络请求需要经过的流程是这样:

  1. DNS 解析,请求DNS服务器,获取域名对应的 IP 地址。
  2. 与服务端建立连接,包括 tcp 三次握手,安全协议同步流程。
  3. 连接建立完成,发送和接收数据,解码数据。

这里有明显的三个优化点:

  1. 直接使用 IP 地址,去除 DNS 解析步骤。
  2. 不要每次请求都重新建立连接,复用连接或一直使用同一条连接(长连接)。
  3. 压缩数据,减小传输的数据大小。

逐条来看能做什么。

1.DNS

DNS 完整的解析流程很长,会先从本地系统缓存取,若没有就到最近的 DNS 服务器取,若没有再到主域名服务器取,每一层都有缓存,但为了域名解析的实时性,每一层缓存都有过期时间,这种 DNS 解析机制有几个缺点:

  1. 缓存时间设置得长,域名更新不及时,设置得短,大量 DNS 解析请求影响请求速度。
  2. 域名劫持,容易被中间人攻击,或被运营商劫持,把域名解析到第三方 IP 地址,据统计劫持率会达到7%。
  3. DNS 解析过程不受控制,无法保证解析到最快的IP
  4. 一次请求只能解析一个域名。

为了解决这些问题,就有了 HTTPDNS,原理很简单,就是自己做域名解析的工作,通过 HTTP 请求后台去拿到域名对应的 IP 地址,直接解决上述所有问题:

  1. 域名解析与请求分离,所有请求都直接用IP地址,无需 DNS 解析,APP 定时请求 HTTPDNS 服务器更新IP地址即可。
  2. 通过签名等方式,保证 HTTPDNS 请求的安全,避免被劫持。
  3. DNS 解析由自己控制,可以确保根据用户所在地返回就近的 IP 地址,或根据客户端测速结果使用速度最快的 IP。
  4. 一次请求可以解析多个域名。

其余细节就不多说了,HTTPDNS 优点这么多,几乎成为中大型 APP 的标配。至此解决了第一个问题 — DNS 解析耗时的问题,顺便把一部分安全问题 — DNS 劫持也解决了。

2.连接

第二个问题,连接建立耗时的问题,这里主要的优化思路是复用连接,不用每次请求都重新建立连接,如何更有效率地复用连接,可以说是网络请求速度优化里最主要的点了,并且这里的优化仍在演进过程中,值得了解下。

keep-alive

HTTP 协议里有个 keep-alive,HTTP1.1默认开启,一定程度上缓解了每次请求都要进行TCP三次握手建立连接的耗时。原理是请求完成后不立即释放连接,而是放入连接池中,若这时有另一个请求要发出,请求的域名和端口是一样的,就直接拿出连接池中的连接进行发送和接收数据,少了建立连接的耗时。

实际上现在无论是客户端还是浏览器都默认开启了keep-alive,对同个域名不会再有每发一个请求就进行一次建连的情况,纯短连接已经不存在了。但有个问题,就是这个 keep-alive 的连接一次只能发送接收一个请求,在上一个请求处理完成之前,无法接受新的请求。若同时发起多个请求,就有两种情况:

  1. 若串行发送请求,可以一直复用一个连接,但速度很慢,每个请求都要等待上个请求完成再进行发送。
  2. 若并行发送这些请求,那么首次每个请求都要进行tcp三次握手建立新的连接,虽然第二次可以复用连接池里这堆连接,但若连接池里保持的连接过多,对服务端资源产生较大浪费,若限制了保持的连接数,并行请求里超出的连接仍每次要建连。

对这个问题,新一代协议 HTTP2 提出了多路复用去解决。

多路复用

HTTP2 的多路复用机制一样是复用连接,但它复用的这条连接支持同时处理多条请求,所有请求都可以并发在这条连接上进行,也就解决了上面说的并发请求需要建立多条连接带来的问题,网络上有张图可以较形象地表现这个过程:

duolufuyong

HTTP1.1的协议里,在一个连接里传送数据都是串行顺序传送的,必须等上一个请求全部处理完后,下一个请求才能进行处理,导致这些请求期间这条连接并不是满带宽传输的,即使是HTTP1.1的pipelining可以同时发送多个request,但response仍是按请求的顺序串行返回,只要其中一个请求的response稍微大一点或发生错误,就会阻塞住后面的请求。

HTTP2 这里的多路复用协议解决了这些问题,它把在连接里传输的数据都封装成一个个stream,每个stream都有标识,stream的发送和接收可以是乱序的,不依赖顺序,也就不会有阻塞的问题,接收端可以根据stream的标识去区分属于哪个请求,再进行数据拼接,得到最终数据。

解释下多路复用这个词,多路可以认为是多个连接,多个操作,复用就是字面上的意思,复用一条连接或一个线程。HTTP2这里是连接的多路复用,网络相关的还有一个I/O的多路复用(select/epoll),指通过事件驱动的方式让多个网络请求返回的数据在同一条线程里完成读写。

客户端来说,iOS9 以上 NSURLSession 原生支持 HTTP2,只要服务端也支持就可以直接使用,Android 的 okhttp3 以上也支持了 HTTP2,国内一些大型 APP 会自建网络层,支持 HTTP2 的多路复用,避免系统的限制以及根据自身业务需要增加一些特性,例如微信的开源网络库 mars,做到一条长连接处理微信上的大部分请求,多路复用的特性上基本跟 HTTP2 一致。

TCP队头阻塞

HTTP2 的多路复用看起来是完美的解决方案,但还有个问题,就是队头阻塞,这是受限于 TCP 协议,TCP 协议为了保证数据的可靠性,若传输过程中一个 TCP 包丢失,会等待这个包重传后,才会处理后续的包。HTTP2的多路复用让所有请求都在同一条连接进行,中间有一个包丢失,就会阻塞等待重传,所有请求也就被阻塞了。

对于这个问题不改变 TCP 协议就无法优化,但 TCP 协议依赖操作系统实现以及部分硬件的定制,改进缓慢,于是 GOOGLE 提出 QUIC 协议,相当于在 UDP 协议之上再定义一套可靠传输协议,解决 TCP 的一些缺陷,包括队头阻塞。具体解决原理网上资料较多,可以看看。

QUIC 处于起步阶段,少有客户端接入,QUIC 协议相对于 HTTP2 最大的优势是对TCP队头阻塞的解决,其他的像安全握手 0RTT / 证书压缩等优化 TLS1.3 已跟进,可以用于 HTTP2,并不是独有特性。TCP 队头阻塞在 HTTP2 上对性能的影响有多大,在速度上 QUIC 能带来多大提升待研究。

3.数据

第三个问题,传输数据大小的问题。数据对请求速度的影响分两方面,一是压缩率,二是解压序列化反序列化的速度。目前最流行的两种数据格式是 json 和 protobuf,json 是字符串,protobuf 是二进制,即使用各种压缩算法压缩后,protobuf 仍会比 json 小,数据量上 protobuf 有优势,序列化速度 protobuf 也有一些优势,这两者的对比就不细说了。

压缩算法多种多样,也在不断演进,最新出的 Brotli 和Z-standard实现了更高的压缩率,Z-standard 可以根据业务数据样本训练出适合的字典,进一步提高压缩率,目前压缩率表现最好的算法。

除了传输的 body 数据,每个请求 HTTP 协议头的数据也是不可忽视,HTTP2 里对 HTTP 协议头也进行了压缩,HTTP 头大多是重复数据,固定的字段如 method 可以用静态字典,不固定但多个请求重复的字段例如 cookie 用动态字典,可以达到非常高的压缩率,这里有详细介绍。

通过 HTTPDNS,连接多路复用,更好的数据压缩算法,可以把网络请求的速度优化到较不错的程度了,接下来再看看弱网和安全上可以做的事情。

弱网

手机无线网络环境不稳定,针对弱网的优化,微信有较多实践和分享,包括:

    1. 提升连接成功率
      复合连接,建立连接时,阶梯式并发连接,其中一条连通后其他连接都关闭。这个方案结合串行和并发的优势,提高弱网下的连接成功率,同时又不会增加服务器资源消耗:
      20180109120421
    2. 制定最合适的超时时间
      对总读写超时(从请求到响应的超时)、首包超时、包包超时(两个数据段之间的超时)时间制定不同的计算方案,加快对超时的判断,减少等待时间,尽早重试。这里的超时时间还可以根据网络状态动态设定。
    3. 调优TCP参数,使用TCP优化算法。
      对服务端的TCP协议参数进行调优,以及开启各种优化算法,使得适合业务特性和移动端网络环境,包括RTO初始值,混合慢启动,TLP,F-RTO等。

针对弱网的这些细致优化未成为标准,系统网络库没有内置,不过前两个客户端优化微信的开源网络库 mars 有实现,若有需要可以使用。

安全

标准协议 TLS 保证了网络传输的安全,前身是 SSL,不断在演进,目前最新是 TLS1.3。常见的 HTTPS 就是 HTTP 协议加上 TLS 安全协议。

安全协议概括性地说解决两个问题:1.保证安全 2. 降低加密成本

在保证安全上:

  1. 使用加密算法组合对传输数据加密,避免被窃听和篡改。
  2. 认证对方身份,避免被第三方冒充。
  3. 加密算法保持灵活可更新,防止定死算法被破解后无法更换,禁用已被破解的算法。

降低加密成本上:

  1. 用对称加密算法加密传输数据,解决非对称加密算法的性能低以及长度限制问题。
  2. 缓存安全协议握手后的密钥等数据,加快第二次建连的速度。
  3. 加快握手过程:2RTT-> 0RTT。加快握手的思路,就是原本客户端和服务端需要协商使用什么算法后才能加密发送数据,变成通过内置的公钥和默认的算法,在握手的同时就把数据发出去,也就是不需要等待握手就开始发送数据,达到0RTT。

这些点涉及的细节非常多,对 TLS 的介绍有一篇雄文,说得很详细,在此推荐。

目前基本主流都支持 TLS1.2,iOS 网络库默认使用 TLS1.2,Android4.4 以上支持 1.2。TLS1.3 iOS 还处于测试阶段,Android 未查到消息。对于普通 APP,只要正确配置证书,TLS1.2 已经能保证传输安全,只是在建连速度上会有所损耗,有一些大型 APP 像微信就自行实现了 TLS1.3 的部分协议,早一步全平台支持。

最后

网络优化这个话题非常庞大,本文只是在学习过程中从优化思路上列举了目前业界常见的优化点,还有很多细节很多更深入的优化没涉及到,网络层实践开发经验不足,若有错误欢迎指出。

2017

2017-12-31 评论(6) 分类:生活

工作

公司

今年最大的变化,自然是换工作了,回腾讯三年,度过了痛苦期,成长期和安逸期,腾讯给我足够的机会和支持,我给腾讯足够的输出,离开时只有感激没有遗憾。

来到蚂蚁,体验大阿里的工作方式,跟腾讯的差别非常大,或者说跟微信事业群的差别很大,很多是业务形态的差别导致,体验不同公司不同文化,不同的成事逻辑,挺有意思的。有几点较有体会:

  1. 庞大,阿里和蚂蚁从人员到各种系统各种方案都很庞大,从外部看阿里商业布局的风格就能看出来,都会铺得很大,有很多可以学习的地方。腾讯擅长快工出细活,靠产品取胜,阿里擅长组织力量办大事,靠战略取胜。
  2. 变化,拥抱变化是阿里一大特点,组织架构/人员调整是分分钟的事,战略调整也不少,虽然成本很高,但可以跟上快速变化的时代。
  3. 沟通,第一点庞大带来的副作用,庞大的人员配备和异地开发带来很大的沟通成本,可以说是大公司病,可能可以通过第二点变化去缓解,通过变化去寻找沟通成本最低的人员架构。
  4. 自由,自由度上感觉比腾讯更像硅谷公司,移动办公能力很发达。
  5. 全栈,技术栈的切换非常方便,也很鼓励全栈发展,技术转产品也没有问题。这也可能是所处团队的个例。
  6. 江湖,江湖气息浓,有时会有山头林立的感觉。
  7. 人才,有没有感觉很多认识的人都进了阿里?阿里的人才真心多,很能招揽和留住人才,庞大的体系,快速变化的职位,内部快速的流动,很有活力。在大公司的好处,跟很多聪明人一起工作,能学到他们做人做事方法和思维模式。
  8. 反思,反思能力很强,一旦犯错误会有各种复盘,导致韧性很强,导致支付宝被微信打趴在地上后还能满血复活活奔乱跳。

进来经历996时期和业务调整重心转移时期,每个地方都有当下的局限困境和机会,努力去做力所能及的事。

JSPatch

JSPatch 在年初达到顶峰,随后遭遇苹果一纸文书直接禁用,很让人吃惊,自己想想其实也合理,JSPatch 脚本权限很大,只要接入过程没考虑好安全问题,就可能会被黑客利用,若大部分 APP 都接入,并且无法确保大家接入的方式是否安全,就会成为 iOS 系统级的一个安全隐患,必须控制,一刀切对苹果来说是最简单的方法,相关想法我也详细写过文章,就不再说了。对这种做法我是情绪稳定,只要是合理的都能接受。目前若要使用 JSPatch 还是可以接入 JSPatch 平台正常使用的,平台的接入方案可以解决这类安全隐患。

至今我做过的两个算是有点影响力的作品,推特中文圈和 JSPatch,都是理论上无法封锁的东西,都被用政策的手段打压,真是巧合,希望下一个作品可以不再这样。

生活

杭州

全家搬到杭州,付出的代价不小,如果只是两个人很好办,但有了小孩离家乡远就很不方便,老人也不适应杭州,很困难,明年还有小孩上幼儿园等问题接涌而来,还没想好怎么办。不过体验另一个城市的感觉还是很新鲜很好的,杭州一片生机勃勃,我也很喜欢跟来自全国各地多样化的同事们工作,时不时长长见识。

杭州目前还是个小城,能骑着电动车上下班,挺惬意,要是再租得近点,像同事那样中午回家吃饭都可以。不过骑电动车也只是天气好的时候惬意,不好的时候风吹日晒雨淋夏天被烤成炭冬天冻成翔,0度到42度,挺惨,这种天气还是坐在汽车里好,塞车都乐意。

抽空去了杭州各个景点,西湖,西溪湿地,小河直街,湘湖,千岛湖,乌镇,其实在杭州生活,也没多少个周末出去玩的,西湖那么大也就去了两次,可能是我们比较懒和宅。时隔7年再次去乌镇,感觉依然很好,跟其他古镇还是有差别的,特别是晚上和清晨寂静的时候,若今年杭州有下雪,还想再去一次。

上海

今年去了三次上海,两次出差一次游玩,感觉像乡下进城,来杭州时感叹超级商场真多,到上海发现杭州是小儿科,上海到处都是大商场,也不知道哪来那么大的消费力,感觉跟广州完全不一样,是江浙沪一带人民的消费水平特别高还是怎么着。

蚂蚁上海办公地点在上海中心大厦,感觉很了不得的地方,第一次进去还被叫住问我是干啥子的,尴尬。站在大厦楼下往上望有种很威严雄伟的感觉,像是个奇迹,远远望过去天上有这么个大柱子也是有种魔幻感,人在这种大建筑下面,会觉得自己很渺小,崇拜和信仰就来了,像金字塔教堂一类的建筑也是这个目的吧,我还挺喜欢看大型建筑的。

苏州

苏州离杭州只有一百多公里,随便开个车就到了,元旦假期跟家人在苏州度过,去寒山寺,苏州园林,同里古镇,感觉跟杭州上海的一些景点差不多,只是寒山寺有枫桥夜泊加持好点。游玩碰到今年江浙一代空气最差的时候,直接pm两百多重度污染,比较减分。

小孩

最近一个月小屁孩说话能力进步很快,各种发音都会学着说了,语言这种能力只要一开窍就学得特别快。看着她成长很幸福,经常被她萌到,带来很多快乐,这货特别喜欢出去玩,特别喜欢吃,很喜欢看书写字听故事,不过小小年纪就有不小的脾气,还提前n年进入叛逆期,怎样教育真是个难题。今年因为工作原因期间有两三个月时间小孩放在老家,错过小孩的成长期这个代价真是非常大,希望明年能减少不在身边的时间。

其他

今年只在江浙一带转转,没有旅游过的感觉,旅程倒是创新高,各种办事和出差游玩,在陆丰/广州/杭州/苏州/上海/合肥/北京多地来回跑。

离开微信读书,加上在杭州没有坐地铁时的阅读时间,直接就没看书了,断断续续看的几本也没看完。不过《禅与摩托车维修艺术》这本书倒是很合我胃口,是本可以看多几次的书。

做微信读书时多看书,在蚂蚁金服就多关注金融知识,确实每个人都无法避开金融,不关注金融的人口袋里的现金就会流向关注的人,置身其中无法逃避,有时觉得挺有趣,有时觉得挺烦,动不动房价涨一倍,腾讯阿里涨一倍,贪婪和恐惧算是小体验过了,理财观念还在逐渐形成。

去年年终总结提到自己的一些缺陷问题,今年回顾起来并没有多少进步,或者说有意识去纠正磨炼的次数不多,要改变确实是困难,不是一年半载的事,特别是在这个大家都在焦虑快跑的时代里。

根据过往经验年末立 flag 通常没什么用,希望2018年保持进步。

资源瓶颈

2017-11-28 评论(3) 分类:随记

在杭州打车实在是困难,前两天打滴滴,排队二十几分钟,打到车后司机距离也就两公里,说不来,我说我等太久了还是过来吧,他说不行,还让我取消,我不取消,司机就开始破口大骂,挂了电话还继续在滴滴上发语音骂,嚣张至极。

虽然当时很生气,但过后想想觉得又挺合理,在资源匮乏的时候,拥有资源方就是大爷,如果这时候没有任何东西可以约束这位大爷,自然随心所欲不爽就发泄,反正没有任何损失,还能获得某种优越感。怎样解决这种问题?滴滴一直以来做的事情是提高资源供给(引入快车专车顺风车)和提高资源分配效率,去解决出行供不应求导致出租车司机一直是大爷的情况,确实是很大程度上改善了,但在高峰期还是资源不足,这种情况下滴滴作为几乎垄断的平台,用评价体系/奖惩标准等手段是可以避免司机过于强势的,只是看起来滴滴还没做好。

滴滴已经是互联网改变线下资源的典范了,仍有一些资源限制导致的问题,互联网+线下还是有很大局限。互联网提供的数字化服务资源是无限的,成本也并不高,而线下资源始终是有限的,十亿人用微信没问题,十亿人都要打车,都想找场馆踢球,都想看病找好老师,可不像数字服务一样都可以满足得了,人力资源和土地资源总是有限和稀缺的,对这两点依赖越强的行业,互联网带来的提升就越少,例如好医生资源匮乏、球场土地资源匮乏、城市道路资源匮乏,互联网想要改善都很困难,只能有限地提升资源分配的效率和体验,很容易就达到瓶颈。

人和土地是两大问题,城市的土地资源靠纵横两个方向的延伸解决,纵向是越来越高的大厦提高单位面积利用率,横向是越来越发达的交通网络提升可触达的面积,而人力资源方面,传统方法是靠加强教育去提升优质人力资源的供给,效率底下,而现在有另一个看得见曙光的方向,就是AI。其实人力资源就是智能资源,像教师/医生/律师/司机/理财师,大家需要的是他们的智能去解决问题,而 AI 看起来是有可能可以提供这些智能的,AI 最大的威力是数字世界的无限供给,只要一个 AI 程序在某个行业有所突破,就可以爆炸式直接解决行业的人力资源问题,诱惑力相当大,而最近 AI 领域出现的进展让人看到了这种可能,这也是 AI 被看重的原因之一吧。

QCon 上海 2017 观感

2017-10-23 评论(2) 分类:互联网

第一次来上海,第一次参加 QCon,说说观感。

AI

主讲 AI 的主题占到了差不多四成,虽然有主办方选题偏向的因素,但还是能说明 AI 的热度确实很高,是当前最火热的技术领域,火到感觉我作为客户端开发,再不学AI就要失业了。虽然有些虚火的嫌疑,但AI相关技术确实是解决了不少传统做法难以解决的问题。

开场危辉教授讲述人工智能这个概念的历史,表示目前人工智能能解决的问题仍只是在一些有限场景下有一些进展,只能解决一些明确的特定的问题,像取得突破的围棋只是因为它是规则简单边界明确的特定领域,但真正的通用人工智能关键的几个问题一个都没有解决,过去二十年人工智能流行过很多技术,连当年OOP面向对象都被认为可以实现人工智能,而现在流行的是深度学习,有人说下一个流行的会是量子计算,人工智能就像一个圣杯,大家一直用各种技术方案在追逐,目前大家觉得接近了,但实际上我们离真正的模拟人脑能解决通用问题的人工智能还差得很远。

教授是从学术界的角度,从准确的定义上去说人工智能,当然没有错,但实际上一个流行词汇,很可能跟它实际所指的事物并不完全相符,只是方便炒作或方便理解。例如共享单车不是真的共享,HTML5不是HTML一样,现在流行的很多场景下说的人工智能也并不是真的指可以代替人脑解决通用问题的人工智能,主要指靠各种机器学习算法去解决一些特定领域的传统算法难以解决的问题,例如图像识别分类,自然语言/语音识别,兴趣推荐等,查了下业内对这些应用还有个稍微准确点的称呼,叫弱人工智能(弱智???)。从业人士应该不会弄不清楚,也就一些媒体忽悠大众哗众取宠的时候弄混。

会场上听到很多 AI 的应用,paypal 用它做反欺诈反洗钱服务,微博用来辅助检测恶意用户,流利说训练出适合中国人口音的英语发音打分模型,腾讯用AI+ROI把视频编码带宽降低20%,也做了AI自动裁剪视频生成短视频,Pinterset 做推荐系统和拉活,QQ邮箱用来优化文档边缘识别,等等,有些公司已经以AI为中心为业务提供各种支持,给人感觉产品要是不结合AI做点什么都不好意思拿出来说,真有一种拿着锤子四处寻找钉子的感觉。

我还没有实践过 AI 相关项目,听这些主题有些尴尬,只有笼统的观感。个人感觉,程序员就算不投身 AI 领域,也应该要了解下 AI 相关技术,了解在现有技术下的 AI 能做什么,毕竟它的套路跟传统确定性算法不一样,了解了才能在解决自身业务问题的时候多一个思路。现阶段的 AI 虽然没达到可以解决通用问题的程度,但对于那些定义和目标明确的问题都是可以或者说有希望解决的。

AI First

有公司已经从 Mobile first 转为 AI first,iPhone 刚出来前几年,大家对移动端还算挺重视,各个大公司会成立移动事业群/移动部门/移动组,一小拨人专门开发各个业务需要的移动产品,后来移动端越来越受重视,变成 mobile first,不再是专门一群人开发各个业务的移动产品,而是每个业务都自己组建移动端团队,移动渗透到公司每个团队,才能跟上时代。现在 AI First 也是有这样的感觉,现在还处于一个公司里一小拨人专门在做 AI 相关的工作,后续可能会发展到每个业务团队都需要具备 AI 的研发能力,AI 渗透到每个业务团队,才能应用 AI 技术去结合自身业务实现价值。

智能音箱

阿里分享和宣传了 AliGenie,AliGenie 类似 Siri,自然语言处理开放平台,目前应用在智能音箱天猫精灵上,类似 Homepod,以及接入阿里智能硬件,类似 Homekit,真是跟苹果干上了。

说说个人看法,智能音箱被认为可能是下一个入口,语音不仅包含的信息丰富,还解放了双手,相比键盘/鼠标/触摸灯方式,很多场景下效率提升很多,方便快捷,用户习惯养成后,用户可能越来越多使用智能音箱去完成需求和触达信息,可能用它来购物/支付/打车/听新闻等等,成为下一个入口。看起来确实是很好,但语音助手 Siri 推出到现在已经七年,到现在还没有成为主流,身边使用的人很少,智能音箱会有戏吗?虽然语音很方便,但有两个致命缺陷,就是暴露隐私和骚扰旁人,很多场景下这个缺陷大过带来的便捷性,也就很难去使用和形成使用习惯。若要让语音助手成为入口,需要找到特定的应用场景才行,个人觉得汽车内较有机会,因为多是独处时间,没有隐私和骚扰的缺陷,眼睛和双手被霸占,空间也有限,不会有接收不到或要吼的情况,而面向家庭的智能音箱就难了。

AR/VR

VR 研发热度一直没有火起来,感觉现在做VR有点像功能机时代做手游,硬件环境没跟上,时机还太早,现场只有腾讯分享了下VR的探索,用于做身临其境的游戏直播体验。

AR因为苹果和谷歌相继推出 ARKit 和 ARCore 又受到关注,不过这次分享都没有这两者,AR 的应用稍微多一些,因为手机上就能实现,不用像 VR 那样主要靠硬件,阿里对 AR 的探索较多,从小游戏到图书增强到家装应用到开放体系,走得很远,在营销上已经有不少应用,不知道数据和效果怎样。

腾讯分享的云游戏是另一类前沿研究,通过视频回传游戏画面,随时随地只要有屏幕和网络就能玩任意游戏,也处于探索阶段,带宽成本高,解决延迟问题较困难,短期内没看到应用的前景,可能可以作为游戏试玩的方案。

前端/客户端

前端和客户端各只有4场分享,在整个QCon一百来场分享里占比可怜,真是药丸。当然技术媒体是追逐热点的,感觉这次追得有点过了,从旁人的反应来看效果不太好。

淘宝分享超级 App 的高可用性保障,也就是保障性能稳定性一整套系统,这块各个大APP都有自己的一套,趋于成熟,淘宝做得更细致些,除了性能数据的采集/监控和展示,也尝试在内存泄漏/资源泄漏/大图异常/线程异常等一些特定的问题上提升问题排查效率,通过记录堆栈追踪问题的来源,例如记录图片/线程/资源是在哪里创建的,从而能快速定位原因。为了解决一些很难排查的疑难杂症,做了更细致的追踪体系,毫秒级记录CPU/内存/存储,追踪方法调用和页面事件,收集数据后再通过分析引擎对比分析。

前端有两个新事物的实践分享,WebAssembly 字节码技术,饿了么于航实践和深入了解后表示 值得关注/标准未定/实践略坑,各大浏览器在实现的路上,短期内还没法用到生产环境。QQ 空间实践了 QUIC 协议,基于 UDP 改进的通信协议,解决 TCP 成为网络传输速度性能瓶颈的问题,目前应用上还有一些坑,用户的网络环境中 UDP 的端口可能会被禁,可能会被限速,也可能丢包率有异常,有些风险,另外目前移动端浏览器都不支持 QUIC,PC端只有少量个位数比例的用户支持,应用还不广泛。

前同事冯牮分享了在QQ邮箱客户端上实现 AI 辅助文档边缘检测。事先针对特定的问题,在后端训练出一个模型,再放到客户端上使用,使客户端本身具备 AI 的能力,这可能是客户端开发后续的一个方向。现在的应用场景是针对一些实时性要求高的,无法回传到后端进行计算的应用,像文档的边缘检测,以及支付宝出的扫描识花的功能,都是这种类型,其他的应用方式大家还在探索中。

其他

蘑菇街侯栋分享的关于黑产的攻防和产业链介绍挺有意思,社会上头脑灵活的人很多,有利益有漏洞就会被人钻,账号会被批量注册,有的用于刷单提升店铺销量信誉,有的通过批量退货赚取退货险的运费差价,有的配合假快递单号套取货品,惊讶于有人为了能套现电商信用卡的钱愿意付出30%的手续费,跟这帮人猫捉老鼠挺有趣的。

区块链有两个分享,都是宣传自家区块链云平台,云服务这个金矿也挺热的,只要自身搭建稍微有成本,就立马有人做出云服务(广告:JSPatch平台也算是热修复云服务)。粗略听下来只能知道区块链可以用于解决信任问题,有些数据放在一家公司里可能会被篡改,不受信任,用区块链可以解决这类问题,应用是可以很广泛的,我没完全搞懂区块链原理,就不多说了。

最后

去年参加 GMTC 有提到过对这种技术大会的看法,这种大会对广大技术人员自然是好的,各界讲师有动力精心准备演讲主题,输出很好的技术分享,但从参与者角度来说,如果单纯去听其实没什么用,时间成本高,单向分享也学不到什么,还不如后续看PPT和视频,参加线下分享会议最主要的还是面对面双向交流的机会,最好能看准人和主题和人,准备好具体问题过去交流,否则参加这个会议跟后续网上看PPT和视频唯一的区别就是更耗时间。

过来参加的大多是一线工程师,目测大部分是传统客户端/前端/服务端开发,而 QCon 的定位高端,现场听到不少人反馈听不懂/离实际太远/太高大上,也可能是AI的主题太多导致。从会场人数来看大伙喜欢听实践踩坑类接地气的主题,毕竟现场的CTO和架构师占比不会很高。本次 QCon 前端客户端相关主题太少,跟上一场 QCon 差别很大,导致作为客户端开发参加起来有些尴尬,希望下场选题上能再平衡下,祝 QCon 越办越好。

规则与用户体验

2017-9-29 评论(9) 分类:随记

一直给自己定下每个月至少要有一篇博客文章的约定,无论是什么类型。这个月临到末尾,因故只发了半篇文章,必须再写一篇扯扯淡把这个空补上。

在杭州一直用电动车上下班,公司所在大楼楼下有电动车停车场,挺好的,不过有一点让人不爽,按这栋大楼规定的路线,电动车从公司骑出来需要绕一个大圈才能到出口,大概需要走300米,但是,如果你不按他规定的路线,逆行50米就可以到达出口。而这个逆行并没有任何危险:

  1. 道路很宽,是单行道但宽得走两辆车没问题 。
  2. 除了道路还有人行道,跟杭州大路非机动车道差不多宽。
  3. 道路很空,在50米距离里人车都很少,很难碰到有人或有车的情况。

这种情况下,你会选择遵守大楼的规则走300米绕个圈,还是不遵守规则走个50米快速到达出口?我选择不遵守规则。但时不时电动车出口处有保安守着,勒令按规则走,挺蛋疼。

我觉得遵守一些不合理、损人不利己、有明显更好解决方案的规则并不是一个好的选择,对于这个案例,在那么宽的道路,只需要划出一小道双向通行的非机动车道就能解决问题了,对行人/机动车没有影响。而规划者不考虑改进这里的用户体验,执行者守着规则站在那里勒令大家遵守,在我看来是比较傻的。

这种情况跟一些蹩脚园林设计一样,草丛捷径被无数人踩出一条路,原本设计的路鲜有人行走,是该质疑行人素质,还是质疑设计者能力?我觉得是后者。

生活中碰到很多这种情况,设计者并不为用户考虑,理所当然地定了一些规则,用户遵守起来感觉像个傻子。像之前住的碧桂园楼盘,访客到门口,必须下车,排队登记,门口工作人员会根据报上来的房号,打电话联系业主,问是否可以让进,再开放行条,才肯让访客进。以给业主和访客添堵的方式去保证小区的安全和人流,这里能让双方都满意的解决方案太多了,但没有人想改进。

而互联网世界则不是这样,不合理的设计大多会被改进,无脑规则并不常见,一是数字世界改进成本低,可以不断迭代,维护成本也相对低;二是覆盖面广,一个小改进能惠泽几百上千万用户,性价比高;三是竞争大,不改进可能导致流失用户。所以再小的细节也会被认真对待。而更重要的是在这些条件影响下,从业者的心智被锻炼成用户体验问题都应该被改进,而现实世界传统行业一些从业者很难有这样的意识,即时是一些成本低的改进也不会想去做,有些人用互联网注重用户体验的意识在传统行业中做事,被称为拥有互联网思维。

今天的扯淡就到这里,下期再见。

小程序技术方案探讨

2017-9-19 评论(2) 分类:技术文章

微信小程序上线大半年,大部分技术原理也有文章介绍了,本文尝试从需求出发探讨微信小程序技术方案的来源,以及最近公测的支付宝小程序技术方案的考量。

微信小程序

微信小程序的需求是让第三方开发者可以接入,可以使用微信的提供的接口去开发应用嵌入在微信里。对于这个需求,最简单的实现方案是:让外部开发者开发纯H5应用,在微信的 H5 容器里打开,容器提供微信 native 接口,就行了。在有小程序之前,已经有很多这样的业务接入,像京东购物,钱包里的各种友商大众点评/滴滴出行等,都可以认为是一个“小程序”,内嵌在微信里,能调用微信 native 接口,是不是沿着这种模式下去,把相应的接口开放给第三方,再提供个入口就行了?

实际上这种简单的方案不能满足需求,在产品上微信小程序有另外两个很重要的需求:

  1. 管控。作为一个平台必须对接入的应用有管控能力,必须能尽量精确控制应用的内容和类型,毕竟若出现非法应用平台是要承担责任的,H5 的方式太过自由,开发者可以随时改变整个应用的内容,平台难以检测到这些改变,无法管控。另外H5开发质量参差不齐,平台也无法管控,这对于一向有洁癖的微信来说无法接受。
  2. 体验。作为一个“小程序”需要让体验接近原生,而上述像京东购物这些普通 H5 页面的体验不太行,包括启动速度/页面切换流畅度都有问题,跟原生体验没法比。

所有小程序的技术方案都是为了这两个需求服务。

(更多…)

移动 H5 首屏秒开优化方案探讨

2017-8-14 评论(13) 分类:技术文章 Tags:

随着移动设备性能不断增强,web 页面的性能体验逐渐变得可以接受,又因为 web 开发模式的诸多好处(跨平台,动态更新,减体积,无限扩展),APP 客户端里出现越来越多内嵌 web 页面(为了配上当前流行的说法,以下把所有网页都称为 H5 页面,虽然可能跟 H5 没关系),很多 APP 把一些功能模块改成用 H5 实现。

虽然说 H5 页面性能变好了,但如果没针对性地做一些优化,体验还是很糟糕的,主要两部分体验:

  1. 页面启动白屏时间:打开一个 H5 页面需要做一系列处理,会有一段白屏时间,体验糟糕。
  2. 响应流畅度:由于 webkit 的渲染机制,单线程,历史包袱等原因,页面刷新/交互的性能体验不如原生。

本文先不讨论第二点,只讨论第一点,怎样减少白屏时间。对 APP 里的一些使用 H5 实现的功能模块,怎样加快它们的启动速度,让它们启动的体验接近原生。

(更多…)

React Native 源码导读(零) – 创建/运行/调试

2017-7-31 评论(9) 分类:技术文章 Tags:

最近工作需要,重新看 React Native (以下简称RN) 源码,了解机制,寻找优化空间,过程中看能不能整理出一些东西。

RN 这个项目已经是庞然大物,打开 github 项目主页,根目录下文件和文件夹就多达五六十个,看起来一脸懵逼,不知道哪些是源码,在看源码之前先理理 RN 最终用到哪些代码,项目是怎样创建,怎样跑起来的。以下皆以 iOS 端为例。

流程

先看看标准 RN 项目创建和运行过程:

  1. RN 根据教程装完环境后,会有一个全局命令 react-native,执行 react-native init AwesomeProject 可以创建一个新 RN 项目。
  2. XCode 打开自动生成的项目,编译到模拟器或真机,一个 RN hello world 程序成功运行了。
  3. 在模拟器运行同时会在 chrome 打开一个页面,在页面里使用 developer tools 可以直接断点调试 RN 页面上的 JS 源码。

疑问

上述流程跑下来整个过程是个黑盒,对黑盒里的处理有一些疑问点:

  1. react-native init AwesomeProject 这个命令做了什么,是怎样创建 RN 模板项目的?
  2. 项目 JS 源码在哪里,如何跑起来的?
  3. 怎样做到可以在 chrome 调试 JS 源码?

接下来一条条看。
(更多…)

晋升评审的套路

2017-6-26 评论(5) 分类:技术文章

很多中大型互联网公司都会有晋升评审,也就是对技术/产品等职位划分成若干个等级,每个员工都有一个等级,若要晋升到下一级,需要由几个评委面试决定是否合格。这跟传统公司的考职称差不多,只不过传统公司是通过考试,互联网公司是通过面试。

为什么会有这种晋级评审?等级是公司内部对员工的一种评价和定位,等级的参照物是公司内的所有员工,假如一个公司比较小,老板每天跟所有员工一起工作,在老板识人能力又没有问题的前提下,老板就很清楚每个人的能力,直接对他们排等级,不需要什么评审,得出来的结果其实是更公正准确的,因为这是根据平时工作过程中获取的大量信息综合考虑得出的结果。但在中大型公司做不到,老板认识不了那么多人,没在一起工作,没法对每个人给出公正的评价。若把评判权都交给一起工作的组长总监又不妥,因为职级的参照系是全公司,而不是组内或部门内,很容易出现偏颇/标准不一的情况。

于是出现一个评审系统,由公司里一些有经验的人士去判断某个人能不能晋升到下一个等级,而这些人平时很可能没有跟他们一起工作,仅仅是通过大概一个小时的陈述和沟通去评判,这导致了这一个小时里陈述的方式和沟通的技巧变得很重要,同样一个人同样的工作,不同的 PPT 不同的陈述方式,结果会完全不一样。这里大致说下我所了解到的套路,套路并不是贬义词,只是能帮助更好地表现自己的能力,让评委得出更公正的评价。

要点

先列一下在准备晋级评审 PPT 时我认为重要的几个要点:目标,重点,思路,数据。

目标

在准备晋级 PPT 时,得先搞清楚目标,这种 PPT 目标很简单只有一个,就是告诉评委我很NB我完全可以晋升到下个等级。时刻问自己 PPT 表现出这个目标了没有。

重点

只有一个小时时间,不可能面面俱到表现出所有,讲的内容多了评委也不会记得,必须突出一两个重点和亮点,用2/3以上篇幅去深入讲,并且要让人听得懂。有人误解了以为晋升评审是述职,罗列过去一年做的工作,这个其实很为难评委,评委需要帮你在你罗列的众多工作中寻找能体现你技术水平的点,整体印象也大打折扣。

另外需要有一些亮点,如果你陈述的都是业界常规做法,其他人也是这样做的,评委会觉得没什么特别,是个人都会这么做,若有自己独特的创新点和亮点,就算是小的点,让评委眼前一亮也是很好的加分项。其实这是这个评审制度本身的缺陷和局限,因为评委每次评审的人数太多,如果大家能力都没有太突出,那决定谁更好的方式就是谁更特别留下更多的印象,这也就是亮点的意义。

思路

讲思路不要讲细节,特别是代码细节,除非是非常有技术含量的,作为亮点的细节。着重表现自己在解决问题过程中的思路,表达出自己在项目/问题涉及到的方方面面都有考虑到(全局观),有深入思考的能力,面对一个问题有能力抽象出关键点,有能力分解问题,若最终能总结出类似问题的统一解决思路(方法论)更好。

数据

要有数据证明做出的成绩,经过你NB的工作后,是性能提升百分之多少,还是工作效率提高多少,还是投诉率降低多少,还是有多少个产品都在用你的东西,业务的核心数据是怎样,都要有证据证明自己不是在吹牛,尽量使用量化的指标。

结构

这里列个常用的结构供参考:

我是谁:工作经历
我做出了什么成绩:在本公司做的事情,负责的业务,做出的成绩。
1-3个重点:

  • 碰到什么问题,业界是怎么解决的,我在这基础上做了些什么,相对业界的做法有什么优点,在这过程中碰到什么困难,怎么解决,最终达到什么效果(数据)。
  • 碰到什么需求,业务特点是什么,有哪些技术挑战(安全/架构/协作/性能/稳定性/历史包袱/响应能力/兼容性/开发效率/自动化等等),我是怎样设计的(方案完整性),有什么优点和创新点,最终达到什么效果(数据)。
  • 碰到什么问题,我按什么样的思路尝试过哪些方法,深入钻研到什么程度,虽然最终做法跟业界一样,但经过我深入研究证明了这已经是最佳做法。
  • 碰到什么问题,有哪些开源项目解决了这些问题,它们有什么缺陷,我重新造的轮子比他们NB在哪里,做到这么NB的难点是什么,我怎么做到的,怎么证明真的NB不是我在吹。

未来计划
谢谢

当然并不是说都要按这个结构写,若个人能有创新发挥用更适合自己的方式陈述自然更好。

交流

交流环节里,一般评委都是会根据 PPT 内容问问题。

最容易被挑战的就是数据,若 PPT 上列的数据不是很常规就会被问为什么,对所有数据都必须准备好被质疑。

评委对某个点感兴趣会追问细节,一些重要的技术细节可以以附录的形式附在PPT后面,问到时方便讲解。

PPT 上提到的点最好对相关技术都了解清楚,例如提到客户端网络层优化,最好把网络层底层相关知识都准备好,评委可能会追问下去以考察技术深度。

有些评委喜欢问一些固定问题,例如你觉得为什么你应该晋级,你觉得有哪些不足,你后续的技术规划是什么等等。

公司一般会有每个职级对应的能力表,有些评委喜欢对着能力表问相关问题。

评审也是个双向学习的过程,如果你能让评委觉得学到东西了效果会很好。

很多评委喜欢问他擅长的专业领域内的问题。显然这个环节有一定运气成分存在,遇到匹配度高的评委通过几率直线上升。

最后

这种一小时判断一个人的晋级评审肯定做不到非常公正,有一些运气成分,甚至有一些关系成分,但已经是相对较好的一种形式,而且评审的准备过程中还能让自己梳理总结一下过去做的事情,虽然准备过程会很痛苦,但也会很有收获。晋升的前提当然是要有足够的技术能力/影响力和视野,这里一些套路只供参考,希望能帮助有需要的人更好地表现自己的实力。

信息和学习

2017-5-30 评论(9) 分类:随记

最近上下班路上还在听罗辑思维,虽然我本人很不喜欢罗胖,但他的节目还是会听听。每次听都会听到一些逻辑错误想吐槽,缺啥喊啥,罗辑思维很缺逻辑,不过仔细想想,每天都要出节目并且拼上一些观点和结论,如果每个观点结论都要求逻辑严谨是比较难,可以理解。

一时举不出逻辑错误的具体例子,因为每天听过后基本上都忘了,罗辑思维从以前的一周四十多分钟变成现在的每天八分钟,其中一个原因是说四十多分钟的节目很长很重很多人听了记不住,所以改成八分钟以内,这个逻辑也是挺搞的,四十分钟讲一个话题记不住,八分钟反而能记得住?实际上都记不住,可能跟各人记性好坏有差异,但更多的是大脑机制就不允许你听一遍就记住,如果大脑把每天所见所闻都记住,那就太多了,信息爆炸。只有那些经过脑子不断思考,重复输入输出的信息才会被记住,才能转化成自己的知识。

轻轻松松听人讲讲故事和观点,只是当下接收一下信息,如果没有后续自行琢磨重复思考,实际上留不下什么东西。罗辑思维这种通过加工后的信息输入会让人感觉很有营养很有效率,实际上信息输入是学习中最简单也是作用最小的部分,真正起作用的是自己大脑对信息的加工思考和输出的过程。回想读书时期,知道一条原理公式是不是很容易?大概几分钟就觉得已经理解了,实际做题要用到这条原理公式时,才发现并不容易,需要反复练习不断通过自己大脑的再加工才能掌握和理解。这跟成功学也挺像的,其他人总结的观点技巧只是信息,输入这些信息是最简单也是最无用的,最困难和最有用的是实践。听节目看文章输入信息只是让你知道有这么个事,完成了学习的一小步,后续一大步还得靠自己。

罗辑思维和得到 APP 标榜终身学习,但产品上并没有让用户学习,并没有任何让需要用户动脑思考的产品特性,只是在单方面提供一些信息,你要是觉得每天轻轻松松不怎么动脑听听电台就是学习,就能获得知识上一个档次,就跟看成功学觉得自己能成功,已经跟成功人事思维在一个档次一样。

得到的产品经理们当然明白这些,只是用户都是懒的,如果真要做到像标榜那样的帮助人终身学习,做一些产品特性帮助用户在思考,对输入的信息再加工再输出,这样产品的受众就很小了,永远只有少部分人愿意去思考和真正学习,大部分人不想动脑,而且是不想动脑不想花时间还想学到知识,得到迎合了这个需求,提供了省时间获取信息的方式,让人轻松获得信息并自以为在学习。实际上得到是提供了挺多高质量信息,是个不错的信息源,但他不告诉你我只是提供跟以前商业杂志一样的信息,而是吹嘘能帮助你终身学习,混淆概念,迎合现代人的焦虑和懒惰,挺鸡贼的。