Cách các kỹ sư của Instagram Direct xây dựng cấu trúc giao diện người dùng dựa trên AI bằng Jetpack Compose và giảm 33% chi phí token cho mỗi phiên của tác nhân

Bài đăng trên blog này được viết với sự cộng tác của nhóm Meta

Instagram Direct là một trong những nền tảng cốt lõi trên Instagram, xử lý hàng tỷ tin nhắn của người dùng mỗi ngày. Qua nhiều năm lặp lại, nhóm đã tận dụng mọi khả năng tối ưu hoá vi mô có thể có từ hệ thống Chế độ xem Android cũ. Tuy nhiên, việc duy trì và mở rộng một nền tảng cũ được tối ưu hoá cao sẽ tạo ra nợ kỹ thuật và chi phí kỹ thuật đáng kể, đặc biệt là khi các nhóm ngày càng áp dụng giao diện người dùng khai báo và trợ giúp lập trình AI. 

Việc áp dụng Jetpack Compose cho Instagram Direct không chỉ là một nỗ lực hiện đại hoá giao diện người dùng thông thường. Nhóm đã xây dựng một cơ sở mã giao diện người dùng dựa trên AI, nhỏ hơn 50% so với phiên bản triển khai ban đầu, đồng thời giảm 35% thời gian thực thi của tác nhân AI, giảm 32% số lần trao đổi giữa kỹ sư và tác nhân, và giảm 33% chi phí mã thông báo. Nhờ hợp tác chặt chẽ với Google, nhóm đã áp dụng Jetpack Compose trong khi vẫn duy trì hiệu suất cao. Thông qua các hoạt động tối ưu hoá hiệu suất, Meta và Google đã cải thiện Compose không chỉ cho Instagram mà còn cho cả hệ sinh thái nhà phát triển Android nói chung.

Hiện đại hoá toàn bộ mã nguồn trên quy mô lớn

AI đã nhanh chóng trở thành người bạn đồng hành hằng ngày của các kỹ sư trong ngành và việc áp dụng AI vào một toàn bộ mã nguồn quy mô lớn như Instagram đã mang lại những lợi ích thực sự về năng suất. Nhóm Instagram Direct đã đặt ra một mục tiêu tham vọng hơn. Thay vì chỉ áp dụng các công cụ AI vào mã nguồn hiện có, nhóm đã thiết kế lại toàn bộ mã nguồn và cấu trúc của mã nguồn để tích hợp AI ngay từ đầu, nhờ đó nhân rộng tác động của AI vượt xa những gì mà việc cải tiến đơn thuần có thể mang lại.

Nhóm Instagram Direct đã chọn Jetpack Compose làm thành phần chính để xây dựng cấu trúc giao diện người dùng dựa trên AI. Bản chất khai báo của Compose đảm bảo mã ngắn gọn, dễ dự đoán và có cấu trúc dễ dàng hơn cho các mô hình AI suy luận, ít tác dụng phụ hơn, ít trạng thái ngầm định hơn và ranh giới thành phần rõ ràng hơn.

Quá trình di chuyển sang Jetpack Compose đòi hỏi phải lập kế hoạch cẩn thận. Hàng trăm triệu người gửi tin nhắn trên Instagram mỗi ngày, vì vậy, quá trình di chuyển phải diễn ra dần dần, suôn sẻ và không làm gián đoạn trải nghiệm trong khi nhóm thiết kế lại nền tảng bên dưới. Để minh hoạ quy mô của thách thức: Các thành phần giao diện người dùng riêng lẻ có thể hiển thị ở hơn 160 kiểu hoán vị trạng thái riêng biệt và một màn hình trò chuyện duy nhất có thể xử lý hơn 200 loại tin nhắn riêng biệt.

