448580ff42f1c263edbc3a8e5d746161
QCon2018·北京站 参会小记

4.20 ~ 4.23 三天时间参加了 QCon2018·北京站 全球开发者大会

三天大会都是从早上9点开始,并且有2天都是周末,简直比上班还累╮(╯_╰)╭

坑爹的北京国际会议中心没有空调啊,这么多人的大会,没有空调简直热死个人啊╮(╯_╰)╭

大会涉及的议题太多了,整整3天 x 每天6个时间段 x 每个时间段9个场地同时开讲,可想而知这几天一共讲了多少议题。所有议题都可以在下面的链接查询,有的可以下载相关PPT,有的可以回看现场录像

QCon2018·北京站全球开发者大会日程

介绍一下我参加的几个议题,每个议题都留下了一定的记录和思考,也有一些评价和感受。

  • 移动端相关
    • 区块链技术助力移动AI
    • 美团移动端动态化实践
    • 增强现实的未来方向
    • 从Observer到Observable -- 使用Functional Swift提升复杂iOS项目的可维护性
  • 前端相关
    • 浅谈前端交互的基础设施的建设
    • Lavas:PWA的探索与最佳实践
    • 面向未来的原生化Web开发
  • 服务器相关
    • 手Q性能优化的大数据实战
    • Reactive架构升级实践 -- 淘宝全站业务的全异步流式架构升级
    • 唯快不破 -- 高效定位线上Node.js应用内存泄漏

移动端相关议题

美团移动端动态化实践

美团带来的移动端动态化实践,因为我本身在大前端动态化方向也有很深的关注,这场议题也算是我比较有兴趣的场次之一。

这场分享,主要从布局动态,虚拟环境,插件化,web增强化四种面向不同场景动态方案来讲,简单的说美团把这四个方向都做了自己的技术规划与轮子架构与业务实践,并且最终4个方向都落地到了完全不同的业务团队中。

我个人也在根据自己的业务特点与技术储备,全面推动部门内实现自研的动态化方案,所以这段会议小记中会夹杂很多我个人的评论。

动态化技术方案总结

上面是美团对移动端动态化技术的一个四象限归纳总结,这里几个象限我想分别解释以及评论一下

  • 横坐标按着偏Native/偏H5来划分
  • 纵坐标按着开发模式是否需要迁移切换来划分

业务插件化

这个象限确实偏Native,他根本就是纯Native的。

这个象限的技术栈也是完全保持至原本的Android原生开发模式,因此是技术迁移成本最低的。

这个象限最大的问题在于,只有Android在往这个方向进行尝试,然而Android P的最新系统也在大幅度限制此类原生动态化的能力。

我的评论:

iOS在苹果的全面封禁打压下,这条路就真的没有希望了么?传说中的滴滴的 Dynamic Cocoa 与企鹅的 OCScript 都变成了闭源根本不会开放的内部私密项目,与此同时很多大厂也在进行很多保密内部项目研究,其实在深入编译原理的层面后,在LLVM面前很多苹果的限制已经无法阻挡底层人员的想象力了,虚拟机也是人写的,还有什么不可能?只可惜现在这块有实力的大厂都在秘密进行研究吧

嘿嘿,这里面其实有很多玩头,嘿嘿(留下了淫荡的微笑,啧啧)

这是美团对业务插件化的评分,其实多方面都挺平均的,也挺不错的,但只运用于安卓,缺乏跨平台性是个弱点

布局动态化

这个象限确实是更偏Native,下发各种JSON来描述各个界面元素的层级与样式,从而用Yoga也好,ComponentKit,其他FlexBoxLayout也好,将JSON数据排版成具体的界面元素坐标,最重创建原生的NativeUI进行绘制。

这个象限也确实是一种新的开发模式,因为开发中需要学习新的基于JSON的结构化描述语言,其实这就是一种DSL,每种DSL都有自己的学习成本,迁移成本。而不是直接使用传统Web的开发 or 传统Native开发。(布局描述协议上,可能稍微贴近一点Web开发)

我的评论

布局动态化的这个话题,我曾在很多自己的文章提到过这个观点,布局动态不等于功能动态,所以这个象限严格意义上讲,他并不能和其他四个象限的技术栈在同一起跑线上进行对比,其他象限其实是可以做到从UI界面到功能逻辑的动态化的,但这个象限,欠缺的功能逻辑能力永远是致命伤。

