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

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

Instagram Direct ist eine der wichtigsten Oberflächen auf Instagram, über die täglich Milliarden von Nutzernachrichten verarbeitet werden. 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 verursacht jedoch erhebliche technische Schulden und Entwicklungsaufwand, insbesondere da Teams zunehmend deklarative Benutzeroberflächen und KI-Unterstützung beim Programmieren einsetzen. 

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

Modernisierung der Codebasis in großem Umfang

KI ist für Entwickler in der Branche schnell zu einem täglichen Begleiter geworden. 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 Grund auf KI-nativ sind. Dadurch wurde die Wirkung von KI weit über das hinaus gesteigert, was durch eine nachträgliche Anpassung allein möglich gewesen wäre.

Das Instagram Direct-Team hat Jetpack Compose als Schlüsselkomponente für die Erstellung einer KI-nativen UI-Architektur ausgewählt. Durch den deklarativen Charakter ist der Code prägnant, vorhersehbar und strukturell einfacher für KI-Modelle zu analysieren. Es gibt weniger Nebenwirkungen, weniger impliziten Status und klarere Komponentengrenzen.

Die Migration zu Jetpack Compose erforderte eine sorgfältige Planung. Hunderte Millionen Menschen senden jeden Tag Nachrichten auf Instagram. Die Migration musste daher schrittweise und reibungslos erfolgen, ohne dass die Nutzer etwas davon bemerkten, während das Team die zugrunde liegende Architektur neu gestaltete. Um die Dimensionen der Herausforderung zu verdeutlichen: Einzelne UI-Komponenten können in über 160 verschiedenen Statuspermutationen gerendert werden und ein einzelner Unterhaltungsbildschirm verarbeitet mehr als 200 verschiedene Nachrichtentypen.

Bei der Migration einer Codebasis dieser Größe zu Compose ist es verlockend, den einfachen Weg zu wählen und Compose-UI-Komponenten in die vorhandene Ansichtshierarchie einzubetten. Als inkrementeller Schritt während einer schrittweisen Migration ist das völlig in Ordnung. Langfristig ist die Einbindung von Compose in eine View-basierte Codebasis jedoch eine Herausforderung. KI-Tools gehen oft den Weg des geringsten Widerstands. Wenn Sie deklarativen und imperativen UI-Code mischen, wird die KI diese wahrscheinlich falsch kombinieren, was zu subtilen Fehlern, technischen Schulden und Leistungseinbußen führen kann. 

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 zunehmendem Wachstum wartbar. Ein gängiges Muster ist, dass jeder RecyclerView-Elementtyp als Nachkomme 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 schleichen sich zwei Probleme ein. Zuerst wird das Flag isPinnedChatsEnabled in imperativem Code gelesen und dann in einem Compose-Lambda erfasst – eine subtile Kopplung über Paradigmen hinweg. Zweitens ist isPinned ein änderbares Feld im Element selbst und nicht in ChatUiState. Es bleibt also beim erneuten Binden und Recyceln von RecyclerView über Zeilen hinweg erhalten, was zu Fehlern führt, die nur schwer reproduzierbar sind.

Auch wenn der Code bereinigt wird, indem dem Element eine dedizierte @Composable-Funktion zugewiesen wird, bleiben die 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")
      }
    }

    ...
  }
}

Dies ist ein einfaches Beispiel, das jedoch ein größeres Problem verdeutlicht: Je weniger Grenzen der KI gesetzt werden, desto geringer ist die Qualität des Codes, den sie im Laufe der Zeit erzeugt. Guardrails und Skills helfen, reichen aber allein nicht aus, da die KI bei Reibungspunkten oft um sie herum navigiert, um sich selbst zu entsperren.

Damit die Codebasis KI-freundlich ist, müssen zwei praktische Regeln befolgt werden: 

