(1)
This is a complex matter. But you just need to know what things cost a lot of compute, and avoid those.
On the CPU side: Use as few bones and images as possible. If you're going to use meshes, give them as few verts as possible.
In animations, don't key things that aren't animated. Avoid FFD. Avoid image swaps (if you don't use image swaps/hiding, you can check "Immutable Triangles" under the Advanced foldout and that'll save a lot of array juggling on SkeletonRenderer).
Avoid the string API. Cache object references. And cache all your animation references and use so the Spine runtime doesn't need to keep searching for animations by name every time you play an animation.
Read up on Unity performance in general. There are a lot of things that are okay in normal/modern C#, but that cause Unity's Mono to slow down. This mostly concerns garbage collection and old libraries.
On the GPU side, make sure your images are pre-trimmed. If you have meshes, reduce fill rate pressure by making sure the meshes cut out as much of the empty/transparent areas as possible. Use pre-multipled alpha blending (and the Spine\Skeleton shader). Don't use lighting. Don't use shadows.
None of this is "best practice". It's just a list of things that can cost some amount to calculate and can scale badly in terms of runtime performance the more you use them.
"Best practice" would mean a workflow that's easy and you can great results. If it's for your singular main character, this arguably doesn't matter. It's probably much more important that it looks great and is easy to make changes and add animations and movements to. All the restrictions above means it's a lot harder to figure out the construction of the images, skeleton and animation. The extra cost there is time working on the assets and possibly more complicated code.
Also, 150-300 animations on mobile, I'd say Unity might not be the best engine right now.
But I guess that depends on what you mean by "mobile". Flagship phones and tablets will probably handle that fine. I don't really know.
(2)
using UnityEngine;
using System.Collections;
public class SkeletonAnimationCuller : MonoBehaviour {
#region Inspector
public SkeletonAnimation skeletonAnimation;
void Reset () {
skeletonAnimation = GetComponent<SkeletonAnimation>();
}
#endregion
void OnBecameVisible () { skeletonAnimation.enabled = true; }
void OnBecameInvisible () { skeletonAnimation.enabled = false; }
}
This is the cleaner way to achieve part of what you were doing.
Setting the animation and changing the rotation, you can still use the distance calculation if you want in a separate script.
Note that timeScale = 0
doesn't mean it will stop updating. But enabled = false;
does.
There's no reason for you to change timeScale unless you're actually trying to slow down an animation.