视频相关

编解码格式

AVC: H.264/AVC，H264 目前已经可以在各种web浏览器、客户端等进行解码播放，如常见的 .mp4、.mov 封装格式的视频。

HEVC: H.265/HEVC，H265目前还没有得到大部分浏览器的支持，没法直接在 web 端播放。

常见的 mp4、mov、flv、mov、mkv、avi 这些封装格式，可以理解为一个箱子，箱子里可以用来放视频的画面、声音、媒体信息和帧，等到播放的时候，软件会用正确的打开方式来打开这个视频，H264（视频压缩） + AAC（音频压缩）封装为FLV或MP4是最为流行的模式。

由于存在将其他文件改变后缀的行为，因此视频真正的压缩算法，需要从 medioinfo 中获取，在网页端中，它将被作为一个 wasm 加载，用于解析视频。

视频抽帧相关：一般在浏览器中，可以被原生浏览器播放的视频，可以通过 video 与 canvas 截取视频帧后上传，不过这种做法相对于封装好的 wasm 文件直接抽帧，速度要慢上不少，估计在20-30% 不等，同时 wasm 一般支持绝大多数格式视频，因此建议全程使用 wasm 来获取视频帧

关于字幕

SRT

是简单的纯文本字幕，无法使用其他高级功能如特效字体。

ASS

属于高级字幕，可以制作出华丽的特效字幕。

WebVTT

是网页中的字幕，可以在 html5 中，可以通过元素来加载额外的文字轨资源，目前处于草案阶段，但已被多数浏览器支持，早期版本是基于 srt 字幕的，在 2011 年改名为 WebVTT，与 srt 字幕格式非常相似。

1
2
3

<video controls src="video.mp4">
    <track default src="track.vtt">
</video>

vite

当前项目开发与打包都是通过 webpack 进行，在 dev 模式下构建速度需要 39s 接近 40s，热更新反应同样较慢，考虑将开发模式使用 vite 构建。优化后打包速度在 500ms，页面初始化缓存需要 5s。

VSCODE 插件

前言

1. 来到这里后，发现这边项目是 ts 项目，但对于请求接口的入参出参，都没有很好类型定义，考虑将内部平台的接口类型通过 vscode 插件直接导入。
2. 项目主要场景为国际化场景，但是各国语言翻译都是在 excel 中进行，开发手动复制各个语言文本，粘贴到项目中，效率低下且容易出错，考虑使用 vscode 插件解析 excel 后将翻译结果导入项目的语言文件中。

开始

2022

一直没来得及写这篇文章，2022 的现状，其实有很多感概。

起初在有赞年会的时候第一次听到降本提效，2022 公司主题是人员优化，本以为年初的大裁员已经算是基本解决了这个问题，后来才发现原来只是开始，只是时候未到。三月中的时候，还在和大哥们开玩笑说最近不太忙是不是要被优化了，结果三月底的时候领了毕业名额，同组大哥们也结伴相行，前端组分崩离析，事实证明忙也会被优化。

毕业后一开始没什么紧张感，只是对这半年有些留恋，每个大哥都很有实力，各自有不同领域的专业知识，部分是开源项目的 Core contributors，我作为组内经验最少的，来这里学到了太多，感谢每一个大哥的指导，希望将来还能再会~

清明之后开始了穿插着放松与复习，到四月中的时候开始投递简历，陆陆续续收到一些小公司 offer，但和个人期望差距较远，期间面试了一下字节，可能是眼缘不佳，老板面没有通过，再一次失之交臂。今年形势确实很不好，相当多的公司到了 hr 面就没有后续了，到了后面实际上已经对面试产生厌恶，最后在五月中下的时候决定了入职的公司，确实感觉 gap 久了，心里会焦虑，所以该上班了。

来到这里，第一想法是，原来已经失去了之前那么多的前端基建，这里更像是一片荒芜，没有自己的组件库，没有针对开发的提效工具，只有基础的 CI/CD，许多东西没有形成规范，甚至包括会议、评审。少了复杂的内部平台，反而有点不适应，这个阶段来到这里更像是对我的考验，我能做出多少对团队有价值的产出。

这里的业务排期很满，但是想要产出，必然需要很强的自驱力，这大概是我现在最需要的。今年还想参与一下开源社区，接触一下更多厉害的人。

除了这些，同样的，这里的年度主题也是降本增效，要保持随时被毕业的觉悟吧，希望一切安好。

Go 语言

最近春节期间开始学习 Go 语言，前端的语言不再只是 JS 了，Rust、Go 都在发光发热，Go 更贴近于 VSCODE 这个编辑器，那么就从 Go 开始吧。

不从零计算机基础开始写，仅仅记录与 JS 的不同之处，并类比 TS。

与 JS 不同的地方

