前言
看到同事在群里分享的一个技术小册 -- 阿里文娱 - 覆盖前端业务的大前端技术，抽空读了下，有些收获（个人向），算是读书笔记吧，做个分享。
因为有多个章节，下面就以技术章节作为本文行文的顺序
如何支撑营销活动？
为了解决活动页中重复劳动力开发的问题，大公司们都会有自己的一套「搭建」系统，让开发者更专注于组件的可复用、可配置。
具体「搭建」系统的架构设计，文章没有展开讲，更多的是讲要处理哪些细节：
- 埋点规范化：做过「搭建」系统的太清楚了，埋点不规范，DA两行泪
- scheme跳转及唤端统一化：活动页的展现方式可能在多个自家 app,微信，甚至是移动端浏览器，所以有必要做跳转的区分
- cms数据分发：这个说得有点高大上，不知道与普通的数据展示组件有何区别
- 组件原生渲染：为了媲美原生组件的性能，采用集团的 weex 框架，相比纯 h5 页面有更好的体验
- 多端搭建：利用 weex 的跨平台能力，加之样式响应式处理，实现组件多端复用
前端工程管理实践
项目之间技术方案各异，复用难，如何解决？
文中提到两点：
- 纵向：提供开发->发布一整套解决方案，包括：脚手架、物料平台、构建服务等，进行工程入口收敛和管控
- 横向：领域专项，比如：鉴权、埋点、监控、日志等
感觉和各大公司的工程管理实践差不多。不过文中有个感兴趣的点是「经验复用」这个，提到： 「将日常开发中错误进行收集，统一解答归类存档，构建错误知识库，下次从知识库中查找对应结果处理」
不清楚这个收集和归档是怎么处理的，感觉可能就是纯人力维护+wiki的形式？要是加入自动收集&ai问答，那就完美了。
优酷 Node.js 重构之路
最早：bigpipe+jq 的方案。
bigpipe 可能你没听过，其实就是将页面分为若干模块（需要进行标识），在服务端渲染之时异步填充到各个模块，能够让浏览器和服务器一起并发执行，快速展现核心模块。缺点可能就是模板编译带来的性能损耗较高？（我没用过）
当前：采用的是 React SSR 方案，并支持 CSR/SSR 一键切换。
有两个处理方式值得借鉴：
- 当服务端出现渲染压力时，进行 CSR 服务降级。此时服务端仅负责页面 SEO 数据获取
我理解应该是在输出 CSR 模板的基础上，把数据也插入 html 页面，这样相比原来的 CSR 方案，有更快的展现。
- 当数据源服务出现问题时，使用 CDN 数据兜底进行页面容灾，避免用户看到空白页面这样。
当然，还有一些细节有待研究，比如如何判断自动判断服务端出现渲染压力，如何自动切换等
未来：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 ，触发互动展示。
高并发下的服务端稳定性优化
感觉文章没发全？？没提优化策略就直接讲好处了。。
总结
文中提到的几个方向，无论是工程化、活动页搭建平台、近原生开发，都是时下前端的热点，要学的东西还好多呀。。
