2021 GIAC 大前端专场思考总结(上篇)

·  阅读 680

持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第 26 天,点击查看活动详情

这是去年我有幸参与 GIAC 全球互联网架构大会大前端专场的一些零散的思考与总结。可能不是很系统,尽可能表达出我自己的思考,希望也能对大家有一些帮助。

从第一性原理解读前端设计

主讲人:

淘系技术部前端工程师:林阳(連山),2014年上线个人第一个开源框架 IOING,2018年加入阿里,重点参与前端智能化相关工程,期间输出 2 个开源项目,3 份技术专利。

什么是第一性原理

事物(系统)本质的源头,比如下图中一团乱麻的绳子,它的第一性原理就是它的起点。

第一性原理有如下的特点:

  1. 任何系统都有自己的“第一性原理”

  2. “第一性原理”是一种演绎法思维

  3. 从本质出发,逻辑推理的根基

  4. 事物的本体、本质、本性

  5. 理念论、简一性

事物的第一性可能是随着外界条件变化而变化的。比如一个公司不同时间段内的有不同的第一战略目标。第一性原理可以帮助跨越非连续性。

第一性原理如何拆解?

要确定两个关键要素:“目的”和“实现目的的途径”。从目标出发,寻找实现目的的方式。

思考:业务需求中,第一性原理应该是该需求的痛点和目标。开发过程中,遇到问题,应该使用演绎法推断该问题的“第一性原理”——根源问题,从根源问题分析得出方案。

前端如何使用第一性原理

第一性原理与编程

开闭原则是第一性原则,原有其他的开发职责都应该基于开闭原则。

开闭原则 (The Open/Closed Principle, OCP) 规定“软件中的对象(类,模块,函数等等)应该对于扩展是开放的,但是对于修改是封闭的

JS运行时安全案例

背景:淘宝很多页面由入驻方提供,那如何保证对方的代码是否安全?比如我不希望第三方网页获取 Cookie。我们应该怎么限制他们的能力?

问题:如何限制?在编译的时候去除?还是运行时的限制?最后的方法是运行时限制。比如小程序中直接使用容器的方案,就是容器提供什么能力,用户只能使用这些能力

解决方法一:将不安全变量覆盖? 比如,在系统中禁止弹窗 alert。禁止获取cookie 等等。但缺点很明显——无法枚举完所有的黑名单

找到问题第一性原理

浏览器的安全策略是什么?比如:

  • 同源策略

  • 沙箱机制

知道第一性原理,该怎么做?

具体的解决方法

iframe 中有一个属性,称为 sandbox。可以控制嵌入网页的权限。将第三方代码放在这个设置了 sanbox 属性的 iframe 中,等同于提供了一个隔离层,即“沙箱”

嵌入的网页默认具有正常权限,比如执行脚本、提交表单、弹出窗口等。如果嵌入的网页是其他网站的页面,你不了解对方会执行什么操作,因此就存在安全风险。为了限制 <iframe> 的风险,HTML 提供了sandbox属性,允许设置嵌入的网页的权限,等同于提供了一个隔离层,即“沙箱”。

假如第三方一定要用到类似弹窗的能力,会对外提供,但会做一定的封装,比如统计、判断有没风险等。

但是暴露出来的 API 是存在传入⻛险。外部传入 Object 对象,通过原型链找到内部的 constructor,可以通过 call 的方式调用方法,这个时候它的上下文就是外部的上下文,就可能存在风险。

那么我们如何解决这个问题?通过 Proxy 监听和控制,所有的访问和设置都需要经过代理,在代理过程中,我们会将对象进行序列化,所以最后沙箱内部获取到的是序列化的内容,序列后之后就是安全的。

对于 DOM 节点的操作,也可以通过 Proxy 去解决。比如调用 document.creatElement 的时候,只能创建白名单中的一些 tag

其他对 DOM 操作的限制,比如点击事件 onClick,我们需要将事件本身等信息外传,就会存在安全问题。跟上面的类似,当传入处理器函数的时候,将它序列化,最后执行。实现一个 Observe 函数,监听回传给处理器的信息,在这个过程中进行序列化和鉴权操作。

以上整体流程如下所示:

智能化出码部分案例解读

要解决的问题:效率问题。其中沟通和编码占用了大部分的时间。如下:

我们的目标是两个重要的步骤,将视觉转换成布局 HTML + CSS 的代码。将 PRD 转换成逻辑 JavaScript 代码。

其中沟通和编码中间需要一个对等协议要完成对接。但是自然语言和程序是有歧义的,自然语言是非结构化的,而编程语言是结构化的。为了消除歧义,需要做到以下几点:

  • 结构化收集
  • 统一表协议
  • 限制信息范围

如何找到对等协议,以下有两种途径去做:

  • 通过对现有工作的统计和归纳从而得出要素结论。根据现在的代码去总结归纳常用的跟 PRD 哪些是相关性的。
  • 演绎法思维。

小结

第一性原理不仅仅跟编程相关,而是一种思维方式,能够帮助我们更好的解决遇到的问题。第一性原理的概念是抽象的,作者花了很多时间解释第一性原理,也从 JS 安全策略和智能化出码两个实例讲解,深入浅出。

哈啰出行在Flutter上的探索与实践

主讲人:

陈小辉。2020年8月加入哈啰出行,哈啰大前端技术委员会负责人&普惠用车大前端负责人,业务方面主要负责四轮相关顺风车、打车、车主服务等业务研发管理工作,致力于推进哈啰大前端技术架构向跨端端容器方向演进,目前主要聚焦在大前端工程化,多端渲染容器,大前端高可用体系,业务架构治理等方面。

基础架构

在端容器方面上进行探索,目标是

  • 标准化。将容器更加标准化,不管是哪个方案,主要采取一个标准,就能很快迁移
  • 容器化
  • 动态化。业务变化快,发版较快

能力层: 将底层能力通用化,给容器层提供能力,不管容器是什么,都可以使用 容器层:对容器的探索,适配统一化 业务层:支持不同的业务形态

flutter 使用,绿色模块就是要建设内容,比如研发工具、稳定性监控等。

两端变一端,时间可能会变多,但个人感觉从长远的角度讲,还是很有意义的

flutter 生态的探讨

端侧技术比较

  • 性能上。flutter 和原生还是有所差异。在单页面应用上,差别不大。一些页面的跳转、动画的需求上会略低于原生
  • 发布效率。flutter 没有很大优势。不能动态发布
  • 一致性
  • 研发效率。需要考虑一些基建等
  • 生态。目前是硬伤,急需改善

总结如下:
Flutter优势 :

  • Skia引擎,强一致性
  • 接近Native性能体验
  • iOS和Android双端研发效率

Flutter不足:

  • 生态不完善
  • 整体框架在进化过程中
  • 缺少动态性

Flutter动态化的实践

基本原理

现在业内有如下的几个方案:

  • 类似 RN。通过 JavaScript 的能力去隐射 flutter 组件去渲染
  • DSL + Runtime
  • 编译产物下发

目前哈啰出行采取的是第二种方案,大致流程:源码转成AST,再将 AST 转换成 JSON,打包,下发到端,解包,解释执行

这种方案存在以下的问题,目前只在一些PV量较少的简单页面上试用

  • 需要实现的语法元素比较多
  • 符号表和Flutter版本存在相关性
分类:
前端
分类:
前端
收藏成功!
已添加到「」, 点击更改