关于这块我真的推荐看一下我以前写的文章 动态界面:DSL&布局引擎,其实就是对比TangramJasonetteWebViewReactNative的差异,来全面阐述DSL与布局引擎的意义,并且里面也重点强调了DSL的学习成本与迁移成本带来的问题

这是美团对布局动态化的评价,可以看出迁移效率/开发效率,都是这类框架的弱点。

我的评价:
还有个最大的弱点就是我说的,无法动态化逻辑,只能动态化界面。

虚拟运行环境

他想把ReactNative类似的技术都归类在这一象限

这一象限确实是从偏向H5的Web技术发展而来的,很多人强调,RN是Native渲染,但so what?RN一整套技术架构里,最终的渲染环节只是一部分,渲染用Native的也改变不了他的整体设计更偏向Web技术栈这个事实,更何况Weex同时支持安卓/iOS/Wap 三种渲染,RN在携程和京东很多公司的支持下也能支持同时渲染H5与Native。

这一象限也确实需要切换新的开发模式,要知道只使用RN/Weex的自带组件,开发中很难满足定制化需求,也就是说免不了深度定制JS与Native业务组件,在这个过程中既需要前端与JS知识,也更需要安卓/iOS的原生开发知识,这种开发模式在业务定制度高的情况下,算是一种与Web/Native差异都很大的新开发模式了。

我的评论:

1 这个名字起的太尴尬了,我是觉得这样起名字非常不妥,他想表达的是类似ReactNative/Weex/Flutter等技术,但居然起了虚拟运行环境这样的名字,我一开始听这个名字,第一反应以为是介绍腾讯的OCScript项目:自研一套基于OC语言但是确是解释执行的虚拟机技术。

2 如果让我起名,我更愿意起名为解释执行原生渲染模式,虽然字数更长,但绝对定义精准的多,基于一种可下发,可以解释执行的脚本语言(Dart的AOT这个话题另说)实现动态更新代码,通过桥接解释执行环境与原生UI环境,进行原生渲染,这类方案其实游戏圈领先应用圈三四年,大名鼎鼎的cocos2dx+lua早在三四年前就已经是这种方案在全面推广了,具体可以看我的另一篇文章,“站在10年研发路上,眺望前端未来”:读后感,这是我在2年前看到一篇谈论大前端发展的文章的读后感

3 解释执行原生渲染其实是完全包含布局动态化这个象限的,这也是我说的他们不能站在同一起跑线进行对比的原因,ReactNative内部一定包含着一套布局动态化的框架,用JSX开发,经过Yoga.c进行排版计算,最后用坐标数据转化成原生UI进行渲染,但是ReactNative还拥有逻辑功能的能力,因为他多了一个JSCore可以下发逻辑,而不只是下发界面。只能说ReactNative是一个整体,比较庞大,如果你不想引入整个RN,而是只想布局一些丰富展现的电商发现页瀑布流的话,布局动态化这个象限才体现出价值,简单轻便的多

4 快应用确实是可以归类在解释执行原生渲染这个圈子里(很多文章表明,他确实是在安卓系统层面支持的但是原生UI渲染的方案),但快应用严格意义上在新老开发模式上,我认为他更偏向老开发模式,因为快应用不同于RN/Weex开放源码与组件,支持灵活扩展的模式,快应用是底层源码黑盒,不提供原生扩展的,所以在开发模式上,不存在当业务需要灵活定制的时候,同时需要Web开发与原生开发一期开发的开发模式。

这是美团对虚拟运行环境的评价,可以看出来,在迁移效率上是一个弱点。

我的评价:
我是觉得还有个更大的问题,整套框架的把控力研究力度,基础技术支持的成本。做RN和做Weex类似的大型业务,绝对免不了面对JS与Native业务源码定制能力的开发,以及JSBundle自研拆包分包,分发部署一整套部署系统架构。

Web容器增强

这个象限没什么歧义,简单说就是基于WebView,小程序/PWA也好,老牌PhoneGap也好,他都是基于WebView的,当然是偏向H5

至于开发模式上,纯前端开发就能搞定,不需要前端与原生配合开发,所以也放在老开发模式里

我的评论:

我个人对Web容器增强这个方向上非常看好,现在WebView在移动端可定制容器的前提下,潜力根本没有被发挥出来,大家还是停留在传统的PhoneGap,或者单纯写几个Bridge,依然还是老旧的Web性能的老思想下

