Wie Instagram Direct-Entwickler mit Jetpack Compose eine KI-native UI-Architektur erstellt und die Tokenkosten pro Agentsitzung um 33 % gesenkt haben

Dieser Blogbeitrag wurde in Zusammenarbeit mit dem Meta-Team verfasst.

Instagram Direct ist eine der wichtigsten Oberflächen auf Instagram und verarbeitet jeden Tag Milliarden von Nutzernachrichten. Im Laufe der Jahre hat das Team jede mögliche Mikrooptimierung aus dem alten Android View-System herausgeholt. Die Wartung und Erweiterung einer stark optimierten Legacy-Oberfläche führt jedoch zu erheblichen technischen Schulden und Entwicklungsaufwand, insbesondere da Teams zunehmend deklarative UI und KI-basierte Programmierassistenten einsetzen. 

Die Einführung von Jetpack Compose für Instagram Direct ging über eine typische UI-Modernisierung hinaus. Das Team entwickelte eine KI-native UI-Codebasis, die 50% kleiner als die ursprüngliche Implementierung ist. Gleichzeitig konnte die Ausführungszeit von KI-Agenten um 35% gesenkt, die Anzahl der Engineer-Agent-Interaktionen um 32% reduziert und die Tokenkosten um 33% gesenkt werden. In enger Zusammenarbeit mit Google hat das Team Jetpack Compose eingeführt und dabei hohe Leistungsstandards beibehalten. Durch die Leistungsoptimierungen haben Meta und Google Compose nicht nur für Instagram, sondern auch für das gesamte Android-Entwickler-Ökosystem verbessert.

Codebasis im großen Maßstab modernisieren

KI ist schnell zu einem täglichen Begleiter für Entwickler in der Branche geworden und die Anwendung auf eine umfangreiche Codebasis wie Instagram führt bereits zu echten Produktivitätssteigerungen. Das Instagram Direct-Team setzte sich ein ehrgeizigeres Ziel. Anstatt KI-Tools einfach auf den vorhandenen Code anzuwenden, hat das Team die Codebasis und ihre Architektur so umgestaltet, dass sie von vornherein KI-kompatibel ist. So konnte die Wirkung von KI weit über das hinaus gesteigert werden, was durch eine reine Nachrüstung möglich gewesen wäre.

Das Instagram Direct-Team hat Jetpack Compose als wichtige Komponente für die Entwicklung einer KI-nativen UI-Architektur ausgewählt. Die deklarative Natur sorgt dafür, dass der Code prägnant, vorhersehbar und strukturell einfacher für KI-Modelle zu analysieren ist. Außerdem gibt es weniger Nebeneffekte, weniger impliziten Status und klarere Komponentengrenzen.

Die Migration zu Jetpack Compose erforderte eine sorgfältige Planung. Hunderte Millionen Menschen senden täglich Nachrichten auf Instagram. Die Migration musste daher schrittweise und reibungslos erfolgen, ohne dass die Nutzer beeinträchtigt wurden, während das Team die zugrunde liegende Architektur neu entwickelte. Um das Ausmaß der Herausforderung zu veranschaulichen: Einzelne UI-Komponenten können in über 160 verschiedenen Statuskombinationen gerendert werden und allein ein einzelner Konversationsbildschirm verarbeitet mehr als 200 verschiedene Nachrichtentypen.

Bei der Migration einer Codebasis dieser Größe zu Compose ist es verlockend, den einfachen Weg zu gehen und Compose-UI-Komponenten in die vorhandene View-Hierarchie einzubetten. Als inkrementeller Schritt bei einer schrittweisen Migration ist das völlig in Ordnung. Langfristig stellt die Integration von Compose in eine View-basierte Codebasis jedoch eine Herausforderung dar. KI-Tools gehen oft den Weg des geringsten Widerstands. Wenn Sie deklarativen und imperativen UI-Code mischen, werden sie von der KI wahrscheinlich falsch kombiniert, was zu subtilen Fehlern, technischen Schulden und Leistungseinbußen führt. 