Khi di chuyển một toàn bộ mã nguồn có quy mô như vậy sang Compose, bạn nên chọn cách dễ dàng và nhúng các thành phần giao diện người dùng Compose vào hệ phân cấp view hiện có. Đây là một bước gia tăng trong quá trình di chuyển dần dần, hoàn toàn hợp lệ. Tuy nhiên, về lâu dài, việc tích hợp Compose vào toàn bộ mã nguồn dựa trên Khung hiển thị sẽ đặt ra một thách thức. Các công cụ AI thường chọn cách dễ dàng nhất. Nếu bạn kết hợp mã giao diện người dùng khai báo và mệnh lệnh, AI có thể sẽ kết hợp chúng không chính xác, gây ra lỗi nhỏ, nợ kỹ thuật và giảm hiệu suất. 

Xây dựng cấu trúc giao diện người dùng dựa trên AI

Ở quy mô của Instagram, một mức độ trừu tượng về cấu trúc là không thể tránh khỏi và đó là điều giúp ứng dụng có thể duy trì khi phát triển. Hãy xem xét một mẫu phổ biến, trong đó mọi loại mục RecyclerView đều được mô hình hoá dưới dạng lớp con của một lớp cơ sở tuỳ chỉnh RecyclerViewItem, lớp này hiển thị các hook vòng đời thông thường như onBind.

Ví dụ 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")
          }
        }
        
        ...
      }
  }
}

Trong đoạn mã trên, có hai vấn đề xảy ra. Trước tiên, cờ isPinnedChatsEnabled được đọc trong mã bắt buộc, sau đó được ghi lại bên trong một hàm lambda của Compose, một sự kết hợp tinh tế giữa các mô hình. Thứ hai, isPinned tồn tại dưới dạng một trường có thể thay đổi trên chính mục đó thay vì trong ChatUiState, vì vậy, trường này vẫn tồn tại sau khi RecyclerView liên kết lại và tái chế trên các hàng, gây rò rỉ và tạo ra lỗi khó tái hiện.

Ngay cả khi mã được dọn dẹp bằng cách cung cấp cho mục một hàm @Composable chuyên dụng, thì các vấn đề tương tự vẫn tồn tại.

Ví dụ 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")
      }
    }

    ...
  }
}

Đây là một ví dụ đơn giản nhưng minh hoạ một vấn đề rộng hơn: AI càng ít ranh giới thì chất lượng mã mà AI tạo ra theo thời gian càng thấp. Các biện pháp bảo vệ và kỹ năng có thể giúp ích, nhưng chỉ riêng chúng thì không đủ, vì khi gặp trở ngại, AI thường sẽ tìm cách vượt qua để tự giải quyết vấn đề.

Để toàn bộ mã nguồn thân thiện với AI, bạn cần tuân thủ hai quy tắc thực tế sau: 

• Giảm thiểu sự phụ thuộc vào bối cảnh tuỳ chỉnh. Tác nhân AI càng cần nhiều kiến thức riêng biệt, dành riêng cho toàn bộ mã nguồn để thực hiện thay đổi chính xác, thì chất lượng kết quả đầu ra càng thấp. Toàn bộ mã nguồn càng gần với các phương pháp hay nhất đã biết thì kết quả AI càng tốt.
• Một toàn bộ mã nguồn ưu tiên AI phải thực thi các ranh giới của riêng mình. Việc vá các lỗ hổng thiết kế bằng kỹ năng AI không thể mở rộng, vì mỗi kỹ năng được tải vào ngữ cảnh đều tốn mã thông báo và có thể làm giảm hiệu suất của tác nhân. Thay vào đó, chính cấu trúc sẽ đảm nhận trọng trách đó. Các tác nhân AI thường chọn con đường dễ dàng nhất, vì vậy, thiết kế phải đảm bảo con đường đó dẫn đến mã chính xác, chất lượng cao, đồng thời khiến các quyết định thiết kế kém trở nên khó khăn và tốn kém.

Một mục trong danh sách vẫn có thể được biểu thị bằng lớp trừu tượng của riêng nó, nhưng trong trường hợp này, tất cả mã Compose đều nằm trong hàm khởi tạo, vì vậy, nó không có quyền truy cập vào các thành phần hoặc trạng thái của lớp và nguồn đối số duy nhất của nó là hàm khởi tạo. Điều này giúp hàm này tương đương với một hàm @Composable đơn giản, đồng thời tuân thủ cấu trúc hiện có.