• Abhängigkeit von benutzerdefiniertem Kontext minimieren: Je mehr spezifisches, codebase-spezifisches Wissen 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. Das Schließen von Designlücken mit KI-Skills ist nicht skalierbar, da jeder in den Kontext geladene Skill Tokens kostet und die Leistung des KI-Agenten beeinträchtigen kann. Stattdessen sollte die Architektur selbst diese Last tragen. KI-Agenten wählen natürlich den Weg des geringsten Widerstands. Daher sollte das Design so gestaltet sein, dass dieser Weg zu korrektem, hochwertigem Code führt, während schlechte Designentscheidungen schwer und teuer umzusetzen 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 Klassenmitglieder oder den Status hat und die einzige Quelle für Argumente der Konstruktor ist. Dadurch entspricht sie einer einfachen @Composable-Funktion und entspricht gleichzeitig der vorhandenen Architektur.

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 Hunderte von UI-Komponenten, die den Großteil von Direct UI ausmachen, mit ihren Legacy-Pendants koexistieren und beide mussten parallel gepflegt werden. KI-Workflows haben diese parallele Migration ermöglicht, indem sie das Schreiben riesiger Codemengen beschleunigt haben. Dank dieses Ansatzes konnte das Direct-Team die Migration in Rekordzeit durchführen, ohne den Rest des Teams zu stören, der weiterhin die Funktionen bereitstellte, die die Nutzung für Millionen von Menschen jeden Tag verbessern.

Mehrere Entwickler haben ihre eigenen KI-Agenten mit einer gemeinsamen Wissensdatenbank aus 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. Für jede Oberfläche wurde die Migration in den folgenden Phasen durchgeführt:

• Den gesamten Compose-Code mit KI schreiben
• Sie haben die Benutzeroberfläche optimiert, Grenzfälle berücksichtigt und Leistungslücken geschlossen, bis sie in einem öffentlichen Test für echte Nutzer eingeführt wurde.

Durch die Aufteilung der Arbeit in zwei Phasen pro Bildschirm kann ein Entwickler schnell die gesamte Oberfläche durchgehen und die Architektur und die kniffligen Grenzfälle im Voraus klären. Mit dieser Grundlage können sich andere darauf konzentrieren, die Benutzeroberfläche produktionsreif zu machen, ohne selbst technische Entscheidungen treffen zu müssen. So bleibt die Migration insgesamt schnell.

Die Ergebnisse der Migration bestätigten den Ansatz. Bei migrierten Instagram Direct-Oberflächen konnte das Team mit Jetpack Compose den gesamten UI-Code um 50%reduzieren. Je weniger Code die KI generieren muss, desto höher ist die Qualität der Ausgabe und desto geringer sind die Tokenkosten pro Aufgabe. 

In einer internen Datenanalyse der Android-Codebasis für Instagram Direct wurden KI-Agenten-Sitzungen, die mit Compose UI arbeiteten, mit denselben Aufgaben unter Verwendung von Android Views verglichen. Die Effizienzsteigerungen waren in zwei Dimensionen deutlich:

• Pro Zeichen des endgültigen Codes: Mit Compose waren 32% weniger Interaktionen zwischen Entwicklern und KI-Agenten und 35% weniger Ausführungszeit durch den KI-Agenten erforderlich(die Zeit, die vergeht, bis ein KI-Agent mit der Bearbeitung der Anfrage eines Entwicklers beginnt und eine Antwort zurückgibt).
• Pro Agentensitzung: Die Tokenkosten insgesamt sanken um 33% , wenn Compose anstelle von Views verwendet wurde.

Wir geben sowohl die Ausgabeeffizienz als auch die typische Anzahl von Sitzungen an, da beide Werte unabhängig voneinander nützlich sind. Die Zahlen für den Austausch zwischen Engineer und Agent sowie die Ausführungszeit vergleichen die Ressourcennutzung pro Einheit der gelandeten Ausgabe, während die Token-Zahl die Gesamtkosten für eine typische Agent-Sitzung vergleicht.

