作为后续行动，这问题，我想不出任何好的理由，为什么我不应该每个包中包含＆LT XML布局，合并＆GT; 对。

As a follow-up to this question, I can't think of any good reason why I shouldn't wrap every included XML layout in a <merge> pair.

然后让我纳闷了，为什么没有ADT团队只是使这个默认的行为？

Which then leads me to wonder, why didn't the ADT team just make this the default behavior?

有其中一个不希望这种行为无论如何？

Is there any case where one wouldn't want this behavior?

顺便提及，在机器人文档的＆LT;合并＆GT; 标签比最差的法律协议的措辞更糟糕的：

Incidentally, the explanation in the Android documentation of the <merge> tag is worse than the wording in the worst legal agreements:

在＆LT;合并/＆GT; 标记有助于消除多余的视图组视图   包括在另一个布局时的层次结构。例如，如果   主布局是垂直的LinearLayout ，其中两个连续的   视图可以重复使用多种布局，然后可重复使用的布局   您将两种观点都需要有自己的根视图。然而，   使用其他的LinearLayout 作为根的可重复使用的布局会   结果在垂直的LinearLayout 内的垂直的LinearLayout 。该   嵌套的的LinearLayout 服务，而不是放慢其他没有什么实际意义   你的用户界面的表现。

The <merge /> tag helps eliminate redundant view groups in your view hierarchy when including one layout within another. For example, if your main layout is a vertical LinearLayout in which two consecutive views can be re-used in multiple layouts, then the re-usable layout in which you place the two views requires its own root view. However, using another LinearLayout as the root for the re-usable layout would result in a vertical LinearLayout inside a vertical LinearLayout. The nested LinearLayout serves no real purpose other than to slow down your UI performance.

罗曼，你在哪里？

推荐答案

在包括标记（我看它的方式）的主要目的是为了让开发者创建可重复使用的xml组件在一个应用程序来多次使用的相同的活性和/或在许多活动。为了为可重用的组件是非常有用的，它需要是自包含的，用最少的外部连接的更多钞票的。从我的角度来看，如果你使用合并标记中的每个包括布局，这将减少的实用性的包括标记的整体。这就是为什么我认为这会发生的一个例子：

The main purpose of the include tag(the way I see it) is to allow the developer to create reusable xml components to be used multiple times in the same activity or/and across many activities in an app. In order for that reusable component to be really useful it needs to be self contained and with a minimum of outside connections as posible. From my point of view, if you were to use the merge tag in each included layout this will reduce the usefulness of the include tag overall. Here is an example why I think this will happen:

假设您想要实现一个可重复使用的动作条 XML组件在您的每一个活动的嵌入。它将包含一个的TextView 和按钮水平放置。布局要做到这一点是：

Consider that you want to implement a reusable ActionBar xml component to embed in each of your activities. It will contain a TextView and a Button placed horizontally. A layout to do this would be:

R.layout.actionbar

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" >

    <TextView
        android:id="@+id/actionbar_title"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

    <Button
        android:id="@+id/actionbar_action"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

</LinearLayout>

现在假设你在你的应用程序的两项活动，一是那里的根视图是一个的LinearLayout （方向垂直）和一个地方根视图是一个 RelativeLayout的。布局上面可以很容易地被列入的LinearLayout （只是把它放在你想要的），同样将有可能与 RelativeLayout的，当然同时考虑从目前的元素 RelativeLayout的（请记住，您必须设置 layout_width /身高（例如，从包括布局的根复制），以便为包括标记为其他 layout_ * 属性被考虑）。