Ví dụ 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")
      }
    }
    
    ...
  },
)

Việc di chuyển một cơ sở mã có quy mô như vậy là một nhiệm vụ rất lớn. Trong một thời gian dài, hàng trăm thành phần giao diện người dùng tạo nên phần lớn Direct UI phải cùng tồn tại với các thành phần cũ, cả hai đều được duy trì song song. Quy trình làm việc dựa trên AI đã giúp quá trình di chuyển song song này diễn ra suôn sẻ bằng cách đẩy nhanh quá trình viết một lượng lớn mã. Cách tiếp cận đó giúp nhóm Direct thực hiện quá trình di chuyển trong thời gian kỷ lục mà không làm gián đoạn phần còn lại của nhóm, những người tiếp tục cung cấp các tính năng giúp cải thiện trải nghiệm của hàng triệu người mỗi ngày.

Nhiều kỹ sư đã chạy tác nhân AI của riêng họ dựa trên một cơ sở kiến thức chung gồm các kỹ năng và quy ước có thể tái sử dụng được xây dựng trong quá trình di chuyển. Điều này giúp đồng bộ hoá quy trình làm việc và các phương pháp hay nhất trong toàn nhóm, thay vì để mỗi kỹ sư tự tìm hiểu lại. Trong mỗi nền tảng, nhóm đã thực hiện việc di chuyển theo các giai đoạn sau:

• Viết tất cả mã Compose bằng AI.
• Đánh bóng, xử lý các trường hợp hiếm gặp và thu hẹp khoảng cách về hiệu suất cho đến khi giao diện người dùng được triển khai cho người dùng thực tế trong một thử nghiệm công khai.

Việc chia công việc thành hai giai đoạn cho mỗi màn hình giúp một kỹ sư nhanh chóng xử lý toàn bộ giao diện, giải quyết trước cấu trúc và các trường hợp hiếm gặp phức tạp. Khi đã có nền tảng đó, những người khác có thể tập trung vào việc chuẩn bị giao diện người dùng cho giai đoạn phát hành chính thức mà không cần phải tự đưa ra các quyết định kỹ thuật, nhờ đó giúp quá trình di chuyển tổng thể diễn ra nhanh chóng.

Kết quả của quá trình di chuyển đã xác thực phương pháp này. Đối với các nền tảng Instagram Direct đã di chuyển, Jetpack Compose cho phép nhóm giảm 50%tổng lượng mã giao diện người dùng. AI cần tạo ít mã hơn, nhờ đó mang lại kết quả chất lượng cao hơn và chi phí token thấp hơn cho mỗi nhiệm vụ. 

Một bản phân tích dữ liệu nội bộ về toàn bộ mã nguồn Android cho Instagram Direct đã so sánh các phiên tác nhân AI hoạt động trên Compose UI với cùng các nhiệm vụ sử dụng Android Views. Hiệu quả tăng lên rõ rệt ở hai khía cạnh:

• Tính theo mỗi ký tự của mã được đưa vào: Compose cần ít hơn 32% số lượt trao đổi giữa kỹ sư và tác nhân và ít hơn 35% thời gian thực thi của tác nhân (thời gian trôi qua từ khi tác nhân bắt đầu xử lý yêu cầu của kỹ sư cho đến khi trả về phản hồi).
• Mỗi phiên của nhân viên hỗ trợ: Chi phí mã thông báo tổng thể giảm 33% khi dùng Compose so với Khung hiển thị.

Chúng tôi báo cáo cả hiệu suất đầu ra và số phiên thông thường vì đây là những kết quả hữu ích độc lập. Số liệu về thời gian thực thi và lượt trao đổi giữa kỹ sư và tác nhân so sánh mức sử dụng tài nguyên trên mỗi đơn vị đầu ra, trong khi số liệu về mã thông báo so sánh tổng chi phí cho một phiên tác nhân thông thường.