Die Daten zeigten auch einen konsistenten Unterschied darin, wie die beiden Frameworks mit komplexem oder fehleranfälligem Code umgehen. Meta erfasst dies anhand einer Risikobewertung von Codeänderungen, bei der die Gesamtqualität des Codes und die Wahrscheinlichkeit, dass eine Änderung zu Produktionsvorfällen führt, bewertet werden. In der Analyse wurde die Ressourceneffizienz eines KI-Agenten anhand einer Kombination aus Tokenverbrauch, Ausführungszeit des KI-Agenten und Interaktionen zwischen Entwickler und KI-Agent gemessen. Je höher der Risikowert von Dateien ist, desto weniger ressourceneffizient sind KI-Agentensitzungen. 

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

Durch die Partnerschaft zwischen Google und Meta hat das Instagram Direct-Team eine neue Perspektive auf die Einführung von Compose eingebracht. Dabei ging es nicht nur um eine Neugestaltung der Benutzeroberfläche, sondern auch um die KI-Bereitschaft der Codebasis. Diese Arbeit hat gezeigt, dass Compose eine hervorragende Grundlage für die Erstellung von KI-basierten Codebasen und Architekturen ist, insbesondere bei Anwendungen im Umfang von Instagram.

Leistungsoptimierungen 

Instagram Direct ist eine der wichtigsten Oberflächen der App und die Nutzer erwarten, dass sie jederzeit schnell und responsiv ist. Die Einführung von Jetpack Compose bedeutete eine erhebliche Überarbeitung der Benutzeroberfläche. Das oberste Ziel war es, die hohe Qualität ohne Regressionen beizubehalten.

Durch jahrelange Iteration hatte die alte View-basierte Implementierung auf Instagram bereits ein außergewöhnlich hohes Leistungsniveau erreicht. Das Team musste diesen Standard auch beim Wechsel zu einem völlig neuen UI-Framework einhalten.

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

• Time to Interactive: die Zeit, die zwischen dem Öffnen des Bildschirms und der Möglichkeit, ihn zu verwenden, vergeht.
• 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 ausgelassen werden.

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 dieser Maßnahme auf die Leistung zu bewerten.

Ein gängiger Ansatz für eine solche Migration besteht darin, klein anzufangen, eine Handvoll UI-Komponenten zu verschieben, Daten zu erfassen und ihr Verhalten zu untersuchen. Diese ersten Ergebnisse sind zwar hilfreich, zeichnen aber nur ein unvollständiges Bild und liefern falsch negative Ergebnisse in Bezug auf die Einführung von Compose, weil:

• Nicht repräsentativ: Eine migrierte UI-Komponente kann nützliche Daten zur Gesamtleistung auf einem bestimmten Bildschirm liefern. Verschiedene Komponenten verhalten sich jedoch aus Gründen, die sich nicht verallgemeinern lassen, unterschiedlich. Sie können also nicht immer davon ausgehen, dass sich die Ergebnisse übertragen lassen.
• Interoperabilitätskosten: Bei einem kleinen Compose-Element in einer großen View-Codebasis fallen unvorhersehbare Überbrückungskosten zwischen den beiden Systemen an. Dieser Mehraufwand verzerrt die Messung, sodass die ersten kleinen Ergebnisse nicht widerspiegeln, 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 Oberflächen ohne Unterbrechungen migriert werden, desto klarer und besser wird das Bild in Bezug auf die Leistung.

Die Hauptbildschirme in Instagram Direct bestehen aus 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 ansichtsbasierten Systems gebunden.

Die Hauptaufgabe des Teams bestand darin, mehrere Hundert einzelne Listenelemente schrittweise in Compose innerhalb der bestehenden RecyclerView-basierten Architektur zu migrieren und sie in kleinen, unabhängigen Gruppen im Rahmen von A/B-Tests in der Produktion einzuführen – ohne sichtbare Änderungen an der Messaging-Erfahrung der Nutzer.

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

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

