东京2017QCon个人共享总计

上周五去参加了 QCon
大会,上一次去好像是两年前了。人没有想象的多,会场也没有当年的气派了,难道是规模缩水了?

有幸作为讲师受邀参加InfoQ在上海举办的QCon2017,不得不说,不论是从讲师还是听众的角度衡量,QCon进一步扩大了技术视野。虽然前端专题只有四场,但每一场分享都是目前的热门话题。并且Qcon的选题都是从实践出发,并没有一些看起来很炫但是尚未经过实践检验的新技术,即使是目前刚刚起步且相对来说比较小众的WebAssembly也是以饿了么的生产实践为基础。

有幸参与了QCon
2016的上海站会议。官方宣传这是一个中高端会议,专题丰富涵盖了当前互联网各种技术领域。

QCon是由InfoQ主办的全球顶级技术盛会,每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。今年月10底,QCon在杭州召开,国内外的各个技术方面的大家齐聚一堂,分享他们在自己的领域获得的成就和经验。在西安寒意阵阵来袭之际,我们葡萄城的几位技术同事前往风景如画、桂花飘香的杭州参加这样了本次会议。

移动开发发展方向—–Hybird混合开发3大方案

在”后移动互联网时代的技术思考与实践“这个主题的教室听了一天,主要是关注目前国内比较领先的大厂在移动端的发展方向。

图片 1

10月20号周四 10月21号周五 10月22号周五
前端技术实践 玩转大数据 Growth Hacking,IoT & React Native
安全之战 移动开发探索 互联网广告系统实战
新Java,新未来 移动视频 工程团队管理
无处不在的容器 让架构更简单 技术创业
微服务架构,我们该如何实践? 运维与监控 机器学习与深度学习
大数据应用与系统优化实践(厂商共建专题) 大数据服务与应用 用户体验设计
业务上云技术拆解(厂商共建专题) 高并发与实时处理架构设计(厂商共建专题) 研发支撑体系
智能出行 – 高德开放平台专场(厂商共建专题) 微服务实践与架构演进之路(厂商共建专题) 业务系统架构
大数据分析与应用
大规模前端系统

Qcon的会议安排是非常的紧张的,早上是三场集中的演讲,基本是国外的专家,下午有3个track,每个track一个主题4个讲座,也就是同时会有3个讲座在同时进行。有时候真是鱼与熊掌不可兼得了。

顾名思义,移动互联网已经进入下半场,技术发展趋于稳定,从快速更新百花齐放过渡到了相对稳定的阶段,一些范式,解决方案在业内达成共识,所以本届QCon在移动端的关注度有了很明显的下降:只有一个分会场,且坐不满。

我的分享话题是《面向SPA和Hybrid应用的前端工程体系和实践经验》,从我个人角度来讲还是缺乏演讲技巧,语速过快导致比预期的时间提前了将近1/3,为听众争取到了一个比较长的茶歇时间╮(╯▽╰)╭。演讲结束后与支付宝的同行探讨了一些相关的问题,挖掘了目前搜狗地图团队从工程角度的一些不足和启发,比如模板更新率以及解析速度提升等。但是与支付宝业务不同的是,搜狗地图中对于模板的定义并不是“离线包”,而是一种类似于html模板的动态解析“引擎”。

QCon 上海站PPT
下载

开幕式的主题演讲是由
Jim
McCarthy来讲的,该君回顾了西方软件开发的历史,以及黑客文化的起源,其演讲激情四射,充分暴露了他对软件行业的热爱。摘录一些:“软件是科学里最切合逻辑的东西,代表了科学的声音,科学的高潮”,“我们要做伟大的软件,进而改变世界”。其热情也打动了我们,我们能不能做一些真正伟大的产品,来改变世界?如果现实没那么美妙,那么我们是不是可以从小事做起,确保我们提交的每一行代码是做美妙的,每一次的提交都在提高,一次一次的美妙就会积累出伟大的代码,乃至伟大的产品。该君还提到软件要与心和灵魂结合,我理解的就是热情,Coding多年之后,我们是否还有激情,决定了我们能否持续成为一个合格的码农,也许要经常问问自己这个问题。

1、微视建立了完善的监控系统,对用户行为、播放质量等数据进行收集、聚合。以及开发了配套的报警、日志的运营平台。

