@kkocdko 是的，但其实最初 out1 和 out2 的合成就是有损的，而且是 8bit，所以永远做不到无损复原。

但中间过程使用更高精度的运算还是很有必要的，毕竟 PS 里每通道最高 16 位的整数色无论如何都会丢失信息。

进行了一下色阶对比：
原始：
https://user-images.githubusercontent.com/8943519/126943582-73583cef-1554-4266-918a-e3e7964ac022.png

8-bit 色彩模式：
https://user-images.githubusercontent.com/8943519/126943596-24a2bb4d-fc71-4af5-b30e-c9b8dd3c1abd.png

16-bit 色彩模式：
https://user-images.githubusercontent.com/8943519/126943601-579577fe-db9f-4816-a2cd-850ac8b6353d.png

这种操作的色彩精度损失还是挺明显的，说明 Photoshop 在处理色彩的时候，因为每一步都需要把浮点色彩转换成整数色彩，在这个过程中精度损失会比较大。

做了一个 Photoshop 录制动作出来，看实际的效果发现，颜色比较鲜艳的话会被弄浅一点，并且需要切换至 16 位颜色以避免色带。
https://user-images.githubusercontent.com/8943519/126942318-f032f5e3-6108-46f2-a461-6a06a2c50646.png
将扩展名改为 zip 后打开，然后将 ReAlpha.atn 导入。
执行时，需要提前准备好 out1 、out2 、bg1 、bg2 四个图层（名字不要错），并且四个图层的混合效果均需为“正常”。

另外比较好用的还有：
变暗是 min
变亮是 max
实色混合是 A+B>=1?1:0
差值是|A-B|

非常不好用但唯一包括 SQRT 的是：
柔光：A<=0.5 ? 2*A*B+B*B*(1-2A) : 2*B*(1-A)+SQRT(B)*(2*A-1)

会玩不嫌麻烦的话甚至可以在 PS 里写 Shader

PS 的问题还包括它其实每一步都做一遍 clamp，把负数和大于 1 的都 clamp 掉，所以实际操作的时候如果遇到不准确的情况可以用一个低于 255 的灰色图去提前正片叠底（乘法）或者线性减淡（加法），把颜色范围弄得小一点，尽量避免被 clamp 。

其实，PS 的混合模式就是普通地进行数学运算。

已知：减去就是相减，划分就是除法，正片叠底就是乘法。
out1=fg*α+bg1*(1-α)
out2=fg*α+bg2*(1-α)
那么两式相减，视α为未知数，得：
1-α=(out1-out2)/(bg1-bg2)
得
α=1-(out1-out2)/(bg1-bg2)
所以得 PS 步骤：
① 将 out1 图与 out2 图以“减去”混合，得 doc1
② 将 bg1 图与 bg2 图以“减去”混合，得 doc2
③ 将 doc1 与 doc2 图以“划分”混合，得 doc3
④ 将纯白色图与 doc3 图以“减去”混合，得 doc4
doc4 即为还原后的 alpha
回到式 1
out1=fg*α+bg1*(1-α)
将 fg 视为未知数，得
fg=(out1-bg1*(1-α))/α
所以得 PS 步骤：
① 将 bg1 图与 doc3 图以“正片叠底”混合，得 doc5
② 将 out1 图与 doc5 图以“减去”混合，得 doc6
③ 将 doc6 图与 doc4 图以“划分”混合，得 doc7
最后，我们把 doc7 套用 doc4 作为蒙版，就得到了最终结果。

未实际操作过，不对结果负责，深夜可能解错方程，结果也可能因 0-1 标准化而不可靠，并且多步骤会造成精度丢失，建议在 16 位模式下搞。

backport vc6 我见过最妖的莫过于 miniblink 了，拆一整个 chromium 下来魔改到支持 vc6，就为了缩小编译体积

@naizhao 我一直以为一个 DNS 服务最基础的职业操守就是正确地按请求 IP 所在位置提供解析服务。

啊这，原来连收费服务都做不到这种基本功能，反而还要让用户自己决定什么样的域名要避开这个服务。