KI-native UI-Architektur erstellen

Bei der Größe von Instagram ist ein gewisses Maß an architektonischer Abstraktion unvermeidlich. Dadurch bleibt die App auch bei zunehmender Größe wartungsfreundlich. Stellen Sie sich ein gängiges Muster vor, bei dem jeder RecyclerView-Elementtyp als untergeordnete Klasse einer benutzerdefinierten RecyclerViewItem-Basisklasse modelliert wird, die übliche Lebenszyklus-Hooks wie onBind bereitstellt.

Beispiel 1

class ChatItem(
  val features: FeatureFlagProvider
) : RecyclerViewItem<ComposeViewHolder, ChatUiState> {

  // Imperative context:
  // AI could often take the path of least resistance and generate a mutable
  // state here, dispatched outside the ChatUiState. This class survives
  // re-bindings and is shared across multiple items, ultimately leading to
  // unexpected, hard-to-reproduce bugs.
  var isPinned: Boolean = false

  override fun onBind(holder: ComposeViewHolder, uiState: ChatUiState) {
      // Imperative context
      val isPinnedChatsEnabled = features.isEnabled("pinned_chats_feature")

      // Declarative context
      holder.composeView.setContent {

        // Blending imperative and declarative contexts
        if (isPinnedChatsEnabled) {
          Button(onClick = { isPinned = !isPinned }) {
            Text(if (isPinned) "Unpin" else "Pin")
          }
        }
        
        ...
      }
  }
}

Im Snippet oben treten zwei Probleme auf. Zuerst wird das Flag isPinnedChatsEnabled im imperativen Code gelesen und dann in einer Compose-Lambda-Funktion erfasst. Das ist eine subtile Kopplung zwischen Paradigmen. Zweitens ist isPinned ein veränderliches Feld für das Element selbst und nicht in ChatUiState. Daher bleibt es beim RecyclerView erneuten Binden und Wiederverwenden über Zeilen hinweg erhalten, was zu Lecks und Fehlern führt, die schwer zu reproduzieren sind.

Auch wenn der Code durch die Zuweisung einer dedizierten @Composable-Funktion für das Element bereinigt wird, bleiben die gleichen Probleme bestehen.

Beispiel 2

class ChatItem(
  val features: FeatureFlagProvider
) : ComposeRecyclerViewItem<ChatUiState> {

  // Imperative context
  val isPinnedChatsEnabled = features.isEnabled("pinned_chats_feature")
  var isPinned: Boolean = false

  // Declarative context
  @Composable
  override fun Content(uiState: ChatUiState) {

 
    // Blending imperative and declarative contexts
    if (isPinnedChatsEnabled) {
      Button(onClick = { isPinned = !isPinned }) {
        Text(if (isPinned) "Unpin" else "Pin")
      }
    }

    ...
  }
}

Dieses Beispiel ist bewusst einfach gehalten, veranschaulicht aber ein größeres Problem: Je weniger Grenzen KI gesetzt werden, desto geringer ist die Qualität des Codes, den sie im Laufe der Zeit produziert. Schutzmaßnahmen und Skills sind hilfreich, reichen aber allein nicht aus. Wenn KI auf Hindernisse stößt, umgeht sie diese oft, um sich selbst zu entblockieren.

Damit die Codebasis KI-freundlich ist, muss sie zwei praktischen Regeln folgen: 

• Abhängigkeit von benutzerdefiniertem Kontext minimieren: Je mehr spezifisches Wissen über die Codebasis ein KI-Agent benötigt, um eine korrekte Änderung vorzunehmen, desto geringer ist die Qualität seiner Ausgabe. Je näher die Codebasis an bekannten Best Practices ist, desto besser sind die KI-Ergebnisse.
• Eine KI-orientierte Codebasis muss ihre eigenen Grenzen durchsetzen. Designlücken mit KI-Skills zu schließen, ist nicht skalierbar, da jeder Skill, der in den Kontext geladen wird, Tokens kostet und die Leistung des Agents beeinträchtigen kann. Stattdessen sollte die Architektur selbst dieses Gewicht tragen. KI-Agents gehen von Natur aus den Weg des geringsten Widerstands. Das Design sollte daher so gestaltet sein, dass dieser Weg zu korrektem, hochwertigem Code führt, während schlechte Designentscheidungen schwer und teuer zu realisieren sind.