分享的现场在正式进入话题前与现场的听众进行了一次小小的互动:粗略统计了一下当时在场的人当中搜狗地图的用户比例。尴尬的是,除了出品人@winter老师碍于面子举起了手以外,现场并没有第三个搜狗地图用户(我是第二个╮(╯▽╰)╭)。当然,这也算是意料之中,搜狗地图虽然国内的市场占有率并不高,甚至我在QCon讲师微信群里打招呼后有位老师竟然问“搜狗开始做地图了?”。“开始”这个词用的真是很尴尬啊,那么我就先科普一下搜狗地图的历史吧。

其中每个专题会在固定的宴会厅进行,由专题出品人主持专题的会议开展。专题下面是各个议题,时长大致为45分钟包含Q&A环节。

这次大会的主题主要是围绕着几个关注度比较高的主题展开。

这也是大厂技术资源人力有余力后领先的地方:在业务之外,有大量的基础架构来支撑运营、产品和质量的管理。

搜狗地图前身是图行天下,成立于1999年,是国内第一家互联网地图服务网站,2005年被搜狐收购后改名为“搜狗地图”。所以这个刚“开始”做的地图产品比大多数人预料的还要老。讲历史主要不是为了科普,也不是倚老卖老,而是从侧面阐明我们在进行工程化改造时所面临的项目特征:一个有着近20年历史包袱、模块结构混乱的“老家伙”(PS:搜狗地图目前的pc
web地图可以完美兼容IE5╮(╯▽╰)╭)。这样的老项目不可能短时间内切换到全新的技术栈,也不可能大胆地使用一些比较潮的技术和框架,更多的是从策略的角度进行优化。所以我分享内容更加贴近于经验而不是技术本身,相比较其他三位的话题,我所分享内容的方方面面几乎是每个人都熟悉的,我们的工作便是综合这些成熟且稳定的“常识技术”进行工程优化。

根据自身技术栈出发,我选择了以下专题

首当其冲的当然是炙手可热的敏捷开发

很特别的一点是,今年大家都谈论敏捷的效果,而不是教条的看待敏捷的清规戒律。成功帮助了大大小小的团队实现转型并取得了明显的成效的敏捷教练Amr
Elssamadisy,在这次的会议中并没有去讲解如何实现敏捷,反而是讲了几个使用敏捷失败的案例,他讲到,敏捷并不是万能的,只有你的项目,你的环境,你的团队成员能够满足敏捷开发的条件才能够成功。敏捷宣言的发起人之一,大名鼎鼎的《程序员修炼之道》的作者Dave
Thomas更是指出,敏捷只是实现目标的方法之一,你可以根据自己的需要去剪裁那些敏捷中使用的原则,他最讨厌最佳实践,认为没有什么最佳实践,你需要自己去实践,并找到最行之有效的方法。

2、介绍了提升视频播放性能的一些方案:移动端对音视频相关的技术需求很大,需要对音视频底层有很深的耕耘。

前端工程体系并不是一个固有名词,每个团队由于组织、业务以及架构上的不同,对于前端工程体系的理解的也不尽相同。在进入正题之前必须区分的两个概念是:工程化与工程体系。工程化是一个动词,意指将业务项目进行工程改造,比如合理的模块化、前后分离等等;而工程体系是一个名词,可以理解为工程化的外在表现以及辅助框架,比如构建、测试、部署等等。搜狗地图前端团队对前端工程体系的理解是:工程体系本质上是一种服务,其服务的对象是技术团队所采用的技术以及组织架构。而架构本身也定位为一种服务,其服务的对象是具体的业务。所以在这一层三角关系之中,业务是决定所有服务的核心和出发点。我们经常将的一句话是:技术不能脱离业务。我也希望这句话能够成为每一个技术开发者和决策者的座右铭。
图片 2

  • 20号 前端技术实践
  • 21号 移动开发探索
  • 22号 Growth Hacking & 用户体验设计 & 技术创业

大数据(bigdata)现在越来越多的出现在人们的视野

