Profiler spikes

I am having difficulties with performance profiling of my game on android mobile phone, this is graph from android mobile on profiler:

In PC profile the graph is different:

Facts and things and methods I am using:

  • pooling
  • particle systems for weapons (and even stretching of particles)
  • trails (not too many)
  • low poly models (objects around 500 tris)
  • skybox and multiple cameras (for gui, for background, for objects)
  • sprite sheets and sprites to draw few GUI parts on screen, (nothing too advanced)
  • These graphs are made on very similar situation of game involving 10 AI objects flying on screen and firing on player, the player is doing nothing special and both tests are same in set up

My question is simple, what may be cause of such spike randomness on mobile? (From my observing the spikes are quite random even when there is almost no difference “in game action” on game screen the graph is very fructuated)

Possible guessed issues that may be the main cause:

  • The spikes are caused by mobile and this kind of frunctuation is normal, yet giga-slow
  • I made some setting of unity I somehow wrong (or not using something)
  • There is much more the profiler can/should tell and I cant see it or configure it correctly
  • Something with overhead (red in graph) or any other color is affecting game globally somehow
  • Memory leaks, allocation or hidden garbage collecting problems
  • Something may be wrongly coded, or I do not understand it properly (most of the code is nothing too complex in calculations(as can be seen under graphs there is no one method that takes most of the time),the code consists mostly of many simple positioning, rotating, etc… (the most complex up to 500lines of code in AI, mostly controled by bool states and if-s, so nothing too special))

I lowered draw calls from 100 to under 50, but that was not the issue.
Any Idea, tip or advice would be helpfull, because I run out of options.

Your problem appears to be physics related (by reading the list of things which are taking time in your script).

The way the Physics system works is by running as many times as necessary to catch up with the current real frame, so in some of your frames it is running twice as frequently as in the others. It would appear that each of the calls to your FixedUpdate functions take quite a lot of time and so when this occurs it creates a vicious cycle pushing the frame time much higher.