也是Android的布局真的很难指数？ [英] Is Android layout really exponentially hard?

问题描述

一些常用的Andr​​oid布局，如 RelativeLayout的和的LinearLayout时（权重为零） 有一个衡量自己的孩子onMeasure（）实现 两次，导致指数运行时间嵌套时。 这是容易核查通过发射日志条目 从叶查看的onMeasure（）...它被调用2 ^深度 次。

Some commonly used android layouts such as RelativeLayout and LinearLayout (when weights are nonzero) have onMeasure() implementations that measure their children twice, resulting in exponential running time when nested. This is easily verifiable by emitting Log entries from a leaf View's onMeasure()... it gets called 2^depth times.

有人可以给一个明确和具体说明，为什么这是？ 最重要的是，这是指数行为由于一个重要部分 整个合同，还是仅仅是一个实现细节 可能被优化掉？如果它被认为是不可避免的， 请给需要它的一个例子。

Can someone give a clear and specific description as to why this is? Most importantly, is this exponential behavior due to an important part of the overall contract, or is it just an implementation detail that might be optimized away? If it is believed to be unavoidable, please give an example that requires it.

这样的例子将极大地帮助我和其他人 谁是抱怨的让你的布局浅 任务是繁重的，谁是想知道 这是否正在被驱动简单地通过 在核心库的尚未优化算法， 或者是否真的有一个根本性的困难 阻断修复。

Such an example would greatly help me and others who are grumbling that the "keep your layouts shallow" mandate is burdensome and who are wondering whether this is being driven simply by not-yet-optimal algorithms in the core libraries, or whether there really is a fundamental difficulty blocking a fix.

也许一个最小的例子包括 在另一个的LinearLayout一个的LinearLayout内按钮 （与match_parent和重量= 1随处可见，触发 完整的指数行为）， 与一些额外的参数或环境 这就很清楚，所有四个呼叫的 到Button.onMeasure（）确实是有意义和必要的。

Perhaps a minimal example would consist of a Button inside a LinearLayout inside another LinearLayout (with match_parent and weight=1 everywhere, to trigger the full exponential behavior), with some additional parameters or circumstances making it clear that all four of the calls to Button.onMeasure() are indeed meaningful and necessary.

我的第一个猜想是，只有两个线性时间 遍历真的needed--的优先遍历，收集大家的 preferred大小，第二遍历分发懈怠 和/或收缩。 其他的布局引擎，世界如纺织品和Swing 似乎能够经常处理非常深层次结构 有很多的对齐约束，纵横交错， 没有任何指数爆破，和我想象这就是他们的工作。

My first guess would be that only two linear-time traversals are really needed-- the first traversal to gather everyone's preferred sizes, the second traversal to distribute slack and/or shrinkage. Other layout engines in the world like Tex and Swing seem to be able to routinely handle very deep hierarchies having lots of alignment constraints and stretches, without any exponential blowup, and I imagine that's how they work.

请注意，我不想回答解释的如何的 指数喷出occurs--我的理解是， 也有过几个职位已经在那里已经被 提出和回答：

Please note, I don't want answers explaining how the exponential blow-up occurs-- I understand that, and there have been several posts already where that has been asked and answered:

• <一个href="http://stackoverflow.com/questions/9430764/why-are-nested-weights-bad-for-performance-alternatives/">Why嵌套的权重不好的表现？替代方案？
• <一个href="http://stackoverflow.com/questions/13850509/android-layout-measuring-time-doubles-with-each-step-up-the-hierarchy/">Android每个加紧层次
布局测量时间加倍
• <一个href="http://stackoverflow.com/questions/14722538/layout-weight-warning-nested-weight-bad-performance/">Layout重量警告嵌套重量糟糕的表现
Android的布局层次
• 效率
• <一个href="http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html">http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html

• Why are nested weights bad for performance? Alternatives?
• Android layout measuring time doubles with each step up the hierarchy
• Layout Weight warning Nested weight bad performance
• Efficiency of Android Layout hierarchy
• http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html

我的问题是递归双测量是否 从根本上必要的/有道理的， 如果是的话，我想解释清楚/例子，说明为什么。

My question is whether the recursive double-measuring is fundamentally necessary/justified, and if so, I'd like a clear explanation/example showing why.

编辑2013年8月22日：我想也许我的问题仍然没有得到跨越。 我会尽力澄清和解释我的动机，更大胆的这个时候。

Edit 2013/8/22: I think maybe my question is still not getting across. I'll try to clarify and explain my motivation, more boldly this time.

布局不是一个指数很难的问题， 作为世界如纺织品和Swing证明有效的布局引擎。

Layout is not an exponentially hard problem, as evidenced by efficient layout engines in the world like Tex and Swing.