Die neuen Compose-Elemente sind nativ mit LazyColumn kompatibel und können in einen ununterbrochenen Kompositionsbaum eingefügt werden. Es wurde jedoch auch eine Interop-API erstellt, um sie in ein RecyclerView einzufügen. So konnte die LazyColumn-Einrichtung im Rahmen eines A/B-Tests parallel zu RecyclerView eingeführt werden. Dabei wurden dieselben Compose-Elemente wiederverwendet und die Leistung optimiert, ohne dass der Rest des Teams bei der Entwicklung und Verfeinerung von Funktionen gestört wurde.

Die Größe, Komplexität und Empfindlichkeit von Instagram gegenüber selbst kleinsten Regressionen stellten eine besondere Herausforderung für Jetpack Compose dar. Um diese Herausforderungen zu bewältigen, war eine iterative, praktische Partnerschaft erforderlich. In enger Zusammenarbeit analysierten die Entwickler von Google und Meta Messwerte, um neue Compose-Funktionen zu entwickeln, die die View-basierten Benchmarks erfüllen oder übertreffen. Im Rahmen dieser Partnerschaft wurden unter anderem die folgenden Ergänzungen zu Jetpack Compose vorgenommen: Pausierbare Komposition mit LazyLayoutCacheWindows und Sichtbarkeits-Tracking. 

Pausierbare Komposition mit LazyLayoutCacheWindows

Mit der pausierbaren Komposition (standardmäßig in Compose 1.10 aktiviert) können rechenintensive Lazy-List-Elemente schrittweise über Frames hinweg zusammengesetzt werden, um Ruckeln zu vermeiden. In Kombination mit LazyLayoutCacheWindow (hinzugefügt in Compose 1.9) wird das Scrollen deutlich flüssiger. In internen Tests bei Meta wurde die pausierbare Komposition mit einem LazyLayoutCacheWindow-Viewport kombiniert. Dadurch wurden die großen Frame-Drops pro Minute (LFDs/m) im Vergleich zu Vanilla Compose um etwa 13% reduziert. Das Cache-Fenster allein reduzierte die Latenz um etwa 8% im Vergleich zur selben Baseline. LFDs/m ist ein interner Messwert, mit dem Meta auffällige Ruckler beim Scrollen erfasst.

Wenn Sie in Ihrer App einen LazyLayoutCacheWindow verwenden, werden Elemente außerhalb des Bildschirms in einem pixelbasierten Bereich um den Darstellungsbereich herum vorbereitet und beibehalten, um schnelles Scrollen zu ermöglichen. Wenn Sie LazyLayoutCacheWindows in Ihrer App verwenden möchten, können Sie die aktuelle Compose-Version 1.13.0-alpha03 verwenden und 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-Fenster zu konfigurieren. Beide beschreiben dasselbe: wie viele Inhalte außerhalb des Bildschirms zusammengestellt werden sollen, aber in unterschiedlichen Einheiten.

• Dp: feste absolute Länge. ahead = 150.dp behält unabhängig vom Gerät 150 dp des Inhalts bei, der über den sichtbaren Rand hinausgeht.
• Gleitkommazahl: Bruchteil des Darstellungsbereichs. aheadFraction = 0.5f hält einen halben Bildschirm im Voraus bereit, sodass die absolute Menge mit der Bildschirmhöhe skaliert wird und verschiedene Formfaktoren unterstützt werden: mehr auf einem Tablet oder aufgeklappten Foldable, weniger auf einem kompakten Smartphone. 

Das Instagram-Team hat die Gleitkommawerte des Cache-Fensters speziell auf die Inhaltsstruktur und die Elementgrößen von Direct abgestimmt. Da die idealen Werte je nach den spezifischen UI-Parametern variieren, ist es erforderlich, ein wenig zu experimentieren, um die richtige Balance zu finden.

Impressionen mit „onVisibilityChanged“ protokollieren