Ein Listenelement kann weiterhin durch eine eigene Abstraktion dargestellt werden. In diesem Fall befindet sich der gesamte Compose-Code jedoch im Konstruktor, sodass er keinen Zugriff auf Klassenmember oder den Status hat. Die einzige Quelle für Argumente ist der Konstruktor. Dadurch entspricht sie einer einfachen @Composable-Funktion, während sie der bestehenden Architektur entspricht.

Beispiel 3:

class ChatItem(
  val features: FeatureFlagProvider,
  val onPin: (Boolean) -> Unit,
) : ComposeItem<ChatUiState>(

 
   // Compose UI
   content = { uiState: ChatUiState ->
    val isPinnedChatsEnabled = features.isEnabled("pinned_chats_feature")

    if (isPinnedChatsEnabled) {
      Button(onClick = { onPin(!uiState.isPinned) }) {
        Text(if (uiState.isPinned) "Unpin" else "Pin")
      }
    }
    
    ...
  },
)

Die Migration einer Codebasis dieser Größe ist ein riesiges Unterfangen. Lange Zeit mussten die Hunderten von UI-Komponenten, aus denen der Großteil der Direct UI besteht, parallel zu ihren Legacy-Pendants existieren und wurden auch parallel gewartet. KI-Workflows haben diese parallele Migration ermöglicht, da sie das Schreiben großer Mengen an Code beschleunigt haben. Dank dieses Ansatzes konnte das Direct-Team die Migration in Rekordzeit durchführen, ohne die anderen Teammitglieder zu beeinträchtigen. Diese entwickelten weiterhin Funktionen, die die Nutzung für Millionen von Menschen täglich verbessern.

Mehrere Entwickler haben ihre eigenen KI-Agents für eine gemeinsame Wissensdatenbank mit wiederverwendbaren Skills und Konventionen ausgeführt, die während der Migration erstellt wurden. So blieben Workflows und Best Practices im gesamten Team synchron, anstatt dass jeder Entwickler sie neu entdecken musste. Auf jeder Oberfläche wurde die Migration in den folgenden Phasen durchgeführt:

• Den gesamten Compose-Code mit KI schreiben
• Wir haben die Benutzeroberfläche weiter optimiert, bis sie in einem öffentlichen Test für echte Nutzer eingeführt wurde.

Wenn die Arbeit in zwei Phasen pro Bildschirm aufgeteilt wird, kann ein Entwickler schnell die gesamte Oberfläche durchlaufen und die Architektur und die schwierigen Grenzfälle im Voraus festlegen. Wenn diese Grundlagen geschaffen sind, können sich andere darauf konzentrieren, die Benutzeroberfläche produktionsreif zu machen, ohne selbst diese technischen Entscheidungen treffen zu müssen. So wird die Migration insgesamt beschleunigt.

Die Ergebnisse der Migration haben den Ansatz bestätigt. Bei migrierten Instagram Direct-Oberflächen konnte das Team mit Jetpack Compose die Gesamtmenge an UI-Code um 50%reduzieren. Weniger Code, den KI generieren muss, führt zu einer höheren Ausgabequalität und niedrigeren Token-Kosten pro Aufgabe. 

Bei einer internen Datenanalyse der Android-Codebasis für Instagram Direct wurden KI-Agentensitzungen, die an der Compose-UI arbeiten, mit denselben Aufgaben verglichen, die mit Android Views ausgeführt wurden. Die Effizienzsteigerungen waren in zwei Dimensionen deutlich zu erkennen:

• Pro Zeichen des endgültigen Codes:Sie müssen 32% weniger Anfragen an den Kundenservicemitarbeiter senden und die Ausführungszeit des Kundenservicemitarbeiters(die Zeit, die vergeht, bis ein Kundenservicemitarbeiter mit der Bearbeitung der Anfrage eines Entwicklers beginnt und eine Antwort zurückgibt) ist um 35% kürzer.
• Pro Agent-Sitzung:Die Gesamtkosten für Tokens sind mit Compose um 33% gesunken im Vergleich zu Views.

Wir geben sowohl die Ausgabeeffizienz als auch die typische Anzahl von Sitzungen an, da sie unabhängig voneinander nützliche Ergebnisse sind. Die Zahlen für den Austausch zwischen Engineer und Agent und die Ausführungszeit vergleichen die Ressourcennutzung pro Einheit des erzielten Ergebnisses, während die Tokenzahl die Gesamtkosten für eine typische Agentsitzung vergleicht.

Die Daten zeigten auch einen konsistenten Unterschied im Umgang der beiden Frameworks mit komplexem oder fehleranfälligem Code. Meta verfolgt dies anhand eines Risikoscores für Codeänderungen, der die allgemeine Codequalität und die Wahrscheinlichkeit bewertet, dass eine Änderung Produktionsvorfälle verursacht. Bei der Analyse wurde die Ressourceneffizienz eines Agenten anhand einer Kombination aus Tokenverbrauch, Ausführungszeit des Agenten und Interaktionen zwischen dem Entwickler und dem Agenten gemessen. Wenn Dateien einen höheren Risikowert erreichen, werden KI-Agent-Sitzungen automatisch weniger ressourceneffizient. 

Wenn sich der kumulierte Risikowert einer Datei verdoppelt, wird die mit Android Views implementierte Benutzeroberfläche um 30%weniger effizient (pro Zeichen). Unter denselben Umständen beträgt die Reduzierung durch Jetpack Compose UI nur 9%.

Durch die Partnerschaft zwischen Google und Meta brachte das Instagram Direct-Team eine neue Perspektive auf die Einführung von Compose ein. Es ging dabei nicht nur um das Umschreiben der Benutzeroberfläche, sondern auch um die KI-Readiness der Codebasis. Diese Arbeit hat gezeigt, dass Compose eine gute Grundlage für die Entwicklung von KI-basierten Codebases und Architekturen ist, insbesondere wenn es in Apps wie Instagram eingesetzt wird.

Leistungsoptimierungen 

Instagram Direct ist einer der wichtigsten Bereiche der App und Nutzer erwarten, dass er jederzeit schnell und reaktionsschnell ist. Die Einführung von Jetpack Compose bedeutete eine erhebliche Umstellung der Benutzeroberfläche. Das wichtigste Ziel war es, die hohe Qualität ohne Regressionen beizubehalten.

Durch jahrelange Iterationen hatte die alte View-basierte Implementierung auf Instagram bereits einen außergewöhnlich hohen Leistungsstandard erreicht. Das Team musste diesen Standard beibehalten, während es auf ein völlig neues UI-Framework umstellte.

Instagram misst Hunderte, wenn nicht Tausende von Leistungsmesswerten. Für die Einführung von Compose waren die folgenden drei Aspekte am wichtigsten:

• Zeit bis zur Interaktion: Die Zeit zwischen dem Öffnen des Displays und dem Zeitpunkt, an dem es verwendet werden kann.
• Zeit bis zum vollständigen Laden : Die Zeitspanne zwischen dem Öffnen des Bildschirms und dem vollständigen Laden aller Inhalte (z.B. Bilder).
• Scrollleistung: Wie flüssig der Bildschirm scrollt, ohne dass Frames verloren gehen.

Diese Messwerte werden zur Laufzeit in der Produktion erfasst. So können Sie A/B-Tests durchführen, um die migrierte Compose-UI mit der alten UI zu vergleichen und die Auswirkungen auf die Leistung zu bewerten.