Dữ liệu cũng cho thấy sự khác biệt nhất quán trong cách hai khung xử lý mã phức tạp hoặc dễ hỏng. Meta theo dõi điều này bằng cách sử dụng điểm rủi ro của các thay đổi về mã, giúp đánh giá chất lượng tổng thể của mã và khả năng một thay đổi gây ra sự cố trong quá trình phát hành chính thức. Phân tích này đo lường hiệu quả sử dụng tài nguyên của tác nhân bằng cách kết hợp mức tiêu thụ mã thông báo, thời gian thực thi của tác nhân và tương tác giữa kỹ sư và tác nhân. Khi các tệp tích luỹ điểm rủi ro cao hơn, các phiên của tác nhân AI sẽ tự nhiên trở nên kém hiệu quả về tài nguyên. 

Khi điểm rủi ro tích luỹ của một tệp tăng gấp đôi, giao diện người dùng được triển khai bằng Android Views sẽ giảm 30%hiệu suất tài nguyên của tác nhân (mỗi ký tự được nhập). Trong cùng trường hợp, mức giảm của giao diện người dùng Jetpack Compose chỉ là 9%

Thông qua mối quan hệ đối tác giữa Google và Meta, nhóm Instagram Direct đã mang đến một góc nhìn mới mẻ về việc áp dụng Compose — tiếp cận công cụ này thông qua lăng kính về mức độ sẵn sàng của AI trong cơ sở mã, chứ không chỉ là viết lại giao diện người dùng. Công việc này cho thấy thế mạnh của Compose trong việc đóng vai trò là nền tảng để xây dựng cơ sở mã và cấu trúc ưu tiên AI, đặc biệt là khi áp dụng ở quy mô của các ứng dụng như Instagram.

Tối ưu hoá hiệu suất 

Instagram Direct là một trong những nền tảng quan trọng nhất của ứng dụng và mọi người mong đợi nền tảng này luôn nhanh chóng và phản hồi nhanh. Việc áp dụng Jetpack Compose một cách hiệu quả đồng nghĩa với việc phải viết lại giao diện người dùng một cách đáng kể, và mục tiêu số một là duy trì trải nghiệm chất lượng cao mà không bị hồi quy.

Nhiều năm lặp lại đã đẩy việc triển khai dựa trên Khung hiển thị cũ trên Instagram lên một thanh hiệu suất đặc biệt cao và nhóm cần đáp ứng cùng một tiêu chuẩn đó trong khi chuyển sang một khung giao diện người dùng hoàn toàn mới.

Instagram đo lường hàng trăm, thậm chí hàng nghìn chỉ số hiệu suất.  Đối với việc áp dụng Compose, 3 yếu tố sau đây là quan trọng nhất:

• Thời gian tương tác – khoảng thời gian từ khi mở màn hình đến khi có thể sử dụng màn hình.
• Thời gian tải đầy đủ  – khoảng thời gian từ khi mở màn hình đến khi tất cả nội dung được tải đầy đủ (tức là hình ảnh).
• Hiệu suất cuộn – mức độ mượt mà khi cuộn màn hình, không bị rớt khung hình.

Các chỉ số này được theo dõi trong thời gian chạy trong môi trường thực tế, giúp bạn có thể chạy thử nghiệm A/B để so sánh giao diện người dùng Compose đã di chuyển với giao diện người dùng cũ và đánh giá tác động của nỗ lực này đối với hiệu suất.

Cách phổ biến để tiếp cận quá trình di chuyển như thế này là bắt đầu từ quy mô nhỏ, di chuyển một số thành phần giao diện người dùng, thu thập dữ liệu và nghiên cứu cách các thành phần đó hoạt động. Mặc dù hữu ích, nhưng những kết quả ban đầu này chỉ cho thấy một phần bức tranh, đưa ra kết quả âm tính giả đối với việc áp dụng Compose vì:

