Popup

弹窗的概念如今已被泛化，主要功能：信息传递与用户反馈。
从是否强制用户交互的角度分类：模态弹窗和非模态弹窗，都位于当前页面的最顶层
模态弹窗：
I.ios-Alert；Material Design-Dialogs
2.ios-Action Sheet
3.ios-Activity Views
4.ios-Popover；Material Design-Menus
5.MD-Sheet

模态弹窗：强交互形式，通常当用户进行重要、有风险或需要用户确认时使用，需要中断用户，用户必须完成对话框内任务（或主动关闭后）才能够继续主面板操作的弹窗。优点：辅助用户顺利完成任务，传递产品信息。缺点：用户操作心流频频打断，增加无用的操作，让用户产生沮丧情绪。

分类一：Alert和Dialogs（警告对话框）（强）
位置置于屏幕中心，用作显示系统的重要信息，告知用户特定的任务，并请求用户进行操作反馈，作出决定或使其参与多项任务。
使用场合最广泛，极易获取用户注意力，干扰度/警示性最高。HIG和MD明确克制此类的设计，alert通常用于紧急不可逆情况的提示，需要用户确认该信息。
注意：不滥用尽可能少用，无预期的频繁打断用户会引起反感；标题简明，不要使用“抱歉打扰”“危险！”“你确定”此类道歉警告含糊不清的标题，不超过2行，描述内容简明，不超过3行；按钮最多竖排3个，横排2个，以上考虑ActionSheet，建议使用三种按钮文案：确定文案“如删除/导出”，驳回文案“如取消”，确认文案“我知道了/好的”；一般用户最可能点击按钮（主操作）放在右侧，取消按钮始终放在左侧。不能被其他元素遮挡，需要一直保持焦点直到被关闭或某个动作已被执行。Dialog存在时禁止滚动对话框以外的元素，如背景。

HIG&MD

应用：系统层面的包括消息提示、信息确认、提交内容。

ios&android a.消息提示弹窗有五个模块：插图、大标题、副标题、操作、半透明。插图是辅助手段，形成app风格和品牌宣传入口，加强用户认知。 image.png

b.消息确认弹窗与消息提示不同的区别是操作部分，消息确认的弹窗至少有两项操作。一般分为肯定操作+否定操作。肯定右侧取消左侧，符合系统规范和用户习惯，同时，肯定性操作文案尽量用动作本身代替“确定”。还有取消操作可以放置在右上角，保留一个就好，避免冗余。
c.提交内容弹窗被赋予的功能较多，形式多样。但基本构成不变：标题，内容，确定性操作与否定性操作。由于提交内容弹窗需要调用系统键盘（个性化），设计时需要考虑适配小屏 操作按钮是否被键盘遮挡。（任何涉及调用键盘的页面都需要考虑遮挡问题，如果无法避免，则需要确定最重要的部分/操作露出）

image.png
显示与消失：Alert仅支持两种关闭方式：点击确定按钮立即执行并关闭；点击取消按钮取消操作并关闭
Android dialog类别

警告（alerts）是紧急中断，通知有关情况并要求确认。
简单菜单（simple menus）显示列表项的选项。
简单提示框（simple dialogs）可以提供有关列表项的详细信息或操作。
确认提示框（confirmation dialogs）要求用户明确确认选项。
全屏提示框（full-size），仅限手机，适合复杂的任务，或需要输入法编辑器，因为它可以在保存之前将一系列任务组合在一起
注意：对话框不应该被其他元素或屏幕边缘遮挡。始终保持视觉聚焦，直到被关闭或被完成了其中重要的行动。谨慎使用，因为提示框有中断性的，突然出现会迫使用户

Simple dialog,GMD原生控件，通常用于提供列表项的详细信息或操作
宽度：width=5x x=56，与屏幕左右边缘的距离应该至少为40dp，距离顶部和底部至少24dp，改对话框的内容距离提示框边缘为24dp

android

支持3种关闭方式：点击一个选项后立即执行提交选项并关闭菜单；点击dialog外任意区域取消操作并关闭；android系统返回键关闭
注意：简单提示框没有明确的按钮来接受或取消操作。允许文字换行。简单提示框比简单菜单更具有中断性，慎用。

