话说大叔我以前以为菊花就是朵单纯的菊花，撑死了也只是个会转的菊花，没想到，它居然还有一个高大上的名字叫做进！ 度 ！指！ 示！ 器！顾名思义：表示进度的机器。瞬时间，我不能仅以看一朵小菊花的眼神看待它了，因为那显得我特别的不纯粹！
为什么加载要用一个转个不停的菊花？
你有没有忍受过一个仿佛要加载到天荒地老的菊花？
到底进度指示器是个什么鬼？
进度指示器 Progress Indicator
A progress indicator is an element of a command line interface, a textual user interface, or a graphical user that is intended to inform the user that an operation is in progress, to reassure that the system is not hung or waiting for user input, and often to provide the user with an estimate of how far through a task the system has progressed.
进度指示器是命令行界面，文本用户界面或图形用户的元素，旨在通知用户操作正在进行，以确保系统未挂起或等待用户输入，以及通常为用户提供任务的系统进展的估计值。（摘自维基百科）
网站上列举了几个例子：Progress Bar进度条，Throbber平面动画，Splash Screen启动页，Mouse Pointer/Spinning Pinwheel鼠标/旋转转轮，Simple Textual Percentage Figure简单文本百分比，他们都属于进度指示器。
从上面这段定义中我们可以总结出：
进度指示器主要功能是指示某个事件正在发生。（至于能不能达到缓解用户焦虑的情绪我就不得而知了，起码我每次看到这些就知道：看来要等会了）
在这个基础上，iOS平台和Material Design分别对进度指示器进行了划分和场景规范。
iOS设计规范描述如下：
Activity Indicator活动指示器
当一个任务无法量化（unquantifiable task）时活动指示器转动，例如加载或者同步复杂的数据时展示。当任务完成时它消失，活动指示器是无法交互的。（1、进度条比活动指示器好；2、保持活动指示器运动；3、如果有用，当等待任务完成时提供有用的信息）
Progress Bar进度条
一个进度条包含了一个从左到右的进度填充过程来表明可知的持续时间（known duration）。进度条不可交互，尽管他们经常伴随着一个取消掉相应操作的按钮。（1、永远精确的报告进度；2、对具有明确定义的持续时间的任务使用进度条；3、隐藏导航栏和工具栏中未填充的轨道部分；4、考虑自定义进度条的外观以匹配您的应用）
从上面这段定义中我们可以总结出：
在iOS平台里，分为可量化和不可量化两种场景，这两种场景有着不同的形式和交互。并且他们更推荐用进度条，可以理解为尽量让用户可预知他们即将花费的时间。
Material Design设计规范描述如下：
线形的和圆形的
Material Design 提供了两种视觉上区别的进程指示器：线形的和圆形的加载指示器。只有一种类型应该代表应用中的每种活动，例如：加入一个刷新行为在屏幕上显示的是圆形加载器，那么在其他地方同样的操作不应该用线形的加载器。
确定的和不确定的指示器
确定的指示器显示进程要花多久时间。他们经常被用在进程完成度可测上。
不确定的指示器表示不确定的等待时间。 如果无法检测到进度，或者没有必要指出活动需要多长时间，则应使用它们。
不确定的指示器可以转成确定的指示器
当反馈时间为2-9秒时，可使用循环的加载样式。当反馈时间超过10秒时，须使用带有进度指示的加载样式（参考数据）。
从上面这段定义中我们可以总结出：
Material和iOS对于进度指示器的的相同之处在于分了两种类型指示器：确定和不确定。但是MD对于不确定的定义比iOS要多两个内容：1、不可量化时间（共同点）；2、不确定的等待时间（不同点）；3、没有必要指出还需要多少时间（不同点），除此之外，MD里的不确定指示器可以转成确定的指示器。
看完上面的定义我们大致了解他们之间的区分，但是这里我们要注意一个细节，不确定指示器有两种理解：不确定时间长短（是1秒还是3秒），不能估算出有多长（未知时间）。在 iOS的描述中，明确的就是指的第二种（英文原词已经附上），而Material Design里面显然拓宽了对不确定时间的理解。
最后回到之前的问题上：
为什么加载要用一个转个不停的菊花？
答：他想告诉你，你要等一会儿哦，慢慢看我转～可是要等多久？我不告诉你～（差评）
你有没有忍受过一个仿佛要加载到天荒地老的菊花？
答：太多次了，转到老壳发晕。所以有比较好的设计就是，当他转的时间超过一个值时，就会直接显示加载失败或其他，不会让加载指示器无止尽的加载。（差评）
到底进度指示器是个什么鬼？
答：看上面。
以下是额外的内容：
在设计的时候，对于用户而言，他根本不Care什么量化不量化，他只希望越快越好，如果不能快，那就告诉我还要等多久。所以，下面展示的是用户的耐心范围：
每个范围对应着用户的状态：
0到A秒之间的是用户感受不到，你不需要做任何事情。
0到B之间是用户可以忍受的时间，你可以适当的分散点用户注意力，比如说什么胸口碎大石啊之类的动效，不过这种场面看一次还好，让你一天看上十次胸口碎大石你也会烦吧？所以现在有skeleton screen，还有MD的Placeholder UI这种类似于占位符的效果，让用户专注于内容本身，而不是加载器。
0到C之间，EMM...时间有点久了哦，超过这个时间你就要告诉用户当前进度状况了，加载了多少，还有多少，让用户心理有个底。
在此，Nielsen Norman Group有一个参考数据：
0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
0.1秒是关于让用户感觉系统瞬间响应的限制，这意味着除了显示结果之外不需要特殊反馈
1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
即使用户会注意到延迟，1.0秒也是关于用户意识流保持不断的限制。通常，在超过0.1秒但小于1.0秒的延迟期间不需要特殊反馈，但是用户确实失去了直接操作数据的感觉。
10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.
10秒是将用户的注意力集中在对话上的极限。对于较长的延迟，用户将希望在等待计算机完成时执行其他任务，因此应该给出反馈，指示计算机何时完成。如果响应时间可能变化很大，则延迟期间的反馈尤为重要，因为用户将不知道会发生什么。
所以再次回到上上面的问题：
你有没有忍受过一个仿佛要加载到天荒地老的菊花？
答：有，解决方案：如果用户已经意识到这个菊花转了很久，那么有两种方法，要么你就告诉他还要等多久，要么就设置一个时间机制，在加载超过这个时间之后就默认加载失败，让用户进行再次操作。
