i7 版本对比 i5 版本优势非常小，建议 i5 版就行。

带两块 4K 没感觉到啥问题，也尝试过一段时间将分辨率调整为 2K hidpi （相当于渲染 5K ）单屏，没啥特殊的感觉。


另：使用 10.15.7 系统，而不是 bug sur

@ajaxfunction
@1258280950
@ajaxfunction
@privil
楼上的几位不会以为这是一张真的 GT730 吧，注意核心代号 GF116，ROPs 8，这卡撑死是一张 GTS450 而已。

https://zh.wikipedia.org/wiki/NVIDIA%E9%A1%AF%E7%A4%BA%E6%A0%B8%E5%BF%83%E5%88%97%E8%A1%A8#GeForce_400


这不禁让我想起了这个视频：
https://www.bilibili.com/video/BV13p4y1a7i9

@haruhi #65
关于 『点击 Navbar 的后退是回到上一个 App，而不是在当前 App 里后退』

其实是很好理解的，因为 Android 系统的返回按钮，是在『 APP 外』的：
那么自然是以 APP 外（系统）的视角来后退页面，也就是上一个 APP 内。

如果想要 『在当前 App 里后退』，那很简单啊，需要点击『 APP 内』的后退按钮：
也就是点击 "Up Button"，结果也是符合预期的，返回了 『 APP 内』的上一个页面。


iOS 的返回按钮为什么符合你的想法，因为 iOS 只有『 APP 内』的返回按钮啊。

@haruhi #64
感谢，想起来了，我第一次吐槽这东西应该就是吐槽这个 Today 精选，它真的是太丢 iOS 的脸面了。

@haruhi #62
1 、（一个全新的）用户首次遇到这个场景的时候，不管是 Android 还是 iOS，都不存在明确的预期。
只有当已经使用了一些 APP 之后，积攒了使用经验才会带来预期，如果大家都遵循规范，那预期就会更『准确』。
所谓的预期，实际上就是该平台下交互方式的『趋同』状态。


2 、如我在 45# 所说，换到 iOS 平台上，这个例子仍然是会引发迷惑的，因为不同的应用对 『连续打开两条 Tweet 』这个情况的处理不同，导致部分应用会返回 Tweet A，部分应用会返回 Twitter 首页。
对于文章中的 『永远都指向一个行为』我表示不认同。

同样的我在 45# 也提到了，Android 对于这种场景，是有规范的，只是很多人不遵守而已；
iOS 对这种场景，却是连个规范都没有，我认为 iOS 在这个场景下表现，实际上是更差的。
（深究原因的话，我觉得是因为这是一个『多窗口』场景，详见 41# ）

3 、虽然我确实是开发，但我不认为这部分属于研发角度，更应当属于交互设计方面，这实际上是与应用自身的逻辑结构相关的，而应用自身的逻辑结构，决定了交互的大框架。


题外话：
实际上，这个事情压根不适合拿 iOS 和 Android 来比较优劣，因为二者压根不是一个东西。
拿 iOS 的设计逻辑来套 Android，或者 Android 的设计逻辑来套 iOS，都是非常不合理的。

我更建议在各自的体系之内，从其自身本源的设计逻辑上入手来查缺补漏。

去年哈理工计算机专业毕业，然后 7 年前就发帖招聘了？ /t/131952

@abersheeran #54
没必要先划定标签，这样是不利于清晰的讨论问题的。
爱之深恨之切，有一些尖锐的声音，往往是重度使用群体才会发出的。

其实看看楼主的博客，楼主更像是一个 Android 粉，或者说的严谨一点：Pixel 历代机型使用者。
https://bilibi.li/2020/05/02/google-pixel-4-xl-review

@mygreens #48
单纯 『从左往右滑的语义』这部分，我觉得没有任何问题。

甚至于，这是比底部的虚拟返回键更明确的语义，因为『按照规范』来说，这时候『 task 栈的逻辑一定是返回上一个页面』，这是非常明确的。

该死的是谁？该死的是那些不按照规范设计的，『 task 栈的逻辑不一定是返回上一个页面』的 APP，是他们导致了这个不明确，而不是完全遵照规范设计的 Android 的手势。

@mygreens #43
我一直强调谷歌的规范，按规范来说，是很明确的，此时一定是返回微信。
（至少从 2015 年至今，谷歌从未修改过这个规范）


