这是一个创建于 1314 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
ejin 2021-04-05 22:39:13 +08:00  10
作为安卓用户从来就不疑惑，更不会绝望，为啥？
因为三个键充分的发挥了作用： 中间的弹回桌面或者切换 app 左边的弹出菜单或者选项 右边的后退到上一页 方便到爆好么……… 你非要混合使用，那肯定是错误操作频频出现了，但是实际上除非是纯新手，否则基本上不会混合使用。 相比之下，Windows 的回退键才是真的有问题，一会是输入状态的删除字符使用，非输入状态又变成了网页退回上一页的快捷键，20 年了都还偶尔会中招，输入了一部分内容后跳到上一页，白输入了。（试了下 Chrome 似乎没这问题，看来是 IE 系） |
 |
3
loli 2021-04-05 22:43:51 +08:00 via Android
不知还有没有在用三大金刚的朋友,双击(不用太快,逻辑就是多任务界面再按多任务切换至上一窗口.)多任务键相当到 win 的 alt tab 哦,两个应用间切换不要太方便.
|
 |
4
agagega 2021-04-05 22:52:35 +08:00 via iPhone
用浏览器的时候，右侧左滑还是会后退而不是前进，很反直觉。
iOS 的问题在于没有一个强制性的规范要求应用如何方便地后退。一些手势做得好的应用（比如 Slack ）很少会觉得返回很难受。其实要 iOS 加入一个系统级返回按钮也可行（就是不太完美），点一下直接返回 NavigationView 的上一级（想想长按左上角返回箭头也能出现上一级列表），就是按苹果的作风应该放到辅助功能里。 |
 |
5
also24 2021-04-05 22:55:44 +08:00 4
关于文章中的问题 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 内部的逻辑层级，不关心你之前在干啥。 |
|
6
also24 2021-04-05 23:01:18 +08:00
关于文章中的问题 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 个应用之间切换，请在“主屏幕”图标 主屏幕 上向右滑动。 “三按钮”导航：点按“概览”图标 概览。向右滑动，直到屏幕上显示您所需的应用。点按该应用。 |
|
8
also24 2021-04-05 23:08:33 +08:00
补充：
在搭配 3D Touch 功能的 iPhone 机型上，支持重按左侧边缘呼出多任务页面， iOS 11 曾因为取消了此功能招致大量反馈： https://www.macrumors.com/2017/09/21/3d-touch-app-switcher-gesture-will-return/ |
|
9
also24 2021-04-05 23:10:31 +08:00
@haruhi #7
在我看来，滑动底部切换 APP，是比呼出多任务页面，更加『高级』的操作，因为你不但需要有明确的多任务意识，还需要对 APP 的先后关系有一定的逻辑认知。 |
 |
10
bkmi 2021-04-05 23:13:51 +08:00 via Android
@also24 我感觉你刚好说反了，系统的 back 按钮才是应该处理 "返回" 这个逻辑，比如弹框可以关闭，输入法可以收起；
而页面上的返回剪头，也就是你说的 “up button”，应该直接返回上一个页面，典型案例就是输入法激活的状态下，也应该直接返回上一页。 |
|
11
also24 2021-04-05 23:20:07 +08:00
@bkmi #10
我这个 『页面』，专门引用了原文中的 "screen"，就是担心引起误解，果然还是引起了。 这个不是指 APP 内部的页面，而是说你看到的那个『屏幕中的内容』，可以更粗略的理解为『将屏幕还原为上一个状态』。（此处不严谨，主要是粗略含义） 实际上引入 Android 的 Activity 栈 Fragment 栈会更好理解， "Back Button" 就是一个简单的出栈操作。 而对于 "Up Button"，应该返回的是『上一级』而非『上一个』页面，是与 APP 的内部逻辑相关联的。 |
|
12
also24 2021-04-05 23:22:48 +08:00
以楼主的例子来分析：
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 ）才对。 |
 |
13
S179276SP 2021-04-05 23:40:54 +08:00 via Android
现在谷歌不晓得咋想的，18 年把 youtube 改的操作逻辑贼难用，视频返回直接到主界面不是上一个视频，右下角小窗非要底部小小窗。后来 chrome 层叠标签左右滑动关闭改成大方块。
|
 |
