@tenwx 考虑软件资源，确实一加普遍更好点，不过还是要多折腾，差距不是决定性的。（ rec 在内的搞机资源丰富程度显然都不如米系，不过 MIUI 默认体验嘛……）
那主要就考虑硬件和性价比了（前提是软件有不用跟厂商打招呼的合法的折腾空间，三星华为蓝绿厂 out ）。

本着买新不买旧和被 64G ROM 空间不够折磨几年的应激反应，要买就顶配，最好能多用几年。
（其实先前的荣耀 V9 ，当年就是个三星 Note 8 在被顺走之后的过渡机，抠门才买的 64G ，没想到苟了那么多年。当然就算当年买了 256G 的，现在应该也不大够用——光是生产的手机截图几百 G 了，所以这次 V9 电源键又坏了……）
然而看看现在的 SoC ，发哥在旗舰市场还没那么大统治力，到处都是 8Gen1 ，想要硬件不浪费，就绕不开怎么驯龙了……（否则，退两代？→还不如海鲜市场玩二手→等等党永不为奴。）
这个意义上友商拿什么跟风扇打啊。

一加的话，现在也就 10P ，参数上还是差点意思。
就算一加 10TP 按也能有 18G+1T ，散热面积和充电效率看来仍然被红魔 7P 摩擦（我不开车，不用无线充电）。价格么预计也没优势。
特别是新品我一时等不及（当时华为售后还说电源键配不到货）；如果真要等，短期物流可能都是问题；另外 8Gen1+我也不指望好哪去，仍然火龙预定。

@Cu635 关于 Python ，我基本同意你引用的这个说法。特别地，不要试图没事去兼容 Python2 和 Python3 ，要迁移历史遗留项目另说。实际体验被恶心过的应该容易理解。其它语言多多少少也有这样的问题，但很少那么乱。比如 C ，就算要混用不同版本的方言，基本上搞定#if 就没太大问题了。

至于学习，语言有共性，可以相互对照。一般应避免以某个完整的语言为模板通过打补丁来学新的（设计上就没有明确版本继承关系的；至于 Python 这种，看着办）语言，而自己应对比和其它语言的差异之后合并重复的知识点。这样便于甩掉偶然习惯的个别语言缺陷的带来的不良影响，也能减少不同语言串味的风险。

见怪不怪说明的是这些现有语言的具体设计都不足以作为设计的合理性的依据，评价设计时应参照更普遍的更直接反映现实需求的理由。习惯不是瘾，不要做历史的奴隶。

@efcndi 本来贴出来效果，有重新编辑好空行，突然有点其它事中断，然后超时了不好编辑……

我倒是觉得玩机大忌首先就是三星这种硬件完整性上歧视和折腾用户的（ KNOX 失效），然后是华为这种不给解 BL 然后还用私有 layout 魔改过系统的。（这两家折腾起来的优点也就是售后还行。）一些小众机型，反而因为定制系统的能力低，底层跟公版差异小，所以容易找到上游公共资源来折腾。像这里内核我很容易就找到上游 ACK 里的 git hash 一致的 commit ，原则上能二进制兼容（ ACK 就是干这个的）；反倒是如果厂商有实力，魔改了或者 cherry-pick 过，那它要是不给内核源码就彻底没救了。

当然，小众到没人会去关心要内核源码那自然也不行（基本 XDA 上是要有国际友人会玩的），否则还不如自己玩开发板了。

数据方面，内部表示我用不到多少现成数据库的功能，至少不用典型的 RDBMS 那么复杂，有个面向记录的数据结构加一些简单的索引足够。分类 /贴标签可以用索引做。要用现有数据库，主要动机是大部分持久层和事务的功能不用自己实现了。
对 UI 我的要求更低，因为我不需要低代码管理，所以基本没什么编辑的要求，只要能正确预览和方便索引就行。另外还要加日历等浏览视图，这算是 PIM 软件常规功能。也许像 Windows 事件管理器那种改改加上预览可能都够了（虽然那个也不太有现成品）。
对我来说 OCR 不一定需要集成，主要是比较灵活，我不太确定现成的 OCR 能直接用，应该免不了针对具体需求二次开发。而且也需要同时处理图像提取其它数据，我在想是不是空了专门训练个模型之类。当然，这种定制就算是小众需求了。

@Cu635 Python 的兼容历来拉胯。Python3.7 这种小版本升级都能加 syntax 破坏向后兼容性，还亏它是个动态语言，连个靠谱的语法扩展都做不到。Python2 到 Python3 不兼容得更加离谱，你当是两种不同的语言也没什么大问题。但这里有个不同的原因不是像 2/3 普遍都有的缺少可扩展性机制的设计，而是 Python2 很多具体特性就设计得尤其烂，不说没有前瞻性，从来就是过气的。要是一开始就不要搞那么拉胯的设计（什么 print 这种阿猫阿狗也好意思当什么“语句”，BASIC 吗……），直接设计成 Python3 这种，不兼容也不会那么低级。