Ein gängiger Ansatz für eine solche Migration besteht darin, klein anzufangen, einige UI-Komponenten zu migrieren, Daten zu erheben und zu untersuchen, wie sie sich verhalten. Diese ersten Ergebnisse sind zwar hilfreich, zeichnen aber nur ein unvollständiges Bild und liefern falsche Negativmeldungen für die Einführung von Compose, weil:

• Nicht repräsentativ: Eine migrierte UI-Komponente kann nützliche Daten zu ihrer Gesamtleistung auf einem bestimmten Bildschirm liefern. Allerdings verhalten sich verschiedene Komponenten aus Gründen, die sich nicht verallgemeinern lassen, unterschiedlich. Daher können Sie nicht immer davon ausgehen, dass sich das Verhalten einer Komponente auf andere übertragen lässt.
• Interop-Kosten: Ein kleiner Compose-Teil in einer großen View-Codebasis verursacht unvorhersehbare Kosten für die Brücke zwischen den beiden Systemen. Dieser Overhead verfälscht die Analyse. Die ersten Ergebnisse im kleinen Maßstab spiegeln also nicht wider, wie eine vollständige Migration tatsächlich aussehen würde.

Das Ergebnis ist, dass kleine Migrationen zwar nützlich sind, aber nicht immer die volle Wirkung von Compose widerspiegeln. Je mehr einer Oberfläche End-to-End ohne Unterbrechungen migriert wird, desto klarer und besser wird das Bild in Bezug auf die Leistung.

Die wichtigsten Bildschirme in Instagram Direct basieren auf langen Listen mit verschiedenen Elementtypen, die ursprünglich mit RecyclerView implementiert wurden. Die Architektur basiert auf benutzerdefinierten Abstraktionen für die Skalierbarkeit, ist aber an den Lebenszyklus des View-basierten Systems gebunden.

Die Hauptaufgabe des Teams war die schrittweise Migration von mehreren Hundert einzelnen Listenelementen zu Compose innerhalb der bestehenden RecyclerView-basierten Architektur. Die Elemente wurden in kleinen unabhängigen Gruppen im Rahmen von A/B-Tests in der Produktion eingeführt – und das alles ohne sichtbare Änderungen für die Nutzer.

Der größte Nachteil einer solchen Einrichtung ist die erhebliche Abhängigkeit vom alten View-System über eine RecyclerView-Kernarchitektur, auch nach der vollständigen Migration aller Listenelemente zu Compose. Als logischen nächsten Schritt beschloss das Team, die RecyclerView-basierte Kernarchitektur durch die Compose-native Alternative LazyColumn zu ersetzen.

Das bedeutet, dass Compose-UI-Komponenten vom Framework, in dem sie enthalten sind, abstrahiert werden sollten, während sie gleichzeitig mit RecyclerView und LazyColumn kompatibel sein müssen. Ebenso wichtig ist die Möglichkeit, zur Laufzeit über Feature-Flags zwischen den beiden zu wechseln, um A/B-Tests zu ermöglichen.

Die neuen Compose-Elemente sind zwar nativ mit LazyColumn kompatibel und können in einen ununterbrochenen Kompositionsbaum eingefügt werden, es wurde aber auch eine Interop-API erstellt, um sie in ein RecyclerView einzufügen. So konnte die Einrichtung von LazyColumn in einem A/B-Test parallel zu RecyclerView erfolgen. Dabei wurden dieselben Compose-Elemente wiederverwendet und die Leistung optimiert, ohne dass das restliche Team bei der Entwicklung und Optimierung von Funktionen beeinträchtigt wurde.

Die Größe, Komplexität und Sensibilität von Instagram gegenüber selbst den kleinsten Regressionen stellten eine einzigartige Herausforderung für Jetpack Compose dar. Um diese Probleme zu beheben, war eine iterative, praktische Partnerschaft erforderlich. Die Entwickler von Google und Meta haben eng zusammengearbeitet, um Messwerte zu analysieren und neue Compose-Funktionen zu entwickeln, die die View-basierten Benchmarks erfüllen oder übertreffen. Aus dieser Partnerschaft ergeben sich die folgenden bemerkenswerten Ergänzungen für Jetpack Compose: pausierbare Komposition mit LazyLayoutCacheWindows und Sichtbarkeitstracking. 