范例：keep的话题举报操作（ios action sheet） image.png Alert警告对话框，是紧急中断，需要确认，通知用户有关情况。snackbar在行动后提供可选信息，例如确认放弃草稿。他们经常允许用户撤销刚刚采取的操作。警告没有标题栏，大多数警告不需要标题。形式包含：提出问题（例如删除此对话？），做出与操作按钮有关的声明 按钮文案明确接下来发生的操作
带有标题的警告，仅对高风险情况使用带标题的警告，例如链接可能丢失。如果需要标题，在内容区域使用明确的问题或陈诉，例如“擦除录入内容？”，注意避免道歉，模棱两可或提问，例如“警告！；你确定吗？” 标题需要明确告知结果

Confirm dialog确认对话框，GMD原生控件，通常用于用户在复杂操作前的最终确认他们的选择。有明确的确认和取消按钮，支持嵌套selection controls，应该尽量避免内容滑动，当确实需要滑动时，标题需固定在顶部，按钮固定在底部，保证滚动的同时仍然可见标题和按钮

confirm

点击确认对话框的取消，或按android的后退，取消操作，放弃所有更改并关闭对话框。

范例：原生安卓系统的彩铃设置功能 confirm
确认单个值，确认提示框可以使用列表以外的布局，例如日期选择器，但仍然专注于选定单个值（选择日期，但不选择时间和日期） image.png

Full-screen dialogs 全屏对话框，GMD原生控件，通常用于对一系列复杂任务被提交或取消之前的分组。

注意事项：仅在以下场景中使用Full-screen，有需要用户输入的选择器或表单时；编辑的内容无法实时保存时；没有本地自动保存的草稿功能；在提交前需要进行批量处理或更改队列时。Full-screen仅限移动端使用。需要在top app bar上展示关闭的X和确认性按钮。屏幕右上角的确认使用描述性动词，而非完成，确定等模糊动作。确认按钮将被禁用，直到满足对话框的所有必填字段都完成时，确认操作才会被激活 full-screen
显示时填充全屏，使用沉浸式的全屏布局。注意点击X或系统返回键时，将放弃所有更改信息并退出，如果用户发生了字段的更改，需要给予confirm dialog进行二次确认。
全屏幕对话框中使用的"X"不同于返回箭头，箭头能表示视图的状态实时被保存。例如，设置中使用的返回箭头表示所有更改立即提交，无需明确的确认或取消操作。 两种形式
全屏提示框的标题应该简洁，不使用动态类型，如有必要，可以换行到第二行，长于第二行应该加上省略号。如果确定标题特别长（多语言），将标题文本置于对话框的内容区域而不是最上面的导航栏。 建议右侧
全屏对话框可能会打开其他对话框（开启简单菜单或简单提示框），例如选择器，因为他们的设计可以容纳额外的材料层，而不会显着增加app深度的感知和视觉干扰
范例：Teambition使用full-screen来承载date picker和time picker的多重时间设置。
full-screen

开发适配：一种开发直接调用系统的原生对话框组件。方便适配，但需要注意配置操作高亮选项。另一种是代码单独写。可以定制化样式，但注意不同机型的适配，一般包含固定宽高尺寸和等比缩放。可以设计一个弹窗的宽高尺寸范围，比例缩放。

分类二：Action Sheet（动作面板 / 动作菜单 / 行动列表）
移动设备的屏幕空间是宝贵的，不可能把所有的选项罗列在一个页面上，如果反其道而行把相关程度非常高的操作分割到多个页面上，又会造成操作繁琐体验不连续的感觉，Action Sheet能承载较多内容，而且仅覆盖当前屏幕的一部分，即不会对用户心流有很大干扰，操作也便捷。适合呈现与当前任务相关的多个选项，且选项相对较少的情况下。

原ios独有，现在日渐安卓化和可定制加强。一种的响应控件，需要用户执行了某个操作才会从底部弹出。提供和当前场景相关的2个以上的同类型的操作动作（如启动某个任务，或确认是否开始执行某个可能具有破坏性的操作），也支持标题和描述，内置固定展示样式。 image.png

