The proposed solutions seem to go in the right direction.
While those get implemented, I found a way to separate the items triggering an animation from the animation definition that may be useful. I call it the scroll switch technique.
Let's imagine our application has many buttons that trigger the same complex animation on a profile picture. Normally you'll have to define the same animation on the profile picture for each of the buttons and propagate every change you make to the animation many times.
In those cases, you can create an auxiliary element. The element will be a scrollable view, and the scroll position will be used to decouple events from animations. Buttons will not trigger the animation directly, but they will change the scroll position (with the "scrollTo" action) and the animated element (the profile picture in my example) will define the animation based on the scroll position. In this way, the auxiliar element acts like a switch that can be triggered from many layers and animations can be defined based on it without having to repeat the definition multiple times.
I created a quick diagram: