起因是策划要求实现一个界面，这个界面里常态会有大概20个左右的可交互物。
一种方案是常态把它们做成spine动画，直接加载到界面上，需要交互的时候播放动作。
另一种方案是把它们做成spine动画，并且额外切待机的静图。常态待机状态下，显示静图，需要交互的时候加载spine并且播放动作，播放完成后切换回静图。
那么第一种好处是十分方便，维护也很容易，缺点是spine太多可能会影响性能。
第二种的好处是方便合批，缺点是非常麻烦，而且额外切图会影响包体大小。
考虑到迭代的难易度，我肯定倾向于第一种方案，但是策划问了我个问题：第二种方案能节省多少性能开销？对帧率的影响减少多少？减少多少发热？
我竟一时不知道怎么回答。求解大牛们，如何量化这两种情况对于性能的影响呢？
自己找一些测试图,测试spine,放上去,让他们不能合批.试一下.不用太难的逻辑,直接显示就行了.数量够了就行.
对， 然后开个性能狗监控1个小时手机， 看发热量变化和电池量变化
当然是都要呀， 一张图和spine定帧动画， 交互时，隐藏图片，显示spine，播放动画； 常态时隐藏spine，显示图片。 只要spine不显示就不会渲染，毫无性能压力
那么如果策划说要加入待机动画呢 还有策划为啥会问性能优化
策划懂个锤子技术~ 
不用实时运算的模式不就行了
不动的时候用rt，这个方案满足你想要的所有优点
100个静图 -> 开启左下角debug 截图1
100个spine -> 开启左小角debug 截图2
rt是啥东西
RenderTexture渲染纹理
才20个spine能有什么性能压力，除非你每个spine的图片都是4096*4096，那么在加载那一瞬间你才有压力
不用管其他人说的，老实的用 spine 实现功能（开启缓存模式），否则别人就是认为你做不了，需求高于你的性能
另外还有一个重要的名言，永远不要对你的代码提前做优化
20个都打不到性能瓶颈，考虑的有点多
50个开缓存模式，都可以闭着眼用，没必要焦虑，还没到头