我是如何用技术开导妹子的-CSDN博客

前言

你见过凌晨4点的洛杉矶吗？

那，你见过凌晨2点的外滩吗？

1. 第二次相遇

那天加班到凌晨1点，顺道着去找了酒喝。不是酒鬼，只是爱喝，和女人都喜欢逛街一样，我只是喜欢喝酒而已。快喝跪的时候，掏出手机打车。

车经过外白渡桥那条路线，我分明看见有个妹纸站在桥上。虽然也就4、5米，肯定不会si，可妹纸在哭哇！

故事开始了。 因为那个妹纸我认识，前不久我招进来的小姑娘，24岁。可能是喝了酒的缘故，我叫停了出租车。好吧，我觉得我真的像酒鬼。

她像受惊的兔子一样，尖叫的声音差点就让我酒醒了。

“嗯。不错，有正常反应。咋地，不适应加班了？”

妹纸点点头，吓得没敢回话。我看懂了，那眼神分明是提防我的眼神。也是，谁会相信我是偶然？

“活不会干？”

“不是。”

“压力大？”

“有一点。”

“不是吧？就那点lowB需求，就压力大了？”

“不，不是……”

“失恋了？”

“嗯。”

气氛戛然而止。 我忽然反应过来，我好像在插手别人的生活。长到这把年纪，已经懂得不要轻易进入别人世界的道理。桥上风冷，我的酒意也消散了大半。

“是不是你写的那个活动页有点卡？”

我认真看着妹纸的眼睛，没回话，双眼却闪过一丝紧张还有一点点……

厌恶。 是的，任何人被当面点出不足之处，都会有厌恶的情绪。妹纸应该还知道，我已经看过她写的代码，code review不是说说而已。

“今天你尝试一下把计算红包位置的margin换成transform试试。”

“噢。margin换成transform有什么好处？它们不都是css属性吗？”

我又盯着妹纸看了两眼。年轻就是好啊！前几分钟还那么悲伤，现在就能正常交流沟通了。她大概是看不到我眼底刹那间闪过的一丝异样。

“浏览器的主线程与合成线程调度了解过吗？一般来说，主线程主要负责运行 JavaScript，计算 CSS 样式，元素布局，然后交给合成线程。合成线程主要负责绘制，当使用width、height、margin、padding 等作为 transition 值时，会让主线程压力很大。此时我们可以使用 transform 来代替直接设置 margin 等操作。”

其实我内心是不忍心的。一个新来的妹纸就要负责活动页面的编写任务，我这老油条像极了爱欺负新兵的老兵。

“可是活动页白屏时间也挺长的，总感觉要白屏1秒才出来。”

这不废话，活动页布局辣么负责，这妹纸又是等接口数据返回以后才开始渲染数据。

“你有没有试过给你的动画加入一个渐入的效果？”

“这点我想过。可是动画做再好也没办法改变白屏时间啊！”

气氛再次戛然而止。 请问，我是招进来一个多么菜的童鞋？接着酒劲，我张开了嘴最终还是没说出口。我心里在想，难道我当初是猪油蒙了心，看上人家了？我再仔细盯了盯妹纸的脸。不对啊！这明显没有心动的感觉啊！

“喂！喂！别用那种很嫌弃的眼神看着我。毕竟我的薪水才那么一点，菜一点又怎么了？！”

理直气壮。嗯，真的是理直气壮！

2. 第三次相遇

那晚，我还是没忍住传授了很多前端知识给她。做code review的时候代码明显好了许多。其实把这故事讲给人听，人肯定不信。

谁会在一妹纸哭泣的时候，给人讲技术的？其实我对妹纸要求不怎么高，code review也只是保证她的代码能被别人轻易看懂，至少在代码层面的性能优化要做得好。

618那天晚上，忙疯了。妹纸的活动页在那天也经住了考验。我夸完了妹纸后就去找地儿喝酒去了。

“哎呦，不错哟。都凌晨1点了，赶紧回去休息吧。加油，升职加薪有盼头了！”

喝完酒，老规矩拿出手机打车，一样路过外白渡桥。what fxxking that I hate ……

那妹纸怎么又在桥上？我让师傅停了下车，摇下窗户，仔细看了看。嗯，这回没哭。保不准是人自己想透透气，对吧？

唉。算了，这回要教育一下。大晚上的，一个女孩子出门在外要保护好自己。

下车，爬上桥。妹纸就一手拿着啤酒罐，一手在抹眼泪。

“你来了。老B让我配一个webpack，还要多入口。我怎么配他都不满意，我觉得我好没用。哇呜呜……”

嘛????，嘴瓢了？一罐啤酒就醉了？你喝醉了就想webpack？你丫骗鬼呢还！

