@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 的侧滑返回适配问题。

咦，想到了这个帖子 /t/767613

@NSAgold #16
https://i.v2ex.co/504J5BO2.png 严谨一点，那时候是四大金刚，还有搜索键呢（而且顺序还不确定）

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

@codehz #15
我觉得 Android 在系统设计层面上的逻辑还是清晰的，因为它实际上还有一个叫做 "Task" 的层级存在。

我们常说的『多任务切换』，实际上切换的并不是 Application 或者 Activity，而是 Task （任务）。

关于这部分的文档可以参见：
https://developer.android.com/guide/components/activities/tasks-and-back-stack
https://developer.android.com/guide/components/activities/recents


但是还是那句话，认真按照规范实现的应用实在是太小了，Android 精心设计的这一套逻辑，实际中的应用大多并未遵守，导致现实世界中的 Android 确实存在极其混乱的状态。

以楼主的例子来分析：
a. 当用户打开一个 Twitter，并点开了 Tweet A ；
b. 然后用户去 Chrome 里搜索一个内容，搜索结果里有另一条 Tweet B，用户很感兴趣，点击了这条搜索结果；
c. 这时候浏览器跳出，自动打开了 Twitter 应用，并跳转到了 Tweet B，这时候，用户点击后退，是应该回到 Tweet A，还是回到浏览器的搜索结果？


假如用户此时点击的是 "Back Button" ，因为 Activity 栈的上一条是 Chrome，那就直接返回 Chrome 就好。
而如果用户此时点击的是 "Up Button"，此时应当返回的是 Twitter APP 的主页面（注意不是 Tweet A ）才对。

@bkmi #10
我这个 『页面』，专门引用了原文中的 "screen"，就是担心引起误解，果然还是引起了。
这个不是指 APP 内部的页面，而是说你看到的那个『屏幕中的内容』，可以更粗略的理解为『将屏幕还原为上一个状态』。（此处不严谨，主要是粗略含义）

实际上引入 Android 的 Activity 栈 Fragment 栈会更好理解， "Back Button" 就是一个简单的出栈操作。


而对于 "Up Button"，应该返回的是『上一级』而非『上一个』页面，是与 APP 的内部逻辑相关联的。

@haruhi #7
在我看来，滑动底部切换 APP，是比呼出多任务页面，更加『高级』的操作，因为你不但需要有明确的多任务意识，还需要对 APP 的先后关系有一定的逻辑认知。

补充：
在搭配 3D Touch 功能的 iPhone 机型上，支持重按左侧边缘呼出多任务页面，

iOS 11 曾因为取消了此功能招致大量反馈：
https://www.macrumors.com/2017/09/21/3d-touch-app-switcher-gesture-will-return/

关于文章中的问题 3，有一些地方需要补充：

『 iOS 的多任务，一直都是一个“高级操作”，从来没有一个按钮可以让用户“一键”多任务』

实际上 iOS 支持在底部滑动来快速切换应用：
https://support.apple.com/zh-sg/guide/iphone/iph1a1f981ad/ios
在配备面容 ID 的 iPhone 上，若要在打开的 App 之间快速切换，请沿屏幕底部边缘向右或向左轻扫。

同样的 ，Android 9/10 也是支持这个手势的：
https://support.google.com/android/answer/9079644?hl=zh-Hans#zippy=%2C%E5%9C%A8%E5%BA%94%E7%94%A8%E4%B9%8B%E9%97%B4%E5%88%87%E6%8D%A2
手势导航：在屏幕的最底部，从左向右滑动。
“双按钮”导航：要在您最近使用过的 2 个应用之间切换，请在“主屏幕”图标 主屏幕 上向右滑动。
“三按钮”导航：点按“概览”图标 概览。向右滑动，直到屏幕上显示您所需的应用。点按该应用。

关于文章中的问题 2，这实际上是 Android 很早就在设计规范中有说明的：
https://developer.android.com/guide/navigation/navigation-principles#up_and_back_are_identical_within_your_apps_task

实际上就是 " Back Buttom" 和 "Up Button" 的区别，但是比较让人无奈的是，几乎所有的 APP，从一开始就无视了这个规范，这个规范也变得名存实亡，以至于荼毒至今。

在我看来这其实是 Android 多任务体系的重要一环，我个人非常喜欢这个规范中所体现出的内在逻辑：
系统层级的 Back Button 管理的是 screen （页面），不关心你是什么 APP ；
APP 内的 Up Button 管理的才是 APP 内部的逻辑层级，不关心你之前在干啥。

@GeruzoniAnsasu
Trackpad 上是『三指拖移』，

其它笔记本上是『单击锁定』，也就是 10 楼说的方法。

买之前对效果很期待，买之后发现用不到。

点击：一直是『轻击』，不需要用力按
右键：一直是『两指点击』，不需要用力按
拖动：一直是『三指拖移』，不需要用力按

确实是用不到。

『但每次都失败』指的是归档失败，还是下载失败呢？

如果指的是下载失败，建议不要直接下载，而是先曲线救国，保存到 onedrive 再下载。

@leimao #10
醒醒，1990 年过去 30 年了 https://i.v2ex.co/504J5BO2.png

就正常的列编辑就可以，但需要注意复制的行数和粘贴的行数需要一致；
当复制的行数和粘贴的行数不匹配的时候，才会出现你说的那种情况。