On Jan 28, 11:08 am, Mark Murphy <[email protected]> wrote:
> kolby wrote:
> > My app is Steel, a web browser.
>
> Ah, sorry, didn't make the connection.
No reason to be sorry, I didn't mention it before ;)
>
> > If I had used other resource heavy apps before launching Steel (like
> > the other browser or maps), the UI is sluggish, pages take longer to
> > render, and event handling in the virtual keyboard is delayed. Until
> > they finally get cleared out, which can take some time.
>
> 1. How long is "some time"?
>
Anecdotal evidence suggests for the first few (< 5 mins). I have too
many
other things to debug still, so this hasn't been one of my priorities
yet, but it
has been to some of my users according to feedback.
> 2. Are you pre-allocating a lot of stuff as Steel opens, or is the
> sluggishness mostly triggered by user actions once your activity is up?
> In other words, are the complaints stemming more from the initial
> launch, or more from attempts to click/pan/type and otherwise use Steel
> once opened?
>
The sluggishness is most noticeable in the virtual keyboard, where
visual
feedback/response time is critical. This is typically used at the
beginning to
enter a web address. But also, page rendering times are longer. If a
page
gets loaded at startup depends on the user's preferences.
> 3. Can you detect that this situation is occurring to your code in real
> time? In other words, while you as a human can recognize sluggishness
> just as a matter of course, is there a way you can put enough internal
> profiling in Steel such that *Steel* realizes "hey, things are going
> slower than normal"?
As stated above, I have not had the time to analyze it in more detail
yet.
>
> Based on these answers, I can help you brainstorm ways for Steel to
> perhaps require resources more gracefully at startup and help manage
> user expectations for everything else that can't be otherwise dealt with.
Between opening at least one WebView and potentially showing a virtual
keyboard, there's really very little in terms of managing user
expectations.
I know that the VKeyboard code could still be optimized, and I wasn't
trying
to discuss Steel's particular needs here, I was just chiming in on the
issue
of letting the OS manage resources vs. applications exiting properly.
>
> After all, the Android OS model is not significantly different than the
> pagefile/swapfile approach used by other OSes, at least in terms of the
> perceived impact upon a newly-opening application. Use the same
> techniques in Android as you would in, say, Windows for dealing with the
> case where your application needs to do work on startup and the user
> might have a bunch of other applications open.
The windows analogy is not 100% working for me here, because I believe
in
Android everything is in memory, we're not trying to access a hard
drive, and
even then, freeing room in a pagefile is much less resource intensive,
than
actually closing other applications based on demand, with callbacks to
allow
those apps to clean up, and having a garbage collector run in a java
environment.
All this while my poor app is trying to look good ;)
Sometimes a user really does know when she wants to close an app and
not
use it again for a while, but Android is denying them the decision.
Thanks,
Michael
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" 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-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
