ShareChat 解決了資源浪費問題，讓動態消息捲動次數提高 60%
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
簡介
ShareChat 是印度的頂尖社群媒體平台，可讓使用者以自己的母語分享意見、記錄生活點滴，並認識新朋友。其他功能包括聊天室和私人訊息收發功能，可讓使用者分享影片、笑話、歌曲和其他語言的社交內容。ShareChat 即將為印度的網際網路革命，改變了接下來十億使用者上網互動的方式。
數字中的應用程式
- 下載次數超過 1 億
- 每月活躍使用人數超過 1.8 億
- 超過 3,200 萬內容創作者
- 15 種印度語言
- 每日建立的訊息數量約為 150 萬則
挑戰
由於 ShareChat 的每日成長為數千人，因此該應用程式持續提供新影格，導致回應時間不佳，進而對使用者體驗造成不良影響。
因此，應用程式的影格遺失或延遲增加 (也稱為「卡頓」)。如要修正這些卡頓問題，就必須改善緩慢影格和凍結影格，才能為所有使用者提供順暢的使用體驗。這也有助於吸引使用者在應用程式中花更多時間使用應用程式、提高參與度，進而改善 Android Play 商店中的 ShareChat 評分。
方法
ShareChat 與 Google 的開發人員關係團隊合作，改善應用程式的緩慢及凍結影格 (資源浪費) 處理速度，藉此為業務帶來正面影響。具體來說，他們正致力改善下列問題：
共用 RecyclerView 集區：透過剖析，我們發現建立不同檢視區塊持有者花費的時間較長，並將建立了一個共用 RecyclerView 集區。這也有助於減輕觀看者建立類似動態饋給的成本。
版面配置 Passl 超出上限：透過剖析，同時發現部分 View Holder 要求了額外的 requestLayouts。為了最佳化，程式碼已更新為擷取建立時間 (而非每個繫結) 的價值，因此可以節省額外的 requestLayout 費用。
OverDraw：簡化版面配置，減少圖層並移除各圖層個別設定的顏色。
壓平階層 - 透過剖析和手動檢查許多畫面，觀察長時間的加載作業。為此，我們使用 ConstraintLayout 彙整階層。
檢視畫面加載過多 - 在分析時找出特定檢視畫面的加載時間過長。這些觀看次數已轉換為 ViewTub。
從 UI 執行緒移除繁重的工作：使用分析器監控幾個在主要執行緒上執行繁重工作的位置，例如使用每個 recyclerView 繫結的標記和樣式建立 SpannableStringBuilder，以及 BlurHash 解碼等工作。這些工作已從 UI 執行緒中移除，並移至背景執行緒。
從 Rx 遷移至「協同程式」 - 記憶體用量也會造成頻繁的 GC 呼叫，而超過 100 RX 執行緒的執行緒計數也非常高。為修正這些問題，我們已將許多用途移至協同程式。
採用 Coil 載入圖片 - 載入圖片時，Glide 發生問題，特別是透過 jetpack Compose 建構的元件。同時發現，在 LazyColumn 中載入圖片時，轉譯門檻長條偏高。發生這類情況時，系統會採用 Coil 來載入圖片。
清除及重構程式碼：移除舊程式碼和實驗，有助於移除使用者介面中不必要的隱藏檢視畫面，並以更好的方式重新編寫部分畫面。
成果
藉由分析改善領域並找出最佳化策略，ShareChat 不僅能改善使用者的整體體驗，還能提高參與度和 Play 商店評分。以下是 ShareChat 成果的量化總覽 -
- Play 商店的「轉譯速度緩慢」影格比率減少約 45%
- Play 商店的「凍結」影格比率減少約 30%
- 轉譯 10K 影格的閒置影格速率從 10.72% 減少至 3.98%
- 動態消息捲動功能增加了 60%
- 商店的整體評分已從 4.0 提升至 4.3
- 貼文使用率提升 10%
「ShareChat 的目標是讓使用者能夠享受愉快的社群媒體應用程式
而這也意味著能夠獲得最佳的應用程式效能。
我們和 Google 的開發人員關係團隊的合作，
協助我們找出最常使用且低階裝置
還有哪些需要改善的地方我們已瞭解最佳效能做法和工具，以便找出並修正凍結影格、資源浪費、過度繪製和 ANR 問題。」
– ShareChat Android 團隊工程經理 Vihaan Verma
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-27 (世界標準時間)。"],[],[],null,["# ShareChat addresses Jank issues to increase feed scrolling by 60%\n\nIntroduction\n------------\n\nShareChat is a leading social media platform in India that allows users to share their opinions, document their lives, and make new friends in their native language. Other features include chatrooms, and private messaging, enabling users to share videos, jokes, songs and other language-based social content. On a mission to spearhead India's internet revolution, ShareChat is changing how the next billion users will interact on the internet.\n\nThe app in numbers\n\n- **100 Million+** downloads\n- **180 Million+** Monthly Active Users\n- **32 Million+** content creators\n- **15** different Indian languages\n- **\\~1.5** Million posts created daily\n\nThe Challenge\n-------------\n\nAs ShareChat grew to be loved by thousands of people daily, the app faced a challenge in consistently delivering new frames leading to poor response times that impeded user experience.\n\nAs a result, the app saw an increased number of dropped or delayed frames (also known as \"Jank\"). Fixing these jank issues by improving slow \\& frozen frames was critical in delivering a seamless experience to all its users. This would also play an important role in making users spend more time on the app, increasing engagement and, in turn, improving ShareChat's rating on the Android Play Store.\n\nHow They Did It\n---------------\n\nShareChat worked with Google's developer relations team to reduce Jank and yield a positive business impact by improving slow \\& frozen frames (Jank) on the app. Specifically they worked on improving the following issues -\n\n- **Shared RecyclerView Pool** - Through profiling, it was observed that creating different viewholders takes longer and to minimize that, a Shared RecyclerView Pool was created. This also helped in removing the viewholders creational cost for similar feeds.\n\n- **Excessive Layout Passesl** - Through [profiling](https://perfetto.dev/), it was also observed that some viewholders were requesting additional requestLayouts. To optimize, the code was updated to take value in creation time instead of every bind, thus saving extra requestLayout costs.\n\n- **[OverDraw](https://developer.android.com/topic/performance/rendering/inspect-gpu-rendering)** - Simplified the layouts to reduce layering and removing colors that were being set separately for each of the layers.\n\n- **Flattening of hierarchy** - Observed long inflation through profiling and manual inspection of many screens. The hierarchy was flattened using [ConstraintLayout](https://developer.android.com/reference/androidx/constraintlayout/widget/ConstraintLayout) to solve for this.\n\n- **Excessive View Inflation** - Identified long inflation time for certain views while profiling. These views were converted to viewstubs.\n\n- **Removing heavy tasks from UI thread** - Using a profiler allowed for observation of a couple of places where heavy tasks were being done on the main thread, such as creating SpannableStringBuilder with tagging and styling of every recyclerView bind, BlurHash decoding, etc. These tasks were removed from the UI thread and moved to a background thread.\n\n- **Migrating from Rx to [Coroutine](https://developer.android.com/kotlin/coroutines#:%7E:text=A%20coroutine%20is%20a%20concurrency,established%20concepts%20from%20other%20languages)** - Memory consumption also led to frequent GC calls, and there were very high thread counts via the \\\u003e100 RX thread. Many of the use cases were moved to Coroutine to fix these issues.\n\n- **Adoption of [Coil](https://coil-kt.github.io/coil/) for image loading** - Glide was causing issues while loading images, specifically in the components built via jetpack compose. It was also identified that while loading images in LazyColumn, the rendering threshold bar was high. These occurrences led to the adoption of Coil for image loading.\n\n- **Old code cleanup and refactoring** - Removal of old code and experiments helped to remove unnecessary hidden views from the UI and helped rewrite some of the screens in a better way.\n\nResults\n-------\n\nBy analyzing improvement areas and identifying optimization strategies, ShareChat could improve the overall experience for users while increasing its engagement rate and Play Store ratings. Below is the quantitative overview of the results ShareChat achieved -\n\n- \\~45% reduction in 'Slow rendered' frames on Play Store\n- \\~30% reduction in 'Frozen' frames on Play Store\n- Janky frame rates for every 10K frames rendered reduced from 10.72% to 3.98%\n- Feed-scrolling increased by 60%\n- The overall ratings on the Store increased from \\~4.0 to 4.3\n- 10% increase in consumption of posts\n\n\u003e \"At ShareChat, our goal is to be the best social media app out there that\n\u003e delights our users.This also means being the best in terms of app performance.\n\u003e Our collaboration with Google's developer relations team helped us identify\n\u003e areas of improvement on our most used low-end user devices. We learned the best\n\u003e performance practices and tools to identify and fix frozen frames, janks,\n\u003e overdraws, and ANRs.\"\n\u003e\n\u003e **-- Vihaan Verma, Engineering Manager, Android Team at ShareChat**"]]
