美国见闻

2018-7-30 评论(3) 分类:生活

7月的博客,写写6月初参加WWDC时在美国的见闻感想。

加州

加州,最深的两个印象,就是充足的阳光和多样化。

每天都是蓝天大太阳,阳光从早上6点晒到晚上9点,关键是晒着还不热,非常舒服,据说一年四季都这气候,18°-25°,真是得天独厚,国内貌似没类似这样的地方。

多样化,不知是美国共性还是加州硅谷特别,世界各地的人,各色各样,各种肤色、装扮、身材、个性,人非常多样化,很喜欢有多样化人群的环境,可以从每个人身上看到学习到不同的东西,我比较不喜欢广州的一点是大部分都是广东人,多样性较低,有趋同的习俗文化、关注点、生活方式,久了会觉得无趣。 (更多…)

WWDC 2018 见闻

2018-6-13 评论(1) 分类:互联网

第一次去美国参加WWDC,说说见闻。

Keynote

未标题-1今年WWDC亮点较少,感觉一般,点也比较散,是各种小点拼凑,没看到主旋律主方向。

AR占了很大篇幅,是本次WWDC的主角,会场专门有块地方去让参会者玩使用了 ARKit2 新特性多人游戏的《Swift Shot》,现场玩了下,感觉一般般,一种不会火的既视感。苹果大力发展 AR,有意作为下一个大的技术点和平台,猜想应该会有硬件上的配合,现在用 iPad/iPhone 玩 AR 着实别扭,AR 还是需要眼镜的配合才能自然用起来,期待苹果的眼镜。这次 AR 支持的图像跟踪、场景保存和真实光反射,据了解效果确实不错,做 AR 的人都会挺兴奋。

AI 有不小的更新,新的 Create ML 可以更简单地训练 CoreML 模型,以前都是使用其他框架训练后再转换模型跑在 CoreML 上,或者用 Turi Create 去开发。苹果面向开发者的 AI 策略上,走的是傻瓜式路线,不需要懂 AI 相关技术和算法,按规则拖拽就可以使用,只提供有限的常用的几种应用场景,像图像分类,文本分类,特征预测。用迁移学习的方式,在系统内置训练好的模型,用户只需训练最后一层,导致模型很小,很符合移动端应用的场。IDE做得非常好,真是零基础一分钟上手,但问题是无法跨平台,如果 Android 也要用就没辙了,只能用其他框架训练后转换。

iOS12的特性,感觉亮点是防沉迷防打扰,跟微信4.2发布时的“是时候放下手机,跟朋友面对面”这个口号有点像。统计APP使用时间,限制单个APP使用时长,对我来说是很有需求的功能,但对于大众来说不一定,很少人会去限制自己。倒是家长控制这个功能应该会比较受欢迎,人们不喜欢限制自己,但对于限制孩子是喜闻乐见的。新增的各种 notification 的特性确实解决了各种手机打扰的问题,也强调APP不要以拉活为目的去推送消息,而是给用户带来便利和有用信息的目的去推,这些特性是以用户价值为中心去做的。

在美国电视上看到三星S9的广告,肆无忌惮讽刺老 iPhone 慢的问题,加上之前的电池门,导致 iOS12 十分重视针对低端机器的性能优化,性能优化是 iOS12 最早提到的一个点,sharesheet,keyboard打开速度翻倍这些感觉不值一提,比较黑科技的一点是,iOS12可以结合硬件,在APP启动瞬间提高CPU的性能(超频?),提升打开速度,再快速降下去省电,这真是软硬件一体的公司才能做到的优化。

Mac 系统的升级,大篇幅讲黑夜模式,呃可能有需求的人很兴奋,实现工程可能也比较大,但感官上觉得只是个小特性。对开发者来说亮点是将在明年支持使用部分UIKit的组件去开发mac应用,这样iOS应用就可以低成本迁移到mac了。这是个大工程,目前苹果官方的股票、新闻等 APP 上就尝试用这种方式开发 mac 应用,一套代码服务iOS/iPad/Mac,用内部业务先趟坑,趟得差不多再推出,难怪今年这些APP会大更新,基础的更新需要业务的配合。

其他特性 Animoji,FaceTime,照片,siri shortcut等就不说了,各个 Session 的细节网上各种翻译文章陆续推出,我也不凑热闹了。