对软件工程实现人员来讲，知道编程语言的缺陷是最起码的整体认识，否则选型就容易出问题，可以说不知道不适合干什么约等于基本不会。C 的历史地位主要体现在第一个跨体系结构实现操作系统的主要部分，说白了也就是只擅长写这种层次特定软件的 DSL ，在有更正常的选项时大规模铺开开发应用本来就是灾难。另一方面，除了知道缺点，科班更应该知道不同语言之间的演化路线，不能学了一种别的就抓瞎。

至于符号，其实抄数学的多了去了，但各种不一致，这种“工程语言”更加见怪不怪了。BCPL 里就有≡，大约是字符集的问题，≢后来改成了 NEQV （但是≡为什么不改呢，我暂且蒙在鼓里）；更离谱的是还有=、≠、<、>、≤和>=，然而没有<=和≥，也许是<=和⇐容易混罢。
但是数学符号也可能滥用，特别是有些用法得看作者（比如→和⇒是否同义），也未必好哪去。这类滥用在个别编程语言中也有体现，像声名狼藉的 APL 。然而虽然语法也不咋地，数学语言的语义可没那么拉胯。

@thedrwu 背景常识：.h 这种 header 的地位在 ISO C++里是 deprecated （[depr.c.headers]），但是 deprecated 也同样是 [要求] 提供，懂？
一个完整的 ISO C++实现里就包含 math.h ，你要是实现标准库不提供 math.h ，管你是不是同时支持其它语言，就没资格当一个 C++的 hosted implementation 。连这点 conformance requirement 都不明白，杠就别抬了。

顺带，倒不需要我特别数落你，WG21 的人自己也有拎不清的。
比如微软的标准库实现的 Stephan T. Lavavej （因为他本人执意把这个实现叫做 STL ，为避免歧义，这里就不用类 TDN 表记法了）曾认为：

D.5 "C standard library headers" [depr.c.headers]
Why is this even deprecated?

——WG21 N4190

他不懂标准化过程中，deprecated 表示 formal discouraged ，也就是不建议用，只是为了兼容等原因保留。
这仍不表示<cname>比<cname.h>更长寿。事实上，WG21 P0063 更新 C99 兼容 header 到 C11 的同时，反倒是加上了：

The use of any of the C++ headers <ccomplex>, <cstdalign>, <cstdbool>, or <ctgmath> is deprecated.

这在 C++17 起生效。
之后，在 P0619R4 中，这个问题被重新讨论：

D.5 C standard library headers [depr.c.headers]
strong recommendation: Undeprecate the remaining [depr.c.headers] and move it directly into 20.5.5.2 [res.on.headers].
Weak recommendation: In addition to tbe above, also remove the corresponding C headers from the C++ standard, much as we have no corresponding <stdatomic.h>, <stdnoreturn.h>, or <threads.h>, headers.
Toronto Review: No recommendation, take no action without a more detailed paper.

结论是 C++20 仍然保持现状不变。
在 P2139 中，这再次被拉出来鞭尸：

D.9 C headers [depr.c.headers]

Strong recommendation(A): Remove the vacuous headers, then undeprecate the remaining [depr.c.headers] and move directly into 16.5.5.2 [res.on.headers].
strong recommendation (B): Undeprecate the remaining [depr.c.headers] and move directly into 16.5.5.2 [res.on.headers].
Weak recommendation: Remove entirely from C++23.

可见即便是到了现在，移除仍然不是主流意见。

而另一方面，是不是 C++先不说，什么时候容忍用.h 过 review ，是不同的问题，应该分类讨论。
例如很多.h 在 POSIX 中提供扩展（像_r 这样的 reentrant routines ），如果你用<cname>，这是不保证提供的，因此是错的，漏了<cname.h>应该不能通过 review 才对。
而就<math.h>，真正的问题远远更琐碎。用<cmath>代替<math.h>不能纠正误用 abs 代替 std::abs 或 std::fabs 这样的经常更危险的错误（效果倒是跟这里 OP 的问题类似），尽管 Clang++的[-Wabsolute-value]可能会指出这种问题。

我不指望随便一个 C++用户比如你是这方面的专家，但笼统以错误的认知装作适格者来 review ，先不说态度，这看起来就是在凑工时捣乱。

@HeyWeGo 羡慕需求少的，笔记本 40GB+2060 平时编译+开各种虚拟机还有点不够用。。。

我倒是觉得至少 CPU+RAM 部分就没几个评测比 xmrig 实在的（不管是不是手机），不过手机上不见得方便 build ，而且现在这风向嘛……

@adoal @Cu635 C 的设计才是残的。