显示与消失：从底部向上滑入，从底部滑出（出发选项、点击浮窗外的区域、点击取消按钮）
注意：突出破坏性选项（对于用户执行破坏性或危险性操作按钮，应当使用红色高亮显示，并放置在顶部）；提供清晰的退出按钮（定制化右上角关闭），取消按钮始终存于动作面板底部（虽然用户可以点击屏幕任何空白位置区域取消Action Sheet，但取消按钮可以在用户不想执行任何操作时，给予用户明确的操作指向）；避免出现纵向滚动（不要放置过多的操作项，横向触发区域很大，滚动会误触。可采用activity views）；不同屏幕尺寸的呈现样式，iphone占据屏幕底部；ipad继续在底部的话，注意力切换和手指移动的路径会很长，所以通常在触发区域附近以popover呈现，这时，不需要取消的按钮，因为点击宽广的空白区域关闭更方便。；清晰准确的描述，如果一个页面有多个唤起Action sheet的对象，例如文件列表，点击某个文件夹弹出Action Sheet后遮盖了页面，用户不知道当前操作的文件是哪个，也许就会引发误操作；合理的视觉强调手法，出于业务考虑，有时我们希望用户更多的点击其中某个选项。如豆瓣/loft里改版后调整选项样式。

豆瓣
loft
ipad.png
Dropbox对文件的描述.png
HIG
IOS
范例：微信选择朋友圈发布类型及清除聊天记录的二次确认。 image.png

衍生：

1.Android有两个使用场景和Action Sheet相似的控件。第一个是Modal Bottom Sheet（模态底部弹窗），和Action Sheet最大的区别是没有“取消”按钮。 返回金刚键代替取消
第二个是Simple dialogs（简易对话框），从屏幕中央弹出，没有取消按钮，通过点击空白区域关闭。微博、豆瓣的android版使用了这个控件。 微博
3.action图标不同于分享图标 image.png
4.ios支持非相册文件上传。网盘类app使用标准的API，能从Action Sheet中选择icloud或者其他网盘跨云传输，不只有选择本地相册和打开摄像头拍照这两个选项。 跨云传输

分类三：Activity Views（活动视图/宫格模式）
ios10引进的新规范组件，为了解决Action sheet滚动问题。国内app使用场景在分享到其他社交APP或第三方app打开文件时（露出信息较少，常作为功能性入口，表现形式多采用图标+文字）。支持横向滚动，选项建议把相关分组后放置在@2x下70px*70px的按钮中，点击热区较小，适合承载更多选项且不容易误触。目前ios原生组件支持sheet+view的形式（文件）。

HIG
样式：列表与宫格 image.png
混合样式 image.png
显示位置：竖屏时显示在页面底部，横屏时居中显示在页面底部 image.png
支持高度延伸：当面板底部仍有未显示的内容时，可设置通过滑动或拖动面板来使其高度进行延伸，从而展示更多信息。 image.png
范例：爱奇艺的分享功能和拍拍圈发布内容类型
image.png

总结：
1.Action sheet中的选项点击后会立即执行任务，而不是仅填写一个选项，它不能用在表单中，表单单选应当使用Picker、Segment Control、Radio Button等控件。
2.危险操作二次确认，用户在使用过程中，出现删除、未保存退出等可能产生潜在风险的行为时，应当弹出Actionsheet，让用户有机会停下来充分考虑当前操作可能导致的危险结果，并将危险操作用红色标注，为他们提供其他替代的安全选项。
注意：Action Sheet是可以连续弹出的，例如第一个Action Sheet中选择删除，第二个ActionSheet中确认删除。此外，如果危险的情况并非由用户主动发起或严重影响系统本身的完整性，应该使用Alert（Alert与Action sheet最大区别）
3.sheet承载丰富的操作和信息，支持嵌入列表、选择器等控件及图片、文本信息。对非系统级或业务级的重要提示，使用Sheets控件进行提示；Dialogs控件仅用于重要的信息提示。在调用原生Sheets组件时，记得分端的差异性。

分类四：Popover（气泡弹窗）& Menus（情景菜单）

popover由一个指向其出现位置的三角箭头和弹出窗口组成。点击控件或某个区域后，浮出一个气泡菜单来做更多的操作，通过点击popover内的按钮或非popover外的其他区域可关闭。HIG规定只适用于ipad中（作为完成某个任务的临时视图/小弹窗，建议实时保存popover的状态，以防因误点关闭，导致重新修改）。目前app中的使用场景是信息提示与情景菜单 image.png
Menus没有太多区别，只是原生控件没有三角指向，不方便用户明确当前弹窗所包含的内容与什么操作有关；Contextual menus会根据APP当前的状态，来动态调整菜单选项的数量，如果简单菜单中的文本需要换行，则使用简单提示框 image.png