Pausierbare Komposition mit LazyLayoutCacheWindows

Mit der pausierbaren Komposition (standardmäßig in Compose 1.10 aktiviert) können rechenintensive Lazy-List-Elemente inkrementell über Frames hinweg zusammengesetzt werden, um Ruckeln zu vermeiden. In Kombination mit LazyLayoutCacheWindow (hinzugefügt in Compose 1.9) wird die Scroll-Geschwindigkeit deutlich verbessert. Bei internen Tests bei Meta wurde durch die Kombination von „Pausable composition“ mit einem Viewport LazyLayoutCacheWindow die Anzahl großer Frame-Drops pro Minute (LFDs/m) im Vergleich zu Compose um etwa 13% reduziert. Durch die Verwendung von Cache Window allein wurde die Anzahl der Anfragen im Vergleich zur Baseline um etwa 8% reduziert. LFDs/m ist ein interner Messwert, den Meta verwendet, um spürbare Ruckler beim Scrollen zu erfassen.

Wenn Sie in Ihrer App ein LazyLayoutCacheWindow verwenden, werden Elemente außerhalb des Bildschirms in einem pixelbasierten Bereich um den Viewport vorbereitet und beibehalten, um schnelles Wischen zu ermöglichen. Wenn Sie LazyLayoutCacheWindows in Ihrer App nutzen möchten, können Sie die aktuelle Version von Compose 1.13.0-alpha03 verwenden und sie wie im folgenden Beispiel einrichten:

val cacheWindow = LazyLayoutCacheWindow(ahead = 150.dp, behind = 100.dp)
// OR
val cacheWindow = LazyLayoutCacheWindow(aheadFraction = 0.5f, behindFraction = 0.3f)

LazyColumn(state = state, cacheWindow = cacheWindow) {
    ...
}

Es gibt zwei Möglichkeiten, das Cache-Zeitfenster zu konfigurieren. Beide beschreiben dasselbe: wie viel Off-Screen-Inhalt beibehalten werden soll, aber in unterschiedlichen Einheiten.

• Dp: Feste absolute Länge. ahead = 150.dp behält unabhängig vom Gerät 150 dp an Inhalten bei, die über den sichtbaren Rand hinausgehen.
• Gleitkommazahl: Bruchteil des Darstellungsbereichs. aheadFraction = 0.5f hält die Hälfte des Bildschirms bereit, sodass die absolute Menge mit der Bildschirmhöhe skaliert wird und verschiedene Formfaktoren unterstützt werden: mehr auf einem Tablet oder einem aufgeklappten faltbaren Smartphone, weniger auf einem kompakten Smartphone. 

Das Instagram-Team hat die Gleitkommazahlen des Cache-Fensters speziell für die Inhaltsstruktur und die Artikelgrößen von Direct optimiert. Da die idealen Werte je nach den spezifischen UI-Parametern variieren, ist es erforderlich, verschiedene Einstellungen auszuprobieren, um das richtige Gleichgewicht zu finden.

Impressionen mit „onVisibilityChanged“ erfassen

Die onVisibilityChanged (in Compose 1.9.0 hinzugefügt) API war ein weiteres wichtiges Ergebnis der technischen Partnerschaft zwischen Google und Meta. So können große Jetpack Compose-Oberflächen einheitlich erkennen, wann ein Composable tatsächlich auf dem Bildschirm sichtbar ist. Das ersetzt benutzerdefinierte, selbst entwickelte Implementierungen, die in der Vergangenheit verwendet wurden. Allein in Instagram Direct werden diese Sichtbarkeitssignale in Hunderten von Dateien verwendet, um Produktqualitätsmesswerte zu unterstützen, die davon abhängen, ob UI-Elemente tatsächlich Nutzern angezeigt wurden.

