我正在参加一个项目，项目里面使用了大量的spine动画，当整个屏幕布满很多同样的动画的时候，性能很差，我怎么做才能让这些动画合批。cocos creator只支持非常简单的动画合批。希望你们能给我一些帮助，非常感谢。
I am participating in a project where a large number of spine animations are used. When the entire screen is filled with many of the same animations, the performance is poor. What can I do to make these animations approved. Cocos creator only supports very simple animation batch. I hope you can give me some help. Thank you very much.
恐怕我们不维护 cocos creator 集成。 因此，很难给出如何提高批处理性能的建议。 通常，如果使用的纹理发生变化，批次将被破坏。 您可以为多个骨架导出单个图集以增加批处理。 请向 cocos creator 维护者寻求进一步的建议，因为他们知道渲染代码的内部结构。
I'm afraid we do not maintain the cocos creator integration. As such, it's hard to give advice how to improve batching performance. Generally, a batch will be broken if the used texture changes. You can export a single atlas for multiple skeletons to increase batching. Please ask the cocos creator maintainers for further advice, as they know the internals of their rendering code.
首先，非常感谢你答复我的帖子！
我想请教另外一个问题，如果一个spine动画在低端手机上卡顿，我该如何去分析这个spine动画，找出卡顿的原因？或者说什么样的spine动画会有比较大的性能开销？贴图太大，骨骼数量太多，混合模式过多？
First of all, thank you very much for answering my post!
I want to ask another question. If a spin animation gets stuck on a low-end mobile phone, how can I analyze the spin animation and find out the reason for the stuck? Or what kind of spine animation will have relatively large performance overhead? Too large map, too many bones, too many blending modes?
动画永远不应该卡住，那将是一个错误。 在这种情况下应用程序会崩溃吗？ 请提供您的骨架和图集文件以及用于启动动画的代码。
至于一般性能提示，我们在此处对其进行了总结：
指标视图 - Spine用户指南: Performance
An animation should never get stuck, that would be a bug. Does the app crash in that case? Please provide your skeleton and atlas file and the code you use to start the animation.
As for general performance tips, we've summarized them here:
指标视图 - Spine用户指南: Performance
对于我的用词不当造成的歧义，我深表歉意。 当我说卡顿时，我的意思是丢帧，低于 60 帧。 指标视图给了我很多参考，非常感谢。 由于一些特殊的原因，一些spine动画，我没有源文件，能否在运行时获取spine动画的指标视图？ 我应该怎么做？
另外，我的一个spine源文件有问题，您能帮我看看这个动画在低端手机上掉帧的原因吗？ 非常感谢。
I'm very sorry for the ambiguity caused by my misuse of words. When I said stutter, I meant dropped frames, below 60 frames. The indicator view gives me a lot of reference, thank you very much. For some special reasons, some spine animations, I don't have the source file, could I get the indicator view of the spine animation at runtime? what should I do?
In addition, I have a problem with one spine source file, could you help me find the reason why this animation drops frames on phones whcih functions are at low-level? Thank you very much.
the spine source url of goole drive.
https://drive.google.com/file/d/1CCW8iofL9fyQtCO_OwR5Uhoud1f0sP93/view?usp=sharing
恐怕在运行时没有等效的指标视图。您可以在运行时自己迭代骨骼、约束和附件。这些存储在“Skeleton”（或“SkeletonData”）中。对于附件，您要计算每个“MeshAttachment”的顶点，因为这些是最昂贵的附件类型。
骨架覆盖 3300x3300 像素，对于低端设备来说，这是很多的。源图像非常大。您导出的纹理图集可能有多个图集页面（.png 文件），这意味着在渲染该骨架时会有很多纹理切换，并且图集页面非常大（> 2048x2048px）。
当渲染器绘制骨架的图像时，它必须不断地在这些图集页面之间切换。它还必须为图集页面采样大纹理，这在低端设备上非常非常慢。
导出图集时，您应该使用纹理打包器设置中的缩放选项来缩小纹理图集。我不能给出具体的数字，你必须尝试适合你的情况。如果可能，请尝试将所有内容放入单个图集页面。 2048x2048 应该可以作为低端设备的图集页面大小。
另外，看看 yu_all_1 骨骼及其子 yu_1、yu_2 等。这是很多覆盖整个屏幕的透明图像。低端设备在混合透明图像方面非常非常糟糕。作为测试，暂时从骨架中删除这些图像，看看这是否会提高性能。
I'm afraid there's no equivalent for the metrics view at runtime. You could iterate bones, constraints, and attachments yourself at runtime. These are stored on Skeleton (or SkeletonData). For the attachments, you want to count the vertices of each MeshAttachment as those are the most costly type of attachments.
The skeleton covers 3300x3300 pixels, for low-end devices, that's a lot. The source images are extremely large. It's likely that the texture atlas you exported has multiple atlas pages (.png files), which means there is a lot of texture switching when rendering that skeleton, and that the atlas pages are very big (> 2048x2048px).
When the renderer draws the images of the skeleton, it has to switch between those atlas pages constantly. It also has to sample big textures for the atlas pages, which on low end devices is very, very slow.
You should down scale the texture atlas by using the scaling option in the texture packer settings when exporting the atlas. I can't give concrete numbers, you have to play around with what works for your situation. Try to get everything into a single atlas page if possible. 2048x2048 should be ok as the atlas page size for low-end devices.
Also, have a look at the yu_all_1 bone and its children yu_1, yu_2 etc. That is a LOT of transparent images that cover the whole screen. Low-end devices are very, very bad at blending transparent images. As a test, remove those images temporarily from the skeleton, and see if that improves performance.
