目录
- 1. 前端故障演练的探索与实践
- 2. 前端智能化实践— P2C 从需求文档生成代码
- 3. 深入剖析海量数据场景下的用户行为分析方案
- 4. 钉钉表格,从零到一打造在线 Excel
- 5. 跨端的另一种思路
- 6. 如何建设灰度跨端监控
- 7. 10万级大型场馆背后的绘选座技术
1. 前端故障演练的探索与实践
前端可用性的困局:
对于发生在客户端上的问题,先天上存在感知相对弱一些的缺陷
- 架构复杂
- 端侧问题难感知
- 整体水位低
- 心智意识缺失(前端从业者对可用性的心智意识没能跟上前端领域自身的发展)
- 生态参与缺失(生态伙伴没能广泛的参与进来,大部分企业/开源社区的质量保障基础设施的建设热点与前端关联度不高)
- 常态化度量能力缺失(能让大家看清当前水位,形成推动力,促使去完善可用性的能力建设)
因此有了前端故障演练
混沌工程:
引述一位业界先驱的话,混沌工程是一种深思熟虑的,经过计划来揭露系统弱点的试验。
简单来说,就是将异常扰动注入已经呈现稳态的系统中,观测系统因此而产生的变化并作出对策,使今后系统面对同类异常扰动的变化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. 如何建设灰度跨端监控
如果一个问题完整上线才发现,会带来问题修复周期长和影响范围广的问题。要解决这些问题,需要在灰度发布过程来提前发现问题。
灰度监控挑战:
- 跨端容器(weex, 小程序等)怎么做灰度监控
- 灰度报警和普通报警怎么区分
- 灰度发布过程的监控,如何帮助业务更好定位问题
整体技术方案:
分为四个部分:
- 灰度发布:发布分为两种,一种是类似小程序这种,打包成zip包发布上线;一种是常规页面发布,静态资源发布到CDN
- 日志采集:页面运行过程需要采集监控的指标,比如js执行报错、接口异常等指标上报
- 数据处理:数据上报完成之后,需要对数据清洗和字段处理
- 灰度监控:基于处理后的数据结果,完成灰度监控的建设
灰度监控分为四个过程:
- 灰度发布,对于WEB、小程序、WEEX等灰度发布能力的覆盖
- 指标采集,浏览器采集通过读取模板变量的方式,容器采集通过读取
response header
信息获取灰度标识 - 监控指标,覆盖全链路监控指标,日志上报过程中携带灰度版本信息并转成规范日志格式
- 灰度应用,通过灰度发布的信息维度做日志分析,来打造灰度报警和灰度实时监控能力
7. 10万级大型场馆背后的绘选座技术
绘图编辑器,视图组件化结构化分层设计:
多座位绘制的批量操作:
批量座位变形:
选座问题:
业务属性的各种累加后,压力全集中到渲染性能
问题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