Hmm, I guess my question is more like if the BULLET behavior is draining a lot of battery. As I said in my previous post, the app is very simple and for test purpose only:
1. You create some solid boundary on the 4 sides of the layout
2. You create several sprites (say 4) with bullet behavior and bounce off solid
No event at all. So there is nothing to optimize.
Build the android app and let it run (so the sprites will be bouncing around) for 3 minutes, and the CPU total will be ~7 minutes on my Nexus 6.
Not sure if it will be the same on other phones. Thanks.
it could be, think of construct as something like windows. when computers first came out, you had to type a paragraph of code to open a program file, but people noticed a lot of the time you type the same lines of code over and over and over. so they made a button, that when you press it, it executes a predetermined line of code. so when you click the button for an app, in the background its executing multiple lines of code to open even more lines of code which comprise the program.
my point being, in construct, even though you didnt program any events, the simple fact that theres a sprite or an object means theres lines of code in there, determining shape size position etc. i would assume the background code on the bullet behavior would be something along the lines of every tick move sprite x spaces at y angle, so every tick, which is 0.001 seconds i believe, its repositioning, redetermining size, color, shape, etc, and relaying that information in a way that you can see it and understand it. thats 1000 times a second. even if im wrong and its only 0.01 seconds, thats still 100 times a second.
most apps are static, and comprised mainly of webdata, i.e facebook instagram twitter snapchat etc. so the information is mainly sent when the page is reloaded, a lot of apps will generally only be performing a function when a button is pressed.
maybe think of it as gifs vs still images. maybe not on newer pcs, but theyll generally take longer to load. this is because its a constantly moving image, its changing files every x seconds.
maybe the constant bullet behavior could be contributing to power consumption, maybe try adding goals, that when the balls hit they disappear and respawn a few seconds later. it'll provide breaks in the bullet behavior and possibly give the phones proccessor a second to catch up to itself. a lot of it has to do with the phone itself. cheaper phones tend to be lacking so as to push you to buy the $1000 one that will be outdated in a month.
slowing movement speeds etc may also help lower consumption, though, im no expert.
as the above mentioned, debugging will tell you when and where you're lagging, so you'll be able to tweak your environment accordingly.