Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 != user. That's the case in CM9 since for some reason they only know about, build type = userdebug. It is stupid to have this patch enabled by default as it affects performance for all their users. 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 initialization/work... Yes absolutely, using threading or lazy initalization when appropriate. onCreate(), onResume(), onStart() have to execute as fast as possible. The only limiting factor here is is the time taken by loading layouts which cannot be easily reduced or reduced at all. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 using AsyncTask) to do heavy initialization/work... Yes absolutely, using threading or lazy initalization when appropriate. onCreate(), onResume(), onStart() have to execute as fast as possible. The only limiting factor here is is the time taken by loading layouts which cannot be easily reduced or reduced at all. It seems that inflating views just isn't very fast, even with the binary XML format and stuff. I recently spent some time profiling my app's opening a ListView containing... a list... of data items (duh). On a Galaxy Nexus, there are about 7-8 of them fitting on the screen, each having about 8-10 child views in a RelativeLayout. The initial onLayout() takes about 150-200ms, which is very noticable. The time spent in the layout inflater (called by getView, called during this initial layout to make scrap views) is about 2/3 of that. By comparison, the Gmail app's (just to pick an example) list rendering is really fast -- but then each item in their message list is a sinlge Android view. -- K -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 avoid the black screen effect while the app is busy in onCreate() loading the layout. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 safe to invoke the layout inflater in a thread to preload the layout while displaying a loading screen , I suppose one could preload some views in advance on the UI thread, taking 10-15 ms here and there when noone's looking... but it's kind of unpleasant to manage and wouldn't work in your case with the initial onCreate to avoid the black screen effect while the app is busy in onCreate() loading the layout. I'm not getting the black screen, but the 150-200 ms is very noticeable (the db query behind the list view runs on a worker thread and takes 10-20 ms -- these times are from when I update the adapter to when the list view is done with its layout). ... except, well, on my app's initial screen when posting a dialog (the changelog after a version update), which is kind of unpleasant too, will need to look at that. -- K -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 aggressive: 08-15 15:33:24.804: I/dalvikvm(8550): threadid=3: reacting to signal 3 08-15 15:33:24.882: I/dalvikvm(8550): Wrote stack traces to '/data/anr/traces.txt' which further slow down app startup (writing on the SD Card take some time). So if setContentView() takes more than 500ms (not an uncommon occurence), then the system penalize the app even more, writting unwanted stack traces (the app is not ANRing at this stage, it is starting). Since is not safe to call the layout inflater in an AsyncTask to load it in the background while displaying some progress display, this result in Activities displaying a black screen until onCreate() finishes which may be quite some time if setContentView() cannot be executed fast. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 complex layouts ? In ICS+, if the main UI thread is stuck for more than approx 500ms the system great the app with a super aggressive: 08-15 15:33:24.804: I/dalvikvm(8550): threadid=3: reacting to signal 3 08-15 15:33:24.882: I/dalvikvm(8550): Wrote stack traces to '/data/anr/traces.txt' which further slow down app startup (writing on the SD Card take some time). So if setContentView() takes more than 500ms (not an uncommon occurence), then the system penalize the app even more, writting unwanted stack traces (the app is not ANRing at this stage, it is starting). Since is not safe to call the layout inflater in an AsyncTask to load it in the background while displaying some progress display, this result in Activities displaying a black screen until onCreate() finishes which may be quite some time if setContentView() cannot be executed fast. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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): 08-15 15:33:24.804: I/dalvikvm(8550): threadid=3: reacting to signal 3 08-15 15:33:24.882: I/dalvikvm(8550): Wrote stack traces to '/data/anr/traces.txt' Shouldn't it write this file only when the ANR happens (5s) ? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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, 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): 08-15 15:33:24.804: I/dalvikvm(8550): threadid=3: reacting to signal 3 08-15 15:33:24.882: I/dalvikvm(8550): Wrote stack traces to '/data/anr/traces.txt' Shouldn't it write this file only when the ANR happens (5s) ? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 (like measure, layout placement, drawing). On 15 August 2012 23:02, b0b pujos.mich...@gmail.com wrote: 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, 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): 08-15 15:33:24.804: I/dalvikvm(8550): threadid=3: reacting to signal 3 08-15 15:33:24.882: I/dalvikvm(8550): Wrote stack traces to '/data/anr/traces.txt' Shouldn't it write this file only when the ANR happens (5s) ? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 '/data/anr/traces.txt' 08-15 23:08:57.128: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:57.582: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:58.058: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:58.558: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:59.011: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' That could explained why I noticed some unexlained lags on my Samsung Galaxy S CM9. It looks like it spends its time writing stack traces... Well, that issue will have had the benefit to make me turbo optimize onCreate() and friends while trying to get rid of it. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 in the know is - can it be disabled ? I had high hope in a property called dalvik.vm.lockprof.threshold set to 500 but chaning it or removing it doesn't do anything. - who thought that this feature to write stack traces if the UI thread is blocked for 500ms is a good idea ? Is it to make the device even slower, writing stack trace that nobody will ever read ? This feature seems to be only be enabled on some ROMs but doesn't look restricted to CyanogenMod. On Wednesday, 15 August 2012 23:14:40 UTC+2, b0b wrote: 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 '/data/anr/traces.txt' 08-15 23:08:57.128: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:57.582: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:58.058: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:58.558: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:59.011: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' That could explained why I noticed some unexlained lags on my Samsung Galaxy S CM9. It looks like it spends its time writing stack traces... Well, that issue will have had the benefit to make me turbo optimize onCreate() and friends while trying to get rid of it. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 initialization/work... On Aug 15, 2012 5:16 PM, b0b pujos.mich...@gmail.com wrote: 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 in the know is - can it be disabled ? I had high hope in a property called dalvik.vm.lockprof.threshold set to 500 but chaning it or removing it doesn't do anything. - who thought that this feature to write stack traces if the UI thread is blocked for 500ms is a good idea ? Is it to make the device even slower, writing stack trace that nobody will ever read ? This feature seems to be only be enabled on some ROMs but doesn't look restricted to CyanogenMod. On Wednesday, 15 August 2012 23:14:40 UTC+2, b0b wrote: 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 '/data/anr/traces.txt' 08-15 23:08:57.128: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:57.582: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:58.058: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:58.558: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' 08-15 23:08:59.011: I/dalvikvm(30403): Wrote stack traces to '/data/anr/traces.txt' That could explained why I noticed some unexlained lags on my Samsung Galaxy S CM9. It looks like it spends its time writing stack traces... Well, that issue will have had the benefit to make me turbo optimize onCreate() and friends while trying to get rid of it. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 nice if Dianne or Romain could confirm this. 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? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 people into thinking that it works a different way than it does: it is because it is true, the view hierarchy is single-threaded, and it is explicitly not designed to be used from multiple threads. If you think that not seeing checks about which thread calls are being made on indicates that something is safe to use from multiple threads, you should probably stop whatever multi-threaded programming you are doing and rethink it. :} Even instantiating a view from one thread and attaching it to a view hierarchy in another is not safe, because many views will internally create Handler objects that are bound to whatever thread they were created on, causing you to have parts of your view hierarchy running on the wrong thread with bad results. On Tue, Jun 26, 2012 at 2:00 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: 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? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 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 nice if Dianne or Romain could confirm this. 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? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 are expensive to compute, just compute those pieces of data in the background thread and create the View in the UI thread after that, giving it the earlier computed data. On Tuesday, June 26, 2012 6:04:44 PM UTC-4, Tamás Kovács 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 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 nice if Dianne or Romain could confirm this. 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? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 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 are expensive to compute, just compute those pieces of data in the background thread and create the View in the UI thread after that, giving it the earlier computed data. On Tuesday, June 26, 2012 6:04:44 PM UTC-4, Tamás Kovács 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 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 nice if Dianne or Romain could confirm this. 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? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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* appear when the Activity is displayed that uses it. This is the reason I preinstantiate my View to a static (yes, I take care to null it out, so there will be no leak). Assume I have Activity A and B. Is the below solution allowed then (all in UI thread, just at different times): 1. From Activity A: sStaticVar = new MyCustomView(this.getApplicationContext()) 2. From Activity B onCreate(): mRootLayout.addChild(sStaticVar); // instead of addChild(new MyCustomView(this)) or new MyCustomView(getApplicationContext()) In this way, each time Activity B is must be displayed, it will display instantly. My SystemClock measurements seem to confirm this. On Jun 27, 12:23 am, Dianne Hackborn hack...@android.com wrote: 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 people into thinking that it works a different way than it does: it is because it is true, the view hierarchy is single-threaded, and it is explicitly not designed to be used from multiple threads. If you think that not seeing checks about which thread calls are being made on indicates that something is safe to use from multiple threads, you should probably stop whatever multi-threaded programming you are doing and rethink it. :} Even instantiating a view from one thread and attaching it to a view hierarchy in another is not safe, because many views will internally create Handler objects that are bound to whatever thread they were created on, causing you to have parts of your view hierarchy running on the wrong thread with bad results. On Tue, Jun 26, 2012 at 2:00 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: 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? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 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 are expensive to compute, just compute those pieces of data in the background thread and create the View in the UI thread after that, giving it the earlier computed data. On Tuesday, June 26, 2012 6:04:44 PM UTC-4, Tamás Kovács 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 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 nice if Dianne or Romain could confirm this. 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? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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: Fix the real problem. For example, if the real problem is too many views, find ways to consolidate them (e.g., compound drawables in TextViews, RelativeLayout or GridLayout instead of nested LinearLayouts). -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in DC: http://marakana.com/training/android/ -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
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 too. The thing that confused me that the doc implies that the rule applies methods on EXISTING views (on any way), and does not state anything about their CONSTRUCTION (instantiation). Moreover, for the beginner eye, at the first glance, the concept of AsyncDrawable may also be confusing: the AsyncDrawable is not instantiated async (it's created on the UI thread), it's called async because its contents (Bitmap) is loaded asynchronously. http://developer.android.com/training/displaying-bitmaps/process-bitmap.html -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