从国人诸多抱怨的12306.com购买火车票,到双十一光棍节,各大银行的电子支付系统顶不住压力,失去响应。另外一些网站却表现的异常出色,比如淘宝,他们的系统提供1000多个应用,平均每天300多亿的请求,却经得住大风大浪。对于twitter,facebook这些高并发,海量数据的网站,是什么样的技术让他们能够可靠地提供服务呢?在这些和数据相关的会议里我们几乎没有听到Oracle,sql
server这些传统的RDBMS,甚至很少听到mysql。充斥在耳朵里的是redis,MongoDB,MemCached,Hadoop,HBASE,HDFS。NoSql的阵营现在真的是日渐壮大了。看来真是要感谢google,要不是他们公开的论文,就不会有后来的Hadoop,也得感谢yahoo,要不是他们的资助,也不会有Hadoop的实现,以及后来的HDFS和HBASE.在QCon的多个讲座里,那些成功的,和正在走向成功的案例中,他们的框架的演变中,我们太多次看到redis的身影,几乎参会的所有网站都在使用,在自己的记忆里,好像新浪微博也是用redis来处理海量的数据。Facebook在用HDFS以及HBASE来存储海量的数据,以及基于这些系统进行信息安全的数据挖掘,这都给我们很多启示。对于这些唾手可得的开源系统,既功能强大,成本低廉,又非常简单易用,是时候要深入了解一下了(想想Oracle那100多个启动参数吧)。

具体的方案,无非是提前下载、视频数据格式优化这类。令人印象深刻的还是他们对用户数据腿毛级的收集,每个视频看了多久,播放质量如何,成功率,各阶段耗时,这些有用没用的数据都有好好收集上报。

从业务出发进行工程优化的第一步是提炼业务特征,从而选择合理的技术和组织架构。我们从四个方面提取业务特征:场景、类型、设备以及平台。
图片 3

前端技术实践

周四的专题对于 客户端开发来说稍显尴尬,没有与之相关的议题。
我选择了和客户端相对平等的前端专题。
下面重点介绍一下我认为有意思的议题:

Web应用依然是热门

Qcon成功案例分析的内容主要围绕web展开。包括京东的虚拟化运营,美丽说的架构变迁,垂直互联网站点的技术改造,聚划算架构演进和系统优化。我们不但看到了大数据的身影,也看到了虚拟化的力量以及私有云的大量运用。还是要感谢开源社区,得以使虚拟化以及云的应用得到了爆发式的增长。大家不必再拘泥于Hyper-V,以及Vmware,使用开源的系统,你可以很快的打造出自己的虚拟化系统以及私有云,你也可以基于这些系统开发出符合自己业务需要的虚拟化应用。从这些成功案例里,我们看到了京东使用虚拟化实现了客服及运维业务,阿里巴巴实现了快速并灵活的配置部署系统以及统一的测试平台。虚拟化和云是未来的趋势,他能为我们的系统提供elastic和具有scalability的部署和运维方案。

据说腾讯在音视频这块的技术实力落后头条一大截,想挖大牛又不舍得给钱,被业内诟病,不知道是不是真的。

以Web地图业务为例,从进入页面到展示完整地图的工作流程大致如下:
图片 4

Vue 2.0: 渐进式前端解决方案

讲师@尤雨溪,很早就关注他了。这次总算见到真人了。Vue已经在Github上收获了3w+颗star,对于开源项目来说,无疑是相当成功了。

我很认同他对框架的理解。框架的存在是为了帮助我们应对复杂度。但同时框架也有复杂度,Pick
the right tool for the job.

开篇的框架理解引出了 Vue
,这个渐进式前端解决方案。可能就是他对当下JS开发环境的一个答案。

框架本身,我不是JS开发,没有使用经历就不做主观评价了。
回到一开始的”框架”,他是如何解决框架复杂度的呢? 答案是”渐进式”。

图片 5

progressive

Vue框架提供 声明式渲染
核心功能,加上可选的附加库/工具链,来打造弹性复杂度。这个区别于传统框架,集成整合了一整套解决方案。提高框架复杂度,增加开发者的学习使用成本。

这种框架的设计思路,是明智的。

不得不说的就是Mobile Apps

随着各种智能手机和平板设备的广泛应用,国内很多公司以及个人投入到这个行业并保持着极大地热情,可以从移动应用的讲座时一座难求看出来。