说句实在话，你真没必要赚那些有 Server，会打洞的人的钱——这市面上有太多太多 RustDesk 的替代品了。

如果真的要赚钱的话，建议还是走服务盈利的方式，也就是向日葵或者 Parsec 的路子。

而且说实话，你这服务器端授权费实在太高了，能买得起你一年服务的，可能只剩下你真正的竞争者了，而且你会搞得他们超级不爽，不爽到要给你的 Client 换个皮赚钱的程度。

你们……真的不知道为啥 UI 都要尽量取 4px 甚至是 8px 的倍数吗？
因为 4px 的倍数在 125% 150% 175%这种奇葩 DPI 下依然是点对点的，而 8px 的倍数则可以确保大多数桌面比例下不会出问题。
在没有可靠的 pt 的排版系统里，4 和 8 几乎就是原则了，这其中唯一的例外应该就是字体大小不需要强制 4 和 8 了。

电池其实只少了 0.32%，因为：
1 - (8693 × 11.45) / (8790 × 11.36) ≈ 0.320016%

直营店需要返厂的话，说明这个直营店已经因为私拆等问题在近期被罚过一次六级维修了。（六级维修指第三方拆修痕迹、部件被私自调换或缺失、备机损坏等恶性事件和无保机器强行维修，六级维修是一种罚价，比普通的“整机换新”也就是四级维修的价格还高。）

这里可能有点马后炮，不过以后如果遇到需要返厂的情况的话，可以试着让天才吧选择次要但真实存在的故障看看有没有店内更换选项，如果全都没有的话，可以换一家直营店试试。

改个球，改完 C 面温度直接不要了，供电还跟不上，苹果原本就是希望你先有体验再考虑性能的，什么价格都尽量先保证体验。

再举一个，比如 UI 里非常常见的圆角矩形矢量，在游戏里就意味着成堆的多边形。
还有比如 UI 里也很常见的各种 PNG 半透明，在游戏里首先解码 PNG 就已经很沉重了（可以了解一下游戏材质是怎样压缩的，这些压缩基本都依赖显卡的硬件支持才得以实现），然后还要处理半透明排序。

如果你是纯标量 UI，就像 Unity 那种的，以标量为主的 UI，并且交互输入就像游戏按键那样简单的化，那在进行了恰当的纹理优化的情况下确实可以直接达到不错的渲染效率，并且你也不需要那么复杂的库和框架了，Flutter 和 Skia 设计之初就是为了支持矢量的。

就是因为 UI 更复杂啊，UI 大部分都很不方便硬件加速。
举个例子，你看在 UI 里几乎滥用了的高斯模糊，哪个游戏敢这么搞？分分钟卡爆的。
还有 UI 通常来说意味着大量的矢量文字渲染，这东西，如果你搞过 Unity 的话就知道其实也挺吃力的。
并且，UI 不像游戏，游戏的输入是简单的，WASD 转转鼠标就行了，交互的主体无非就是相机和主角，而 UI 几乎全部都需要响应输入，这使得多线程和 GPU 并行化非常难搞。现代的显卡可以很轻易地渲染粒子一类的复杂转场，但前提是输入是一次性的，因为通讯延迟很高，并且很难进行预先计算。
而且，写游戏的时候你可以去主动干涉和调整 Shader，但是在使用 Flutter 的时候就没那么幸运了，只能靠 Flutter 翻译成 Skia 再翻译成 Shader，底层被层层封装起来了，效率自然会进一步下滑。

git config --global diff.algorithm histogram

因为第三方键盘最高只允许 30MB 的内存占用，超过的话会被系统直接杀死并替换为原生键盘。
但是呢，国产键盘却总是喜欢在刀尖上跳舞，换皮语音内置菜单一类的玩的不亦乐乎。

@laragh
可视化工作室代码版的这个叫做浅色太阳光的配色主题很有我来的感觉

如果您看到上面的文字无法理解的话，以后请收一下您的杠杆——它太短小了，掏出来撬不到点子上。