• Không mang tính đại diện — một thành phần giao diện người dùng đã di chuyển có thể cung cấp dữ liệu hữu ích về hiệu suất tổng thể của thành phần đó trên một màn hình cụ thể. Tuy nhiên, các thành phần khác nhau sẽ hoạt động theo cách khác nhau vì những lý do không khái quát, nên bạn không phải lúc nào cũng có thể suy luận từ đó.
• Chi phí tương tác — một thành phần Compose nhỏ bên trong một toàn bộ mã nguồn lớn của Khung hiển thị sẽ phải trả chi phí cầu nối không thể dự đoán giữa hai hệ thống. Mức hao tổn đó làm sai lệch kết quả đo lường, vì vậy, kết quả ban đầu ở quy mô nhỏ không phản ánh đúng kết quả thực tế của quá trình di chuyển toàn bộ.

Kết quả là các hoạt động di chuyển nhỏ, tuy hữu ích, nhưng không phải lúc nào cũng phản ánh toàn bộ tác động của Compose. Càng nhiều nền tảng được di chuyển từ đầu đến cuối mà không bị gián đoạn, thì bức tranh về hiệu suất càng rõ ràng và tốt hơn.

Các màn hình chính trong Instagram Direct được xây dựng dựa trên danh sách dài gồm nhiều loại mục, ban đầu được triển khai bằng RecyclerView. Kiến trúc này dựa vào các lớp trừu tượng tuỳ chỉnh để có khả năng mở rộng, nhưng vẫn liên kết với vòng đời của hệ thống dựa trên Khung hiển thị.

Nhiệm vụ chính của nhóm là di chuyển dần vài trăm mục danh sách riêng lẻ sang Compose trong cấu trúc dựa trên RecyclerView hiện có, triển khai các mục này trong môi trường thực tế theo các nhóm nhỏ độc lập trong các thử nghiệm A/B — tất cả đều không có thay đổi rõ ràng đối với trải nghiệm nhắn tin của người dùng.

Nhược điểm lớn nhất của cách thiết lập này là sự phụ thuộc đáng kể vào hệ thống Khung hiển thị cũ thông qua cấu trúc cốt lõi RecyclerView, ngay cả sau khi di chuyển hoàn toàn mọi mục trong danh sách sang Compose. Bước tiếp theo là nhóm quyết định đầu tư vào việc thay thế kiến trúc cốt lõi dựa trên RecyclerView bằng giải pháp thay thế gốc của Compose — LazyColumn.

Điều này có nghĩa là các thành phần giao diện người dùng Compose phải được tách biệt khỏi khung chứa chúng, đồng thời vẫn tương thích với cả RecyclerView và LazyColumn. Điều quan trọng không kém là khả năng chuyển đổi giữa hai chế độ này trong thời gian chạy thông qua cờ tính năng để bật thử nghiệm A/B.

Mặc dù các mục mới trong Compose tương thích gốc với LazyColumn và có thể được đưa vào một cây thành phần không bị gián đoạn, nhưng một API tương tác đã được tạo để đưa các mục đó vào RecyclerView. Nhờ đó, chúng tôi có thể triển khai chế độ thiết lập LazyColumn trong một thử nghiệm A/B song song với RecyclerView — sử dụng lại cùng một mục Compose và cải thiện hiệu suất mà không làm gián đoạn các tính năng xây dựng và tinh chỉnh của nhóm còn lại.

Quy mô, độ phức tạp và độ nhạy cảm của Instagram đối với ngay cả những lỗi hồi quy nhỏ nhất đã đặt ra một thách thức riêng cho Jetpack Compose. Để giải quyết những vấn đề này, chúng tôi cần có một mối quan hệ đối tác thực tế và lặp đi lặp lại. Các kỹ sư của Google và Meta đã phối hợp chặt chẽ để phân tích các chỉ số nhằm xác định và thiết kế các tính năng mới của Compose để đáp ứng hoặc vượt qua các điểm chuẩn dựa trên Khung hiển thị. Nhờ mối quan hệ đối tác này, Jetpack Compose đã có thêm những điểm nổi bật sau: Thành phần có thể tạm dừng bằng LazyLayoutCacheWindows và theo dõi chế độ hiển thị. 

Thành phần có thể tạm dừng bằng LazyLayoutCacheWindows

Thành phần có thể tạm dừng (được bật theo mặc định trong Compose 1.10) cho phép các mục danh sách tải từng phần tốn kém được kết hợp dần dần trên các khung hình để tránh hiện tượng giật. Khi kết hợp với LazyLayoutCacheWindow (được thêm vào Compose 1.9), sự kết hợp này giúp cải thiện đáng kể độ mượt mà khi cuộn. Trong thử nghiệm nội bộ gần đây tại Meta, việc kết hợp thành phần có thể tạm dừng với một khung nhìn LazyLayoutCacheWindow đã giảm khoảng 13% số khung hình bị rớt lớn mỗi phút (LFD/m) so với Compose thông thường. Chỉ riêng Cache Window đã giúp giảm khoảng 8% so với cùng một đường cơ sở. LFD/m là một chỉ số nội bộ mà Meta sử dụng để theo dõi tình trạng giật hình đáng chú ý khi cuộn.

Việc sử dụng LazyLayoutCacheWindow trong ứng dụng sẽ chuẩn bị và giữ lại các mục ngoài màn hình trong một dải dựa trên pixel xung quanh khung nhìn để cho phép vuốt nhanh. Để tận dụng LazyLayoutCacheWindows trong ứng dụng, bạn có thể sử dụng phiên bản Compose 1.13.0-alpha03 mới nhất và thiết lập như trong ví dụ dưới đây:

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

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

Có hai cách để định cấu hình cửa sổ bộ nhớ đệm. Cả hai đều mô tả cùng một điều: lượng nội dung ngoài màn hình cần giữ lại, nhưng theo các đơn vị khác nhau.

• Dp: chiều dài tuyệt đối cố định. ahead = 150.dp giữ 150dp nội dung được kết hợp qua cạnh hiển thị bất kể thiết bị.
• Float: phân số của khung nhìn. aheadFraction = 0.5f giữ cho một nửa màn hình được kết hợp trước, vì vậy, số lượng tuyệt đối sẽ điều chỉnh theo chiều cao màn hình hỗ trợ nhiều kiểu dáng: nhiều hơn trên máy tính bảng hoặc thiết bị gập chưa gập, ít hơn trên điện thoại nhỏ gọn. 

Nhóm Instagram đã tinh chỉnh phân số thực của cửa sổ bộ nhớ đệm dành riêng cho cấu trúc nội dung và kích thước mục của Direct. Vì các giá trị lý tưởng sẽ thay đổi tuỳ thuộc vào các tham số giao diện người dùng cụ thể, nên bạn cần thử nghiệm một số lần để tìm ra điểm cân bằng phù hợp.

Ghi nhật ký lượt hiển thị bằng onVisibilityChanged

API onVisibilityChanged (được thêm vào Compose 1.9.0) là một kết quả quan trọng khác của mối quan hệ đối tác kỹ thuật giữa Google và Meta. Thư viện này cung cấp cho các nền tảng Jetpack Compose quy mô lớn một cách nhất quán để biết thời điểm một thành phần kết hợp thực sự xuất hiện trên màn hình, thay thế các phương thức triển khai tuỳ chỉnh, thủ công được sử dụng trước đây. Chỉ riêng trong Instagram Direct, các tín hiệu về khả năng hiển thị này được sử dụng trên hàng trăm tệp để hỗ trợ các chỉ số về chất lượng sản phẩm, phụ thuộc vào việc các phần tử trên giao diện người dùng có thực sự hiển thị cho người dùng hay không.

Hiệu suất khởi động

Việc áp dụng Jetpack Compose cho Instagram Direct đã giúp cải thiện hiệu suất ngoài mong đợi trên các nền tảng khác của ứng dụng. Thời gian chạy Jetpack Compose có chi phí khởi động mà bạn chỉ phải trả một lần. Vì nhắn tin là một nền tảng có lưu lượng truy cập cao thường được truy cập sớm trong phiên của người dùng, nên các nền tảng khác trên Instagram dựa vào Compose đã có những cải thiện đáng kể về hiệu suất.