QCon还有很多其他主题的讲座,比如测试方面的专家,获得Jolt提名的Gerard
Meszaros,讲的基于移动设备和云的自动化测试等等,也都非常精彩,不再一一赘述。

最后以一张西湖美景结尾:

图片 6

3、讲了下实时音量均衡:同样通过对音频底层编码的研究,做到各个短视频响度的均衡,提升体验。现场有人问怎么处理电影里突然的枪声这种情况,回答是顾左右言他,估计没有考虑这么多。

地图可以说是将按需加载发挥到极致的最佳实践业务。大家可以想象一下,以街道为维度将北京市的全貌绘制到浏览器中,浏览器能否承载如此大的工作量?即使抛开技术的局限性,单纯从需求的角度来讲,用户通常只需要查看以当前位置或者搜索位置为中心的有限区域内的地图。所以对于地图来说,第一步也是最重要便是定位

Progressive Web App:反击序章

讲师@黄玄开篇讲述了web在当下移动时代的窘境。有一定的技术高度看待这类行业问题是蛮赞的。不认可web在移动时代只有Hybrid这一种选择。

开始布道 PWA(Progressive Web App),认为这是web针对native的一次反击。
The new application model for Web

  • add To HomeScreen (web 也有像native原生应用一样的桌面图标入口)
  • Instant Loading & ReliableExperience
    (提供一种缓存机制,类似原生应用的首次下载)
  • Push Notifications (web 也可以像原生应用一样接受通知)

…等等一些特性。让我这种native同学感到十分新鲜。确实在 纯web 到
纯navite 之间有许多可能的点

反观业界,应该很少有企业对自己的网站能支持到这种体验程度。特别是在iOS
9提供了 web
mark机制之后,直接把web流量切给了native。不知道有没有统计过用户是愿意留在浏览器
还是 更愿意跳往原生应用

不过在原生应用开发实践中,我个人偏向于 hybrid
方案。这个取决于你的App大多数是什么样的业务场景,需要权衡体验和发布节奏等利益点。

  1. 纯native,体验是有可以保证的。 缺点就是发版受限
  2. hybrid,这里讨论指的是 RN,Weex这种跨端方案。好处是
    发布不受限制,一人开发跨两端(iOS,Android) 节省人力。体验稍逊于native
  3. 纯web,包括不经优化,直接套用webview的这种。缺点是体验差,卡顿,load时间久

4、最后提了下移动端的ML,也就机器学习、智能分析这块,看的出来腾讯对这块的研究没有阿里强。

  1. 进入页面后首先请求定位服务,此时页面的状态是loading,也有人将其称为骨架页面;
  2. 定位成功后,用户所在位置的经纬度以及对应比例尺数据决定后续瓦片数据的获取;
  3. 瓦片数据请求成功后,浏览器端JS代码将其排列组合最终展示出完整的局部地图。

移动开发探索

这个专题与我息息相关,吸引的我是这些议题

阿里整块就讲了一个东西:移动端的智能。

精确定位是非常复杂的功能,感兴趣的可以自行查阅相关资料。

React Native 业务实践和性能优化

图片 7

who use RN

讲师 携程@赵辛贵。 携程积极拥抱RN技术,多数业务和页面使用RN搭建。
好处明显

  • size优势,RN页面大小计算脱离原生包大小
  • 支持动态发布,跨端节省开发人力
  • RN技术成熟,社区活跃(参会时和旁边的途牛网开发交流,他们动态方案也是选择RN)

携程内部还演化出了CRN(ctrip
RN)业务框架。做了性能和稳定性优化(思路参见PPT),规划支持CRN-web实现跨三端(iOS,android,H5)。

外界RN动态方案使用的如火如荼,他们正在证明这是未来移动前端开发的方向。

主要是解决后端智能的一些痛点:实时性、数据隐私、离线问题等等。

除了Web地图以外,搜狗地图前端业务的另一种主要形式是Hybrid。将这两种业务形式进行归纳总结,提取的业务特征大致如下:
图片 8

Weex 极致性能优化

公司同学分享,Weex性能优化的几个思路方向。围绕性能,干货较多。
不过,这种经历只能听听思路。 基本没有实践复用场景 :)
安利Weex性能很好,倒是真的。

关于端智能:

