Which runtime are you using?
Spine-C, Spine-C#, SpineLua, SpineJS all use opaque pointers to store textures (although the latter two are prototyped languages). Look at how the animations are rendered and you can see possibly a way to 'log' which textures you are using.
However, I'm going to suggest a different approach: skins.
You see, to save memory and increase rendering performance, you should really be packing your regions/sprites into an Atlas. Generally speaking, textures are uploaded to power-of-two surfaces on the GPU (barring certain extensions). That means if your sprite isn't pow2 sized, extra space is added around the sprite to align it properly. I think one time I calculated an average wasted space of 40% in a game. 40% means you could have unused regions loaded on an atlas and still save more memory than having everything separate.
When you pack your regions into a single sheet, only the outer edges gain wasted space, and that's if the texture isn't pow2 on disk. (But why waste disk space)
Changing textures on the GPU is another performance bottleneck. If all of the regions are packed into the same texture, then this occurs less frequently; increasing the throughput.
BUT! If all of your regions (for a particular skin) are packed into the same texture, there's no way to drop them individually. 🙁
You can drop whole skins if you pack skins into separate textures. There's no real runtime/dynamic trick to dropping a skin. You can just say: "Hey, this level doesn't use Zombies" and just not load it to begin with. You will have to iterate over the skins to update the renderObject pointers (or null them out) before calling 'setSkin' on the spSkeleton.
==========================
My Level descriptor files specify level assets at the top (in a Library structure). The Libraries are chained together, so when I'm searching for an asset, it looks in the local library, then chains up to it's parent. The root parent contains all assets that the entire game uses (e.g. fonts). If your game uses a lot of the same animations with different skins in different levels, then the SkeletonData would probably be in an intermediate library with the skins in the level library.
That way, when you end a level, the local library is released and it takes the assets with it.