Hiệu suất khởi động của giao diện người dùng Compose trong Instagram Direct được tối ưu hoá thông qua việc sử dụng Hồ sơ cơ sở. Hồ sơ này biên dịch trước các đường dẫn mã nóng tại thời điểm cài đặt để Compose hiển thị nhanh chóng ngay từ lần khởi chạy đầu tiên.

Bài học từ quá trình di chuyển Instagram Direct sang Jetpack Compose 

• Jetpack Compose mang lại lợi tức đầu tư ngay lập tức: Bạn không cần phải sử dụng quy trình AI nâng cao để hưởng lợi từ Compose. Việc giảm khoảng 50% mã đồng nghĩa với việc giảm mã cần duy trì và giảm phạm vi xảy ra lỗi.
• Việc thiết kế một cấu trúc dựa trên AI đã mang lại những thành công đáng kể, bao gồm việc giảm 35% thời gian thực thi của tác nhân AI, giảm 32% số lần trao đổi giữa kỹ sư và tác nhân, đồng thời giảm 33% chi phí mã thông báo.
• Mặc dù có nhiều API tương tác và hỗ trợ kết hợp Khung hiển thị và Compose với nhau, nhưng hãy hướng đến việc di chuyển các nền tảng lớn hơn thay vì các thành phần nhỏ riêng lẻ. Điều này giúp giao diện người dùng nằm trong một hệ phân cấp thành phần duy nhất, không bị gián đoạn và khai thác tất cả các tính năng tối ưu hoá hiệu suất gốc tốt nhất của Compose.
• Kết hợp thành phần có thể tạm dừng với LazyLayoutCacheWindow: Việc kết hợp hai thành phần này sẽ mang lại kết quả tốt hơn so với chỉ dùng cửa sổ lưu vào bộ nhớ đệm. Nếu chỉ có cửa sổ bộ nhớ đệm, một mục nặng vẫn có thể cố gắng kết hợp trong một lượt truyền, có khả năng vượt quá ngân sách khung hình.
• Đóng góp cho chính Compose! Meta đã hợp tác với nhóm Jetpack Compose để hiện thực hoá ý kiến phản hồi và ý tưởng của họ trong Compose. Khi làm việc trên một bộ công cụ nguồn mở, tất cả chúng ta đều được hưởng lợi khi các lỗi và điểm cải thiện hiệu suất được thực hiện tập trung. Vì vậy, hãy cho chúng tôi biết ý kiến phản hồi của bạn!

Việc áp dụng Jetpack Compose đã mang lại những lợi ích đáng kể trong quá trình phát triển sử dụng AI, đồng thời đơn giản hoá công việc kỹ thuật giao diện người dùng hằng ngày tại Instagram. Phương pháp khai báo giúp giảm bớt mã nguyên mẫu, giúp dễ dàng suy luận về trạng thái và cải thiện năng suất tổng thể của nhà phát triển. Nhóm kỹ sư của Instagram mong muốn đưa Compose lên nhiều nền tảng hơn trong ứng dụng, đồng thời tiếp tục hợp tác giữa Google và Meta để mang đến nhiều điểm cải tiến hơn cho người dùng Instagram cũng như Jetpack Compose. 

Nếu bạn chưa dùng thử Compose, thì giờ đây, nhờ có sự hỗ trợ sử dụng AI, việc di chuyển sang Jetpack Compose trở nên dễ dàng hơn bao giờ hết.

Xác nhận. Cảm ơn Michal Zielinski và Matthew Du của Meta, cũng như Andrei Shikov và George Mount của Google, vì đã nỗ lực cải thiện hiệu suất cho Compose thông qua sự hợp tác giữa Meta và Google! Cảm ơn Gary Ye của Meta đã giúp đưa Compose vào Instagram Direct, và Gopal Juneja của Meta đã hỗ trợ nỗ lực này thông qua khoa học dữ liệu!