业务特征决定技术架构,最终提炼出适用于搜狗地图前端业务的架构类型便是目前较流行的单页应用—SPA。

蘑菇街 App 的稳定性与性能实践

从用户角度出发看 性能和稳定性问题:

  • 闪退
  • 打开慢
  • 滑动不流畅
  • 耗电
  • 网络不畅/出错
  • 流量大

都是客户端常见的问题,相信各大公司都有自己的答案实践。

他们有一个比较有意思的工具:AppMate(小蘑菇)
提供给测试和业务开发进行开发阶段的一个性能把控。

或许是在阿里的原因,这些东西听来都不足以让我兴奋。

  • 端智能已成为趋势,各⼤大公司积极布局 AI 芯⽚片和 AI 框架
  • 端智能已在⼿手机和 App 中发挥巨⼤大价值,未来可期
  • 手机摄像,短视频特效,端计算,IOT 智能硬件是重点应用⽅方向

不依赖与服务端渲染的SPA不论是从架构层面,还是从开发和部署层面都带来很多便利。HTML文档可以作为一种静态资源与js、css等一同部署,然而从缓存处理方面,需要单独处理HTML这种“特殊”的静态资源。它的特殊之处便在于:HTML是所有其他静态资源的入口。
图片 9

Growth Hacking 最新动态和最佳实践

这个是受团队运营产品委托,刻意留意了这个议题(我所在的天猫team也负责push通道来召回用户,提高留存)

阿里这块的技术做的非常深,解决了很多痛点:

HTML的特殊性决定它不能使用http强制缓存策略,只适用于协商缓存:
图片 10

Growth Hacking 最新动态和最佳实践

  1. 数据看板 – 数据分析 – 数据监控
  2. 数据驱动产品决策
  3. AB 测试实验
  4. 灰度渠道发布

其中的数据分析提到:”Core Action” 指到的是核心操作,关键路径到达。
列举了几类APP的”Core Action”

APP类型 Core Action
Facebook connect(连接?相互关注?朋友互动?)
Slack/Wechat 接发信息
Pinterest 晒图
电商 浏览、下单购买
知乎 回答,点赞,收藏,感谢
互联网金融 购买理财产品
二手车 购买,砍价

这里有一个观点 重点关心产品核心操作是否被用户触达

图片 11

recall

这个模型 描述了
新客或流失客户(最近打开app的时候是在30-60天之前),我们应该积极的通过Push通道来进行用户召回,当用户下沉为忠实用户之后。要谨慎使用push。这个模型是可逆的,也就是说当用户不再活跃的时候,回归上层我们也要通过push相关利益点来进行召回。

分享了业界做病毒式扩散的几个经典例子:

  1. airbnb 分享给朋友,两方都能获得25刀的优惠券
  2. PRISMA 图片滤镜软件 制作图片打上软件水印
  3. Pokémon Go 户外现象级户外捕捉小精灵

这些快速扩散区别于
用户推荐和口口相传。分享者和你分享的时候,并不是在说这个平台或者软件如何如何,还是在和你分享他们得到了什么。分享一定要满足用户一些心理:增加声望、财富、乐趣。

最后病毒式扩散一定要作用在Core Action上。

  • 算法模型的选择
  • 模型文件压缩,体积轻量化
  • 部署和更新
  • 安全问题
  • 移动端计算性能问题

这样可以保证各类型资源实时性的同时,最大化利用http缓存,对于常规的SPA项目(比如Web地图)是一种比较普适的方案。然而协商缓存必须要求一次真实有效的http请求以便服务器进行缓存有效性判定,离线场景下并不适用。而离线是Hybrid应用较普遍的场景之一,后续会提到如何在协商缓存理念基础上的优化策略。

产品思维和设计思维详解

讲师
@张玉婷,她的设计思路蛮不错的。她认为设计师设计产品交互的时候,一定是从产品架构出发分析产品用户需求,进而推导出产品界面。而不是接到需求在网上一通翻找竞品界面。不同的需求场景有不同的用户语境,进而有不同的视觉交互表达。

比如
从业参与的Weico客户端,是设计驱动的一个产品。目前是最大的微博第三方客户端,跳脱开
官方微博客户端的通用性和功能化,主打个性化和情感化。围绕核心功能(阅读和发送微博)进行
特色的设计扩展。

