通读「阿里文娱 - 覆盖前端业务的大前端技术」
# 前言
看到同事在群里分享的一个技术小册 -- 阿里文娱 - 覆盖前端业务的大前端技术 (opens new window)，抽空读了下，有些收获（个人向），算是读书笔记吧，做个分享。
因为有多个章节，下面就以技术章节作为本文行文的顺序
# 如何支撑营销活动？
为了解决活动页中重复劳动力开发的问题，大公司们都会有自己的一套「搭建」系统，让开发者更专注于组件的可复用、可配置。
具体「搭建」系统的架构设计，文章没有展开讲，更多的是讲要处理哪些细节：
- 埋点规范化：做过「搭建」系统的太清楚了，埋点不规范，DA两行泪
- scheme跳转及唤端统一化：活动页的展现方式可能在多个自家 app,微信，甚至是移动端浏览器，所以有必要做跳转的区分
- cms数据分发：这个说得有点高大上，不知道与普通的数据展示组件有何区别
- 组件原生渲染：为了媲美原生组件的性能，采用集团的 weex 框架，相比纯 h5 页面有更好的体验
- 多端搭建：利用 weex 的跨平台能力，加之样式响应式处理，实现组件多端复用
# 前端工程管理实践
项目之间技术方案各异，复用难，如何解决？
文中提到两点：
- 纵向：提供开发->发布一整套解决方案，包括：脚手架、物料平台、构建服务等，进行工程入口收敛和管控
- 横向：领域专项，比如：鉴权、埋点、监控、日志等
感觉和各大公司的工程管理实践差不多。不过文中有个感兴趣的点是「经验复用」这个，提到： 「将日常开发中错误进行收集，统一解答归类存档，构建错误知识库，下次从知识库中查找对应结果处理」
不清楚这个收集和归档是怎么处理的，感觉可能就是纯人力维护+wiki的形式？要是加入自动收集&ai问答，那就完美了。
# 优酷 Node.js 重构之路
# 最早：bigpipe+jq 的方案。
bigpipe 可能你没听过，其实就是将页面分为若干模块（需要进行标识），在服务端渲染之时异步填充到各个模块，能够让浏览器和服务器一起并发执行，快速展现核心模块。缺点可能就是模板编译带来的性能损耗较高？（我没用过）
# 当前：采用的是 React SSR 方案，并支持 CSR/SSR 一键切换。
有两个处理方式值得借鉴：
- 当服务端出现渲染压力时，进行 CSR 服务降级。此时服务端仅负责页面 SEO 数据获取
我理解应该是在输出 CSR 模板的基础上，把数据也插入 html 页面，这样相比原来的 CSR 方案，有更快的展现。
- 当数据源服务出现问题时，使用 CDN 数据兜底进行页面容灾，避免用户看到空白页面这样。
当然，还有一些细节有待研究，比如
- 如何判断服务端出现渲染压力，进行自动切换
- qps 其实并没有降，只是减少了模板解析的压力，这样能提高多少，还是说接口不走 node 层
# 未来：Serverless SSR
React SSR 方案是依赖于 Node.js Web 应用的，那必然需要关心服务和运维。
而在 Serverless 时代，基于 FaaS （函数即服务）进行 API 开发是很简单的，那如何加入 SSR 能力呢？
正如 Umi SSR 等框架让开发者不再需要关心 webpack 一样，当我们继续对 node 框架进行定制后，就不再需要关注 node 服务的细节，仅需要编写 React 代码了。
# OTT 端登录态设备穿透：扫码登录与反登录
这部份内容比较有收获的是第一次听说「扫码反登录」这个应用场景。（可能是因为我没用过电视盒子吧。。
什么是「扫码反登录」？就是在 ott 端登录的情况下，出现一个二维码，此时手机扫码，手机将同步 ott 账号登录态，接下来就可以在手机上进行该账户的一些操作了，比如开通会员（因为 ott 端一般不会有支付软件只能在手机上进行支付）等。
具体的技术方案，和扫码正登录有点类似。过程如下
- 在 ott 端，携带 token 发起请求获取唯一标识值 authCode （随机生成，由 Redis 维护，关联 token），并返回「登录验证二维码」url
这个感觉也可以写死，由服务端返回可能是更加可控，防止服务挂了可以动态更换，而写死的话还得用户更新 ott 版本
- 将 authCode 拼接在 url （得到 newUrl）后并生成二维码
- 手机端进行扫码，即请求 newUrl ，此时将去服务端进行验证 authCode ，验证通过将返回 token
- 还可以再加入重定向的页面（比如会员购买页）放入 url 后，手机扫码登录成功后重定向到相应页面
- 还可以让 authCode 加入「消费」字段，ott 端进行轮询，在手机登录成功后自动关闭二维码页面
# 小而美的 egg-react-ssr 开源实现方案
文章的内容差不多就是该项目的 README ，可以直接点击查看。
印象比较深的是里面提到该方案相比 Next.js 的代码非黑盒，有空的话可以看下实现。
# 双 11 猫晚互动前端容器化之路
# 组件化平台差异的处理
组件适配平台还是平台适配组件？可以这样处理：
- 组件较多而平台较少时可以由平台进行适配
- 平台适配较难或者差异难以抹平则由组件适配
- 尽量让平台进行适配，减少新组件适配劳动力
# 容器化
基于 Weex 的原生渲染和拓展能力实现热更和高性能。具体我没用过这个框架，就不展开讲了。
# 互动游戏秒开优化
秒开优化对于 h5 开发的同学来说应该是老生常谈了。
因为没有玩过双 11 的互动游戏，不太理解文章里面讲的「选队结束」->「游戏开始」阶段，看上去的优化策略应该就是预加载
# 互动与视频对齐
首先有个共识，网络状况不同，同一时刻每个用户看到的画面是不同的。
而互动信号是，主持人说出「开始」时，界面产生互动。
通常的实现方案是两者分离，直播是直播，互动是互动，互动由另外的接口下发通知。
但是这样可能会造成，用户网络较慢，还没听到直播中主持人喊出「开始」口号，界面互动就开始了，这样会缺少一点现场感。
解决方案可以从视频编解码入手。
我们知道，视频编码中 SEI (附加增加信息) 可以带上自定义数据，那么只需要再主持人喊开始时，将互动信号通过 SEI 编入视频流中，这样用户看到相应画面时，正好解到相应的 SEI ，触发互动展示。
# 高并发下的服务端稳定性优化
感觉文章没发全？？没提优化策略就直接讲好处了。。
# 总结
文中提到的几个方向，无论是工程化、活动页搭建平台、近原生开发，都是时下前端的热点，要学的东西还好多呀。。