I just recently helped another developer do just that. It's really just a matter of stepping back and thinking about how long everything takes.
Mobile is very very hard to do. You really have got to keep the memory footprint down and you can't hit a processor with a lot of tasks. But some tricks that I could teach you that creates the illusion that it's doing everything but its really not, using basic logic I'll show you what I mean...
As an example you have a character running around the screen you have to update the position of that character about 17 times a second. However you don't have to check the input 17X second because nobody can move that quick. So you could put your input routine into a function that only runs four times a second and you're freed up some processing power - actually just saved 4.25ms per tick. Do the same thing with collisions to achieve the same effect. I usually go 5X (3.32ms) a sec for collisions.
Now, Maybe your guy has an inventory... You don't have to take and check the inventory to see if the hammer is in there 17 times a second do it once every second. Just those 3 things saved us running executing 43.98 tasks - saved us the couple thousand operations of the short game. That would help stuff run on lower end devices and make desktops and higher end devices work less which saves battery usage all the way around.
one note, I learned very quickly that on C2, don't put path finding AI in a slower loop. Keep it every tick for fast paced stuff. If you run your game in the debugger and look at the system section, make a note of your collisions/sec and CPU %, I guarantee you you will cut both in half.
Another trick if the layout is biggest than the screen is to see if objects are even visible, if not ignore them. The player will never know. Just update the stuff the user can see, everything else, update every second if you must.
Hope this help someone. Chow.
Develop games in your browser. Powerful, performant & highly capable.