后面提及高德客户端的交互设计,虽然
App类型不同,设计很难参考。但思路是ok的。要关注
用户与产品发生交互的真实场景,介绍了高德在这方面的交互实践。

针对移动端打造了一整套的自研方案,现场图标各项指标吊打业内主流。虽然对这块一窍不通,但是个人感觉牛逼闪闪,要献上膝盖。

搜狗地图Hybrid架构经历了三个阶段,最初始的方案是:Web多页项目+多Webview。也就是说,每个Webview承载一个Web页面,页面之间的切换就是Webview之间的切换,页面之间的通信便是Webview间的通信。
图片 12

如何选好技术初创风口:从0到1,1到100

这个。实话说我睡着了,可能是吃完中饭乏了。恩,是的。

至于具体的应用场景,目前还只是一些商品推送、运营互动中会使用,感觉潜力没有被开发。

这种架构一个最大的问题是:各页面之间的通信非常不顺畅,而且影响用户体验。如下所示的是一个非常普遍的场景:
图片 13

这套方案叫ALiNN,大佬表示会开源,不知道什么时候。

  • pageA包括两个部分:pageB的入口、由服务端数据驱动的Content;
  • pageA打开pageB的方式是新建一个Webview;
  • pageB中的表单提交数据到服务端,成功后返回pageA;
  • pageA需要获取经pageB修改后的服务端数据,最简单粗暴也是最省事的办法就是:刷新。

携程讲的东西很传统,就是大厂自己的平台建设,没有啥出彩的地方。

这种方案存在的致命缺陷在于,pageA并不知道pageB是否提交了表单[注],所以返回pageA后不论pageB操作与否都要进行刷新。不论是从节省流量还是用户体验的角度来讲都是负面的。

1、持续交付平台:就是携程的自动化集成、打包、发布平台,解决夸团队开发的许多痛点。这个东西开源的收费的大厂内部自研的一大堆了。当然还包括崩溃收集(演讲人吐槽了下
bugly 很难用,确实很难用)、配置中心、灰度这些基本功能。

注:pageA其实有办法获取pageB是否进行了提交。一种方案是通过localstorage的storage事件,然而兼容性非常不理想;另一种方案是通过native提供特定的接口,这种方案虽然兼容性好但是需要客户端的开发工作。

App Size 管理算是个比较有特点的东西,打包时计算各个组件模块的占用比。

在上述问题的基础上进行优化的第一步,是结合SPA架构和Webview自身的缓存机制。
图片 14

另外崩溃收集会根据调用栈中的函数名等符号自动在平台上分配给对应的团队,但是没有解决多团队公用轮子的坑。

Webview的缓存机制包括以下几种:

2、性能监控平台:提供了精细化运营、多维度查看数据、App运行状态实时反馈等功能。

  • LOAD_CACHE_ONLY – 不使用网络,只读取本地缓存数据
  • LOAD_DEFAULT – 根据cache-control决定是否从网络上取数据
  • LOAD_NO_CACHE – 不使用缓存,只从网络获取数据
  • LOAD_CACHE_ELSE_NETWORK
    只要本地有,无论是否过期,或者no-cache,都使用缓存中的数据

3、日志排障平台:又是对用户数据腿毛级别收集了,做到了全链路打通,H5,Native,Hybrid,我全都要。

其中LOAD_DEFAULT是最接近常规浏览器的缓存机制,在这种模式下,结合上文提到的SPA缓存策略,与常规的Web页面并无二致。然而App并不是常规的浏览器,其使用场景(手机)的特殊性要求我们在一些特殊的方面进行优化,比如缓存清理和离线使用。
图片 15

4、无线技术平台:相当于公司代码资源的公共平台吧,解决了轮子去哪找,谁来维护这些坑。

其中第一条是历史原因,公司运维层面将CDN缓存有效期固定位1小时,迁移优化成本较高。http缓存过期后并不会自动清理,之所以常规浏览器不用顾忌这个问题是由于PC设备储存空间大,并且可以使用电脑管家之类的优化软件手动清理。虽然手机等移动设备的储存空间也不断加大,但仍然有相当一部分设备的储存空间十分感人(我自己用的16G的iphone
7P,感同身受╮(╯▽╰)╭)。如果放任过期的http缓存不管便会造成app占用的空间越来越大,极端的用户可能一气之下就把app卸载了,我自己便曾经在阴阳师和狂野飙车之间做过抉择,最终卸载了阴阳师╮(╯▽╰)╭。

总而言之,如果团队规模很大,这些平台的建设是必须要走的路,大厂考虑安全问题往往要投入大量精力去自己研发。小团队小公司的话有一大推现成的可以用。

所以这并不是最终合理的方案,但是这次探索给了进一步的优化工作灵感:是不是可以吸取协商缓存的理念,同时结合Webview自身的缓存机制呢?以此为方向便产生了目前采用的协商缓存理念的Hybrid模板更新策略
图片 16

令我震惊的是携程光移动端的开发团队就有一千号人,查了一下,也就几款
App,体验在一线厂商中也算稀烂,总觉得发力错了方向啊……

模板是什么?前文提到了模板并不是静态的离线包,而是具备动态数据解析功能的逻辑模块。这个理念来源于SSR(服务端渲染)中的html模板,这应该是前端工程师们再熟悉不过的名词了,前几年尚未实现前后端分离开发时,html模板可以说是折磨前端工程师的主力之一。
图片 17

看名字本来以为会比较水,结果是最硬核的演讲了,涉及到很多算法的细节,emmmmmm……所以我基本没听懂。

模板以压缩包的形式传输,进入App之后如果处于Wifi环境则会自动检查并下载最新版本的模板包。并且在App进程运行以及挂起期间不会进行多次检查。
图片 18

简单总结就是:

具体每个模板包对应的页面,进入之后并不会检查模板包的版本,只要本地存在便展示,否则fallback展示线上的Web
URL。这种策略是为了尽可能减少具体业务页面的解析时间。作为fallback的Web地址采用WebView的LOAD_DEFAULT缓存策略,有效期为CDN缓存(1小时)。另外,如果用户通过任务管理器手动杀死了App进程,下次进入App之后首先会清理之前残留的http缓存文件。
图片 19

  • 黑产有规模有组织有技术,所以 App 安全要求很高
  • 基于代码文本的混淆太 low 了,破解没难度
  • 混淆安全性:汇编>字节码>代码,总之越底层越安全
  • 混淆有很多技巧,拆分、拉长、分散等等等等。
  • 做混淆,需要对编译器系统有很深刻的理解。大部分的混淆都是对 llvm
    编译周期的IR做的。

综上,搜狗地图的前端工程体系简易架构大致如下:
图片 20

腾讯做的是编译器级别的混淆,也就是说不需要对代码做任何处理,编译完成后出来的就是混淆后的
App 包了。

与常规Web项目的不同点在于,地图项目大量使用SVG和Canvas,组件库包括两者相关的组件。另外,负责与native通信的bridageJS是Hybrid应用所特有的。平台层由Gitlab把关,Webhook触发自动构建、测试和部署。另外,模板包可以由开发人员直接部署,不需要经过公司运维,这也是与常规Web项目相比的优势之一。

被大佬这么一讲,就觉得我们的还是在裸奔状态,不过也没有余力去研究这么深啦。

由于每个模板包都会对应一个fallback的Web地址,所以在构建流程中需要针对两种场景分别构建。模板文件对于App来说其实就是本地文件,所以模板文件中对于其他文件的引用统一使用相对地址,并且由于模板本身就是增量的,无需在静态文件名中加入hash指纹。构建工具有Node.js为底层平台,使用特殊的环境变量结合EJS引擎区分构建,如下:
图片 21

阿里在咸鱼 App 试水 Flutter
做吃螃蟹的大厂,还是很有创新勇气的,不过大厂就是大厂,google
那边亲自派人来对接指导接受反馈,爸爸级待遇。小团队要是尝试没有成熟的
Flutter 踩了坑只能自己哭了。

至此便是搜狗地图目前针对SPA和Hybrid项目的整体工程体系,当然这并不是终点,甚至称不上是最佳实践。此次分享的目标也并不是剖析我们团队的工程实践,更多的是将这一路走来的探索历程分享给大家,希望能够给同样面临老项目改造的团队一些启发。

总之就是夸了下 Flutter
的性能不错,体验也不错,应用过程也是经历了一系列的迭代,慢慢将原生替换为Flutter。