从 C 的直系祖宗来看：
ALGOL 60 支持实数（实质上是浮点数），/是浮点除法操作符。÷（一些方言中记作 DIV ）表示整除，取整数绝对值同 ENTIER 函数定义，即向下取整。
CPL 支持实数（浮点数），/是浮点除法操作符。
在 BCPL 中，浮点数的支持被移除，/表示整数除法，而舍入并非固定，依赖实现。
B 语言中，恢复了浮点数支持，但 /仍保持整除，并规定向零截断。另有#/表示单精度浮点数除法。
基本上，C 以前的语言，除非是语言限制只支持整数算术，/总是表示接近数学含义的实数除法。否则，整数和浮点数除法的操作符语法不同。

但到 C 就乱了。
因为 C 引入了显式类型，/被特设地重载了（虽然语言并不整体支持这个特性）。
不幸的是，整除对浮点数也有意义（所以浮点数除法还需要另外引入函数），而不论整除如何实现，/的语法已经造成了一些理解上的混乱。
要让 /正常地多态，最直接的设计是支持 numeric tower ，根据参数的类型提供最精确的近似，典型地出现在一些 Lisp 方言中。这样的设计更加具有可扩展性，也适应动态检查类型的潜在类型语言（不需要依赖复杂的类型检查规则）。Python3 只是部分地恢复这个传统罢了。

C 的 /的另一个显著问题是有符号数的 /在涉及负数时的行为由实现定义而减少可移植性，这也影响模运算和照搬 C 设计的 C++等语言。直到 C99/C++11 ，才明确要求整除截断。
即便如此，钦定一种明确的计算也没消除整除的固有复杂性，而且经常引起通常的用户低估和忽视这里的问题。参见：en.wikipedia.org/wiki/Modulo_operation 。
一种比较正常的设计是严格区分不同整除，并以不同的操作显式地明确，而非使用笼统的 /等历史上含义混乱的操作符语法，例如：
people.csail.mit.edu/riastradh/tmp/division.txt 。这里给出了 5 组有明确数学含义的整除和模运算，其中两组被 R7RS 接受，包括 C99 的截断整除。其它表述（如 R6RS 的 div0 ）可对应翻译到这些明确的操作上。
对潜在类型语言，是否接受不精确数（浮点数）作为整除的操作数又具有两种变体。在此不再赘述。

@thedrwu 谁告诉你“math.h 不是 C++的”。

@xuanbg 你似乎是没从编程语言历史开始学，而被数据结构坑了。
事实上所谓的数据结构并不太关心这里的问题（虽然一些分支倒是更关心具体的数值表示），根本上也无能解决这里的混淆。

弟弟 V9 64G 虽然能官方售后扩容 ROM ，但是官解 BL 的就算了。
root 了共享到局域网，但是共享在 PC 上的数据 app 读不出来，就解决了怎么方便自动转移数据。
忍不了在这次内屏摔出问题后（电池换了 4 次屏幕换了 3 次电源键换了 2 次后壳换了 1 次）直接上了红魔 7P 1T ，但纠结解锁 BL 掉指纹然后自己校准一个星期后现在纠结内核没 cifs 支持怎么实现脚本同步了……

看到 root 门清儿……跑题问俩事儿：
1. Android 有 root 但是内核不支持 cifs 的情况下有没啥容易折腾的方案允许脚本访问 Windows 网络共享？
（折腾的方式搞过，没内核源码，猜出 ACK 的 git 版本编译内核模块成功但是 modver 不一样符号也对不上，甚至另外写了个模块抓的 kallsyms 的 printk 都死活不认，还是躺了吧。）
2.现在 Android 12 的第三方 rec 有支持解密 data 的么？自己编译一个没官方支持第三方 rec 的一般流程是啥？
（不急，我现在还在纠结怎么给该死的 AOSP 源码腾出空间……）

@agagega 确实……hg 很多逻辑设计看起来都正常点，CLI 也没那么反人类。
但是 hg 本地存储就有些拉胯，特别是没 git pack 这种，大量小文件存储时间空间效率多数文件系统上都非常捉急……

其实我这里其实是有更具体的实际需求的，虽然不是你面向的用户层次，但根本上也算是 PIM 最终用户需求。
比如你提到的财产、健康数据之类，我现在是自己用 DSL 手工录入文本存储，大量数据还得清洗，所以数据处理部分我得自己实现。
如果你能针对你的需求提供一个方案，我可能复用你的数据持久层和部分 UI 。中间还是得自己做。你这里看来并没考虑二次开发，不过如果是开源的，我自己改改也能节约点工作量。
而另一个重要数据源是日常的截屏，比如交易和聊天记录存档以及游戏截图。这里大概还得 OCR 之类的所以二次开发要求更高，不过最主要的首先就是……数据存储和同步，然后就是根据图像识别分类（照片自带时间，大部分截图文件名带时间；有些文件名带包名，但更多没有，所以根本还是得分析内容）。
正常来讲，我希望你这里做的，至少框架上还是能足够复用，加点东西就能满足我的实际需求，而不是砍掉太多重来——对我来讲就没多少意义了。
数据量的话，文本几 M ，图像几百 G 吧……
另外我想要一个历时数据库，也就是把记录尽量和日历时间关联起来并提供视图便于查找统计。