Die API  onVisibilityChanged (in Compose 1.9.0 hinzugefügt) war ein weiteres wichtiges Ergebnis der technischen Partnerschaft zwischen Google und Meta. Damit wird für große Jetpack Compose-Oberflächen eine einheitliche Möglichkeit geboten, zu erkennen, wann ein Compose-Element tatsächlich auf dem Bildschirm sichtbar ist. Dadurch werden benutzerdefinierte, selbst entwickelte Implementierungen ersetzt, die in der Vergangenheit verwendet wurden. Allein in Instagram Direct werden diese Sichtbarkeitssignale in Hunderten von Dateien verwendet, um Messwerte zur Produktqualität zu unterstützen, die davon abhängen, ob UI-Elemente tatsächlich angezeigt wurden.

Startleistung

Die Einführung von Jetpack Compose für Instagram Direct führte zu unerwarteten Leistungsverbesserungen in anderen Bereichen der App. Die Jetpack Compose-Laufzeit verursacht eine Aufwärmphase, die nur einmal bezahlt werden muss. Da Messaging ein Bereich mit hohem Traffic ist, der oft früh in einer Nutzersitzung besucht wird, konnten andere Bereiche von Instagram, die auf Compose basieren, spürbare Leistungsverbesserungen verzeichnen.

Die Startleistung der Compose-UI in Instagram Direct wurde durch die Verwendung von Baseline-Profilen optimiert. Diese kompilieren häufig verwendete Codepfade bei der Installation vor, sodass Compose von Anfang an schnell gerendert wird.

Lessons from the Instagram Direct migration to Jetpack Compose 

• Jetpack Compose bietet eine sofortige Rendite: Sie müssen keine erweiterten KI-Workflows verwenden, um von Compose zu profitieren. Durch die Reduzierung des Codes um etwa 50% muss weniger Code verwaltet werden und die Angriffsfläche für Fehler ist kleiner.
• Die Entwicklung einer KI-nativen Architektur führte zu erheblichen Verbesserungen, darunter eine Reduzierung der Ausführungszeit von KI-Agenten um 35 %, 32% weniger Interaktionen zwischen Entwicklern und Agenten und eine Reduzierung der Tokenkosten um 33 %.
• Es gibt zwar viele Interoperabilitäts-APIs und Unterstützung für die Kombination von Ansichten und Compose, aber Sie sollten größere Oberflächen statt einzelner kleiner Komponenten migrieren. Dadurch bleibt die Benutzeroberfläche in einer einzigen, ununterbrochenen Kompositionshierarchie und alle Compose-nativen Leistungsoptimierungen werden freigeschaltet.
• Pausierbare Komposition mit LazyLayoutCacheWindow kombinieren: Wenn Sie diese beiden Funktionen kombinieren, erzielen Sie bessere Ergebnisse als mit Cache-Fenstern allein. Wenn nur das Cache-Fenster vorhanden ist, kann ein schweres Element trotzdem versuchen, in einem einzigen Durchgang zu rendern, was möglicherweise das Frame-Budget überschreitet.
• Beiträge zu Compose leisten Meta hat sich mit dem Jetpack Compose-Team zusammengetan, um Feedback und Ideen in Compose umzusetzen. Die Arbeit an einem Open-Source-Toolkit bedeutet, dass wir alle davon profitieren, wenn Fehler behoben und Leistungsverbesserungen zentral vorgenommen werden. Teilen Sie uns also Ihr Feedback mit.

Durch die Einführung von Jetpack Compose konnte Instagram die KI-gestützte Entwicklung erheblich verbessern und gleichzeitig die tägliche UI-Entwicklung vereinfachen. Der deklarative Ansatz reduziert Boilerplate-Code, erleichtert das Nachvollziehen des Status und verbessert die allgemeine Produktivität der Entwickler. Das Engineering-Team von Instagram freut sich darauf, Compose in weiteren Bereichen der App einzusetzen. Außerdem wird die Zusammenarbeit zwischen Google und Meta fortgesetzt, um weitere Verbesserungen für Instagram- und Jetpack Compose-Nutzer zu erzielen. 

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

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