onMeasure被称为1500多次

Question

我最近发现我的应用存在严重的性能问题。我基本上有以下布局......

描述
简而言之，有一个ViewPager可以将3个RelativeLayout作为页面。每个页面内都有许多TextView个。我最近注意到当我在EditText上输入TextWatcher来执行自动完成的快速SQL查询时会出现很多延迟。当我输入文本时，我的HTC One M8口吃和滞后，但我知道这不是查询速度慢，因为我测量的查询只花了大约7毫秒。

我使用了方法分析，Systrace和普通的Log调试，并得出结论，每次我在EditText中输入一个关于 1,700 调用onMeasure的字符时TextView在RelativeLayout A，B和C中TextView进行。累积地，页面上只有大约15个独立的onMeasure。我注意到每个EditText被调用了数百次，而不是像往常一样被调用一次或两次。

问题
我不知道为什么键入页面B中的TextView会导致页面A和C中的其他onMeasure也被“重新测量”。更重要的是，是否有人对如此频繁调用onMeasure的原因有所了解？而且，有没有人知道一个解决方案，可以显着减少对onMeasure的调用次数？

详情
这可能有所帮助：我实际上可以通过删除RelativeLayout 2来将onMeasure来电数量减少到大约900，这可能表明ViewPager来电的传播在外面开始{{1}}。

Answer 1

虽然我没有足够的信息来确定具体问题，但我可以告诉你一般情况：

调用根视图的measure会导致调用每个子视图的measure，依此类推，直到树下。

假设视图调用＆＃34;当前视图＆＃34;，在询问每个子视图自我测量后，决定没有足够的空间供所有孩子使用。它将要求他们每个人再次测量自己，建议最大尺寸。那么，假设该视图称为＆＃34;相对布局B＆＃34;根据指定的最大值从根本上改变其大小。因为变化是如此之大，＆＃34;当前观点＆＃34;必须再一次问每个孩子。这个循环可能很容易需要多次迭代才能解决。

当＆＃34;当前观点＆＃34;决定它的大小，它报告回＃＆＃34;查看寻呼机＆＃34;。假设＆＃34;查看寻呼机＆＃34;它的三个视图没有足够的空间，并且必须要求它们重新测量，最大值。我们现在至少有20次调用TextView＆＃39; onMeasure。如果ViewPager上面的每个其他视图都会迭代几次，很快就会看到大数字。

正如您已经指出的那样，最好的解决方案是减少树的深度。或者，您可以使用具有更简单的测量算法的布局管理器（FrameLayout，LinearLayout）

1500虽然很多。其中一种观点是做一些奇怪的事情。您应该能够使用DDMS套件中的TreeView工具非常简单地识别它。在eclipse中，它被称为＆＃34; TreeView＆＃34;。在Studio中，单击Android图标并切换到“层次结构视图”透视图。您也可以从SDK工具目录的命令行运行它。

<强>加了： 如果您在应用程序运行时将Hierarchy Viewer连接到应用程序，您将在其中一个窗格中看到整个视图树。树中的每个节点都有三个朝向底部的彩色橡皮糖。第一个胶基糖代表测量阶段。如果胶基糖是绿色的，那么该视图的测量阶段很快。如果它是黄色，则该节点位于布局中节点的前50％。如果它是红色，则它是布局中最慢的。

你应该可以沿着黄色的痕迹跟踪有问题的视图。