那么，发生了什么的LinearLayout， 以及如何在Android开发者社区进行应对？ 我问不怪铺设的精神， 而是要了解并决定如何最好地向前迈进。

So, what happened with LinearLayout, and how should the android developer community proceed in response? I am asking not in the spirit of laying blame, but rather to understand and decide how to best move forward.

我能想到的4种可能性：

I can think of 4 possibilities:

1. 修正的核心库的性能缺陷，在不改变任何合约
2. 根据需要，并修复性能缺陷更改合同 核心库
3. 在编写一个替代的LinearLayout，有其基本 功能（即分配额外的空间儿童在特定的比例），但没有业绩的错误，并将其用于新的应用程序
4. 在继续我们的微观布局来解决 为我们的Andr​​oid开发事业的其他部分的性能问题。

1. Fix the performance bug in the core library, without changing any contracts
2. Change contracts as needed, and fix the performance bug in the core library
3. Write an alternative to LinearLayout, that has its essential features (namely distributing extra space among children in specified proportions) but without the performance bug, and use it for new apps
4. Continue to micromanage our layouts to work around the performance bug for the rest of our android development careers.

（4）不是对我个人一个严肃的选择。 此外，它似乎很清楚，我认为 改变此时的LinearLayout的行为是不切实际的， 所以我不认为（2）是一个严肃的选择无论是。

(4) isn't a serious option for me personally. Furthermore it seems clear to me that changing the behavior of LinearLayout at this point is impractical, so I don't believe (2) is a serious option either.

这叶（1）和（3）。 我有能力和愿意做任何的个人的，但哪一个？ 显然，（1）远preferable如果是possible--所以，这可能吗？ 这似乎是一个需要回答的关键问题，堵塞 以决定如何向前推进。

That leaves (1) and (3). I'm capable and willing to do either of those personally, but which one? Obviously (1) is far preferable if it's possible-- so, is it possible? That seems to be the crucial blocking question that needs to be answered in order to determine how to move forward.

我已经花了一些时间在核心code 和DOC，它不是越来越明显， 所以这就是为什么我问的问题在这里。

I have spent some time in the core code and the doc and it's not becoming clear, so that is why I'm asking the question here.

推荐答案

在测量儿童的两倍而言，这是我的理解，这是与LinearLayouts参与权特别是当发生了什么。我发现这个最好的解释来自RomainGuy在他的presentations之一。

In terms of measuring children twice, it's my understanding that this is what happens with LinearLayouts particularly when weights are involved. The best explanation I've found for this comes from RomainGuy in one of his presentations.

他有一个关于这个幻灯片，并简要说来它在17:45。随意倒带变得有点背景的，虽然。你可以找到我在这里引用视频： Devoxx'10 - 深入的Andr​​oid

He has a slide about this and briefly speaks to it at 17:45. Feel free to rewind to get a bit of context though. You can find the video I'm referencing here: Devoxx'10 - Dive Into Android

基本上他说的是，在第一轮，他们计算出总的宽度或高度依赖于的LinearLayout的方向，增加孩子们的权重，并找出多少空间留下来，然后在第二遍用该信息，他们都能够正常瓜分出所有剩余的空间给所有的孩子。就这么简单。

Basically what he says is that on the first pass they calculate the total width or height depending on orientation of the LinearLayout, add the weights of the children, and find out how much space is left over, then on the second pass with that information they are able to properly divvy out all the remaining space to all the children. Simple enough.

我也想指出，尽管这是的，虽然这是很真实的那浅浅的布局层次少的性能损失，如果要添加只有1或2个额外的图层，你可能不会看到一个大的性能影响的用户。一旦它摆出来，它的完成。即使在ListView的，如果你正确地使用给定的convertView，并成立了ViewHolder的，你会得到不错的表现。

I'd also like to point out though that yes, while it's very true that shallow layout hierarchies have less of a performance hit, if you are adding just 1 or 2 extra layers, you probably aren't going to see a big performance impact for the user. Once it's laid out, it's done. Even in ListView's if you properly use the given "convertView", and set up ViewHolder's, you're going to get good performance.

我会鼓励你使用DDMS，并做了一些谷歌的应用程序布局转储。他们是非常复杂的，很多时候令人惊异的，但他们仍然获得良好的性能。别傻了你的布局，但如果它可以节省您的时间，增加一个额外的布局是不是世界的尽头。

I'd encourage you to use DDMS and do a layout dump of some of Google's apps. They are very complex, and often times surprisingly deep, but they still get good performance. Don't be stupid with your layouts, but if it saves you time, adding an extra layout isn't the end of the world.

这篇关于也是Android的布局真的很难指数？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！