Now suppose you have two activities in your app, one where the root view is a LinearLayout(orientation vertical) and one where the root view is a RelativeLayout. The layout above could easily be included in the LinearLayout(just put it where you want), the same will be possible with the RelativeLayout, of course taking in consideration the current elements from that RelativeLayout(keep in mind that you must set the layout_width/height(for example, replicated from the included layout's root) for the include tag in order for the other layout_* attributes to be considered).

现在需要考虑你的建议。布局将变为：

Now take in consideration your proposal. The layout will become:

<merge xmlns:android="http://schemas.android.com/apk/res/android" >

    <TextView
        android:id="@+id/actionbar_title"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

    <Button
        android:id="@+id/actionbar_action"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

</merge>

看着我们动作条的布局并没有告诉我们这么多，你只是有一个的TextView 和按钮在某个地方包括在内。现在考虑的活动，其中的根源是垂直朝向的的LinearLayout 。布局 R.layout.actionbar 不能简单地纳入，因为这会破坏我们的动作条，我们需要添加一个额外的的LinearLayout （与水平方向）为我们的布局，使它看起来像期望。正如你可以看到你在上面（布局没有合并标记）的情况，但现在你要记住包裹在包括布局的LinearLayout 与水平方向究竟在哪儿父根是一个的LinearLayout 与方向垂直。

Looking at our ActionBar layout doesn't tell us that much, you just have a TextView and a Button to be included somewhere. Now consider the activity where the root is the vertical orientated LinearLayout. The layout R.layout.actionbar can't be simply included as this will break our ActionBar, we need to add an extra LinearLayout(with orientation horizontal) for our layout to make it look as desired. As you can see you are in the situation above(layout without the merge tag), but now you have to remember to wrap the included layout in a LinearLayout with orientation horizontal where ever the parent root is a LinearLayout with orientation vertical.

事情变得更糟合并在 RelativeLayout的（一个很好的问题，读How让RelativeLayout的合作与合并，包括？）。该选项，再嵌入包括在的LinearLayout 这使你的情况没有合并标记（但是现在增加了更多的问题比解决）。同样读的是最后一部分，从这个链接的http：// code.google.com / P /安卓/问题/详细信息？ID = 2863 可能会发现其他错误与包括标记。

Things get even worse when the root is a RelativeLayout, you can't simply use the include tag with merge in a RelativeLayout(a nice question to read How to get RelativeLayout working with merge and include?). The option is, again, to embed the include in a LinearLayout which puts you in the situation without the merge tag(but now adding more problems than solving). Also reading the last part from this link http://code.google.com/p/android/issues/detail?id=2863 may reveal other bugs with the include tag.

正如你可以从我的例子见上面，具有合并默认标签可能会导致在某些情况下一些问题。同样，当前系统重新presents更一致的方式与布局工作（如你创建正常的布局有一个根查看）。此外，合并标记是一个优化，我不认为你应该尝试优化，直到你开始看到一些性能问题（或者你真的想榨取最后一滴的性能，在复杂性的费用）。大多数应用程序会就好了与现行制度，有意见可以生活在没有合并的优化，没有任何问题都一个体面的数额的三四级深的布局

As you can see from my example above, having the merge tag by default could result in some problems in certain situation. Also the current system represents a more consistent way to work with layouts(you would create the layout for the include tag like you create normal layouts with a root View). Also, the merge tag is an optimization and I don't think you should try to optimize until you start to see some performance issues(or you really want to squeeze every last drop of performance, at the cost of complexity). The majority of apps will be just fine with the current system, a three-four level deep layout with a decent amount of views could live without the merge optimization with no problems at all.

与合并标签的另一个问题是，一个充气的布局，有合并作为它的根须重视本身到父膨胀时。如果你吹大 R.layout.actionbar 的布局，那么你就必须将其附加到父：

Another problem with the merge tags is that a inflated layout that has merge as its root is required to attach itself to a parent when inflated. If you were to inflate the R.layout.actionbar layout then you would have to attach it to a parent:

View actionBar = getLayoutInflater().inflate(R.layout.actionbar, root, true);

我不知道这是不是一个真正的限制，也许在某些罕见的情况下，它可能是一个大忌。

I don't know if this is a real limitation, maybe in some rare situation it could be a deal breaker.

约只是我的意见包括 - 合并对使用

Just my opinion about the include - merge pair use.