。
注意：popover很少强制用户进行操作，是否设置遮罩取决于控件的重要属性，提示和普通操作可以没有（微信右上角的更多按钮）。
a.操作型弹层通常在顶部导航栏（Overflow menu溢出菜单），将2个或2个以上的非重要功能融合在“更多/加号”按钮中，用户点击后，会在原位置上展开更多内容，用户再次进行选择，并使用相关功能。优势：避免用户在app中频繁跳转页面，造成使用迷失，让用户前后操作步骤都是有心理预期模型，减少顶部导航栏复杂程度。
b.情境下的相关选项,如果界面中有多个条目，每个条目都有多个相关选项，可以使用popover承载多个多个情景下的相关选项。在移动设备上，相比于action sheet，popover的三角箭头能明确的指示当前操作的是哪个条目，当然，如果选项很多，为防止误操作不建议在popover里启用滚动，选项多，建议使用action sheet。
c.提示型弹层，popover三角箭头这一特性，常用作新手引导/功能入口的调整/营销某模块等展示信息。如上线新功能，用popover能很好的吸引用户注意力。界面图形较多的情况下，用popover简短的展示附属文字信息，帮助用户理解图形含义。
注：Tooltips（工具提示/文字提示）和Popover区别。Tooltips是鼠标hover或者触摸长按（material design），移动端Tooltips不常见，在某元素上，出现的对此元素的附加解释。Popover是从样式上命名的控件，tooltips是根据其用途命名的控件，两者不冲突。
word balloons是界面内聊天气泡。界面层级和用途有所区别。
d.特殊：定制化广告弹层（运营用作活动宣传，拉新促活、推广新功能等，包括插图、肯定性操作与否定性操作（常用关闭按钮），会尽量隐藏关闭按钮，给用户造成一定关闭难度在，增加活动曝光）；提示用户当前所处的状态，及信息，反馈等。

分类五：MD-Sheets
通常有用户操作触发显示，干扰度较Dialog低（更易关闭），MD中专属划分为Bottom sheet 和 side sheets
1.Bottom sheet
使用场景：用于补充内容相关的更多信息（百度地图切换路线非模态），提供可交互的菜单或对话（模态）或其他关键功能/任务的拓展。
[图片上传中...(image.png-d5834e-1591083937084-0)]

样式：菜单样式，可嵌套Menus，展示多个选项内容； image.png
宫格样式，可使用宫格布局，展示多个选项内容； image.png
迷你样式（非模态），一个非模态底部浮窗可被固定展示在页面底部，用户可以随时用它来对其他功能/任务进行快速操作，如前程无忧小程序的快速投递简历，电商的进入购物车，历史记录等。 image.png
显示与消失：从底部向上滑入。模态弹窗以下情况会消失：当用户触发浮窗上的对应操作（自定义）；点击浮窗外的区域；下拉浮窗达到收起阈值后（自定义）；用户点击Android系统返回键。非模态弹窗：常驻页面或触发弹窗上的对应消失按钮。
支持高度延伸：当浮窗底部仍有未显示的内容时，可设置通过滑动或拖动浮窗来使其变为全屏展示，并在顶部显示Toolbar来展示关闭/收起效果。 image.png
支持深层链接：模态弹窗可以展示其它应用的深层链接内容或操作，比如调用Google翻译 image.png
2.Side sheets侧边浮窗/抽屉
使用场景：用于补充内容相关的更多信息（非模态），提供可交互的菜单或对话（模态，通常用于PC端，移动端很少）或其他关键功能/任务的拓展。
注意：Bottom sheet通常用于android竖屏场景，在android横屏场景建议使用Side sheet。
样式：菜单样式：嵌套Menus，展示多个选项内容。 image.png ；宫格样式 image.png

显示与消失：浮窗从左/右边缘滑入。消失同bottom sheet
滑动说明：支持上下滑动，不支持左右滑动

淘宝.png

非模态弹窗：
1.MD-Toast
2.Ios-Hud
3.MD-SnakeBars
4.MD-Banner