“你知道webpack的 loader 和 plugin 的区别吗？”

“我想听你说。”

“听好，我就说一遍。“

loader是专注于文件转化，例如加载非commonJs 规范的文件，babel-loader和babel-core模块是为了把ES6的代码转成ES5，url-loader和file-loader是对图片进行打包等。”
plugin完成的是loader不能完成的功能。plugin也是为了扩展webpack的功能，但是 plugin 是作用于webpack本身上的。而且plugin不仅只局限在打包，资源的加载上，它的功能要更加丰富。从打包优化和压缩，到重新定义环境变量，功能强大到可以用来处理各种各样的任务。
webpack提供了很多开箱即用的插件：CommonChunkPlugin主要用于提取第三方库和公共模块，避免首屏加载的bundle文件，或者按需加载的bundle文件体积过大，导致加载时间过长，是一把优化的利器。而在多页面应用中，更是能够为每个页面间的应用程序共享代码创建bundle。

妹纸吸了吸鼻子，看来是真的哭过。渣男啊渣男，求求你不要在这个时候给人讲技术了，会挨雷批的。

“就完啦？”

“哟，那你还想知道啥？”

“你的那什么性能监控是咋做的？好神奇噢！你是怎么做到了解页面白屏时间的？”

“哟呵，胃口不小。你恐怕得在这里站上一个礼拜了。”

“好呀！没有问题呀。那你今天就先开个头好吧？我领悟能力很强的！”

"好吧，我输了。"

确立性能指标
白屏时间
数据接口响应时间
图片加载资源等
以直接从后端服务中获取，不需要前端再重复计算. 获取后上报性能平台即可。
计算图片
它指的是从输入内容回车（包括刷新、跳转等方式）后，到页面开始出现第一个字符的时间。这个过程包括 DNS 查询，建立 TCP 连接，发送首个HTTP请求（如果使用HTTPS还要介入 TLS 的验证时间），返回HTML文档，HTML文档 Head 解析完毕。它的标准时间是 300ms。
白屏时间
首屏时间
视觉稳定性指标（CLS, Cumulative Layout Shift）
秒开率
卡顿、完全加载时间、资源加载时间等…… 重要优先级不高。

首屏时间秒开率标准

类型	首屏时间	秒开率	1.5秒开率	2秒开率
SSR	1000ms	80%	95%	98%
端内	1200ms	65%	85%	90%
端外	1500ms	40%	60%	80%

“哇！秒开率最高才80%嘛？”

“我…… 业界能做到这个标准的屈指可数。”

“噢。你说的，我大概都懂。可视觉稳定性指标是什么？”

“交互性和视觉稳定性关键指标，业界还在探索，没有统一的衡量标准，且必须手动采集。”

“那确立了这些性能指标，然后呢？”

“然后上报性能监控平台啊。笨！”

“那如何上报呀？”

“唉，咋说呢。先设计一个性能上报的SDK吧。”

步骤	action1	action2
性能SDK设计	sdk接入设计	1. 把之前首屏、白屏和卡顿采集的脚本封装在一起，并让脚本自动初始化和运行。
		2. 提供帮助文档，提高sdk的易用性。毕竟现在随便一个库都有帮助文档
		3. 还可以设置性能分析小助手，快速定位一些基础问题。

	sdk运行设计	1. 兼容性策略。用 `javascript` 去写性能指标的采集方法，从而能够跨技术栈。
		2.自身容错机制，`try catch`捕获异常，再上报。
		3.根据用户实际的浏览器和机型分布比例，确定 `top10%` 用户的机型和浏览器类型。然后在每次开发完成并进行代码 `code review` 后，使用这些机型和浏览器类型进行自测
上报策略设计	日志数据过滤	1. 在采集性能指标之后，最好先对异常数据进行过滤
		2. 异常数据错误，包括合法的异常数据，最大阀值、最小阀值。
	数据抽样策略	1. 性能 `SDK` 上报数据是全量还是抽样，得根据本身 App 或者网站的日活来确定。毕竟日活`10W`和`1000W`是有很大区别的。
		2. 日活大就适当减少抽样样本。例如天猫双十一，日货巨大，就必须要减少抽样样本。
	上报机制选择	1. 根据网络能力，选择合适的上报机制。在强网环境（`如 4G/WIFI`），直接进行上报。在弱网（`2G/3G`）下，将日志存储到本地，延时到强网下再进行上报。
		2. 根据APP忙碌的时间来选择上报时间。例如 App 处于空闲状态，直接上报，忙碌状态就等到闲时（`比如凌晨 2-3 点，用户活跃度相对不高`）再进行上报。