Well, it didn't seem insane on 1.1, and it ran happily enough. Let me break it down for you, and see if it makes any more sense.
>From the top, in HierarchyViewer, reading down the deepest path, we go: PhoneWindow$DecorView LinearLayout FrameLayout TabHost LinearLayout (comes with the TabHost) FrameLayout (comes with the TabHost) PhoneWindow$DecorView FrameLayout (for this tab) LinearLayout FrameLayout (also holds a loading-progress gizmo) FastScrollView ListView RelativeLayout (for the list item) OurPhotoView ImageView So, the total depth is the sum of several constructs that each use a few nested views - the TabHost needs a few, the fancy list needs a few, the photo view needs a few, and all of a sudden we are at 15. We used to use more, because the nesting of LinearLayouts worked very well as a way of collecting up a number of items that were often invisible, but that took us over the new stack size limit. Do you see how we got here ? Richard On Apr 24, 1:13 pm, Romain Guy <romain...@google.com> wrote: > A custom control has nothing to do with this kind of issue. Actually, > custom controls are a good way to avoid that issue, and optimize > layouts in general. Around 15 levels deep of layouts is just insanely > complex for a cell phone screen. > > > > On Fri, Apr 24, 2009 at 5:08 AM, jarkman <jark...@gmail.com> wrote: > > > I'm not sure it's realistic to describe this as a simple optimisation > > issue. > > > We've just gone through an exercise to fix these crashes in one of our > > apps. We've managed it, but only at the expense of uglification of the > > code. > > > We're working with a custom list on a tab. Looking at the hierarchy > > viewer, we are 12 deep in the tree by the time we get to our ListView. > > We now have three levels under that - a RelativeLayout for our list > > item, various simple views, and one custom control with a child view. > > > That just fits, and doesn't crash in 1.5. Previously, we laid out the > > list item with a 2-deep tree of linear layouts, which was a lot more > > convenient in our code. > > > As far as I can see, if we had built any more custom controls or used > > a more complex layout, we'd be quite knackered at this point, which > > makes this restriction seem like a real step backwards. > > > Richard > > > On Apr 24, 9:23 am, Dianne Hackborn <hack...@android.com> wrote: > >> We didn't have time for Cupcake, but we definitely want to have some very > >> well-defined limits in a future release. There is no nice error because > >> what actually is happening is the app is running out of stack space -- some > >> optimizations and new features in the view hierarchy caused certain > >> functions to use a little more stack, which can result in apps that were > >> skirting the edge of the stack to go over the limit. > > >> We apologize, and definitely aren't happy about this; we had some some > >> additional optimization of the code to reduce stack usage at the very last > >> minute but found a little later that it still wasn't enough. > > >> Anyway, if this makes cupcake not a good as 1.1 to you, well okay, I guess > >> don't run cupcake or something. > > >> (Btw, in practice, an application with a deep hierarchy like this is also > >> going to have noticeable performance issues because of the work required to > >> manage it, so this can be considered a nice opportunity to do a bit of good > >> optimization.) > > >> On Fri, Apr 24, 2009 at 12:52 AM, Al Sutton <a...@funkyandroid.com> wrote: > > >> > Having read > > >> >http://android-developers.blogspot.com/2009/04/future-proofing-your-a... > >> > l I noted this little section; > > >> > "Due to changes in the View rendering infrastructure, unreasonably deep > >> > (more than 10 or so) or broad (more than 30 total) View hierarchies in > >> > layouts are now likely to cause crashes. This was always a risk for > >> > excessively complex layouts, but you can think of Android 1.5 as being > >> > better than 1.1 at exposing this problem..." > > >> > Will the SDK warn us when we're reaching the limit for crashes? > > >> > And more to the point why does it crash and not return some form of > >> > meaningful error to the app? With an error code or thrown exception > >> > developers could create various levels of layout complexity and step down > >> > the layout complexity level until they find one the device will support. > > >> > Al. > > >> > P.S. No matter what the post says I see this as a regression in > >> > functionality and I definitely do not see it as "Android 1.5 as being > >> > better > >> > than 1.1" in any way. > > >> > --- > > >> > * Written an Android App? - List it athttp://andappstore.com/* > > >> > ====== > >> > Funky Android Limited is registered in England & Wales with the > >> > company number 6741909. The registered head office is Kemp House, > >> > 152-160 City Road, London, EC1V 2NX, UK. > > >> > The views expressed in this email are those of the author and not > >> > necessarily those of Funky Android Limited, it's associates, or it's > >> > subsidiaries. > > >> -- > >> 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. > > -- > Romain Guy > Android framework engineer > romain...@android.com > > Note: please don't send private questions to me, as I don't have time > to provide private support. 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 -~----------~----~----~----~------~----~------~--~---
