Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2024年终总结 #59

Open
berwin opened this issue Jan 4, 2025 · 0 comments
Open

2024年终总结 #59

berwin opened this issue Jan 4, 2025 · 0 comments
Assignees

Comments

@berwin
Copy link
Owner

berwin commented Jan 4, 2025

2024年终总结

一晃一年又过去了,时间过的真快,希望自己没有虚度光阴吧。

工作

XR和元宇宙就像一阵风一样,风口还没吹起来就凉了。今年还是回归到主线,负责会场的全链路架构的框架升级和性能优化。

生活

筑巢计划

22年买的房子在24年最后一个月交付了。整体感受是,背上了房贷后,压力确实比之前大。就像一层枷锁一样把自己固定在不知道什么地方。坏处是自己不再具备任性的条件了,好处是自己变的稳重了起来。

关于理财

投资方面一直没有停,也一直系统性的学习理财相关的知识,基于自己的认知和判断,今年理财收益还不错,24年A股收益率达到了16.11%,跑赢大盘1.43%,美股收益率39.26%跑赢纳斯达克8.48%,今年的理财收益有点超预期,近几年大环境不好,年初我觉得今年不亏就是赚,没想到今年最终收益还不错。

再次感叹,在A股,不要做时间的朋友,要做周期的朋友。在美股,一定要做时间的朋友,只要筹码拿得住基本上不太容易亏。

A股收益

美股收益

健身

虽然今年工作比较忙,但健身还是没落下,仍然有在锻炼~

健身总结

年度成长计划

年初给自己制定了一些成长计划,总体上完成的还行。

leetcode刷50道题 ✅

原计划是一周一道题,所以年初定了50道,实际上今年一共做了144道,超额完成任务。

背1000个单词 ✅

原计划1000个单词,实际上看软件里给定义的划分是背了1,048个,其中有617个已掌握,431个需要进一步复习。

这里的完全掌握意思是看见就能认出来,需要进一步复习的意思是虽然背了,但可能已经忘了。据我观察,这个软件给的评估还是很准的。

搭建技术(在线链路)

去年主要投入在了3D和互动相关的领域,会场这边其他同事同时并行在做性能优化,所以技术的架构迭代也是日新月异。今年回来继续负责会场全链路架构的框架升级和性能优化,所以也给自己定了个目标希望把全链路各个环节都了解透。

这些环节包括不限于:在终端执行的核心能力包(Tubes体系下的概念) -> 在CDN执行的ER(EdgeRoutine)函数 -> 业务网关 -> Solution -> SSR渲染函数。以及一些相对独立的体系:骨架体系(自动生成 -> 缓存 -> 读取使用 -> 检测)、性能优化相关的策略。

目前核心链路的主逻辑都已经摸透了(不然工作也没法进行),但个别条件分支下的细节逻辑还是有没有了解到的。

跨端能力

跨端能力是一个需要长期投入的事情,起因也是因为要做会场的性能优化。做性能优化要从端到端全链路视角去看,去观察和发现哪个环节有问题,或者哪个环节虽然没问题但它的性能数据没达到理论上的上限,也就是仍具备可提升空间。

发现哪个环节有提升空间,首先得知道都有哪些环节,以及各个环节的耗时是多少,以及对应环节的技术体系能做什么不能做什么。而这就需要具备跨端能力。

给自己定了一些长期需要投入的技术点:客户端开发、SQL语法(经常需要些SQL语句去跑数据分析)、计算机网络、AI。

客户端

我们现在前端的C端页面基本上都在APP里运行,那么性能的一个大头就是在客户端。首先客户端自身的逻辑在整个环节的耗时要控制在一个合理的范围内,在这基础上可以结合着前端做很多策略优化,比如把很多原本是串行的流程并行执行,把很多资源提前加载并充分利用好缓存能力等等。

SQL语句

身为一名前端,不敢相信自己有一天在工作上SQL的使用频率竟然这么高。

发现哪个环节有提升空间的主要手段就是执行SQL去跑数据,分析数据。在这个过程中你会发现有些环节性能埋点是缺失的,缺的就补上,所以你会发现,性能优化的第一步是跑SQL,第二步是补埋点。

无论是前期分析数据发现问题,还是后期某个策略上线后的AB实验数据回收与分析,都需要写SQL去跑数据。

计算机网络

纯网络RT的传输速度也是性能的一个主要部分,深入下去你会发现不同的传输协议速度有很大差异。这部分我们不是专业的,专业的事由专业的人来干。但是我们要具备识别问题和发现问题的能力,无论是网络库,还是CDN,还是统一网关他们都只能看到大盘数据,很难看到某个业务的性能数据情况,不同业务技术体系和特点都不一样的情况下,业务同学如果覆盖不到这里,专业的同学又不会每个业务都关注到,那么这里就会成为一个盲区,那么这里如果有问题就不会被发现。

在这个领域我们虽然不是专业的,但只要能具备发现问题的问题,就可以将问题反馈给专业的同学处理。

举个例子,自己的业务有多少用户运行在H3协议上,有多少用户运行在HTTPS协议上?如果数据显示H3协议比HTTPS快了70ms,通过H3传输占比90%。那么把H3协议占比提高到99%就可以提升70ms的P95数据。

再举个例子,如果你发现自己的业务用了流式渲染,但是拿到的数据有被切割的情况,且被切割的部分会延迟一会跟着下一个chunk一起返回,那么就说明在网络传输的过程中,一定有某个节点有一个Buffer逻辑,也就是说被切割说明达到了一个chunk的MaxSize,而剩下的部分又不满足发生一个chunk的MinSize。那么这就需要优化与调整根据业务特色可以选择取消MinSize与MaxSize。

以上两个例子都是从大盘数据无法发现的问题,需要业务技术同学去发现并推进解决。

AI

目前AI已经成为共识,作为未来的一种趋势多了解相关的知识准没错。

AI作为一种工具来解决一些问题也是真的很好用,比如我们自动生成的骨架,每次大促几百张页面,不可能人工挨个去检查哪些页面的哪些模块骨架生成有点瑕疵,都是人工发现了问题再去修正调整。但是通过AI就可以解决这个问题,而且检查的还挺准。再比如离线通过puppeteer针对每个页面进行访问录屏,然后把数据丢给AI去检测页面有没有闪动等场景。

有些场景通过AI来解决确实比传统技术要简单好用,这方面知识还是要多了解持续投入。

总结

一晃,过完这个年自己就30岁了,希望自己未来能够一帆风顺,诸事顺遂~

@berwin berwin self-assigned this Jan 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant