首先一个根本性错误：SHA256/512 依然是速度优先的，根本没有什么「循环 100000 次」的过程，中间每个 chunk 最多也就循环 64 次。

对于「循环 100000 次」的问题，楼上说得很清楚了：次方还是对一个数做 N 次乘法呢，你能化简次方运算为 1 次吗？

回到正题，加密循环可参考这篇文章： https://blog.csdn.net/u011583927/article/details/80905740

总的来说就是右旋和位运算叠加的过程，原理上来说因为要读取整个文件（而不是什么「循环 100000 次」），不能化简。

@TimPeake 玩机的人和普通的用户追求不一样啊。你要易用性当然可以全用系统应用商店，但玩机为的不就是手机用起来更舒服吗？为了这点舒服，自然有人认为折腾是有必要、有乐趣的。

你不应该和玩摄影的人说「说好的一键拍照呢？你们这么摆弄相机累不累啊」或者和玩钓鱼的人说「天天摆弄鱼竿饵料累不累啊」，一样的道理。

挺好的，几个补充：

1. 搜索问题请用英文，中文搜不到或搜到垃圾内容是常态，搜到正确答案是走运；
2. 另外这种包装作为语法糖性质的东西，本就应该先了解原理再使用（没有说楼主这篇不对的意思）。先用再了解原理或者根本不学习原理，生活处处是魔法。

C/Zig/Rust/Go 占内存都小。说到底为什么要吊死在 Java 上？你也知道资源不足，还用企业级的 JVM 。要么 GraalVM 编译为原生，要么等 Kotlin Native 吧。

我的一般顺序：

1. F-Droid 找开源构建
2. Google Play 找国际版
3. 华为应用商店（在国内算审核比较严格的了，最早强制要求 64-bit 原生的应用商店）找国内版

从 Type Theory 来说结论早就有了：Go 的 Prod type 抽象就是错的。

在错误的抽象前提下，不管讨论什么都是错的。我就不掺和楼主对具体情况的讨论了。

正确的抽象如 Rust 、Zig 、Haskell 都是 Sum type ，即要么 Value ，要么 Error 。

====

先打预防针：我猜肯定会有人 Argue 说「难道你不考虑既有错误又有返回值的情况吗？」，拜托，那应该是 Value | Error | (Value, Error) 这个复合类型，怎么也轮不到 (Value, Error) 吧。即使 (Value, Error) 确实从结果来看「巧合」地达成了复合类型的结果，后续处理中也依然要分成 value != nil && error ==nil, value == nil && error != nil, value != nil && error != nil 三种情况来处理。发现了吗？只不过是在重新发明 Sum type 用一个 pattern matching 就能搞定的简单任务罢了。

单就前一个需求（嵌入资源），C23 已经标准化了： https://zh.cppreference.com/w/c/preprocessor/embed

@zhng920823 #6 CMake 被大公司推行的好处是能统一。另外，Meson 作为纯社区项目，其实没有被大公司裹挟吧？

我也喜欢 xmake ，还贡献过代码。xmake 的问题可能是包装得太深了，想要做一些自定义很困难，以及没有一个 CMake 级别的 behavior reference 文档。

什么乱七八糟的，弱智就弱智，弱智喜欢啥品牌都是弱智。为何起吸引眼球的流量标题？

@zhng920823 是啊，我知道可以用，我自己也不是没干过这事。后来换到 CMake 、Meson 才发现：干，这些事原来根本不用自己操心维护。Makefile 里判断平台大多是白忙活！

别人写了十几年的轮子了，兼容性自然远高于我们手写的几行 Makefile 。与其遇到一个不兼容问题修复一个，不如直接用现代化构建工具。

另外，只有第 3 个缺点和 autotools 有关啊，1 、2 、4 点 Makefile 都有。

要我说 Makefile 这种东西早就应该扔进历史垃圾桶了。

多亏了 Autotools 家族：