数据类型

基本数据类型

数值型：int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64, byte, float32, float64

int8 是 [-128, -127] 之后的以此类推，2^7 作为值，首位作为符号位

uint8 是 [0, 255] 之后的以此类推，无符号位

字符型：没有专门的字符型，使用 byte 来保存

布尔型

字符串

派生/复杂数据类型

数组：相当于元组类型，定义了长度之后不可以更改

1

var intArr [3]int = [...]int{1, 2, 3}

切片：相当于数组类型，长度不定

1
2
3

slice := intArr[1:3] // [1, 2] 从上面的 intArr 中的第二个元素开始，截取到第四个元素之前作为切片元素
len(slice) // 2 长度
cap(slice) // 4 容量，go 自动调整，不一定是双倍

近期问题

我们的 .lock 文件，每次生成的时候 integrity 属性，会有一串 sha1 加密的内容，当这个包下次更新版本的时候，会通过这个加密值，查看要更新的版本是否为这个包的后续版本，如果不是，就报下包失败 404，因为找不到你这个包的后续版本了，这种情况可能出现在，你对 A 仓库发布了一个新版本1.0.0，并且在你的另一个 B 仓库中使用这个版本，此时你发现之前的发布还有点问题，需要回退，于是把之前 A 仓库的发布 unpublish 掉，之后再重新发布一个 1.0.0，此时生成的加密值就不一样了。如果后续 A 仓库发布了 1.0.1，B 仓库想升级了，但是由于前后两个 1.0.0 的加密值不一样，之前的 1.0.0 版本没有后续版本（实际上这个 1.0.0 版本不存在 npm 私服中了）了，因此报错，需要把这个对应的加密值改掉才能正常下载，否则这个正确的包下的任何版本都无法下载。

最近新入职的公司里有一个中台化的概念，大概需要投入一定的人力成本才能做这件事，所以比较小的公司应该见不到这个。

中台化

举个例子，正常我们写 vue 页面的时候，可能定义一下 component，route，然后把这两者做一个映射，到路由表里就好了，页面就能够正常启动，一切正常。但是现在想想，这时候如果我们有很多很多页面，并且有多个项目，可能也有很多很多人，然后页面里可能有些方法，有些属性，或者是一些组件，甚至是页面，大家都一遍又一遍地些，其实是可以复用地。这时候我们还是把这些可复用的东西一股脑的从私有的 npm 库里下载，塞到当前项目下的 component、util、page 下吗。

这时候可能就需要一个中台化的概念，我们把属性、方法、组件、页面都使用一种统一的方式引入，而这种方式的内部逻辑，就交给中台处理，中台给予你一个工具，让你决定复用哪些东西。你发的每个包都会被中台接受，并在对应的 gitlab 里建立一个仓库，之后会自动部署到 npm 私有库上，并与之关联，在你打包的时候，会自动从远端仓库拉取一个 temp 文件，包含你选择的复用内容及其关联文件，之后就可以复用逻辑了，你在页面里直接使用，引入复用内容的逻辑，全都交给中台。自此，每个组件都变成可以复用的状态了，因此可以通过一个外层容器，把所有组件关联到这个容器内，通过摆放组件，对应生成一个新的路由页面，完成逻辑复用。

面试总结

​ 近期从前公司离职后，安排了相当多的面试，其实目的还是想寻找一个人来打破现有状态的点，毕竟面试你的人一般情况下会比你强上很多很多，尤其是 cto 面，或者业务线负责人面试。

​ 大部分面试我的人和我职级相差过大的时候，我都反问了几个问题，比如写博客的投入产出比不高的问题，虽然每天都有部分产出，看似 github 上每天都是绿的，并且博客也在持续更新，但更像是一种自我安慰，我也知道这方面的事情，但一直没有做一个自我打破，但我觉得现在可能是时候了。

​ 目前一个相对来说普遍的情况是数据结构方面的问题，比如给予一棵树，但不是二叉树结构，这样的算法题方面我没有很好的一些思路，即使它很简单。

​ 技术还是需要业务驱动的，不妨深入某一个技术，并用这个技术做了些什么有深度的东西，然后再把它整理成一篇博客，这才是比较有价值的博客，目前这里的博客形式类似于一种知识的整理，而不是对自我的知识深度探索。

​ 未来一年计划：业务驱动，深入技术。

​ 那么本次面试也差不多尘埃落定了。

2021 前端面经

记得清的大概就这些，相对小的公司暂时就不放了。

其实面试也是一个交流的过程，而且从中可以了解到一些自己可能不太理解的点点滴滴，个人还是比较喜欢面试或者被面试的，虽然结果可能不太好。

webpack5

重新整理一下 webpack 知识，内容过多，了解功能即可，遇到 api 查文档。