DoTween介绍

DoTween可以给变量定义一个沿着曲线变化。

DoTween提供比较便捷的动画控制效果，对比Unity原生的Animation动画曲线控制，其多了局域动画属性控制，但是我思考后决定根据情况使用DoTween插件，原来我觉得从某些架构角度来讲并不合适，但是后面发现虽然都是事实但是也有对应的方法，好处。这里描述这些HighLevel想法，然后记录DoTween的一些功能接口。

原来理由

给出的不使用理由

1：

根据其官方文档介绍，其实际应该是一个中心注册式的Timer管理器。对于调用的接口实际都是形成了一个实例放在了DoTween中心里面。而这种中心管理式的Timer，存在很多的弊端。更何况交付给一个插件管理，举例来说如下：

对于一个中心管理器，如果其Tick的索引的对象销毁，都要手动去销毁关联的Timer，容易出现bug，trace。
其次中心管理器中的实例会索引对象，相对应的管理中心Tick会不停访问不同对象，进而降低内存命中。这要就没办法做ECS这种对象密集型，而对于这种就需要把Timer放到对象身上。
而如果把Timer实体放在主体对象上，通过统一的Tick接口来执行则不存在其他引用。销毁后Timer自然销毁，不需要多余操作。简单来说就是负责运行Tick的对象究竟是何的问题。
但是如果只是单纯的简单Timer表现效果，这种中心Timer的效果实现会很快速，方便快速出原型对象。而且如果表现不需要被打断修改，则不会出现什么复杂情况。

2：

而从其内部功能来看，其提供大多数都是一些简单的曲线移动控制。而这类都可以同过以下两个过程封装实现，而且具有更高的可控性。

Timer运行器：放在主体身上，每个Update进行调用
采样器：从目标曲线上获取当前值
修改器：将采样的值，通过规则作用到目标

而且这个方式还更容易扩展。

3：最后，可以看到DoTween没有基于Editor提供一个好的可视化编辑。准确说是两方面。

对于曲线的可视化编辑，可以key帧曲线，进行方便的修改。
曲线作用后效果无法在Editor模式先预览。

类比Unity自己的Animation系统，其本身可以拉曲线，并且直接再Editor模式预览动画的最终效果。当然有些预览有一定问题，毕竟需要跟逻辑挂钩，但是有一些例如UI位移，材质动画，这些也要进入游戏就显得太过鸡肋，不如自己做一个简单的曲线编辑器接入。

不过DoTween对于Transform的Path进行了较好的支持。

但是要做到全套预览的方案，不如自己建立基于曲线，Timeline的编辑器更加强大。

新的理由

DoTween确实是一个中心化结构。即所有时间Tick运行状态对象是放在一个中心里面。如果目标对象运行过程中销毁，那会报错。所以导致使用时去注册，但销毁关联结构的时候，要去移除，更麻烦的是有一些特殊情况下对运动状态的修改需要反复去进行添加移除。但是有更高的角度，理由来看到这个问题，使我接受他。

上述问题确实存在，但对于中心式的移除和添加其实只是一句话的事情，代码量并没有那么多。在大部分情况下使用起来还能接受，并不是特别麻烦。
中心管理器确实索引对象，导致内存命中降低，但是这点程序损耗对于非特定类型游戏不是很大，完全可以接受。对于小体量游戏，初期开发。验证与开发效率才是第一保障。功能实现，表现良好才是目标。
DoTween实际已经实现了大部分功能曲线，而且这些功能原理是类似的，自己再去写一遍，只是重复别人工作。使用DoTween可以快速使用类似功能，而不是再去造轮子。
即使自己写可视化编辑器部分，其实也只是曲线编辑器部分，一方面DoTween其实也提供了。但更值得一说的是，对于这些可控制的曲线部分还不能完全承担起计算功能部分。还是要用类似动力系统的方式去定义，用方程曲线来实现效果。
再其次，一般对于可视化编辑的部分也会有详细的编辑方式来实现特定的功能，这种功能需要挖掘到一定程度，明确内容之后再建立。例如跟随操作的二阶运动系统，这种需要一个反应参数特性的变化曲线，但是这种功能比较明确化。

跟重要的一点。

对于DoTween已经了解非常深入了，对于某些内容，是用DoTween，还是自己曲线编辑器其实都取决于使用者。目前看来，DoTween尤其适合的地方，应该使用之，不适合的地方，自己开发结构来满足也不是问题。而这种情况的判断，已经有能力快速决断。从这种用于不用都可以的角度来说，即功能性应当提供，找合适切入点操作。而复杂合适的功能自己来实现也很OK。

总结

DoTween还是应当了解功能结构，找到合适的情景使用。