1. 直到今天 C/C++ 项目的构建和编译还是充满了不在文档中的命令行参数、不知名的环境变量、随心所欲的模块管理和依赖地狱；
2. 甚至每个项目都不得不自己编写一个 INSTALL 或 BUILD 文档来专门教别人如何编译；
3. Autotools 既不通用也不思进取，直到今天依然和 GCC 、glibc 强绑定，AM 宏语法残缺不全、极难理解，并且只支持「 GNU 认为你只需要」的寥寥几门语言和功能，充满了 quirks ，和其他语言的互操作更是无解问题。说是公共构建工具，更像是一群 geeks 自己开发自娱自乐的产物；
4. Makefile 完全没有考虑不同 Shell 和 Platform 的问题，想要跨平台编译，开发者不得不自己考虑并编写几百行的 boilerplates 来适配新的构建平台（例如 Windows ）。

CMake is better, and Meson is even better.

如果你需要一个命令行运行器，你应该用 just 或 ninja 。

@besto 补：倒也不至于说无解。

@besto 你说得对。其实还有几个思路：

1. Port knocking
2. 自动定期换端口
3. Virtual LAN 层（ Tailscale ，Zerotier ），然后关闭外网访问
4. 用小众远程控制协议，例如 mosh

> 每开一台新 VPS

国内 VPS 的常用 IP 段早就加入恶意攻击的目标 IP 库了，怎么换 IP 作用都不大。

> 只要不更换 ssh 默认端口，必然会有一大堆的恶意尝试登录请求

你已经知道解决方案了。

> 同在互联网，大家就不能友善一点吗

从另一个角度来说，每天有人免费帮你做渗透测试，不开心？

那显然是手游模拟器。这些模拟器本质是经过裁剪和驱动优化的 Android x86 镜像，运行在 VirtualBox 之类的开源虚拟机内。

另外，严格意义上来说绝大部分 PC 安卓模拟器其实是「仿真器（ Emulator ）」，因为它完全模拟了系统的全部底层硬件设备，性能相对较低（ Android Studio 里的英文翻译也是 Android Emulator ）。

仅模仿系统外部行为，利用主机环境进行指令执行的才是「模拟器（ Simulator ）」，XCode 附带的那种就是，因为模拟器和主机共用相同的 Darwin 内核。

Linux 平台上也有一些 Android 模拟器，例如 Anbox 、Waydroid 等，但一是对 Linux 内核有要求，二是由于缺少好的显卡驱动，图形性能可能还不如经过优化的仿真器。

一些人对软件的认知定格在中国移动互联网兴起的 10 前了。

或者更精确地说，自从 10 年前的程序员根据当时的最新版软件创作出第一组优质的教程后，中文互联网就再没有进化过，而是被内容农场和反复洗稿塞满了。下一批更新的内容迟迟没大规模出现在网上，也没大规模进入一些人的思维。

@haidishayu #60 那你说的是国产 ROM ，是国内大厂自己加的，和楼主说的（ Google 的） Android 功能也不是同一个厂商做的啊。

从国产 ROM 安装 APK 变麻烦以来我就换成 AOSP 系统了。手机在你手里，你也可以试一试。

不是，怎么这也要党争啊，某些人的智商真就退化到只会跟人吵立场是吧？

1. 从厂商角度出发（无论是 Google 还是 Apple 还是别的），我认为有法律纠纷的才叫「抄袭」。看到友商有个好功能，学过来，不是很正常的事吗？友商都没意见你有意见？友商学你说明你的路走对了，大家纷纷效仿，不是好事？

2. 从消费者角度出发，（对某些人）那厂商是你爹天天护着？厂商不是消费者的孙子吗？我觉得作为消费者就是要天天鞭鞑喜爱的厂商：看到其他家有好的功能催他快去学、看到自家不好的地方尽快反馈（直接骂也可以），这不才是喜爱产品的表现？捧杀和无脑喷的人本质一样弱智。

3. 借用一个 B 站 up 的话：「对于一个产品，那你还要我说什么？“哇，NB 到爆，宇宙都要为他鼓掌”？非要这样吹才能显示出你们爹的伟大吗？」

@haidishayu 这个结论是怎么得出的？你说国产 ROM 自我阉割我能理解，AOSP 至今没有添加（也没有暗示想添加）任何侧载限制啊？