非模态弹窗：弱交互形式，通常给用户提示信息时使用，不需要强制中断用户操作，干扰性低，有时间限制，在一定时间可以自动消失，作用相当于内容信息提示的弹窗。优点：用户可以继续操作主面板的内容。缺点：出现时间短，不容易引发用户关注，甚至容易看不完消息就消失。

分类一：Toast（吐司）

MD独有（windows也有，等同于android的notification），常用于加载中、已完成、失败等结果提示。平台规定位置应该出现在屏幕底部（泛化后iosapp出现在顶部：内容区上方，导航下方，如下拉刷新，好处：出现位置稳定，不会因为软键盘出现导致原本在底部或中间的toast被遮盖或浮动到其他位置；更容易引起用户注意，ios持续录音，gps使用，正在通话状态还有活动指示器和系统push通知都出现在顶部，ios用户习惯于在顶部感知反馈信息；不干扰用户浏览主体内容），并且只能包含尽量较少的文字信息，不应该出现增加用户认知成本的图标等内容。吐司出现的时长是2-3.5s，不干扰用户的同时，有助于阅读完整的提示信息。 顶部toast

注意：避免滥用，当一个app在加载、表单提示、状态变更反馈、断网消息等使用toast，不断出现的黑色矩形会对整个体验带来非常大的阻塞感。一次只显示一个toast，字数限制在14个以内。

分类二：Hud（透明提示层）
HIG没有录入，但是ios系统独有（ios的音量调节），无法被第三方应用调用。目前app模仿hub样式，进而演变成现在的Toast（有gif图，位置居中，短文字）。字数限制在4-6个为宜。有的产品考虑到用户情感化需求的场景，还会加入一些自定义元素。车载HMI使用较多。 iOS中建议，设计一种引人注目但又和App 的界面协调融合的方式去展示信息。

Hud和toast的优点：占用屏幕空间小，不会打断用户操作，使用简单适用范围广，人人都是会用toast的产品经理。缺点：出现时间短，碎片化时代注意力不集中容易错过提示。虽然非模态，但遮罩样式会给人一种模态错觉，打断心流。遮盖其它控件，但不能对toast进行交互。
滥用toast是懒惰的做法，代替toast的其他形式包括

1.页面内提示：常驻与页面内，即使用户短时间内注意力转移，提示也不会消失，确保用户能一致完整的看到，可以容纳更多的信息量，适用于表单错误提示、加载过度 表单页面内提示
2.多态按钮：如果按钮被按下后需要与服务器交互后才能真正相应操作，那么等待难以避免，可以给按钮增加多个状态，让用户已经知道app接收到了操作。典型例子是支付宝确认付款按钮，拥有付款前、正在付款和付款成功三个状态，直接在按钮层显示反馈。 支付宝多态按钮

3.动效：优雅动效吸引用户注意力，富含情感给用户留下印象，事物之间的关系可以通过动效进行隐喻，例如电商app加入购物车，动效商品飞入购物车中。
4.震动和声音：除了屏幕内反馈，屏幕外反馈效果更强烈真实。调用线性震动马达等

可以预见，随着设计师的专业程度提升还有用户对体验品位的不断提高，toast使用场景会不断缩小，泛化的定义终将回归到原点：操作的轻量级短时反馈提示。

分类三：SnackBar，加强版toast

最初是android only，中和了模态弹窗和非模态弹窗属性（非模态不支持操作，会自动消失，模态框是必须用户操作或手动关闭才会消失），支持用户操作主动滑动关闭，会自动消失，一般出现在屏幕底部。支持纯文本提示与操作容器两种模式。显示时间及弹窗长度更长4-10s image.png

分类四：Banner/横幅提示
MD推荐使用的提示控件，常用于轻度干扰的消息提示，该消息会对用户形成视觉干扰但不会阻断当前操作，用户可以选择忽略它或稍后再进行操作。banner通常固定显示在页面底部，不会主动消失，除非达成了其消失的必要条件，持续时间不会影响用户进行其他操作。banner可以兼容1-2个次要操作，兼具提示与操作功能。

image.png

常见的窄/宽屏样式，注意控制文案字数，保持单行展示，按钮展示不下时允许折行展示。

image.png
1.显示与消失机制：banner通常在屏幕加载内容时出现，加载后从顶部向下滑出显示。
banner必须保持显示在屏幕上，直到自定义消失逻辑被满足时才消失。
注意：当页面有top app bar或search bar ，显示在其下方，不可发生重叠。 image.png