14
feiandxs 2021-04-05 23:48:15 +08:00
作为曾经的 Android 用户，现在的 iOS 用户，我觉得 Android 上什么东西都没让我特别印象深刻过，但是那三个导航键简直好用到爆。这点上我觉得 iOS 的底部任务条只是个拙劣的实现。
iOS 在这一根小横条的操作上确实也做到了几乎登峰造极，但我还是觉得，其实本可不必如此麻烦的。 |
 |
15
codehz 2021-04-06 00:09:42 +08:00
android 多任务最大的问题是隐藏在背后的逻辑问题，这个永远不是交互设计所能解决的。。。
什么逻辑呢，就是 android 自带了一个返回堆栈，不同的 activity 正常切换时，应该可以维护这个栈，返回键能返回到上一个界面，回到启动器点开新 app，或者点击通知，应该会启动一个新的栈（暂且不提那些设计不良的，滥用 clear top,single top 的） 但是呢，一旦你使用任务切换功能，以上功能就会被完全破坏了，返回键很有可能是直接回到启动器，再也找不回原来的栈了。。。 更别说应用内部的导航也可以轻易破坏这个栈，使得返回键存在的意义被无限缩小，用户需要小心谨慎的使用手机，才可以在按下返回键的时候有充足的自信预测下一帧看到的画面是桌面还是前一个应用。。。（关键也没个提示告诉你返回键是回到桌面还是上个应用） 一个理想的多任务切换，应该把这个结构拓展成有向无环图，A 界面导航到 B 界面，然后返回 A 界面导航到 C 界面，再切换到 B 界面按下返回键时应该能回到 A 界面，再次切换 C 界面时，也应该能够回到 A 界面。 |
 |
16
NSAgold 2021-04-06 00:36:40 +08:00 via Android
“这里需要指出的是，“三大金刚按钮”实际上是由 Android 3.0 引入，但该系统仅仅运行在平板。↩︎”
不严谨，应改成“navbar 中的三大金刚按钮” 因为屏幕外的三大金刚按钮（电容式，按键式）从安卓 1.x 时代就有了 联系上下文没问题，但是单看注释并不严谨 现在有一部分国产应用已经走在了遵循该规范的路上了，这是好的。 |
|
17
also24 2021-04-06 00:41:57 +08:00
@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 确实存在极其混乱的状态。 |
 |
19
stabc 2021-04-06 00:59:20 +08:00
很喜欢 Android 的返回键，很方便。ios 的返回键一般在左上角很难按到，不知道为什么没见很多人吐槽这个。
|
 |
20
murmur 2021-04-06 08:08:11 +08:00
国产 android 的 nav bar 是可以选的，你要全面屏就全面屏，你要金刚按键就金刚按键
|
 |
21
mx8Y3o5w3M70LC4y 2021-04-06 08:12:18 +08:00 via Android
@stabc 因为 iOS 的返回是手势操作，左侧边缘右滑返回
|
|
22
murmur 2021-04-06 08:35:11 +08:00
|
 |
23
dingwen07 2021-04-06 08:49:18 +08:00 via Android 2
iOS 的返回逻辑才令人头大，没有系统级别的返回实现。特别是“全屏弹窗”这个东西，有时候能下拉退出有时候不行，有时候能向右滑动退出有时候不行，完全无法预测。。。
还有在微信内置浏览器里，需要用底部的浏览器方向键，右滑返回会直接退出内置浏览器 |
 |
24
Lin0936 2021-04-06 08:55:05 +08:00
在用 Android11 with 三大金刚
|
 |
25
DOLLOR 2021-04-06 08:58:07 +08:00
三大金刚多好，从第一次玩 android 到今天都在用，哪怕“全面屏时代”也是。
|
 |
26
imicksoft 2021-04-06 09:13:25 +08:00
喜欢物理三大金刚
|
 |
28
cmdOptionKana 2021-04-06 10:17:34 +08:00
用了一段时间全屏手势，还是不习惯，改回三大金刚了，幸好安卓机自由度大，爱怎么样都可以改。
|
 |
29
FlyingShark 2021-04-06 11:21:23 +08:00 4
感觉标题说反了，应该是 “令人绝望的 ios”，有些可以边缘右滑返回，有些必须按返回键，令人费解
|
 |
