[Tfug] OT: Phones..... Argh!

[Bexley Hall]

Hi John,

>> Can this be an application "startup" problem?
>>
>> I.e., if you were to start the app/applet AND THEN WAIT (for some
>> period of time), would the device be more responsive?  I'm wondering
>> if it's busy doing housekeeping, late bindings, etc. and just
>> hasn't brought itself to a point where it is ready to deal with
>> user I/O (and the OS is cooperating by buffering your input events
>> until such time as the application can actually call for them)...
>>
>> Not that this (in and of itself) will do anything to improve
>> performance... but, it might help understand what *might* be
>> going on while the device seems "preoccupied".  And, maybe a
>> clue as to how you can get it LESS "preoccupied"...
>
> I had considered this route as well, but it seems to have only a
> minimal effect.  Whether this is due to my device's underlying problem
> or due more to how Android operates (normally or under memory
> pressure) I can't really say.

Once "responding", does it process keystrokes (or whatever other
"events") quickly?  I.e., does it look like there is just some
large "front-loaded" delay after which things move along normally?
Or, does it look like the processor is running at half/third/etc.
speed?  Like continually "thrashing" or being preempted by
some "nuisance"?

> But, as I said, it does help a little.  If I start something large and
> known to be slow, such as the Amazon app store, letting it sit for
> 15-30 seconds before trying to use it will make it slightly more
> bearable.  This doesn't always work, though.  Trying to use Firefox
> tends become slower as time passes... same for the built-in Browser
> app.

<frown>  Speaking entirely from ignorance <grin> that *sounds* like
a memory issue.  I.e., the cost of visiting a URL should remain
the same -- regardless of how long Firefox has been running.  What
is likely to change, over time, is how much memory has been consumed
and.or how heavily fragmented memory is becoming (making it harder
to satisfy memory allocation requests... leading to more GC activity,
etc.)

> I'm looking forward to trying one of the Android 4.2 nightlies to see
> how big a difference there is in performance, or, at least, perceived
> performance.  :)

It's just hard for me to imagine something with that much horsepower
being that *sluggish*!  Unless there are power conservation issues
that are getting in the way (e.g., if it has to power down regions
of memory not in currently use.... or, demand load pages from secondary
storage *when* needed, etc.)

In your reply to Nick, you mentioned "LBE"s role.  Do you know *how* it
is implemented?  I.e., does it "hook" the portions of the API that would
normally be used to access "private data" and conditionally filter
them based on its current configuration?  (In which case, it should
only have an impact on those particular calls!)   Or, does it sit
and examine executing threads to see where they are poking around
(in which case, it could slow down *everything*)?