On Thursday, 16 August 2012 03:47:02 UTC+2, MagouyaWare wrote:
Then you would need to talk to the makers of the roms that are doing
this...
Yes after even more digging deeper, it is due to a recent CM commit:
http://review.cyanogenmod.com/#/c/18319/1
which is enabled if build type !=
2012/8/16 b0b pujos.mich...@gmail.com
On Thursday, 16 August 2012 03:47:02 UTC+2, MagouyaWare wrote:
As for onCreate() you shouldn't really be doing ANYTHING except calling
setContentView() and initializing a few member variables. Anything else
needs to go in a separate thread (perhaps
It seems that inflating views just isn't very fast, even with the binary
XML format and stuff.
Yes it can be very slow for complex layouts.
It is unfortunate that it is not safe to invoke the layout inflater in a
thread to preload the layout while displaying a loading screen ,
to
2012/8/16 b0b pujos.mich...@gmail.com
It seems that inflating views just isn't very fast, even with the binary
XML format and stuff.
Yes it can be very slow for complex layouts.
I wouldn't consider 8-10 views, times 7-8 list view items very complex.
It is unfortunate that it is not
Interesting discussion but how are we supposed to handle setContentView()
(which calle the layour inflater, which instantiates views),
taking a lot of time for complex layouts ?
In ICS+, if the main UI thread is stuck for more than approx 500ms the
system great the app with a super
An ANR is triggered if the UI thread is blocked for 5 seconds, not 500ms.
On Aug 15, 2012 9:15 PM, b0b pujos.mich...@gmail.com wrote:
Interesting discussion but how are we supposed to handle setContentView()
(which calle the layour inflater, which instantiates views),
taking a lot of time for
On Wednesday, 15 August 2012 22:07:46 UTC+2, Romain Guy (Google) wrote:
An ANR is triggered if the UI thread is blocked for 5 seconds, not 500ms.
Yes, but until the ANR hapens (or not if the UI thread is blocked fior
say...3s), the logcat spams these messages every 500ms (CM9, ICS 4.0.4):
My Asus TF101 running stock ICS doesn't display the Wrote stack traces
line in the logcat every 500ms the UI thread is not responding, which make
me think it could be a CM9 issue or bug ?
On Wednesday, 15 August 2012 22:39:09 UTC+2, b0b wrote:
On Wednesday, 15 August 2012 22:07:46 UTC+2,
Kedves Tamás,
It's really strange. What are you doing in your view's constructor? I
view's constructor mostly reads's out the given attributes depending
on the given style. Init some members, like Paint objects, but usually
that's all.
Every hard work comes after it's attached to the hierarchy
I'm now convinced it is a CM9 issue as it writes stack traces for almost
any app, at startup but also sometimes during normal execution.
To prove I am not affabulating, this when starting the camera app (in
between lines omitted):
08-15 23:08:57.078: I/dalvikvm(30403): Wrote stack traces to
After more investigations, it look like each of this Wrote stack traces
logcat line will write a /data/anr/slow??.txt :
shell@android:/data/anr $ ls
slow00.txt
slow01.txt
slow02.txt
slow03.txt
slow04.txt
slow05.txt
slow06.txt
slow07.txt
slow08.txt
slow09.txt
traces.txt
My question to thows
Then you would need to talk to the makers of the roms that are doing
this...
As for onCreate() you shouldn't really be doing ANYTHING except calling
setContentView() and initializing a few member variables. Anything else
needs to go in a separate thread (perhaps using AsyncTask) to do heavy
It works seamlessly like a charm. It would be nice to know if this is
supported/acceptable generally.
I hope we'll get an answer from the Android guys/ladies.
On Jun 26, 10:53 pm, Justin Anderson magouyaw...@gmail.com wrote:
I'm not sure, but I doubt it... Have you tried it? Did it work?
OK I made additional research and source code exploring:
only *ViewGroup* and its descendants check the Thread, the *View*
class does not. It does not even STORE the thread which created it.
Based on this, it should be safe to create Views (but never
Viewgroups) in different threads. It would be
No, it is not safe. Don't do this.
The documentation is very clear about this:
http://developer.android.com/reference/android/view/View.html
Note: The entire view tree is single threaded. You must always be on the
UI thread when calling any method on any view.
This wasn't written to mislead
It is not safe, and definitely not guaranteed to even work.
On Tue, Jun 26, 2012 at 3:04 PM, Tamás Kovács
falcon.firebre...@gmail.com wrote:
OK I made additional research and source code exploring:
only *ViewGroup* and its descendants check the Thread, the *View*
class does not. It does not
I would still advise against it, because you don't have control of the code
after you call the constructor of the View.
Creating a View should never be that expensive (i.e. time consuming) that
it could not be done on the UI thread.
If the creation of the View needs other pieces of data that
And if you have performance issues when instantiating certain Views,
please let us know so we can fix it.
On Tue, Jun 26, 2012 at 3:26 PM, Streets Of Boston
flyingdutc...@gmail.com wrote:
I would still advise against it, because you don't have control of the code
after you call the constructor
Thanks, Dianne, and others. This is what I needed to know.
I know I can async preload Drawables and Bitmaps (there is an official
tutorial, too), but it seems that my custom View is so complex that it
takes 1 second to instantiate (even if its drawables are preloaded).
And I need to *instantly*
Thanks, Boston, that's a good idea. I'll try to split my custom View
to smaller pieces, isolating the View-independent parts.
@Romain: thanks, we'll keep that in mind.
On Jun 27, 12:26 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
I would still advise against it, because you don't have
On Tue, Jun 26, 2012 at 6:51 PM, Tamás Kovács
falcon.firebre...@gmail.com wrote:
but it seems that my custom View is so complex that it
takes 1 second to instantiate (even if its drawables are preloaded).
Step #1: Run Traceview on your app.
Step #2: Find where the real problem is.
Step #3:
On a side note:
Note: The entire view tree is single threaded. You must always be on the
UI thread when calling any method on any view.
This wasn't written to mislead people [..]: it is because it is true
True, any method means the constructor too, since the constructor is
practically method
22 matches
Mail list logo