30
mygreens 2021-04-06 12:50:26 +08:00
@also24 问题 2 通过 activity 栈实现不同逻辑。问题是用户对于实体返回键的行为没有预期，到底是返回上一个页面，还是上一个 app，还是收起键盘，开发者的实现逻辑对用户完全是黑盒。
|
|
31
mygreens 2021-04-06 12:55:15 +08:00
iOS App 不乱实现的话，怎样返回是很直观的，看一眼就知道是下滑还是右滑。觉得不好用是用安卓的上帝返回键太久了，相反是反逻辑的，手势和各种组件冲突，没有动画，需要 app 自己来擦屁股。
|
|
32
also24 2021-04-06 12:57:52 +08:00
@mygreens #30
每个用户自身的逻辑思维是不一致的，并不存在统一的用户预期，用户预期是靠 『统一的实现』来培养的。 Google 给出了它认为合理的统一实现（并详细阐述了背后的逻辑）。 然而（大量的）开发者，由于各种原因，没有做相应的配合，导致用户实际体验到的逻辑不一致。 这个问题实际上在各个系统中都存在，只是表现的是否明显，以及用户的谅解程度，例如你楼上提到的 iOS 的侧滑返回适配问题。 |
 |
33
TypeError 2021-04-06 13:27:10 +08:00
三大金刚多好用，
全面屏下都舒服，手势也只能辅助，不能替代 |
|
34
also24 2021-04-06 13:42:45 +08:00
@mygreens #31
『 iOS App 不乱实现的话』这段话很重要，系统提供的边缘侧滑返回，实际上是和 UINavigationController 的 Push Pop 相关的，如果你只这样使用，不触碰其它的坑，自然是不会遇到问题。 但是确实没有『乱实现』的么？翻个帖子看看： https://v2ex.com/t/669493 另外，iOS13 之后，Present Modally 的出现，加入了下拉返回的逻辑，带来了更多交互上的迷糊。 想要体验的话，打开『待办事项』，点击新建，在新建页面从左侧边缘向内侧滑，随着从左向右的手势，页面很配合的来了一个下滑的动画。 随着系统的发展、硬件的更迭，新旧交互逻辑混在一起是两家都存在的顽疾，大家都是满脸灰，真就谁也别来嘲笑谁。 至少在我看来，这些问题更大的责任方是第三方 APP，是否有研究对应平台的设计逻辑，做出与平台相匹配的产品。 |
 |
35
wipbssldo 2021-04-06 13:54:00 +08:00
@also24 「另外，iOS13 之后，Present Modally 的出现，加入了下拉返回的逻辑，带来了更多交互上的迷糊。
想要体验的话，打开『待办事项』，点击新建，在新建页面从左侧边缘向内侧滑，随着从左向右的手势，页面很配合的来了一个下滑的动画。」 iOS14.3 并没有复现 |
 |