Startleistung

Die Einführung von Jetpack Compose für Instagram Direct führte zu unerwarteten Leistungssteigerungen in anderen Bereichen der App. Die Jetpack Compose-Laufzeit hat einen einmaligen Warm-up-Aufwand. Da Messaging ein stark frequentierter Bereich ist, der oft zu Beginn einer Nutzersitzung besucht wird, konnten in anderen Bereichen von Instagram, die auf Compose basieren, deutliche Leistungssteigerungen erzielt werden.

Die Startleistung der Compose-Benutzeroberfläche in Instagram Direct wurde durch die Verwendung von Baseline-Profilen optimiert. Dadurch werden Hot-Codepfade bei der Installation vorkompiliert, sodass Compose ab dem ersten Start schnell gerendert wird.

Erkenntnisse aus der Migration von Instagram Direct zu Jetpack Compose 

• Jetpack Compose bietet einen sofortigen Return on Investment:Sie müssen keine fortschrittlichen KI-Workflows verwenden, um von Compose zu profitieren. Durch die Reduzierung des Codes um etwa 50% muss weniger Code gewartet werden und es gibt weniger potenzielle Fehlerquellen.
• Die Entwicklung einer KI-nativen Architektur führte zu erheblichen Verbesserungen, darunter eine um 35% verkürzte Ausführungszeit von KI-Agenten, 32% weniger Austausch zwischen Entwicklern und Agenten und eine um 33% geringere Token-Kosten.
• Es gibt zwar viele Interop-APIs und Unterstützung für die Kombination von Views und Compose, aber du solltest größere Oberflächen anstelle einzelner kleiner Komponenten migrieren. So bleibt die Benutzeroberfläche in einer einzigen, ununterbrochenen Kompositionshierarchie und alle Compose-nativen Leistungsoptimierungen können genutzt werden.
• Pausable-Zusammensetzung mit LazyLayoutCacheWindow kombinieren: Die Kombination dieser beiden Elemente führt zu besseren Ergebnissen als Cache-Fenster allein. Mit dem Cache-Fenster allein könnte ein schweres Element immer noch versuchen, in einem einzigen Durchgang gerendert zu werden, wodurch das Frame-Budget möglicherweise überschritten wird.
• Selbst zu Compose beitragen Meta hat mit dem Jetpack Compose-Team zusammengearbeitet, um Feedback und Ideen in Compose umzusetzen. Da es sich um ein Open-Source-Toolkit handelt, profitieren wir alle, wenn Fehler und Leistungsverbesserungen zentral vorgenommen werden. Geben Sie uns Feedback.

Die Einführung von Jetpack Compose hat die KI-gestützte Entwicklung erheblich verbessert und gleichzeitig die tägliche UI-Entwicklung bei Instagram vereinfacht. Der deklarative Ansatz reduziert Boilerplate-Code, erleichtert die Nachvollziehbarkeit des Status und verbessert die allgemeine Entwicklerproduktivität. Das Instagram-Entwicklungsteam freut sich darauf, Compose auf weiteren Oberflächen in der App einzuführen und die Zusammenarbeit zwischen Google und Meta fortzusetzen, um Instagram und Jetpack Compose-Nutzern noch mehr Verbesserungen zu bieten. 

Wenn Sie Compose noch nicht ausprobiert haben, ist die Migration zu Jetpack Compose jetzt mit KI-Unterstützung einfacher als je zuvor.

Danksagungen. Vielen Dank an Michal Zielinski und Matthew Du von Meta sowie an Andrei Shikov und George Mount von Google für ihre Arbeit, die durch die Zusammenarbeit zwischen Meta und Google zu Leistungsverbesserungen bei Compose geführt hat. Vielen Dank auch an Gary Ye von Meta, der uns dabei geholfen hat, Compose in Instagram Direct einzuführen, und an Gopal Juneja von Meta, der uns bei diesem Vorhaben mit Data Science unterstützt hat.