@Chad0000 普通人用多终端是很常见的。有意识到 PIM 的用户中，一台 PC+一个手机算是基本配置，只有一台 PC 或者一个手机的反而不多见。特别是考虑数据来源的不同（比如 PC 通常不会直接处理照片，手机通常不会录入大量文本），要综合处理不同格式内容的系统基本总是迟早面临跨端同步的需求。

@Chad0000 只要多端就得支持同步，这个是免不了的，无非是谁做的问题。比如局域网直接共享编辑文件是文件系统能做的，你就不用做（不过现在手机怕是连 CIFS 都普遍没支持好……）；数据库的底层对文件系统的同步你也不用做。但是大部分应用场景都没法支持远程直接修改数据的程序实时实现修改，或者根本不可能合理实现（比如带宽限制），所以这（不管是否用户可见而可能引入冲突）横竖都得你做——要么是提供 UI 允许用户自己同步，要么是启发式判断修改完就附加同步的逻辑，更好的是两者都有。
数据库“在远程无需同步”是你想得太简单了。而你现在想象中需要同步的简化做法，也不过是这种启发式地添加（而不是减少）一个附带同步的操作。
既然你也知道缺陷了，为什么不让用户自己选择？怕用户不懂，默认同步就行了，就是 UI 上的差别。
至于冲突，想要完全避免也是不方便的，比如会限制多端离线编辑（这是用户不喜欢 Web 应用的另一个常规理由）。你只需要在接口支持可能合并以及提供基本的实现（常规 DVCS 支持的文本就可以，工具都现成的，算法都不用自己搞）。具体应该怎么合并不是你需要考虑的，因为合并策略根本取决于数据的用途和用户的习惯，钦定具体一种同样不便。

@Chad0000 你搞错了一个要点：集中存储更依赖单一设备可靠性，更容易丢，也就是彻底灭失无法恢复。不一致的存储只要能以合理的代价恢复就不算丢，而物理存储冗余是确保这个意义上不丢数据的不二法门。
和很多开发人员想像的相反，现代 DVCS 实现普遍做好的首先就是低成本的基本分布式内容冗余存储：想放哪就放哪，只要摸得到。这允许实现不易丢失的物理保障。否则，用户至少还得相信一个第三方运维来担保数据的安全，这物理上并没那么直接和靠谱；比起用户自己强的部分，只不过是真丢了数据后能承担补偿责任的事后诸葛亮而已。当然，考虑大多服务供应商存放数据的位置比一般用户物理上能摸到的地方更远，所以不担心数据被偷看的话，混合方案更好。
（ DVCS 实现的多版本管理反倒是其次的。）
只要是要同步的分布式系统就会有理解同步实现的问题。既然要同步，用户至少就得理解和谁同步，谁来保证完整性，否则就实际上会承受设备好好的，最新的完整正确内容却某天稀里糊涂就没了的风险。

@PopRain
404 Web Site not found.
@kuangwinnie 不支持 hash ，每隔个几百年搞不好内容改得妈也不认识，还得时不时考古重建……

说点半相关的：pacman 拒绝支持 git shallow clone （ bugs.archlinux.org/task/34677 ）很多次，乃至殃及下游也无法解决（ https://github.com/Jguer/yay/issues/1713 ）。
考虑到下游从逻辑上确实不那么好解决（不算 fix 只能是 workaround ），所以下游拒绝有合理性，问题出在上游。而上游维护者的理由是既然用了 git ，就该都用整个 repo 。
这种“哲学”（ bbs.archlinux.org/viewtopic.php?id=240972#4 ）原则上就很欠骂，philosophically not even wrong：为什么能心安理得假定带宽之类的基础设施问题一定能够被用户忽略？变相就是说如果出问题（比如嫌弃太慢）就爱用用不用润，然而这种地方是不是出问题根本上就不是用户说了算的。况且，如果 git 就只应该那样用，为什么 git 还要提供 shallow clone ？根本问题是，它以反直觉同时技术上没有必要的理由拒绝（从很多人重复提出就能看出来的）常规需求。
（其实 2202 了，git clone --depth=1 照样容易卡翔失败没法恢复，没断点续传这点本身就很欠揍。）
当然，退一万步讲，好歹它还是允许用 git 了。要是非得要求 svn ，那就不是欠揍的问题了。

以上问题欢迎对号入座。