狭义的Hybrid
也是现在大家普遍认知的,Hybrid就是一种给 WebView 增加一些js通信可以调用原生API的方式

广义的Hybrid
我能否认为,只要是前端的开发思路与客户端原生的开发思路相结合,就认为他是一种 Hybrid?我能否认为,通过原生的配合,把原本js or 前端开发做不到的事情做到了,用原生的方式增强了原本的前端技术能力,是否就是一种 Hybrid?如果说ReactNative以原生渲染被人著称,那么微信小程序一样做到了原生渲染部分组件,谁说WebView做不到?

webview慢?webview渲染卡?webview交互差?什么是Hybrid?Hybrid就是纯web做不到想尽一切办法用native补,别局限在一个用个jsbridge,掉几个oc函数就叫hybrid了,所有webview的痛点都能用Hybrid的思路让native补齐

Hybrid就相当于不依赖谷歌苹果支持,在自己的App壳里实现自己的能力更激进的PWA

Hybrid就相当于不依赖微信支持,让自己App壳里的WebView也做到像微信小程序一样的框架,拥有更好更快远超传统WebView的体验。

这是美团对于Web容器增强这方面的能力评价

我的评价:
其实在我看来,Web容器增强如果本着自研一套小程序能力级别的框架来做,他的流畅度得分不见得有这么低,流畅度虽然不会完全直追ReactNative那类,但也绝对会提高不少。并且也不见得只适合应用于节日类运营活动,与广告运营活动,可以运用在很多地方。

美团的动态化落地

来看下美团这4大方向的全景图,好家伙,每个方向都做了一整套比较深度的研发架构和工作流辅助平台,真可谓是每个方向都造了个大轮子啊,并且这些方向完全运用在不同的业务上,只能感慨,人真多,每个方向都自己造轮子。(不得不说公司大了这也是通病,俺们厂里也一样,跨大部门之间轮子被造了无数,选型也选了无数)

动态化的未来

这是一个很有意思的话题,并且这个话题我的看法和主讲嘉宾也是一致的!移动端的很多时候都似曾相识,那么回看PC年代的发展,客户端与Web技术的发展差异不就是CS/BS的发展差异么?什么样的业务在PC上还在坚持用客户端技术在实现,而什么样的业务在PC上已经全面Web技术化了(包含Electron等web包壳技术)

我在“站在10年研发路上,眺望前端未来”:读后感提到过这么一个看法

如果说标准WebView不能满足性能或者Native独有硬件设备上的需求,那么我们就参照借鉴Web标准,在native内重新打造一个,经过优化各种包袱后的 Web Native Runtime,毕竟Web的标准从灵活性上经历了那么久的考验,而客户端如果能改变一些内核策略,甩掉一些包袱,争取到适应当下移动设备性能并且兼顾动态性的最优体验,那就真的是客户端与前端的水乳交融的Hybrid了

所以,在探讨关于动态化未来上,PC端的现在可以侧面看移动端的未来这个观点没错,Native与H5在越来越相互靠近这一点是最重要的,但是如果不能四个方向都做,如果让我选择我们自己做动态化方案,我会选更贴近web的方案

从Observer到Observable -- 使用Functional Swift提升复杂iOS项目的可维护性

这是@aaaron7莲叔带来的一场关于swift的函数式编程思想分享

Functional Thinking

心累想哭的代码,如何用函数式思想进行改造?如果把if的判空逻辑统一进行抽象,抽象出一个g,那么会怎样?

  • 通过抽象来更好的描述问题
    • 本质:非确定性 State ->确定性 State 的转换
  • 对于同构的场景提取模型
    • 普适的模型(input:a?,f:(a)->b?)->b?
  • 最终通过符合直觉的方式解决问题
    • 链式调用,顺序执行,无需维护中间变量逻辑分支

现在主流的 Functional 框架

  • ReactiveCocoa
  • RxSwift

自己亲自实现一个 Observable 框架

  • 动动手 实现一个 signal

  • 动动手 加入map filter功能

用 Signal 解决实际的业务问题

  • 中间层的消息传递

  • delegate逐级上传
    • 弊端:一个简单改动要改N个地方
  • 通知中心
    • 全局通知Name表,无法反应依赖调用关系

用Signal解决

  • 与 delegate 的⼀一对⼀一不不同,panSignal 可以被任意多个对象订阅
  • 新增事件,只需要新增⼀一个 signal,中间层⽆无需修改
  • 子view内部的控件⽆需暴露,只需暴露 signal,保证了了封闭性
  • 依赖关系清晰,⽆无需维护全局通知列列表