36
Jooooooooo 2021-04-06 13:56:48 +08:00 1
苹果的返回才让人头大
|
|
37
also24 2021-04-06 13:59:13 +08:00 via Android
@wipbssldo
我不太确定 iOS14 的『待办事项』是否修理了这个问题，实在懒得更新到 14 了，至少 iOS13 还是存在这个问题的。 第三方 APP 里应该也有存在这个问题的，不过需要找一下，之所以选『待办事项』，是因为它是第一方应用，更有讽刺性。 这个问题之前还是引发了大量讨论的，回头我翻一下历史。 |
|
38
mygreens 2021-04-06 14:17:09 +08:00
@also24 大部分同意。iOS 上只要遵循哪个方向弹出来的页面，从反方向下滑就可以返回逻辑，基本可以覆盖所有 app （微博之类的除外），这个逻辑很直观，在 app 间跳转的情况，系统也会在左上角给出返回上一个 app 的按钮。
安卓的问题在于最开始做按键机遗留下的硬返回键，返回目标不明确。官方给的文档开发者看都晦涩，更别指望用户能理解。 全面屏风潮之后学习 iPhone 的返回手势，和自己的汉堡菜单冲突，官方的方案居然是让开发者停用返回手势（长按 peek 只支持 DrawerLayout ）。安卓的侧滑返回只是硬返回的另一种拙劣实现，目测还需要几个版本擦屁股。 最大的问题还是谷歌的短见，没有给出成熟的解决方案，导航样式 3 年 3 个样也是没谁。从刘海开始流行以后，官方给出适配全面屏的 api 一直在改，导致开发适配难度大，app 不适配很大程度是谷歌的问题。 |
|
39
mygreens 2021-04-06 14:25:03 +08:00
汉堡菜单在手势返回出现之前，就是个失败的东西，谷歌一直不承认（ Gmail 也还在用），给不解决问题，这种行为是很恼人的。
|
|
40
also24 2021-04-06 14:25:53 +08:00
@mygreens #38
『官方给的文档开发者看都晦涩，更别指望用户能理解』 这段话不太同意，Android 的这套逻辑，实际上就是为了『辛苦开发者，解放用户』，如果开发者按规矩做了适配，用户层面来说，只要体验保持一致，是没有太大的认知障碍的。 （此处要补一条：不要把其它操作系统的逻辑，先入为主的带入进来，评价 Win 和 macOS 的时候也是同理） 『最大的问题还是谷歌的短见，没有给出成熟的解决方案』 这段话同意一半： 同意的部分是在控件、手势层面上，谷歌确实是三番五次的打自己的脸，折磨开发者，自作自受。 但是在逻辑层面上，其实 Task 的概念一直都未有改变，我前面贴的关于 Task 的文档，印象中至少存在了 6~8 年左右。 |
|
41
also24 2021-04-06 14:40:49 +08:00
继续补充一下关于 Android 的 Task 机制，这个机制为什么在文档上看起来非常复杂呢？
实际上，这个机制对应的就是 『单应用多窗口』，这个在桌面操作系统上习以为常的功能。 而 iOS 系统，实际上一直只支持 『单应用单窗口』，只有在 iPadOS 之后，才引入了 『单应用多窗口』。 『单应用多窗口』的最常见应用场景，就是微信小程序： Android 上的微信小程序，是可以展示为和微信同一层级的独立 Task 的，可以直接在多任务界面切换。 而 iOS 系统由于只支持『单应用单窗口』，就需要先切换到 wechatOS，再选择具体的小程序。 当然，在小小的手机屏幕上，引入这种重量级的功能，许多 APP 又不适配，选择将自己做成『单应用单窗口』形态，那必然会引起更多的麻烦，包括对返回键的适配难题。 这样来想，这可能也是为什么 Apple 只在尺寸更大的 iPadOS 上引入这个功能吧。 以上，无关优劣，各有取舍罢了。 |
 |
42
KyonLi 2021-04-06 14:42:26 +08:00
前几天更新了 Android 11 发现返回手势还是不跟手，手指的操作已经完成离开屏幕了返回动画才刚开始
|
|
43
mygreens 2021-04-06 14:54:09 +08:00
@also24 Task 不是多窗口的问题。比如在微信看到一个链接，点击之后跳转到系统浏览器（假设可以），在浏览器消费完之后想返回，这时候点返回究竟是返回到浏览器主页，还是到微信，这个是不明确的，app 会拦截返回事件做自己的逻辑，不同的 app 实现都不同，给用户很大的迷惑。相比 iOS 在这种情况下会在通知栏显示返回上一个 app 按钮。
硬返回键确实方便，但是有目的上的迷惑，并且手势和页面冲突，iOS 的返回有很多问题，但谷歌的反逻辑操作更迷惑，这个谷歌自己都不想解决。 |
 |
44
clf 2021-04-06 14:56:31 +08:00
个人认为 Android 的返回逻辑是挺清晰的，无论 App 有没有做所谓的适配，我的返回按钮都会执行默认的返回逻辑。按钮改边缘滑动无疑是对全面屏的适配。
（ IOS 也做了适配，但没有要求强制实现，且没有默认的返回逻辑，所以可能出现：5 个连续的页面浏览中，前面 2 个和后面 2 个是可以左滑返回的，中间一个必须点左上角返回。这是我退坑 IOS 的原因之一，手没这么大，点左上角太累了。所以个人认为 IOS 目前的 UI 交互逻辑适合小屏时代而不适合全面屏时代。 |
|
45
also24 2021-04-06 15:08:20 +08:00
@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/ |
 |
46
huaxianyan 2021-04-06 15:09:11 +08:00
|
 |