2.当页面无以上栏时，显示在status bar下方，不可重叠
层级关系：a.设置banner高于页面内容，固定底部，上滑页面会有部分页面内容被遮挡；b.设置banner与页面同级，banner从顶部向下滑入时，会把页面内容向下推移，当页面内容向上滑动的时候，banner会跟随滑出页面
注：当使用 Navigation drawer/抽屉，banner会被展开的抽屉导航遮挡
3.banner的点击热区。承载2个操作时，设置对应操作按钮为点击热区。仅承载1个操作时，可设置对应操作按钮或整行banner为点击热区，注意应用内需保持交互统一。
4.注意：不要同时展示多个banner，每次仅展示一个；不要使用text button之外样式，因为会过强；2个以上的按钮，可以考虑dialog ；按钮文案不要使用忽略或取消这样的文字，取消文案应当与信息内容相匹配。

例：Teambition利用Banner在首页进行新版本提示，用户可以点击查看，关闭，或置之不理。微信的告知网络异常状态，可以点击查看详情，或在网络回复正常时自动消失 image.png image.png

总结：模态弹窗与非模态弹窗各有优势与不足，恰当使用可以辅助用户一步步完成操作，频繁使用会让用户操作流程被打扰。非模态更加友好，不切断心流体验，但不能承载操作，又容易被用户忽略。但是，弹窗在辅助用户完整完成任务的过程中，功不可没的。
尽量将弹窗应用在重要的使用场景（包括定制的活动弹窗），少量凸显其重要性，过度使用则会使人感到异常反感。
在信息架构正确的前提下，如何选择？以内容信息的重要程度为判断基准：不重要（用户可以不注意或者不操作），使用Toast或snackbar；一般重要（用户可稍后注意或者稍后操作），使用banner；很重要（用户必须立即注意或立即操作），尽量优先考虑Bottom sheet/Action sheet或者view，若以上不能满足需求，再使用Dialogs
或以三个维度依次判断
维度一：是否含有交互类操作
因为非模态时间短、会自动消失的特质，让它在大多时候都是被用于承载用户操作的反馈提示，例如收藏成功、提交成功等，而无法包含操作项（除了snackbar）。所以当包含交互操作项，用户通过点击这个操作项会引发下一步操作（如：删除、提交、跳转页面），那不用犹豫，直接上模态框。如果操作项不含交互，看下一维度

模态

维度二：是否有较高的重要级别

因为模态框必须由用户手动关闭的原因，可以承载重要信息来获取用户注意力。所以如果不包含交互操作项，但因为提示内容重要（如隐私协作、危险操作信息、版本更新等），也应该使用模态弹窗 重要信息
维度三：是否包含大量文字
非模态弹窗不建议放置大量文字

模态框的alert和sheet的选择
操作数量区分：iosHIG规定，为了避免alert选项溢出可视区域，让用户产生滑动行为，应最多承载三个选项，但sheet可以承载更多；

位置区别：alert出现在屏幕中心，而sheet由屏幕底部向上滑出 button
范例：网易云音乐，当用户批量下载音乐时，点击底部的删除下载按钮，会弹出sheet形式出现的确认删除框。虽然按钮只有两个但根据实际项目设计出更符合用户体验的设计（菲茨定律其中一条：当目标大小一定时，起点离目标中心的距离越近，所花费的时间越短；距离越远，所花费时间越长）
费茨定律

非模态框的toast和snackbar选择
ios中常用popovers代替snakebar。所以非模态框的选择相对自由，只是考虑到产品的统一性，需要在设计规范中将非模态的样式、弹出位置等信息定义清楚，以免在类似场景中出现不同的弹窗样式，容易让用户产生疑惑。

目前很多app对弹窗进行情感化改良，因为只单纯的引导用户操作、给予用户反馈，并且频率过高很容易让用户厌烦。这种改良一般会出现在可能让用户产生敏感情绪的场景中，例如产品需要获取用户提醒访问等权限，或者出于商业考虑的广告运营。情感化设计可以增加用户的共鸣，用情感化弹窗鼓励、赞扬他们的用户或者用于增加节日氛围增加特效，让用户在使用产品的过程中更加愉悦，在弹窗打扰用户心流时，给予用户的一些情感弥补。