第十五届D2前端技术论坛 笔记

目录

• 1. 前端故障演练的探索与实践
• 2. 前端智能化实践— P2C 从需求文档生成代码
• 3. 深入剖析海量数据场景下的用户行为分析方案
• 4. 钉钉表格，从零到一打造在线 Excel
• 5. 跨端的另一种思路
• 6. 如何建设灰度跨端监控
• 7. 10万级大型场馆背后的绘选座技术

1. 前端故障演练的探索与实践

前端故障演练的探索与实践 | D2分享视频+文章

前端可用性的困局：

对于发生在客户端上的问题，先天上存在感知相对弱一些的缺陷

• 架构复杂
• 端侧问题难感知
• 整体水位低
• 心智意识缺失（前端从业者对可用性的心智意识没能跟上前端领域自身的发展）
• 生态参与缺失（生态伙伴没能广泛的参与进来，大部分企业/开源社区的质量保障基础设施的建设热点与前端关联度不高）
• 常态化度量能力缺失（能让大家看清当前水位，形成推动力，促使去完善可用性的能力建设）

因此有了前端故障演练

混沌工程：

引述一位业界先驱的话，混沌工程是一种深思熟虑的，经过计划来揭露系统弱点的试验。

简单来说，就是将异常扰动注入已经呈现稳态的系统中，观测系统因此而产生的变化并作出对策，使今后系统面对同类异常扰动的变化delta在空间和时间维度上尽可能的小。

故障演练就是混沌工程的实现方式之一
故障演练可分为：

• 在岸持续可用
• 离岸持续可用
  
  
  红蓝对抗贼刺激！

2. 前端智能化实践— P2C 从需求文档生成代码

前端智能化实践— P2C 从需求文档生成代码 | D2 分享视频+文章

观后感： AI智能是未来的发展趋势，传统的前端，测试等职业会慢慢的消失。
还有，太牛b了。
啊啊啊！！。要努力，要加油，要变成大神，要保住饭碗！

3. 深入剖析海量数据场景下的用户行为分析方案

深入剖析海量数据场景下的用户行为分析方案 | D2 分享视频+文章
业界用户行为分析工具：

• Google Analytics
• Growing IO
• 神策数据

4. 钉钉表格，从零到一打造在线 Excel

钉钉表格，从零到一打造在线 Excel | D2 大会分享视频+文章

5. 跨端的另一种思路

跨端的另一种思路 | D2分享+文章
逻辑跨端

总结：

• Write Once 是一个理想目标，Write Logic Once 在部分场景下能更好的解决我们的问题。
• 介绍的方案仅适合重逻辑的场景，对于重 UI 表现场景不适用。我们需要根据场景做出对应的选择取舍。
• 对于写一份逻辑，无论是 Dart 还是 TS，仍然存在一定的抽象泄露问题，对于一些复杂问题的排查仍依赖开发者的经验

6. 如何建设灰度跨端监控

如何建设灰度跨端监控 | D2分享视频+文章

如果一个问题完整上线才发现，会带来问题修复周期长和影响范围广的问题。要解决这些问题，需要在灰度发布过程来提前发现问题。

灰度监控挑战：

• 跨端容器（weex, 小程序等）怎么做灰度监控
• 灰度报警和普通报警怎么区分
• 灰度发布过程的监控，如何帮助业务更好定位问题

整体技术方案：

分为四个部分：

• 灰度发布：发布分为两种，一种是类似小程序这种，打包成zip包发布上线；一种是常规页面发布，静态资源发布到CDN
• 日志采集：页面运行过程需要采集监控的指标，比如js执行报错、接口异常等指标上报
• 数据处理：数据上报完成之后，需要对数据清洗和字段处理
• 灰度监控：基于处理后的数据结果，完成灰度监控的建设

灰度监控分为四个过程：

• 灰度发布，对于WEB、小程序、WEEX等灰度发布能力的覆盖
• 指标采集，浏览器采集通过读取模板变量的方式，容器采集通过读取response header信息获取灰度标识
• 监控指标，覆盖全链路监控指标，日志上报过程中携带灰度版本信息并转成规范日志格式
• 灰度应用，通过灰度发布的信息维度做日志分析，来打造灰度报警和灰度实时监控能力
  

7. 10万级大型场馆背后的绘选座技术

10万级大型场馆背后的绘选座技术 | D2分享视频+文章

绘图编辑器，视图组件化结构化分层设计：

多座位绘制的批量操作：

批量座位变形：

选座问题：

业务属性的各种累加后，压力全集中到渲染性能

问题1：
10万的信息一次全量请求不现实，如何作分离？
解决方法：
对数据本身做一个区分，静态的座位信息（位置，楼层区域，票档信息）和动态的属性标签信息（售卖状态，加锁状态，保留状态）
静态信息可以做本地缓存，动态信息可以实时更新。

问题2：
信息要加密，体积不能太大，传输速度要快
解决方法：
使用结构化数据Protocol Buffer替代传统Json

当数据来到前端时，我们的操作事件不是直接作用在视图上的，中间会有一层DataProxy的设计。
目的是为了把我们业务属性的数据和分层结构，组件插件的能力解耦掉(不再关心业务上的差异，语言框架React还是Vue的问题，对未来能力迁移和复用，更加有益)。
因为底层的原子能力都是原生JS和Canvas。

渲染性能问题：

三个重要的突破口：

• 优化底层的原子组件和插件本身
• Service Worker
  当同步加载一个焦点看台周边的多个看台时，因为线程池能力的丰富，可以同步对数据的请求加载、座位初始化带来大幅的性能提升。
• 加载后的东西我们全部 Cache住，性能瓶颈的突破，也让我们对已加载过的区域不再需要重绘。

首次加载环节，多座位渲染：

• Canvas对CPU的压力。即便Chrome会自动开启少量的GPU加速
• Canvas画布尺寸的上限
  对整个画布做Grid块级的切分（分区加载）

未来展望：

• 智能
• VR： WebXR
• WebGL： Canvas 2d
• 。。。
  WebAssembly