Effizienz findViewById

Macht es absolut keinen Unterschied, ob Sie sich für die View direkt oder wenn man sich für ein Elternteil und erst dann das Kind. Aber wenn Sie zum Beispiel wollen Sie zum abrufen der drei TextViews im LinearLayout mit der id some_id_8 dann wäre es besser für die Leistung wenn Sie ersten Blick für die LinearLayout und dann für die TextViews. Aber der Unterschied ist verschwindend klein. Das eigentliche problem ist das layout selbst (mehr dazu weiter unten).

Und in der Regel findViewById() ist nicht die Quelle allen übels. Es kann sein, ein problem in einem ListView wenn Sie anrufen findViewById() möglicherweise sogar mehrere Male während jeder getView() nennen, aber das ist es, was die Ansicht Halter pattern ist für.

Wenn die Leistung entscheidend ist, dass Sie rufen findViewById() so wenig wie möglich. In einem Fragment oder Activity Sie Aussehen kann für alle die Views Sie jemals brauchen werden, in onCreateView() oder onCreate(). Wenn Sie speichern die Verweise in ein paar member-Variablen, die Sie nie haben, es zu nennen, wieder.

Nun zu erklären, warum findViewById() kann ein performance-problem, das wir haben, um einen Blick auf seine Umsetzung, dieser link führt zur Android 4.4.4 View source code:

public final View findViewById(int id) {
    if (id < 0) {
        return null;
    }
    return findViewTraversal(id);
}

So findViewById() nur überprüft, ob die id gültig ist, und wenn es dann die protected-Methode findViewTraversal() genannt wird. In einem View implementiert ist es so:

protected View findViewTraversal(int id) {
    if (id == mID) {
        return this;
    }
    return null;
}

Es nur prüft, ob die übergebene id gleich der id des View und zurück this wenn Sie es tut, sonst null. Der interessante Teil ist die findViewTraversal() Umsetzung von ViewGroup, dieser Link führt zur Android 4.4.4 ViewGroup source-code:

protected View findViewTraversal(int id) {
    if (id == mID) {
        return this;
    }

    final View[] where = mChildren;
    final int len = mChildrenCount;

    for (int i = 0; i < len; i++) {
        View v = where[i];

        if ((v.mPrivateFlags & PFLAG_IS_ROOT_NAMESPACE) == 0) {
            v = v.findViewById(id);

            if (v != null) {
                return v;
            }
        }
    }

    return null;
}

Den ersten, wenn an der Spitze dieser Methode ist die gleiche wie in der View Umsetzung, es prüft nur, ob die übergebene id entspricht der id des ViewGroup und wenn es tut, gibt sich selbst. Danach durchläuft es die Kinder und fordert findViewById() auf jedes der Kinder, wenn der Rückgabewert dieses Aufrufs ist nicht null dann die View suchen wir für gefunden wurde und zurückgegeben werden.

_{Wenn Sie mehr details darüber, wie Views oder ViewGroups Arbeit ich schlage vor, studieren Sie den source-code selbst!}

Also das scheint alles ziemlich straight-forward. Die view-Hierarchie ist im wesentlichen durchzogen ist wie ein Baum. Und, kann es ziemlich teuer oder ziemlich schnell, je nachdem, wie viele Views sind in Ihrem layout. Es spielt keine Rolle, wenn dein layout sieht so aus:

<LinearLayout android:id="@+id/some_id_0">
    <LinearLayout android:id="@+id/some_id_1">
        <LinearLayout android:id="@+id/some_id_2">
            <TextView android:id="@+id/textview0" />
        </LinearLayout>
    </LinearLayout>
</LinearLayout>

Ist oder wenn es sieht wie folgt aus:

<LinearLayout android:id="@+id/some_id_0">
    <LinearLayout android:id="@+id/some_id_1" />
    <LinearLayout android:id="@+id/some_id_2" />
    <TextView android:id="@+id/textview0" />
</LinearLayout>

Da die Menge der Views ist die gleiche in beiden Fällen, und die Leistung von findViewById() skaliert mit der Menge des Views.

ABER die Allgemeine Regel ist, dass man versuchen sollte zu reduzieren die Komplexität des Layouts, um die Leistung zu erhöhen und, dass Sie sollte benutzen oft eine RelativeLayout. Und das funktioniert nur, weil, wenn Sie reduzieren die Komplexität Sie reduzieren auch die Menge der Views in das layout und die RelativeLayouts sind sehr gut auf die Reduzierung von Komplexität. Lassen Sie mich veranschaulichen, dass, Bild, Sie haben ein layout wie diese:

<LinearLayout android:id="@+id/some_id_0">
    <RelativeLayout android:id="@+id/some_id_5">
        <LinearLayout android:id="@+id/some_id_1" />
        <LinearLayout android:id="@+id/some_id_2" />
    </RelativeLayout>
    <RelativeLayout android:id="@+id/some_id_6">
        <LinearLayout android:id="@+id/some_id_3" />
        <LinearLayout android:id="@+id/some_id_4" />
    </RelativeLayout>
</LinearLayout>

Vorstellen, dass in diesem Fall sowohl von der RelativeLayouts oben sind nur da, um die position des inneren LinearLayouts auf Besondere Weise die äußeren LinearLayout ist nur da, um die position der RelativeLayouts unter einander. Sie können sehr leicht erstellen, die das gleiche layout mit nur einem RelativeLayout als eine Wurzel und die vier LinearLayouts als Kinder:

<RelativeLayout android:id="@+id/some_id_0">
    <LinearLayout android:id="@+id/some_id_1" />
    <LinearLayout android:id="@+id/some_id_2" />
    <LinearLayout android:id="@+id/some_id_3" />
    <LinearLayout android:id="@+id/some_id_4" />
</RelativeLayout>

Und die Leistung, das layout wird besser sein als das layout oben nicht, weil die RelativeLayout ist irgendwie leistungsmäßig besser als ein LinearLayout - und nicht weil das layout flacher, sondern einfach, weil die Menge der Views im layout ist niedriger. Das gleiche gilt für fast alle anderen view-bezogene Prozesse wie zeichnen, layouten, Messen. Alles wird schneller, nur weil die Höhe der Views im layout ist niedriger.

Und um zurück zu deiner ursprünglichen Frage: Wenn Sie möchten, eine Leistung zu erhöhen als verringern Sie die Komplexität Ihres Layouts. Es gibt absolut keinen Grund zu haben, so viele verschachtelte LinearLayouts. Ihre "große Teilmenge" kann fast sicher sein, reduziert dies:

<RelativeLayout android:id="@+id/r0">  
    <TextView android:id="@+id/textview0" />
    <TextView android:id="@+id/textview1" />
    <TextView android:id="@+id/textview2" />
    <TextView android:id="@+id/textview3" />
    <TextView android:id="@+id/textview4" />
</RelativeLayout>

Und so eine layout wäre auf jeden Fall Ertrag, einen großen performance-boost.