发光小板板

手机触屏坏了，好像整个世界都隔了一层玻璃… ——2026-01-25

实习，上班可能也挺…无聊鸡肋的；但我换了个手机，开始玩原神。
那时，我是玩的挺开心的，在上下班地铁上，在秋冬晚上的被窝里什么都不管的扣手机可能不论怎么讲都是应该感到舒服的事情，可…

从电子产品的角度看，移动互联网的发家史，其实可以看作这块“发光小板板”狠狠雷普了当时带了一堆实体按键的功能机的历史。实体的物理按键，做成啥样就是啥样了，没法改了；但在这块发光小板板上，你想要什么按键、什么交互，只要性能够，都能画出来。甚至可以闲得无聊写一堆回弹动画——这太神奇了，第一次见的话，也许只是一个带阻尼感的下拉刷新，就足以让一些无聊的人我玩上一整天。再加上苹果在小板板里塞了各种传感器，还有神奇的压感和震动反馈… 一个设备，仅仅因为打开了不同的“应用”，就可以变成完全不一样的东西。

虽然现在也没那么新奇的了…但不论怎么讲，可以戳戳戳的发光小板板里面，好像还住了一堆人，小板板好。

机器、与消费

老说年轻人喜欢追新的电子产品追各种东西。可这些消费可能是…某种意义上不可避免的东西。首先现在可能没人离得开手机，而那些所谓的好的贵的产品，许多时候…
拿写交互界面的事举例子的话，那些在潮头的，也许不去观察新产品的一个动画一个特效，可能就会慢慢脱离那个圈子，可能自己做的东西就会越来越显得落伍粗糙，然后竞争力下降… 这可能是另一种关于体面合群的事。

生存竞争：交互设计师必须买最新的 iPhone，开发者必须用最新的 AI 模型，因为审美和工具的迭代就是他们的劳动工具本身。
合群的阶梯：这种消费变成了另一种形式的“缴纳租金”。如果你不持续购买这些“孩子”（机器）的最新迭代，你就失去了定义未来、甚至理解当下的语言。这是一种被迫的进食。

小板板的用户界面

GitHub - huamurui/zhihu-minus-minus: 知乎-- ｜zhihu-- ｜ zhihu-minus-minus｜一款轻量、简洁的第三方知乎客户端 · GitHub

最近，也不是很近了，做了个知乎的客户端。
那时候，虽然一开始就打算用 rn，但我还去看了看 kotlin 的 Jetpack Compose。大概是，安卓的开发更加的专一，就只考虑应用。
web 诞生最初是为了网络文档的传输与展示；而智能手机的 app，也许很早，几乎一开始就知道自己要做的就是用户界面。
我不确定它们谁先开始尝试做的所谓面向一般用户的炫酷的用户界面，但 web 在一开始做的确实不好。flex-box 出现之前的 css 里的许多奇奇怪怪的东西，各种抽象的 trick，其实是尝试在用文档排版的那套工具，去做类似 app 的用户界面。相比之下，app 也许确实会显得干净些。

最近在做那个知乎的三方客户端时，感觉 web 也许也不一定就一无是处，在内容排版上，web/webview 确实能搞定更复杂更丰富的一些东西（虽然知乎还有我最后还是打算放弃 webview 了）。

另外还有一件事，手机上，一般会有一个震动马达，在调用它的时候，好像突然意识到手机其实是一个嵌入式设备，~~那开发安卓 app 算不算嵌入式开发~~。

我们的小板板，究竟会，变成什么样子。

做这个客户端最无聊的部分，大概就是被各家的大门挡在外面。那个知乎的 x-zse-96 加密有点难搞，听说还会偷偷更新。知乎的加密如果只是意思意思…那小红书就是动了点真格的了，知乎学学 js 逆向还能掰一下，小红书的 App 的加密能涉及 Native 层。抖音微信这些…就更不用说了。
发光小板板里的世界变得越来越封闭。每一个 App 都是一座建着高墙的城堡。即使是懂一些编程的人，想把自己的数据搞出来，也要花好多功夫，而想要和别人分享，可能还是离不开互联网这些平台。

编程仙人