Lab

未标题-2

实际上除了第一天的总结性 keynote 必须朝圣式地在现场听,其他的 Session 分享其实完全没必要在现场,后续自行在网上听是一样的,还可以快进重复自由自在。Session 结束后也没有提问环节,所有的交流都在 lab。所以现场参加 WWDC 的重点只有两个:lab上与苹果员工面对面交流,以及认识其他开发者。我也尝试去lab问了些问题。

审核

有机会面对 AppStore 审核人员,自然要问下 hotpatch 相关的事情。

Lab 上得到的回复并不那么让人满意,主要在重复一点:不能绕过审核。但绕过审核这一点实在很难说清楚,只要有网络,一个请求字段就能改变所有功能绕过审核,没办法说某个技术能不能绕过审核,感觉她自己都绕不过来了。

在另一个较高层的会议上,提到 hotpatch 时得到很感性的答复:We don’t like it。总体听下来感觉,即使 hotpatch 在中国是个强力的需求,但苹果并没有意愿花大精力去满足中国开发者这样的需求,JSPatch 这种权限过大的方案触及安全底线,他们没法去一个个检查是否有做好安全措施,没法检查有没有审核后私自动态调用私有 API,最简单的做法就是一刀切,会一直切下去。

苹果不拒绝动态更新,只要更新的内容跟审核时的内容没有大出入,不是为了绕过审核去做动态更新就可以接受。对于各种新的动态化方案像 RN / Flutter 他们会去评估这些技术有没有风险,会不会被滥用,观察线上 APP 都用它们来做什么,再决定审核措施。

其他一些点:

  1. 审核人员会根据情况对APP进行延迟审核的惩罚,目测是针对故意违反规则或连续违规的 APP。延迟的时间长度没有期限,内部怎么定的时间不透露。
  2. 审核时会横向跟同个账号的其他 APP 做参考,看是否其他 APP 也有违反规则的行为,综合审查。
  3. 一般非常恶劣的情况才会直接对一个 APP 下架,至少会提前一两天通知,一般不用担心审核不通过会影响线上版本。

在 facebook 交流时问了他们怎么应对需要 hotfix 的情况,他们是直接更新版本,若特别紧急的话,有专门对接苹果公司的人可以得到快速审核响应。

TestFlight

我们在公司内部做了 iOS 灰度系统,通过自己的邮箱去收集所有的 TestFlight 的邀请码,再在 APP 内直接给用户使用,做到用户不需要离开 APP 不需要填邮箱就可以参与内测,可以回收邀请码,充分利用 1w 个邀请码。这个最早是QQ邮箱的idea,我们把这个过程自动化了做成系统,所有APP都可以使用,并实现了突破1w个邀请码的限制,后续可以再详细介绍。

这个东西一直没有对外是因为不了解苹果对这种做法的看法,这次在 lab 上问了相关人员,得到的答复是这样做是没有问题的,虽然不推荐,但是是完全允许的。另外因为我们系统请求量大,他们也注意到了,也开始考虑到了中国用户不喜欢用 email,TestFlight 原生满足不了需求,于是他们推出了 TestFlight Public Link,可以不需要用户提供 email,直接打开链接就可以匿名参加内测,这个是个很好的改变。不过还没有给出具体上线时间,只是说 This summer。

iTunesConnect (改名 AppStore Connect) 这次开放了不少API,之前做灰度系统很多 API 都是自行在网站上抓包看请求去拿到,没有标准接口,经常有接口更改的风险,这次完善后持续集成会更好了,还支持了linux,不需要搞台mac机器去跑部署了。

Technique lab

跟同事一起去 technique lab 问动态库加载小概率失败的问题,现场上 github 看 dlopen 的源码,得出结论是内存不足,可能是 APP 体积过大导致,没有明确的原因,并喷了一下我们100多M的体积太大了,他们不认为一个 APP 需要做到这么大,我说 FB 更大,他说 FB 是个 bad case 不应该拿来对比,直接喷 FB 的做法非常糟糕,感觉这些专注底层库的哥们对外界业务需求不太了解。

花絮