实际上，楼主文章中举的例子，在 iOS 上的动作同样是不明确的：
a. 当用户打开一个 Twitter，并点开了 Tweet A ；
b. 然后用户去 Chrome 里搜索一个内容，搜索结果里有另一条 Tweet B，用户很感兴趣，点击了这条搜索结果；
c. 这时候浏览器跳出，自动打开了 Twitter 应用，并跳转到了 Tweet B，这时候，用户点击后退，是应该回到 Tweet A，还是回到浏览器的搜索结果？


在 iOS 上，步骤 C 的迷惑略有不同：
这时候，用户点击后退，是应该回到 Tweet A，还是回到 Twitter 应用的首页？


需要注意的是，iOS 是没有针对这种场景的规范的（至少我没翻到）；
可能有点沾边的是 HIG 中的 Navigation 部分，暗示了不同类型的 Navigation 可以采取不同的方式处理：
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/navigation/

继续补充一下关于 Android 的 Task 机制，这个机制为什么在文档上看起来非常复杂呢？

实际上，这个机制对应的就是 『单应用多窗口』，这个在桌面操作系统上习以为常的功能。
而 iOS 系统，实际上一直只支持 『单应用单窗口』，只有在 iPadOS 之后，才引入了 『单应用多窗口』。

『单应用多窗口』的最常见应用场景，就是微信小程序：
Android 上的微信小程序，是可以展示为和微信同一层级的独立 Task 的，可以直接在多任务界面切换。
而 iOS 系统由于只支持『单应用单窗口』，就需要先切换到 wechatOS，再选择具体的小程序。

当然，在小小的手机屏幕上，引入这种重量级的功能，许多 APP 又不适配，选择将自己做成『单应用单窗口』形态，那必然会引起更多的麻烦，包括对返回键的适配难题。
这样来想，这可能也是为什么 Apple 只在尺寸更大的 iPadOS 上引入这个功能吧。

以上，无关优劣，各有取舍罢了。

@mygreens #38
『官方给的文档开发者看都晦涩，更别指望用户能理解』

这段话不太同意，Android 的这套逻辑，实际上就是为了『辛苦开发者，解放用户』，如果开发者按规矩做了适配，用户层面来说，只要体验保持一致，是没有太大的认知障碍的。
（此处要补一条：不要把其它操作系统的逻辑，先入为主的带入进来，评价 Win 和 macOS 的时候也是同理）


『最大的问题还是谷歌的短见，没有给出成熟的解决方案』

这段话同意一半：
同意的部分是在控件、手势层面上，谷歌确实是三番五次的打自己的脸，折磨开发者，自作自受。
但是在逻辑层面上，其实 Task 的概念一直都未有改变，我前面贴的关于 Task 的文档，印象中至少存在了 6~8 年左右。

@wipbssldo
我不太确定 iOS14 的『待办事项』是否修理了这个问题，实在懒得更新到 14 了，至少 iOS13 还是存在这个问题的。
第三方 APP 里应该也有存在这个问题的，不过需要找一下，之所以选『待办事项』，是因为它是第一方应用，更有讽刺性。

这个问题之前还是引发了大量讨论的，回头我翻一下历史。

@mygreens #31
『 iOS App 不乱实现的话』这段话很重要，系统提供的边缘侧滑返回，实际上是和 UINavigationController 的 Push Pop 相关的，如果你只这样使用，不触碰其它的坑，自然是不会遇到问题。

但是确实没有『乱实现』的么？翻个帖子看看： https://v2ex.com/t/669493


另外，iOS13 之后，Present Modally 的出现，加入了下拉返回的逻辑，带来了更多交互上的迷糊。
想要体验的话，打开『待办事项』，点击新建，在新建页面从左侧边缘向内侧滑，随着从左向右的手势，页面很配合的来了一个下滑的动画。


随着系统的发展、硬件的更迭，新旧交互逻辑混在一起是两家都存在的顽疾，大家都是满脸灰，真就谁也别来嘲笑谁。
至少在我看来，这些问题更大的责任方是第三方 APP，是否有研究对应平台的设计逻辑，做出与平台相匹配的产品。

@mygreens #30
每个用户自身的逻辑思维是不一致的，并不存在统一的用户预期，用户预期是靠 『统一的实现』来培养的。

Google 给出了它认为合理的统一实现（并详细阐述了背后的逻辑）。
然而（大量的）开发者，由于各种原因，没有做相应的配合，导致用户实际体验到的逻辑不一致。


这个问题实际上在各个系统中都存在，只是表现的是否明显，以及用户的谅解程度，例如你楼上提到的 iOS 的侧滑返回适配问题。