Agreed! It would be nice to see something like Task Manager, where a user could see which currently running apps/services are sucking up CPU time, and also track it's CPU use over a period of time. And it would also be nice to see a way to KILL the process that's sucking up the juice without having to restart the phone or open up a bunch of smaller apps to force it out of the queue.
That would rock. As it is now, it's often a lengthy trial and error process to figure out which app is slowing everything down. On Fri, Mar 27, 2009 at 12:33 AM, ShrinkRay <[email protected]> wrote: > > Hey don't knock java... if background processes weren't allowed, then > this wouldn't be an issue. > > But that's one of the good things about Android isn't it... LOL. > > Even a proper desktop or laptop computer struggles when a big > background process (anti virus etc.) hits and sucks resources > (network, memory, disk etc.), away from the foreground processes. > It's difficult to expect a a much less capable device to fare any > better. > > The real problem is support and not getting an application returned in > the first 24 hours... imagine the user who has added "big fat > background process" as an application on their phone. I'd imagine the > developer of "big fat background process" doesn't add a disclaimer > "this application may affect the quality and performance of other > applications". How is the user to know that when your application is > exhibiting signs of stutter or poor performance/frame rate (assuming > it is coded right) that the issue is the background process. > > Maybe Google needs to add a permission to suspend/throttle background > processing and the API needs to have a way to let the application > suspend background processing in sections of their own code. For > example a game might allow background processing on loading screens or > end of level screens, but not in time critical sections of code. > > Just a thought. > > On Mar 26, 4:52 pm, Sundog <[email protected]> wrote: > > So the EULA for Java needs to be extended: > > > > "You acknowledge that Software is not designed, licensed or intended > > for use in the design, construction, operation or maintenance of any > > nuclear facility or side-scrolling games." > > > > This is why I've always avoided Java until now. If you can't write > > realtime code what good is it, especially for critically important > > things like nuclear plants and games? ;) > > > > On Mar 26, 7:23 am, Incognito <[email protected]> wrote: > > > > > You will have the same problem in a computer if too many apps are > running. The solution in a computer is to uninstall and dump those programs > that hug too much memory. Same thing will happen in android. Those > background processes that cannot play nice will get a bad reputation and be > uninstalled. People must write their background processes so that they > consume as little resources as possible or face an early death. The game > will only stutter if there is excessive gc. > > > > > On Mar 26, 2009, at 9:13 AM, Stoyan Damov <[email protected]> > wrote: > > > > > I don't see how opengl helps with the fact that the game's code runs > > > on the *same* processor, as the one, doing the GC. > > > You can have all your drawing occur on the GPU, but the game will > > > *still* stutter, if a background process triggers GC, because the very > > > drawGameScene() call will be postponed because of the GC. > > > > > On Thu, Mar 26, 2009 at 1:54 PM, Incognito <[email protected]> > wrote: > > > > > Did you try opengl? > > > > > On Mar 26, 2009, at 5:18 AM, "[email protected]" < > [email protected]> wrote: > > > > > because I don't think Android can handle smooth scrolling. Tried > > > myself with all sorts of views, surface views, always a horrible > > > flicker even with 20 - 30fps. > > > > > Looking at the market its the same story. Most games don't attempt > > > side scrolling and the ones that do end up with very jerky scrolling, > > > e.g. deBlob $3.99 ported from iPhone. Alien Blood Bath is a similar > > > story. > > > > > I'm starting to think this is a technical limitation.If it is, this > > > could mean our games never compete with other mobile platforms and > > > could limit Android's ability to compete in the market. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
