恐怕在运行时没有等效的指标视图。您可以在运行时自己迭代骨骼、约束和附件。这些存储在“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.