MVVM是Signal绝佳的使用场景

背后的设计模式

Monad - 关于“顺序结构”的设计模式

  • 名字来源于 Category theory(犯愁论)
  • 面向对象的视角:当一个类以及其方法满足是⼀个 Monad 时,代表其可以被⽤来将⼀些 “⾮顺序” 结构的代码,改造为“顺序”结构
  • 经典的⾮顺序结构代码:event handler 和 async operation

一个简单的需求转化为 Function Programing

  • 点击按钮,开始计时, 倒数30秒
  • 倒计时完毕后提交记录到服务器器
  • 请求成功返回后更更新⽂文本框提示

收获

抛开学习曲线陡峭的巨型轮子RAC RxSwift,莲叔带着听众一步步从自己实现一个基础能力得signal,到用这个signal解决业务中常见问题,再到函数式概念的理解,真的是深入浅出循序渐进

区块链助力移动AI

这一场标题又讲AI又讲区块链,初看感觉很像一个大噱头,但实际上干货十足,来讲的杨林博士式是AI与硬件芯片方面的专家泰斗,简洁精炼的从算力的发展史来剖析未来AI的发展方向,以及现在的落地

AI的发展需要什么? 数据/算法/算例

数据就是客观现况
算法就是人的先验经验
算力就是芯片

算力的是什么?

  • 专属算力
    • 搜索算力 CPU
    • 娱乐算力 GPU
    • 通信算例 专用集成电路
    • 挖矿/AI算力

算力的发展遵循着,CPU -> GPU ->专用集成电路的发展趋势,现在AI也面临新的算力需求,平行算力/并行算力 + GPU,未来一定会发展到专用电路

算力为什么这么重要

一个小芯片 3个T的算力(教授他们公司的自主芯片)
为未来算力提供基础

算力问题如何解决

  • 手机算力也越来越强,1个神州太湖相当于100w个手机,但是中国有几亿手机。
  • 随着手机的普及,有太多算力处于闲置

算力问题如何解决

区块链如何解决算力问题

  • 区块链 打比方:打麻将记公分 白天干活晚上记 谁胡谁记
  • 比特币 打比方:打酱油买酱油,不花钱可以花公分

区块链来共享算力,衡量工作量,分布式全民参与的算力,并产生价值

专用集成电路如何解决算力问题

有了区块链式的软件服务,还有低成本研发芯片能大幅提升软件开发者的ai移动开发能力

强算力下的移动AI愿景

广大应用开发者参与进来,一起玩AI,除了大公司做AI,应用开发者做AI的硬件平台+分布式软件平台已经趋近成熟

增强现实的未来方向

这是一场由老外带来的未来增强现实的大会场,全程英语交流,我听的还真是有点吃力,好累╮(╯_╰)╭,不过也算坚持下来了。这一场开始介绍了AR现况与市场发展趋势,然后就开始介绍还在实验室中的神奇技术了

Augmented Reality Present

以下内容为简单PPT翻译,需要可以去文章顶部的Link下载App

  • 真实与虚拟影像结合
  • 虚拟内容可以进行交互
  • 虚拟内容展现在真实空间中

AR市场的增长非常之快,是VR的3倍

Augmented Reality Future

未来AR技术还将在这些方向深入进行研究

  • 更广阔的空间探测,深度探测
  • 植入隐形眼镜的虚拟显示屏技术
  • 更精准的自然手势识别交互
  • 语音/手势/眼神等多模输入
  • 三维空间的追踪探测还原识别(机器人视觉)
  • 广阔户外空间的追踪探测还原识别
  • 情感探测/眼球追踪

前端相关议题

浅谈前端交互的基础设施的建设

这是由winter寒冬大神讲的交互基础建设,很朴实的从view框架发展讲起,最后聊到web下如何与native交融,在高频复杂交互下如何进行合理的js与native通信融合,最后引出了本场重头戏-前一段时间开源的BindingX

交互的发展与演变

UI架构演变

界面也在同时发展

视图职责在演变

计算机功能也在演变

交互的本质

由输入一系列信号

  • 屏幕触摸
  • 陀螺仪传感器
  • 时钟
  • ……

进行输出

  • 图形变化
  • 渲染
  • ……
top Created with Sketch.