通读「阿里文娱 - 覆盖前端业务的大前端技术」

前言

看到同事在群里分享的一个技术小册 -- 阿里文娱 - 覆盖前端业务的大前端技术，抽空读了下，有些收获（我的向），算是读书笔记吧，作个分享。

由于有多个章节，下面就以技术章节做为本文行文的顺序

如何支撑营销活动？

为了解决活动页中重复劳动力开发的问题，大公司们都会有本身的一套「搭建」系统，让开发者更专一于组件的可复用、可配置。

具体「搭建」系统的架构设计，文章没有展开讲，更多的是讲要处理哪些细节：

1. 埋点规范化：作过「搭建」系统的太清楚了，埋点不规范，DA两行泪
2. scheme跳转及唤端统一化：活动页的展示方式可能在多个自家 app,微信，甚至是移动端浏览器，因此有必要作跳转的区分
3. cms数据分发：这个说得有点高大上，不知道与普通的数据展现组件有何区别
4. 组件原生渲染：为了媲美原生组件的性能，采用集团的 weex 框架，相比纯 h5 页面有更好的体验
5. 多端搭建：利用 weex 的跨平台能力，加之样式响应式处理，实现组件多端复用

前端工程管理实践

项目之间技术方案各异，复用难，如何解决？

文中提到两点：

• 纵向：提供开发->发布一整套解决方案，包括：脚手架、物料平台、构建服务等，进行工程入口收敛和管控
• 横向：领域专项，好比：鉴权、埋点、监控、日志等

感受和各大公司的工程管理实践差很少。不过文中有个感兴趣的点是「经验复用」这个，提到： 「将平常开发中错误进行收集，统一解答归类存档，构建错误知识库，下次从知识库中查找对应结果处理」

不清楚这个收集和归档是怎么处理的，感受可能就是纯人力维护+wiki的形式？要是加入自动收集&ai问答，那就完美了。

优酷 Node.js 重构之路

最先：bigpipe+jq 的方案。

bigpipe 可能你没听过，其实就是将页面分为若干模块（须要进行标识），在服务端渲染之时异步填充到各个模块，可以让浏览器和服务器一块儿并发执行，快速展示核心模块。缺点可能就是模板编译带来的性能损耗较高？（我没用过）

当前：采用的是 React SSR 方案，并支持 CSR/SSR 一键切换。

有两个处理方式值得借鉴：

1. 当服务端出现渲染压力时，进行 CSR 服务降级。此时服务端仅负责页面 SEO 数据获取

我理解应该是在输出 CSR 模板的基础上，把数据也插入 html 页面，这样相比原来的 CSR 方案，有更快的展示。

2. 当数据源服务出现问题时，使用 CDN 数据兜底进行页面容灾，避免用户看到空白页面这样。

固然，还有一些细节有待研究，好比如何判断自动判断服务端出现渲染压力，如何自动切换等

将来：Serverless SSR

React SSR 方案是依赖于 Node.js Web 应用的，那必然须要关心服务和运维。

而在 Serverless 时代，基于 FaaS （函数即服务）进行 API 开发是很简单的，那如何加入 SSR 能力呢？

正如 Umi SSR 等框架让开发者再也不须要关心 webpack 同样，当咱们继续对 node 框架进行定制后，就再也不须要关注 node 服务的细节，仅须要编写 React 代码了。

OTT 端登陆态设备穿透：扫码登陆与反登陆

这部分内容比较有收获的是第一次据说「扫码反登陆」这个应用场景。（多是由于我没用过电视盒子吧。。

什么是「扫码反登陆」？就是在 ott 端登陆的状况下，出现一个二维码，此时手机扫码，手机将同步 ott 帐号登陆态，接下来就能够在手机上进行该帐户的一些操做了，好比开通会员（由于 ott 端通常不会有支付软件只能在手机上进行支付）等。

具体的技术方案，和扫码正登陆有点相似。过程以下

1. 在 ott 端，携带 token 发起请求获取惟一标识值 authCode （随机生成，由 Redis 维护，关联 token），并返回「登陆验证二维码」url

   这个感受也能够写死，由服务端返回多是更加可控，防止服务挂了能够动态更换，而写死的话还得用户更新 ott 版本

2. 将 authCode 拼接在 url （获得 newUrl）后并生成二维码
3. 手机端进行扫码，即请求 newUrl ，此时将去服务端进行验证 authCode ，验证经过将返回 token
4. 还能够再加入重定向的页面（好比会员购买页）放入 url 后，手机扫码登陆成功后重定向到相应页面
5. 还可让 authCode 加入「消费」字段，ott 端进行轮询，在手机登陆成功后自动关闭二维码页面

小而美的 egg-react-ssr 开源实现方案

项目地址

文章的内容差很少就是该项目的 README ，能够直接点击查看。

印象比较深的是里面提到该方案相比 Next.js 的代码非黑盒，有空的话能够看下实现。

双 11 猫晚互动前端容器化之路

组件化平台差别的处理

组件适配平台仍是平台适配组件？能够这样处理：

1. 组件较多而平台较少时能够由平台进行适配
2. 平台适配较难或者差别难以抹平则由组件适配
3. 尽可能让平台进行适配，减小新组件适配劳动力

容器化

基于 Weex 的原生渲染和拓展能力实现热更和高性能。具体我没用过这个框架，就不展开讲了。

互动游戏秒开优化

秒开优化对于 h5 开发的同窗来讲应该是老生常谈了。

由于没有玩过双 11 的互动游戏，不太理解文章里面讲的「选队结束」->「游戏开始」阶段，看上去的优化策略应该就是预加载

互动与视频对齐

首先有个共识，网络情况不一样，同一时刻每一个用户看到的画面是不一样的。

而互动信号是，主持人说出「开始」时，界面产生互动。

一般的实现方案是二者分离，直播是直播，互动是互动，互动由另外的接口下发通知。

可是这样可能会形成，用户网络较慢，还没听到直播中主持人喊出「开始」口号，界面互动就开始了，这样会缺乏一点现场感。

解决方案能够从视频编解码入手。

咱们知道，视频编码中 SEI (附加增长信息) 能够带上自定义数据，那么只须要再主持人喊开始时，将互动信号经过 SEI 编入视频流中，这样用户看到相应画面时，正好解到相应的 SEI ，触发互动展现。

高并发下的服务端稳定性优化

感受文章没发全？？没提优化策略就直接讲好处了。。

总结

文中提到的几个方向，不管是工程化、活动页搭建平台、近原生开发，都是时下前端的热点，要学的东西还好多呀。。