我还去看了看 Telegram Android，也不是我看的，一个文件四五万行我还是顶不住的，只是 ai 告诉我了我那些代码大概在做什么事情。
感觉虽然许多事情像是魔法，但发光小板板的交互模式也是有限的，而不是无法预料想象的。所以，知道要做什么，做出来了，确定要的效果就是哪些，然后再自己算坐标手绘替换组件，换一些调度策略优化性能功能什么的，虽然依旧是我搞不定的事情，但可能也不是完全做不到的魔法。

（以及乱逛逛到了不少自己写布局系统的 repo… 是不是闲的无聊了都会想看看这些…）

我想下雨，但 web 不让。

看到 ios 酷酷的液态玻璃，我也想搞点东西，但 web 不让。 (ps: 好像最近也让了， https://developer.chrome.com/blog/html-in-canvas-origin-trial?hl=zh-cn 这下是我不知道致远星战况如何了)

css 的一些 shadow，bg-filter， svg 的一些奇技淫巧倒是可以和 dom 有相互影响，但效果还是有限。

然后，发现大概是要写 shader，虽然我不会但是有 ai 应该也不是很难搞。但我也意识到浏览器的布局系统与渲染管线是两个东西，这里写的 shader，只在 canvas/webgl 这个世界能有效果，这里和 dom，是两个世界。

大概有两种方案，一种是直接在 canvas 里做界面也就是得自己整一套布局系统；一种是将 html 输出为图片放到 canvas 计算后在需要交互的地方显示而其他透明……。前者太为了醋包饺子还损失 web 原本有的东西，后者只能做非常有限的效果不然就性能爆炸。

其实之前尝试下雪的时候，因为用 dom 做雪花太卡所以在 canvas 里画，然后用一些方法，让雪花能“落”到一些 dom 上，假装它们在同一个世界…

所以，只弄了下面这个东西，它在 canvas 里，摸不到旁边的 dom。

其实我还看了 flutter，skia，yoga；和 ios android 原生的布局系统和渲染的关系和开发能做到的事…
也许它们比 web 强… 我其实打算用 flutter 或 ios 再做做试试。
但，即使是 ios26 也被吐槽耗电发热卡顿，可能… 想要酷酷的就会有一些逃不掉代价吧。

附：关于 GPU 编程与 Shader 的乱七八糟笔记

算了在这里记一下 GPU 编程：
通过操纵简单的数值，再借助 gpu 强大的并行计算，来处理 3d，材质等图形特效。关于 GLSL 等运行在 gpu 上的编程，一段 GLSL 代码，GPU 会把它复制几万份，分发给所有小运算单元，让他们在同一瞬间、并行地计算出所有像素的颜色，这叫做 SIMD ，而 cpu 上的是 SISD。
gpu 上许多时候不会有循环之类的东西，而是直接就很… 声明式？也许也是不声明根本不知道要怎么弄好吧，gemini 说 gpu 最初甚至只有写好的一堆像是内置 shader 一样的东西根本不能编程只能选哪个打开关闭…
以及，在希望处理图形之外的大量矩阵运算… 会有类似的但另外的东西。
但回到图像，大概，有两种 shader: vertex 和 fragment/pixel; 前者和 3d 视角变换等计算很相关，但这里的雨滴，更多是一种颜色、材质的模拟，主要用的是后面这个。

水滴，其实是一个凸透镜，它有一个弧形的折射面，这里用一个纹理图片来描述。
连成块的水滴，我们可以根据水滴位置中心与边缘的距离去定义一个点折射面的…嗯，法线？
根据法线，去取背后图片某一块的颜色，也就是环境色，再结合一个水滴高光的材质模拟的计算
最后把算的颜色涂到屏幕上去

ps: 还有一件事，其实玻璃面上的水珠，有两种，一种是屏幕上的，表现是中心放大和边缘扭曲和色散，相当于放大镜；另一种是玻璃窗上的，由于背景距离比焦距远得多，所以表现是“缩小倒立的实像～”。

ps2: 还有一件事是， intel, snapdragon 等等芯片说的 gpu 个数就是个数… nvdia 的产品似乎整个就是一个大 gpu… 里面页也有 sm 这种东西，但产品标注宣传喜欢说运算单元，也就是他们 cuda 的个数。

好乱七八糟的… 东西。