最后简单提一个优化的案例。模板也是分模块的,不能将所有的业务集中在一个模板中,否则任何一个微小的修改都会造成整个模板包的更新,而且随着业务的不断扩展,模板包的体积越来越大,下载和解析时间最终会超过用户的心理承受界限。所以我们在模板颗粒度划分方面做了一些优化:将逻辑无耦合的业务定义为一个模板包,比如用户中心与详情页,两者除了登录信息共享以外,几乎不存在逻辑上的耦合,所以将两者划分为两个模板。在此基础上将共用的类库文件提取出来单独作为一个模板。
图片 22

也有踩坑,解决了一些问题:

如果让我给这套工程体系打分可能只达到了60分的及格线,但是对于一个“历史悠久”的团队而言,这仍然是非常可观的“一大步”。后续仍然需要不断进行优化和迭代,比如会后与支付宝的同学一起探讨的更新率问题。技术的道路远没有尽头,回到一开始的那句话:技术永远服务于业务。总结这次的QCon之行,我看到了优秀的技术从业者们以实际业务为中心的探索和务实精神,收获的不仅仅是技术的增长,更重要的是扩宽了眼界。

  • 工程管理和混合栈管理
  • 外接纹理播放视频
  • 图片缓存优化
  • 无反射JSON序列化
  • 私有PUB库、阿里⽣态适配

最后,感谢主办方InfoQ的邀请,完整PPT下载。

最后将 Flutter 框架导致的闪退率降到了
0.01%,很厉害了。羡慕大团队有精力去扣这种细节。

然后介绍了一个三端开发的新模式:震惊!App
程序员竟然可以自己开发服务端接口!

总而言之,就是接入网关使用 Dart
Server,平台那边提供了一个胶水层服务,然后 App
程序员就可以在一个技术栈内同时开发前端和服务接口了,目前闲⻥详情页所有流量由
Dart Server 服务的,所以性能是满足需求的。

这样做的好处是能优化开发体验,部署方便,可以本地无冲突的调试,而且避免了前端和后端相互甩锅,后端同学的那句”你行你上啊“,终于成真了。

个人感觉会是未来发展的一个小趋势,服务器端接口本身也是业务的一部分,让调用端按照自己的需求开发很合理;而后台同学,则专注于提供平台级服务。

最后两个主题演讲居然撞车了,都是介绍了各自的动态化方案,那就是谁丑谁尴尬了。

所谓动态化方案:

  • 后端提供一个平台给运营方使用
  • 运营配置到页面的组件布局,要展示的内容
  • 这些内容组成一个描述文件
  • 通过下发平台下发给 app
  • app 根据描述文件渲染出页面

这样就做到页面配置的动态化啦。

其实仔细想想,这不就是一个 App
级别的浏览器渲染框架嘛,或者就是运营内容级别的 React Native。

最后感觉美团好像略微专业点,也有可能是讲师形象的问题,美团的讲师虽然照片很嘚,但真人挺帅,身材不错,爱奇艺那位感觉像是买假药的,讲出来的东西就没那么有说服力了。

总之,动态化一直是移动端的一个痛点,大家也还在探索最好的解决方案了。

总结一下:

  • 移动端开发的低门槛时代过去了,对开发人员的要求高了很多。
  • 技术发展从快速更新百花齐放过渡到了相对稳定的阶段,一些范式,解决方案在业内达成共识。
  • 目前的跨平台方案没有一个可以达到支持复杂客户端建设标准的。
  • 动态性是目前移动端的最大痛点,特别是体量大的大厂,大家都在做自己的解决方案。
  • 多团队,跨部门的开发效率低下是被关注和正在解决的问题。
  • 前端一体化,后台去业务,平台化是最近的一个小热点。
  • 人工智能,机器学习在移动端落地也算是个热点

个人觉得目前国内移动开发的品味不足,大家都在推进一些技术上,运营上的变革,但是
app
的交互、审美、品味仍然停留在几年前,创新的交互和设计是移动端产品在现阶段能脱颖而出的重要因素。好的公司产品设计地位一定要比开发高,开发主导的公司产品体验真的是一言难尽。

You may also like...

发表评论

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

网站地图xml地图