95 lines
7.8 KiB
Markdown
95 lines
7.8 KiB
Markdown
---
|
||
title: 再见 2022，你好 2023
|
||
date: '2022-12-31'
|
||
tags: ['总结']
|
||
draft: false
|
||
summary: 2022 年就要结束了，写个工作与学习的总结，记录下我的 2022 年。
|
||
---
|
||
|
||
二零二二，疫情不出意外地还在我们身边，而我们也早已经习惯了疫情。
|
||
|
||
## 电子电路与嵌入式开发
|
||
|
||
我一直对电子电路有着兴趣，而今年三月，我突然觉得我行了。购买了仪器和工具设备，开始自学电子电路知识。
|
||
软件开发一直和数字电路有着密不可分的联系，草草地学习完模拟电路和数字电路后，更加肯定软件和硬件不能独立，而是相辅相成的。
|
||
而我的第一个目标是构建一个锂电池 UPS，为的是让充当服务器的 J4125 工控机能从容应对突然的断电。
|
||
项目我拆分了好几部分，一个阶段，一个阶段地完成，向着目标努力。
|
||
印象比较深的还是第一个部分的实现，第一个部分是实现一个理想二极管。
|
||
所谓理想二极管就是电流单向流动，并且（几乎）没有普通二极管的压降。
|
||
还记得我开开心心地在各大电子电路论坛爬楼找思路时，找到了个方案，在电路模拟软件搭建好电路后，运行了模拟，结果挺有效的。
|
||
我就赶紧画电路板打样了。等待样板寄来的包裹的这几天，我思来想去这电路好像不应该有效啊，换了个模拟软件一跑，坏了，不对。
|
||
接着就在洞洞板上做实验，果然，效果不对，压降那叫一个大。
|
||
最后这样改方案，画了第三块板后，终于实现了这一电路。果然实践才是检验真理的唯一途径，三个月从零搞出这么个东西，其实没啥，但是过程确实有趣。
|
||
就这样，边学边试，软件和硬件都验证完了，过程充满松香味。
|
||
不过可惜的是，半年后的八月，我换了 AMD 迷你主机，UPS 设计供电已经不满足新主机的要求，项目搁置了。
|
||
电路的理论论证和各部分的功能验证板已经实现了，外壳也已经设计好了，但是还是没继续往下走，因为当时工作上发生了一些变动，就没余力折腾了。
|
||
之后又开始折腾屏幕氛围灯，挺有趣的，不过还没做完，目前一周也就花几小时在边学边弄。
|
||
|
||
我能想着开始折腾电子电路，还是因为国产单片机的崛起。
|
||
乐鑫公司的 ESP32 系列单片机真的是物美价廉，白嫖嘉立创的 PCB 也非常的香。
|
||
学习成本就低了很多，想想去年我入手的树莓派 4B。当时也有考虑折腾物联网，但是一个三四百，也只适合当个上位机干活了。
|
||
而现在用着 ESP32 模组和开发板，烧了也不心疼，嘿嘿。
|
||
|
||
嵌入式开发是一个陌生的领域，C 语言是一个上古的高级语言，而天天写着现代高级语言的我，一时之间回不到大一时写 C 语言的感觉，
|
||
所以用了一段 C 语言做嵌入式开发后，我看上了 C++。或许是 C++ 没看上我，编译器报错我是一个也看不懂，所以我想起了 Rust。
|
||
Rust 比着“耶”向我招手，我大意了，就进了这个跟大的坑。
|
||
|
||
Rust 语言确实费脑子，因为开发过程中将会被编译器一直教育，非常地严谨。还记得我被引用变量的生命周期教育得死去活来，被结构体没有实现 `Copy`、 `Send`、`Sync` 折磨得痛不欲生。
|
||
其实本来没这么复杂的，可是我却拿着嵌入式开发和 Rust 一起学，难度不能说陡增吧，只能说是经常看不到明天的太阳。
|
||
不过我还是磨出来了 UPS 的程序，还行，能用。之后开发屏幕氛围灯就滚回去用 C 语言写了，还别说，嵌入式开发我也学出了点感觉，写起来可亲切了。
|
||
因为示例多、论坛上的开发者主要也是用 C 写，资料很充足，也没有那群还在 0.0.x 版本的 Rust 库，感觉代码好写多了……
|
||
但是我贼心不死，拿着 Rust 转眼就配着 Tauri 开始开发氛围灯的上位机程序。
|
||
不知是没有了 rust-embedded 系的折磨，还是我懂得了 Rust 的脾气，开发得比较顺利，很舒服。
|
||
|
||
嵌入式的世界非常的美妙，将虚幻的软件借着硬件能更真实地让我们触碰到。
|
||
看好 IoT，这是极客们的方向，也是科技改变生活的方向。
|
||
|
||
## 元宇宙
|
||
|
||
年中因为业务调整，我的工作和元宇宙搭上了边。年中出去嗨皮了一周后，回来就开始学习 Unity 3D。
|
||
不得不说，国内疫情防控挺好的，走了好几个城市，回来也没阳，哈哈。
|
||
跑题了，不得不说， Unity 3D 作为入门 3D 游戏开发确实挺合适的，虽然我们当时本想着用 Unity 开发元宇宙项目。
|
||
正当我在庆幸我还没把 C Sharp 忘光光时，又换成了现在正在使用的 Three.js 作为引擎，也回到了 Web 领域。
|
||
接下来的半年，我和我的同事们便开始踩坑之旅。
|
||
|
||
因为是全新的领域，我和我的同事经历了 Unity 3D、Lingo 3D、r3f 这三个阶段，踩了许多的坑。
|
||
不知为什么，他们似乎对游戏开发好像并不觉得是全新的世界，极其低估了所需的知识储备。
|
||
现在回头看，每次的技术选型其实都不合理。
|
||
Lingo 3D 作为刚出现的框架，并没有经过市场的检验，也并没有基于该框架商业项目，使用这个框架和二开这个框架并没有什么区别。反对无力，作罢。
|
||
当我向 Lingo 3D 提了一个 PR 后，同事就抛弃了 Lingo 3D，转向 r3f + BVH 碰撞检测。
|
||
而接下来，继续遇到了大量的性能问题。
|
||
|
||
十二月，是我专攻前端性能问题的一个月。不过滑稽的是我之前几个月基本上在开发 WebRTC 相关部分和后端，而前端游戏场景渲染这部分并不是我开发的……
|
||
就这样，从项目开发的第一周起，我就有一个 3D 场景渲染性能优化的任务挂着。
|
||
我断断续续地折腾这事，现在回头看看，其实得出的结论挺正确的，但是当时没人懂也没人信，我也是半验证半猜测，没想到正确率还行。
|
||
第一，游戏开发确实很考验建模师的素质，调优后的模型性能直接翻倍；
|
||
第二，模型拆分、复用、LOD 是真的有明显的性能提升；
|
||
第三，内存瓶颈是存在的，降低内存占用量能够让程序更稳定。
|
||
|
||
虽然我对元宇宙没啥兴趣，不过可视化这方向是很有价值的。
|
||
看好元宇宙的风口，也看好可视化的前景。
|
||
|
||
## 自建服务与远程开发
|
||
|
||
八月换了新的迷你主机作为服务器，依然使用移动平台的 CPU，性能和功耗还可以。
|
||
比之前的机子性能好太多了，当然，满载时也学会芜湖起飞了。
|
||
我也多部署了几个服务。
|
||
|
||
### RSS 阅读器
|
||
|
||
现在信息茧房问题挺严重的，所以使用 Miniflux 自建了 RSS 阅读器。目前搜寻了一些个人博客、小众资讯站作为资讯源，感觉挺好的，没有乱七八糟的内容，很舒适。
|
||
|
||
### 标签打印机和短网址服务
|
||
|
||
另外，买了一个标签打印机，配合短网址服务 Kutt，给我买的一堆电子元件做分类打标签。标签上带了个二维码，里面存了描述元件信息文件的超链接地址。
|
||
|
||
### 日志分析服务
|
||
|
||
最后，因为部署了太多服务，自建服务又容易挂，所以跑了 Grafana + loki 用作日志分析服务。再配合在云服务器上部署的 Kuma 服务健康监控服务，目前服务状况了然于胸。
|
||
|
||
我还购入了国内的 NAT VPS，做内网穿透和 SD-WAN，比使用境外服务器快太多啦，还稳定。
|
||
公司网络不太稳定，直接组网性能经常断线；
|
||
使用 VPN 拨入 NAT VPS 后，再由 NAT VPS 与家里组网，就没在掉过线。
|
||
现在从公网访问我的自建服务是由从境外服务器反向代理的，延迟比较大。
|
||
目前域名重新备案，希望能套上国内 CDN，这样再由 NAT VPS 反向代理应该能改善国内访问速度。
|