未标题-3

  1. WWDC 提供的午餐很黑暗,尤其是第一天的汉堡,是我吃过最难吃的,又冷又硬,令人发指。后面几天有鱼排什么的还好接受点,虽然都是冷的。
  2. WWDC 周四有 bash,一个户外聚会和演唱会,效果非常赞,这次演出请了挺有名的 Panic! At The Disco 乐队,很擅长调动气氛,摇滚得很,全场很high,差不多算是 WWDC 的闭幕式了。不过有点尴尬的是因为加州九点才天黑,演唱会全程在阳光下进行,夜生活真是跟加州无关。
  3. 硅谷在残障人士的支持上做得很好,WWDC 都能看到盲人参加,lab 上也有坐轮椅的员工解答问题,看到不止一个。
  4. 苹果的 lab 里有听过年纪较大的程序员在解答问题,目测至少50+,工作就是写代码,据了解是苹果这样的公司才会比较多,像 FB Google 这种主要还是年轻人。

再游日本

2018-5-27 评论(4) 分类:生活

五月再去了次日本,这次主要带家人去转转,非个人休闲游,角色主要是家庭服务员,还是再写写一些见闻感想。

我对三种旅游感兴趣,一是壮阔的自然风光,草原瀑布沙漠高山之类的,二是休闲度假,海边躺着的那种,三是体验不同的文化和生活方式,就是日本这种。旅游的部分意义在见识更多生活的可能性,避免在日常中碰到一些小问题就觉得是全世界,一叶障目,不过正常观光旅游只能见到些皮毛,如果找一个本地导游带领深度体验当地生活可能会好点,不过这个行业似乎还没起来。

上次是冬天去北海道,这次是夏天去关西,两次体验不太一样,这次感觉会更好一点,上次北海道没有体验到传说中的日本干净,这次体验到了,感觉很神奇,不是街道没有垃圾的干净,这种杭州也差不多,是没有灰的那种干净,路上每辆车都刚洗过的样子,房子外墙也是发亮看似不会旧的材质,地面也没有灰尘,再加上空气好,随便一个街道感觉景色都很好,即使路上铺满电线杆。不太了解这种干净是不是有日本是海岛的原因。干净的环境和空气让人感觉很舒服,加上房子都是小栋别墅,很惬意。看起来日本人是很爱干净的,但是去奈良时,看到巨多的小鹿在街上跑,人与动物和谐相处是挺好,只是动物不会上厕所,搞到很多地方很脏,也有些气味,这种情况日本人就能忍受了,感觉挺奇怪的。

日本人有礼貌这点也是体验到不少,遇到90%的人都是各种客气礼貌,走廊碰到个陌生人都点头微笑,有些不知所措,但也挺舒服,看起来是他们一贯的习惯,为什么会形成这样的习惯呢,有人说社会发达了素质提高了压力小了,这种对陌生人的和善是自然会有的,但日本压力似乎也不小,香港这个发达社会表现出来的是相反的,还是文化的因素较大。

日本守规矩到偏执的程度,也不会去想是否合理。在京都御所,入口出口在同一地方,在入口不远处看俩外国人往回走,在找出口想出去,结果被工作人员截住了,意思不能往回走,本来出口近在咫尺走几步就能到了,工作人员非得让他们按规定的路线往前走绕一整个御所走到出口,而不能回头走几步到出口,为了守规矩,让人多走十几倍的路程,也是醉了。另一个例子,很多地铁扶手电梯只站一边,人多时也是这样,导致排队很长,这做法似乎很文明合理,但是不想想为什么要只站一边,是为了给有急事的人让道,但是电梯旁边就有楼梯,有急事的人大可跑楼梯,所以这个行为一点意义都没有,单纯为了守规矩降低通行效率。

这次再度体验日本的线下支付,理解了为什么中国移动支付普及率领先世界,因为我们没有基础设施,切换的性价比很高,每个商家小贩用户有足够的动力去支持移动支付,像日本这种发达国家各种支付设施足够方便,切换成移动支付收益不高,商家用户都没有动力去换。 首先国外刷信用卡并不比移动支付慢,不需要输密码不需要签名,掏出信用卡的动作也并不比打开手机APP慢,用户能体验到的移动支付带来的便利只有少带一张卡。其次自动贩卖机特别多特别发达,各种面额纸币硬币都能用,很多饭店还有现金点菜机,替换这些机器的成本太高,并没什么动力可以把这些机器换成移动支付。同时也可以理解为什么 ApplePay 的方案是纯绑卡, 为什么一些产品不够本地化就无法推行。

在日本的时候正好 Google IO 大会在召开,公布唬人的 AI 帮你打电话预定功能,然后宣传称该 AI 在预定领域已可以通过图灵测试。同时我在日本使用 Google 翻译日文,发现 Google 把中文翻译成日文后,日本人很多情况下都看不懂翻译的结果。可能大公司要的是噱头可宣传的产品,而不是可能更有价值的对一个产品细细耕耘做到真正好用。

这次去对日本的兴趣更大一些,回来后看了些日本的资料,看起来日本不好的方面跟好的一样多,不好的主要是在日本工作生活才会体验到,像关系处理繁杂,极注重机器主义忽略个人,教条主义,歧视,失败容忍度低等,这些东西比国内的雾霾和高压难容忍多了,不知道真实普遍情况是不是确实这样。日本好的部分尽情开放给游客了,游客看到的是缺点少优点多的日本,难怪喜欢,有机会再去东京转转。

沟通杂想

2018-4-22 评论(2) 分类:随记

一个人做一个项目,效率是最高的,各模块间的接口,前后端联调,产品策略,视觉还原,灰度部署方案,运营方案,都在一个人脑里,各块以毫秒级速度进行沟通,瞬间能完成,这里的沟通成本是没有的。

一旦涉及到团队合作做一个项目,沟通成本就上来了,随着项目越来越大,分工越来越细,项目的沟通也细分了很多个层级,同个小团队间的沟通最快,然后是跨团队,跨部门,跨事业群,跨公司。而这里的沟通往往除了项目本身确定性的方案对齐外,更多的是其他额外的不确定因素,像任务排期(优先级不统一)、权力和意愿(不配合,层层批准)、信息不对称(不知道谁负责,不知道为什么这样做)、意见不统一等,导致沟通成本不可控,一个中大型公司很大一部分工作就花在研究如何减少沟通成本上。

技术层面上,接口封装就是减少沟通成本,省去不同模块的的开发者之间沟通细节的成本。全栈也是种减少沟通成本的方式,一个前端页面,是跟其他页面需要沟通协调的内容多,还是跟后端联调接口的沟通多?大部分情况是后者,所以如果前后端一个人做,可以省去这里的沟通成本。产品PRD/运营方案文档/统一的视觉规范等自然也是为了减少沟通而产生的。

非技术层面上,很多组织架构的调整都是在寻找减少沟通成本以提高效率,像腾讯早期各产品的交互和视觉设计由一个部门负责,其他产品团队以提需求的方式跟设计团队合作,好处是专业度高和风格统一,结果每个产品跨部门沟通成本太高,现在都改成各个产品线配自己的设计团队。对于大公司,目前看到的比较好的常见做法是,大型固定的业务成立部门,备齐所有工种人员,包括技术产品设计运营等,需求在部门内完成,减少跨部门沟通成本。各工种仍是独立自己的团队,比如技术团队/产品团队,保持自己的专业度,而做一个个具体项目时,通常需要各团队人员协作完成,可以各团队抽人组成虚拟组,配一号位人员总体负责,减少因为跨团队跨组带来的沟通成本。不过这个虚拟组和一号位人员得有组织上/实际行动保证才能起作用,否则真的是纯虚拟了,变成仍然是跨团队沟通。

一些公司的精英招聘策略也是能有效减少沟通成本,若一个人能力强工作效率高,产出能顶两个人,那实际上加上减少的沟通成本,带来的收益远不止两倍,而若招平庸或差一些的人,跟团队间沟通效率不匹配,带来的沟通成本上升效率下降也不止一个人力的范围内。一个组织大了就一定会有各种人相关的问题需要解决,精英小团队各种好,不好的是招聘困难,以及在铺业务时还是会面临人力不足问题导致扩招,难以控制。

对快应用的看法

2018-3-21 评论(8) 分类:互联网

国内厂商联合起来推出快应用,说说看法。

与小程序相同点

  1. 前端技术栈:毫无疑问所有类似方案都只能是前端技术栈,从社区成熟度,开发者接受程度,开发效率各方面没有对手。
  2. native 能力:都提供了比 web 更多的 native 能力。
  3. 即时/离线:跟 web 一样即点即用,跟 native 一样离线使用,前提是应用不复杂,体积限制在1M以内,当然以后复杂了也可以做分包。

