1.类型：Object
gsap.ticker就像GSAP引擎的心跳——它在每个requestAnimationFrame事件上更新globalTimeline，因此它与浏览器的渲染周期完美同步。你可以在每次更新后添加自己的监听器来运行自定义逻辑(这对游戏开发者来说很棒)。添加任意数量的监听器。
2.基本示例
//添加监听
gsap.ticker.add(myFunction);
//监听器回调函数
function myFunction() {
//在核心引擎更新后的每个tick执行
}
//删除监听器…
gsap.ticker.remove(myFunction);
3.回调参数
下面的参数传递给每个监听器函数：
（1）time : Number类型，从计时器开始的总时间(以秒为单位)。ticker的开始时间可能被lagSmoothing提前。
（2）deltaTime : Number类型 - 从上一个ticker开始经过的毫秒数。注意:你可以使用gsap.ticker.deltaRatio()来获得一个基于特定目标对象的FPS的比率。
（3）frame : Number类型 - 帧(刻度)数，在每一个刻度上递增。
所以你的监听器函数可以设置为使用那些传递给它的参数，像这样:
function myFunction(time, deltaTime, frame) {
//使用time, deltaTime和frame
}
4.add()的高级选项
在gsap.ticker.add()中有两个可选参数:
（1）once : Boolean类型 - 回调函数只会触发一次，然后被自动删除。
（2）prioritize : Boolean类型 - 回调将被添加到队列的顶部而不是底部，这意味着它将在当前队列中的任何监听器之前触发。如果你想让你的回调在GSAP的全局时间轴之前触发，这是很好的办法。
// 在全局时间轴更新之前，在下一次requestAnimationFrame调用一次myCallback。
gsap.ticker.add(myCallback, true, true);
注：这些高级选项是在GSAP 3.10.0中添加的
5.当浏览器标签被隐藏时进行节流
当用户切换到浏览器中的另一个选项卡时，为了节省电池电量和减少CPU的负载，ticker的更新速度会显著降低（这是因为浏览器本身限制了requestAnimationFrame事件调度），通常情况下，requestAnimationFrame事件每秒大约发生60次，但这取决于浏览器，也取决于系统性能，一些现代设备的更新频率为120hz(每秒120次)。如果requestAnimationFrame不被支持，计时器会自动退回到使用常规的setTimeout()循环。
6.Ticker的属性
- time：Number类型 - 总时间(秒)自从ticker开始。ticker的开始时间可能会被lagSmoothing提前。
- frame：Number类型 - 帧(刻度)的数字，它在每个刻度上递增。
7.gsap.ticker.fps()
为了限制一个特定的帧速率，你可以像这样使用fps()方法:
//将帧数控制在每秒30帧
gsap.ticker.fps(30);
因为它不可能让浏览器加速本机requestAnimationFrame事件(通常是60帧/秒)，你不能做一些像gspap .ticker.fps(100)(好吧，你可以，但它仍然会以大约60帧/秒运行)。但是，你也可以使用gsapp.ticker.fps(30)来让计时器在必要时跳过节拍，以便让你尽可能接近30fps(或者你设置的低于本机频率的任何fps)。
8.gsap.ticker.deltaRatio()(在3.5.0中添加)
gsap.ticker.deltaRatio()方法以基于特定目标对象的FPS的比率返回自上次tick以来所经过的时间。例如，如果你执行gsapp.ticker.deltaRatio(60)，但是从最后一次tick开始的运行时间实际上更像是以30fps运行(可能事情陷入了困境)，它将返回2，这样你就可以轻松地设置动态调整帧率变化的循环，如:
gsap.ticker.add(function() {
obj.x += 3 * gsap.ticker.deltaRatio(60); //即使帧率波动，变化率也将始终保持一致
});
默认的fps参数是60，所以你甚至不需要传入一个，除非你使用的不是60fps。例如，如果你想获得基于30fps运行的比率，你可以执行gsap.ticker.deltaRatio(30)
9.gsap.ticker.lagSmoothing()
- gsap.ticker.lagsmoothing()方法作为GSAP的延迟平滑的getter和setter。
- 当CPU陷入困境，呈现之间有延迟时，会发生什么? 例如，假设一个2秒的补间应该立即开始，但是CPU在第一次渲染该补间之前忙了一整秒。大多数其他动画引擎(包括一些浏览器中的CSS动画)都将开始时间向前滑动以进行补偿，但这种方法有一个主要的缺点:它牺牲了同步并可能破坏延迟，因此当你试图整齐地错开动画时，它们会成群结队地涌出。那肯定不好。
- GSAP一直使用严格的定时模型来优先考虑完美的同步，这意味着在上面的例子中，在初始的1秒延迟之后，补间会呈现为完成了一半。基本上，每个动画引擎都必须以某种方式支付延迟税——要么保持严格的时间和同步，要么滑动启动时间，失去同步。
- gsap.tick.lagsmoothing()为你提供了最好的两个世界，因为当CPU陷入困境时，它会在下一个tick上调整核心计时机制，这会影响所有动画，因此一切都保持完美同步。您可以设置阈值(以毫秒为单位)，以便当延迟超过该阈值时，引擎将调整内部时钟，使其像adjusttedlag一样运行。即使在gsap上调用静态方法，这个调整也会影响gsap中的所有内容(tweens、timeline和delayedCalls，因为它们都是由gsap核心的单一计时机制驱动的)。
- 例如，如果阈值是500,adjusttedlag是33(这些是默认值)，那么调整只会发生在两个tick之间超过500ms的时候，在这种情况下，它会表现得好像只经过了33ms。因此，如果CPU停滞了整整2秒(哎呀!)，你的动画将在下一次渲染时移动33ms的时间，而不是跳跃整整2秒。注意:这对设备的性能或真实帧率没有影响——这只会影响当浏览器掉帧时GSAP的反应。
- 默认情况下，该功能已经激活，使用500ms的阈值和33ms的adjuststedlag，但如果你想更改设置，你可以这样做:
//仅当2个tick之间间隔1000ms或以上时进行补偿，
//然后让它看起来只经过了16毫秒:
gsap.ticker.lagSmoothing(1000, 16);
- 为什么不把值设得非常低，比如都设为10? 因为这样做不会有太多的喘息空间，它会自然地让你的补间看起来像它们运行得更慢(因为从技术上讲，如果几乎每次渲染的时间都被往前推，它们就会变得更慢)。还要注意，如果你有任何delayedCalls，这些也会受到影响。这是一件好事——它可以确保你可以依靠这些与引擎的其他部分完美同步，但如果浏览器在巨大的压力下，每秒只渲染几帧，看起来就好像时间真的变慢了，2秒的补间(或delayedCall)实际上可能需要8秒才能完成。
- 在大多数现实场景中，默认值500和33是理想的，因为它们可以防止浏览器/CPU的重大故障，同时允许帧速率的微小变化，而不会不必要地降低速度。
- 如果你想禁用延迟平滑，你可以简单地将它设置为0，比如gsapp.ticker.lagsmoothing(0)，这与将阈值设置为一个超级大的值相同，这样它就永远不会生效。
