价格两三百的话，可以看看能不能搜罗到相应价格的 『电脑棒』

几年前买了 IKBC 的 DC87 和烈焰枪，目前都正常使用，供参考

https://ww1.sinaimg.cn/large/760b39b3gy1gphwhhfhwqj20xa0fm0ve.jpg

感觉这篇文章，和这个帖子有很大关联

https://mp.weixin.qq.com/s/nvSaf2qTr4usvwOHALp00g

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 上引入这个功能吧。

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