与小程序的不同点

  1. native 渲染:快应用使用前端技术栈开发,native 渲染,性能体验会比较好,看代码挺像是直接拿 RN 改改用了,不过发布会上没提到 RN,而小程序目前是webview渲染。
  2. 自定义框架和规范:与小程序不同的开发框架和规范,快应用更像 vue 的写法,文件结构不一样,样式上因为使用native渲染,只支持 flexbox 布局,CSS 属性的支持程度上不如 webview 渲染的小程序,能力会弱一些。
  3. 系统级能力:目前看起来小程序没有的只有deeplink和push,通过url唤起快应用的deeplink,以及跟原生一样的push能力。

优势

  1. 流量:目前看起来,对开发者来说,使用快应用最大的理由就是厂商的流量扶持,而这是不是个优势还得看各厂商的扶持力度。
  2. 反垄断:小程序腾讯有绝对控制权,开发者把身家性命都放在腾讯的平台里,可能会导致任人宰割,自身对应用的控制力也弱,多一个渠道多一份活路。
  3. 其他:native渲染,deeplink入口,原生桌面入口,push能力这些目前相对小程序算是有一些优势。

劣势

  1. iPhone:联合再多的厂商,也联合不到苹果,中国高端手机市场 iPhone 份额高达85%,做快应用要不就是放弃这部分用户,要不就是针对 iPhone 再做一套,这个成本划不划算只能看能从厂商流量扶持里拿到多少好处,否则为什么不开发小程序。
  2. 跨公司合作:一个大公司内跨部门协作都困难,何况跨N个公司的合作,而且还没有一个站在上一层的领导者,要做成非常困难。
  3. 社交:快应用缺乏微信的社交场景能力和传播手段,推广拉新成本仍不低。

看法

移动开发向前端技术栈倾斜,原因:

  1. 超级APP,业务越来越多,为了减体积和动态发布能力,大部分业务使用前端技术栈开发。
  2. 普通APP,拉新成本高,用户装APP的意愿低,开始尝试转向即开即用的H5/小程序和类似平台拉新。

普通业务开发,按目前趋势越来越倾向前端技术栈,即使是独立APP,展示型业务在 APP 里也会倾向用前端技术栈开发,从开发效率/跨平台/动态性都很有优势,劣势是性能体验稍差,这点长期可以靠机器硬件的提升,短期可以用类似RN方案。

小程序为这样的需求提供了个很好的平台,但缺陷是开发者对应用没有控制力,无法 push 触达唤起用户,入口也一般,生命线掌握在腾讯上,快应用可以弥补这些缺陷,提供了另一个选择,不过不支持 iPhone 仍是个几乎无法解决的致命缺陷,加上上述提到的劣势,总体上不看好。这种事可能得由 google 联合苹果一起做才有戏。

native VS web 这个话题从 08/09 年开始开始到现在都没有结束,因为各有不小优势,即使是现在 web 技术栈占上风,原生 APP 的性能体验,快捷入口,品牌认知这些优势仍是不小,而且技术的发展同时给 native 和 web 两种模式提供了利好,并没有倾向其中一方:对于 web,硬件提升使得体验越来越好。对于 native,运营商无限流量的时代和越来越大的存储空间使得用户装 APP 成本下降,这两个开发模式在很长时间内仍是融合的状态。

北海道杂记

2018-2-25 评论(6) 分类:生活

过年前去日本北海道浪,说了三四年要去日本,这次终于成行了,第一次去日本,写篇体验杂记水文。作为一个从小受日本动漫和游戏熏陶的人,本来想去东京秋叶原这些地方,季节原因还是先去北海道转转。

北海道玩的就是雪和温泉,在登别玩白花花软绵绵厚厚的雪,走在洞爷湖边上纯白的湖畔小道,在札幌白色恋人公园体验大雪纷飞,确实都挺美的。北海道温泉特别多,连札幌市内的酒店都有温泉,不过还是登别的温泉最好,在室外天寒地冻边泡温泉边欣赏旁边雪景是挺不错的体验。不过温泉只能全裸不能穿泳衣导致必须男女分浴这点搞得挺没意思。
(更多…)

移动 APP 网络优化概述

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

一般开发一个 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 评论(7) 分类:生活

工作

公司

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

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

  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 越办越好。