47
binux 2021-04-06 15:19:26 +08:00 via Android
你知道 iOS 的四种后退吗？
photo 的后退在左上 lookup 的后退在右上 浏览器的后退在左下 有道词典的后退在正下方 |
|
48
mygreens 2021-04-06 15:21:33 +08:00
@also24 我的看法是，不管是不是遵从规范，只要是硬返回键，大不了多点几下总能返回到上一个 app，安卓的返回键用了十年也什么大问题。
但是手势导航之后，官方开始模仿 iOS，从左往右滑的语义就是要把当前页面滑走，但安卓上映射到的是物理返回键，这时候 task 栈的逻辑不一定是返回上一个页面，这个才是让人迷惑的点。谷歌只是照搬手势，产生的逻辑上的和跟老控件之间的冲突一概不管，目测未来几个版本还要改，这个是灾难级的。 |
|
49
mygreens 2021-04-06 15:24:00 +08:00
@also24 安卓 9 上的胶囊按钮应该是处于这种考量，之后看到 oem 全部改成手势之后也跟着改，但是不解决由此产生的问题，这对开发者和用户都是无法接受的。
|
|
50
also24 2021-04-06 15:25:47 +08:00
@mygreens #48
单纯 『从左往右滑的语义』这部分，我觉得没有任何问题。 甚至于，这是比底部的虚拟返回键更明确的语义，因为『按照规范』来说，这时候『 task 栈的逻辑一定是返回上一个页面』，这是非常明确的。 该死的是谁？该死的是那些不按照规范设计的，『 task 栈的逻辑不一定是返回上一个页面』的 APP，是他们导致了这个不明确，而不是完全遵照规范设计的 Android 的手势。 |
 |
52
idealhs 2021-04-06 16:18:38 +08:00
android 转 iOS 说一说个人体验
iOS 的返回，不是被 Google Android 完爆？ Google Android 的返回，不是被魅族 mBack 完爆？ |
 |
53
camillo 2021-04-06 16:23:13 +08:00
汉堡菜单 Google 已经开始改了估计
Google Play 最新版已经取消掉汉堡 变成点击首页右上角的头像弹出菜单的形式了 和 Gmail 里那个一样 但是 Gmail 那个弹出菜单是只有账号切换管理相关功能的 邮件相关的一长串功能还是塞在汉堡里…… 所以也不知道 Google 下一步会怎么走 菜单内容比较少的可以像 Play 这样塞进头像弹窗里 多的怎么办 拭目以待 |
 |
54
abersheeran 2021-04-06 16:54:09 +08:00
我觉得果粉没必要踩安卓来抬高 iOS 吧。
有钱买苹果的，基本都会买个苹果意思意思，没钱买苹果的你再吹别人也不会买的。 另外，我就是你说的那个 8 -> 10 的安卓用户。我没有丝毫不适应。你不适应，因为你是果粉，是你的问题，不是安卓的问题，更不是安卓用户的问题。 |
|
55
also24 2021-04-06 17:30:32 +08:00
@abersheeran #54
没必要先划定标签，这样是不利于清晰的讨论问题的。 爱之深恨之切，有一些尖锐的声音，往往是重度使用群体才会发出的。 其实看看楼主的博客，楼主更像是一个 Android 粉，或者说的严谨一点：Pixel 历代机型使用者。 https://bilibi.li/2020/05/02/google-pixel-4-xl-review |
|
56
abersheeran 2021-04-06 17:32:25 +08:00
@also24 我倒觉得只是反串黑。
|
 |
57
borisz 2021-04-06 17:38:16 +08:00
真实怀念魅族的小圆点
|
 |
58
marcong95 2021-04-06 17:47:53 +08:00
作为 Android 手机 + iPad 用户，iOS 没有系统级的返回操作才是让人绝望，所谓的屏幕边缘右划返回在 [小屏] 手机且 app 正确实现的前提下确实是比较符合直觉的。但是，在大屏手机甚至平板上，你往往基本上只能点击左上方的返回按钮，而且在横屏且具有侧栏的 app 上，这个返回按钮在 [中上偏左] ，而非左上，极难定位
|
 |
59
psklf 2021-04-06 19:36:40 +08:00
一直坚持保留三个按键。拒绝手势。
|
 |
61
chencc48111 2021-04-06 20:35:05 +08:00
苹果 ,再一次改变世界
|
 |
62
haruhi OP @also24
感谢提供的链接和相关信息，已经在原文中更新。不过想指出的是：假设所有 Android App 都遵循准则，依然无法回避一个问题——用户首次遇到文中的场景，点击 Navbar 退后时，用户并不知道会后退到哪个页面（当然，后退认知的习惯，的确可以在多次交互的教育后培养）。 长期的 Android 用户，从 Galaxy Nexus 开始，经历历代 Nexus 以及类原生手机（如历代 Moto X ），再最终换到 Pixel，算是 Android 粉了。 下一期估计会吐槽下 Android 分享菜单，接着会是多任务页面变化、Dark Theme 设计准则变化、通知栏 /Quick Settings 变化。 再次感谢，提供从研发角度看问题。之前是没有考虑这块的。 |
|
63
haruhi OP |
|
64
haruhi OP |
|
65
haruhi OP @binux
还是回到了：iOS 点击后退时（以及 Look Up，我理解是 dismiss 窗口，而不是后退），是有明确预期的，并不需要教育用户。 但 Android 即使彻底遵循设计要求，用户首次遇到文中的场景里，点击后退，则是在教育用户，点击 Navbar 的后退是回到上一个 App，而不是在当前 App 里后退。 |
|
66
also24 2021-04-06 23:47:31 +08:00
@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，都是非常不合理的。 我更建议在各自的体系之内，从其自身本源的设计逻辑上入手来查缺补漏。 |
|
68
also24 2021-04-07 00:00:37 +08:00
@haruhi #65
关于 『点击 Navbar 的后退是回到上一个 App，而不是在当前 App 里后退』 其实是很好理解的，因为 Android 系统的返回按钮，是在『 APP 外』的： 那么自然是以 APP 外（系统）的视角来后退页面，也就是上一个 APP 内。 如果想要 『在当前 App 里后退』，那很简单啊，需要点击『 APP 内』的后退按钮： 也就是点击 "Up Button"，结果也是符合预期的，返回了 『 APP 内』的上一个页面。 iOS 的返回按钮为什么符合你的想法，因为 iOS 只有『 APP 内』的返回按钮啊。 |
 |
70
Darkatse 2021-04-07 03:36:19 +08:00 via Android
iOS 的后退才是令人绝望，混乱的不行。官方提倡的滑动返回也没有实体的返回键用的舒适，更别提还有适配问题
|
 |
71
chendeshen 2021-04-07 08:16:34 +08:00 via Android
我只想说...我一直双持两个系统的手机，实话实说 Android 的三大金刚效率远高于 iOS 的（手势）切换交互。绝对秒杀，一直以来多年以来都是。
|
 |
72
fuchunliu 2021-04-07 08:17:02 +08:00 via Android
对于安卓用户来说，你这是无病呻吟，安卓用户没有楼主的烦恼
|
 |
74
q197 2021-04-07 09:59:41 +08:00
安卓 10 等后来的版本可以开启三大金刚不用手势，我就是只用三大金刚，毕竟键位固定不会按错，而且现在手机屏幕这么长完全不需要节省那点空间
|
 |
75
tanranran 2021-04-07 10:01:05 +08:00
楼主一看就是对安卓没有深入使用的
|
 |
76
lostpg 2021-04-07 10:24:47 +08:00 via Android
说起来，iOS 有个很喜感的地方在于，如果一个页面没有返回键，用户除了杀掉任务以外对此似乎无能为力。前段时间淘宝就有些活动的 h5 页面没有放置返回键，用户点进去以后就困死在这个页面里出不来了。。
|
 |
77
wangxiaoaer 2021-04-07 10:31:24 +08:00
看你写的洋洋洒洒，就好比认为吃饭的时候 拿筷子的姿势，夹菜的姿势，碗的摆放姿势，放到口里的姿势等等都让吃饭这件事情很绝望，可是吃饭没那么多事儿啊。
我用 Android5 年以上就没考虑过你说的那些个问题，更没有觉得疑惑、绝望等等，一个返回键打天下不是吹的，起码在 99%的情况下。 至于 iOS，我就呵呵了，一会左滑，一会儿左上角，一会儿右上角，一会下拉，这才是绝望好吗？跟别说那个左滑如果碰到轮播图或者视频、看图软件，那才是绝望。 |
 |
78
WebKit 2021-10-15 09:20:40 +08:00
看到第一段就不想看了:
对于 iOS，给予用户方便的后退方式，则是在 2013 年的 iOS 7 中才引入了侧滑后退。 对于 iOS，给予用户方便的后退方式，iOS 返回方便吗？你试试单手拿手机的时候，是底下的按钮好按，还是屏幕上面的按钮更容易按？单手+下手呢？从一开始就带有个人情绪在里面。只能说是一篇发泄自己情绪的文章。 |
Select Language