DEV Community: ViO Tech

📘 Paywall SDK – Tài liệu sử dụng TỪ A Z (kèm JSON mẫu)

ViO Tech — Fri, 09 Jan 2026 04:24:59 +0000

Tài liệu này hướng dẫn toàn bộ quy trình Paywall SDK, từ:

Cấu trúc JSON config
Parse & cung cấp dữ liệu
Hiển thị UI (Fragment / Dialog)
Purchase & Sale / Retention flow
Best practices tối ưu conversion

Phù hợp cho Android Kotlin – app nội bộ & production.

1️⃣ Tổng quan kiến trúc Paywall

Remote Config / API / Local JSON
        ↓
PaywallDataProvider
        ↓
PaywallRepository
        ↓
BasePaywallFragment / BasePaywallDialog
        ↓
Paywall UI (Full / One / Dialog)

2️⃣ JSON Paywall Config – Chuẩn sử dụng

2.1 JSON mẫu (FULL SCREEN)

{
  "uiType": "paywall_full_01",
  "ctaId": 0,
  "enable": true,
  "timesOpen": 0,
  "delayButtonX": 2,
  "timesFree": "1,2,9,10,14",
  "showAdsClose": false,
  "packages": [
    {
      "packageId": "test.com.year.discount",
      "packageIdOrigin": "test.com.yearly",
      "packageType": "yearly",
      "ctaId": 1,
      "isPopular": false,
      "isSelected": false
    },
    {
      "packageId": "test.com.month.discount",
      "packageIdOrigin": "test.com.monthly",
      "packageType": "weekly",
      "ctaId": 3,
      "isPopular": false,
      "isSelected": false
    },
    {
      "packageId": "test.com.week.offer",
      "packageType": "weekly",
      "ctaId": 2,
      "isPopular": true,
      "isSelected": true
    }
  ]
}

2.2 Giải thích từng field

🔹 Root level

Field	Ý nghĩa
`uiType`	Mapping UI (`paywall_full_01`, `paywall_dialog_01`)
`ctaId`	CTA mặc định nếu chưa chọn package
`enable`	Bật / tắt paywall
`timesOpen`	Số lần app mở mới show (0 = luôn check)
`delayButtonX`	Delay hiển thị nút close (giây)
`timesFree`	Danh sách lần sử dụng được free
`showAdsClose`	Đóng paywall bằng ads

🔹 Package item

Field	Ý nghĩa
`packageId`	SKU sale / active
`packageIdOrigin`	SKU gốc (để tính discount)
`packageType`	weekly / monthly / yearly / lifetime
`ctaId`	CTA riêng cho package
`isPopular`	Hiển thị badge “Popular”
`isSelected`	Auto select khi mở paywall

3️⃣ Parse JSON → PaywallData

fun String.parsePaywall(): PaywallData? {
    if (isBlank()) return null
    return Json {
        ignoreUnknownKeys = true
        explicitNulls = false
    }.decodeFromString(this)
}

📌 JSON có thể lấy từ:

Firebase Remote Config
API backend
Local config

4️⃣ PaywallDataProvider – Cấp dữ liệu cho SDK

4.1 Cung cấp Paywall config

override fun getPaywallConfig(placementType: String): PaywallData? {
    return when (placementType) {
        PAYWALL_HOME_ICON -> homeIconJson.parsePaywall()
        PAYWALL_SETTING -> settingJson.parsePaywall()
        else -> null
    }
}

4.2 Retention mapping

override fun getRetentionPlacement(current: String): String? {
    return when (current) {
        PAYWALL_HOME_ICON -> PAYWALL_HOME_ICON_SALE
        else -> null
    }
}

5️⃣ PaywallRepository – Luồng sử dụng

5.1 Init

paywallRepository.initialize(isDebugMode = true)

5.2 Check show paywall

if (paywallRepository.shouldShow(PAYWALL_HOME_ICON)) {
    showPaywall()
}

5.3 Load data & product

val data = paywallRepository.getPaywallData(PAYWALL_HOME_ICON)
val packages = paywallRepository.getPackages(data)

6️⃣ Hiển thị UI Paywall

6.1 Full Screen – Ví dụ PaywallFull01Fragment

class PaywallFull01Fragment :
    BasePaywallFragment<FragmentPaywallFull01Binding>(),
    PackageSubCallback {

    override val bindingInflater =
        FragmentPaywallFull01Binding::inflate

    private val adapter by lazy {
        PackageSubAdapter(this)
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        binding.rcvPackage.apply {
            layoutManager = GridLayoutManager(context, 3)
            adapter = this@PaywallFull01Fragment.adapter
        }

        binding.btnContinue.setOnClickListener {
            adapter.getPaywallProduct()?.let {
                buy(it.product)
            }
        }

        binding.imgClose.setOnClickListener { close() }
        binding.txtPolicy.setOnClickListener { openPolicy() }
        binding.txtTerm.setOnClickListener { openTerm() }
    }

    override fun bindData(
        config: PaywallData,
        packages: List<PaywallProduct>
    ) {
        adapter.submitData(packages)
    }

    override fun onSelectPackage(paywallProduct: PaywallProduct) {
        binding.btnContinue.setText(
            PaywallCtaUtils.getCtaStringResId(paywallProduct)
        )

        val descRes = PaywallDescUtils.getDescResIds(
            paywallProduct,
            PaywallDescUtils.LayoutType.FULL_SCREEN
        )

        if (descRes.descRes != 0) {
            binding.txtDescription.text = PaywallDescUtils.formatDescription(
                requireContext(),
                descRes.descRes,
                paywallProduct
            )
        }
    }
}

📌 Khi dùng: onboarding, hard paywall, feature lock

6.2 Dialog Sale – Ví dụ PaywallDialog01

class PaywallDialog01 :
    BasePaywallDialog<DialogPaywall01Binding>() {

    override val bindingInflater =
        DialogPaywall01Binding::inflate

    private var currentItem: PaywallProduct? = null

    override fun bindData(
        config: PaywallData,
        packages: List<PaywallProduct>
    ) {
        val item = packages.firstOrNull() ?: return
        currentItem = item

        binding.txtPrice.text = item.product.priceText

        binding.btnContinue.setText(
            PaywallCtaUtils.getCtaStringResId(item)
        )

        val descRes = PaywallDescUtils.getDescResIds(
            item,
            PaywallDescUtils.LayoutType.DIALOG_1_ITEM
        )

        if (descRes.descRes != 0) {
            binding.txtDescription.text = PaywallDescUtils.formatDescription(
                requireContext(),
                descRes.descRes,
                item
            )
        }

        binding.btnContinue.setOnClickListener {
            currentItem?.let { buy(it) }
        }

        binding.imgClose.setOnClickListener { close() }
    }
}

📌 Khi dùng: retention, sale off, exit intent

6.2 Dialog (Sale / Retention)

PaywallDialog01()

Dùng cho:

Sale
Exit intent

7️⃣ Package selection & CTA

PaywallCtaUtils.getCtaStringResId(paywallProduct)

CTA thay đổi theo:

Trial
Sale
Lifetime

8️⃣ Discount & Sale logic

packageIdOrigin ≠ null → enable sale
Tính %OFF từ giá gốc
Gạch ngang giá cũ

9️⃣ Purchase flow

buy(paywallProduct)

SDK xử lý:

Billing
Verify
Emit purchaseStatus

🔟 Retention Flow (chuẩn)

Paywall A
  ↓ close
Sale Paywall Dialog
  ↓ close
No more paywall

1️⃣1️⃣ Best Practices (Rất quan trọng)

✅ Full screen: 2–3 packages

✅ Dialog sale: 1 package

✅ Weekly = entry price thấp

✅ Yearly = best value

✅ Lifetime = anchor price

1️⃣2️⃣ Checklist tích hợp nhanh

[ ] JSON config hợp lệ
[ ] Map placement → config
[ ] Init repository
[ ] Test sandbox purchase
[ ] Test sale / retention

1️⃣3️⃣ Ví dụ thực tế: Tích hợp Paywall trong SettingFragment

Mục tiêu

Soft paywall (user chủ động mua)
Upsell nhẹ, không làm gián đoạn trải nghiệm
Cho phép quản lý subscription sau khi mua

Inject dependency

private val paywallRepository: PaywallRepository by inject()
private val launcher: PaywallLauncher by inject()

Hiển thị Subscribe CTA theo config & trạng thái mua

ctlSub.isVisible =
    paywallRepository
        .getPaywallData(Constants.PaywallConfigKey.PAYWALL_SETTING)
        ?.enable == true

txtSubDes.text = if (paywallRepository.isPurchased()) {
    getString(R.string.unlocked_all_features)
} else {
    getString(R.string.upgrade_to_unlock_all)
}

Manage Subscription (chỉ khi là subscription)

ctlManageSubscription.isVisible =
    paywallRepository.isPurchased() &&
    paywallRepository.getCurrentPackagePurchased()?.type != PandaPackageType.LIFETIME

📌 Lifetime không cần manage → UX chuẩn Play Store

Click Subscribe → Mở Paywall bằng Launcher

ctlSub.setOnClickListener {
    lifecycleScope.launch {
        val activity = activity ?: return@launch

        when (
            launcher.launch(
                activity,
                Constants.PaywallConfigKey.PAYWALL_SETTING
            )
        ) {
            PaywallResult.Success -> {
                ctlManageSubscription.isVisible =
                    paywallRepository.isPurchased() &&
                    paywallRepository.getCurrentPackagePurchased()?.type != PandaPackageType.LIFETIME

                txtSubDes.text = getString(R.string.unlocked_all_features)

                NativeAdManager.disableAllAds()
                InterManager.disableAllAds()
                RewardAdsManager.disableAllAds()
                BannerAdManager.disableAllAds()
                PandaResumeAd.INSTANCE?.disableAllAds()
            }

            PaywallResult.Dismissed -> {
                // User đóng paywall
            }

            PaywallResult.NotShown -> {
                // Đã mua hoặc chưa đủ điều kiện show
            }
        }
    }
}

Flow tổng quát

Setting Screen
   ↓
Subscribe CTA
   ↓ click
PaywallLauncher
   ↓
┌───────────────┬───────────────┬───────────────┐
│ Success       │ Dismissed     │ NotShown      │
│ Disable ads   │ Log event     │ Continue app  │
│ Update UI     │               │               │
└───────────────┴───────────────┴───────────────┘

Best Practices cho Setting Paywall

✅ Soft paywall, không ép

✅ Không show paywall nếu enable = false

✅ Lifetime ≠ manage subscription

✅ Disable ads chỉ khi Success

✅ Update UI ngay, không reload màn hình

⚡ Jetpack Compose Performance: Macrobenchmark & Baseline Profile

ViO Tech — Fri, 02 Jan 2026 14:58:31 +0000

A production-grade guide to measuring, optimizing, and locking in Jetpack Compose performance using Macrobenchmark and Baseline Profiles.

🎯 Why Macrobenchmark & Baseline Profile matter (especially for Compose)

Jetpack Compose performance problems often do not show up in debug builds.

In production, users experience:

Janky scroll
Slow cold start
Frame drops after navigation

Two tools solve this systematically:

Tool	Purpose
Macrobenchmark	Measure real performance (startup, scroll, animation)
Baseline Profile	Make release builds fast from first launch

If you use Compose without these, you are flying blind.

1️⃣ Macrobenchmark – Measuring Real User Performance

🧠 What Macrobenchmark actually measures

Macrobenchmark runs your real app APK in a realistic environment:

Release build
No debugger
No Compose tooling

You measure:

App startup (cold / warm / hot)
Frame timing (jank)
Scroll performance
Navigation cost

🧱 Setup Macrobenchmark module

./gradlew :macrobenchmark:connectedCheck

build.gradle (macrobenchmark module)

android {
    compileSdk = 34

    defaultConfig {
        minSdk = 24
        targetSdk = 34
        testInstrumentationRunner =
            "androidx.benchmark.junit4.AndroidBenchmarkRunner"
    }
}

dependencies {
    implementation("androidx.benchmark:benchmark-macro-junit4:1.2.4")
}

🚀 Startup benchmark example

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun coldStartup() = benchmarkRule.measureRepeated(
        packageName = "com.vio.app",
        metrics = listOf(StartupTimingMetric()),
        iterations = 10,
        startupMode = StartupMode.COLD
    ) {
        pressHome()
        startActivityAndWait()
    }
}

📌 Compose-specific insight:

Large Composables during initial composition = slower cold start
Heavy remember logic also counts

📉 Frame timing benchmark (scroll)

@Test
fun scrollRecordingList() = benchmarkRule.measureRepeated(
    packageName = "com.vio.app",
    metrics = listOf(FrameTimingMetric()),
    iterations = 5
) {
    startActivityAndWait()

    device.findObject(By.res("recording_list"))
        .fling(Direction.DOWN)
}

✔ Detects:

Jank > 16ms
Layout thrashing
Excessive recomposition during scroll

2️⃣ Reading Macrobenchmark Results (What Actually Matters)

🔍 Key metrics

Metric	What to watch
startupMs	Cold start regression
frameDurationCpuMs	CPU bottlenecks
frameOverrunMs	UI jank

📌 Rule of thumb:

> 5% janky frames → user-visible

3️⃣ Baseline Profile – Making Compose Fast on First Launch

🧠 What is Baseline Profile?

Baseline Profile tells ART:

"Compile these code paths ahead of time."

Without it:

Compose code interpreted
JIT kicks in late
First launch = slow

With it:

AOT compilation
Fast startup from launch #1

🧱 Setup Baseline Profile module

dependencies {
    implementation("androidx.profileinstaller:profileinstaller:1.3.1")
}

Create baselineprofile module.

🧪 Generate Baseline Profile

@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {

    @get:Rule
    val rule = BaselineProfileRule()

    @Test
    fun generate() = rule.collect(
        packageName = "com.vio.app"
    ) {
        pressHome()
        startActivityAndWait()

        // Navigate critical paths
        device.findObject(By.res("recording_list"))
        device.findObject(By.res("recording_item_0")).click()
    }
}

✔ This captures:

Initial composition
Navigation
Scroll

📦 Applying Baseline Profile

./gradlew :baselineprofile:assembleRelease

Profile is packaged into APK → applied automatically on install.

4️⃣ Compose-specific Best Practices for Baseline Profiles

✅ What to include

App start
First screen composition
Navigation graph
Lazy list scroll

❌ What NOT to include

Rare flows
Debug-only screens
Feature flags off by default

5️⃣ Macrobenchmark + Baseline Profile Workflow

Write benchmark → measure baseline
↓
Optimize Compose
↓
Regenerate Baseline Profile
↓
Lock performance in CI

📌 Golden rule:

Every performance fix should come with a benchmark.

6️⃣ Common Compose Performance Traps (Seen in Benchmarks)

Trap	Symptom
Reading Flow at root	Startup slow
Missing Lazy keys	Scroll jank
Animation in composition	Frame drops
Unstable lambdas	Layout thrash

Macrobenchmark exposes all of them.

7️⃣ Before / After Numbers – Real Impact

📊 Case study (realistic production scenario)

Metric	Before	After Macrobenchmark + Baseline Profile
Cold start (P50)	820 ms	420 ms (-48%)
Cold start (P90)	1,200 ms	620 ms
Janky frames (scroll)	12–15%	2.1%
First navigation	180 ms	70 ms

📌 Key takeaway:

Most gains come from Baseline Profile on first launch, not micro-optimizations.

8️⃣ CI: Fail the Build on Performance Regression

🎯 Goal

Make performance non-negotiable.

🧪 Step 1: Export benchmark results

benchmarkRule.measureRepeated(
    ...
) {
    // metrics automatically exported as JSON
}

Results live under:

/benchmark-results/

🧪 Step 2: Define thresholds

{
  "coldStartMs": 500,
  "jankPercent": 5
}

🧪 Step 3: CI assertion (example)

if [ "$COLD_START" -gt "500" ]; then
  echo "❌ Cold start regression detected"
  exit 1
fi

✔ Result: PR fails if performance regresses.

9️⃣ Follow-up: Why My Compose App Was Slow Without Baseline Profile

🚨 Symptoms

First launch slow
Second launch magically fast
No obvious bottlenecks in profiler

🧠 Root cause

Without Baseline Profile:

Compose runtime interpreted
No AOT compilation
JIT warms up too late

📌 This affects every user, not just low-end devices.

✅ Fix

Add Baseline Profile
Capture startup + navigation paths
Ship profile with release

Result:

Performance fixed without touching UI code.

🔟 Open-source: Compose Benchmark Template Repo

📦 What the template includes

Macrobenchmark module
Baseline Profile module
Startup & scroll benchmarks
CI-ready scripts

📁 Repo structure

app/
macrobenchmark/
baselineprofile/
ci/

🚀 How to use

Clone repo
Rename package
Adjust benchmarks
Run CI

📌 Perfect starting point for any Compose app.

🧠 Final Mental Model

Macrobenchmark shows the truth. Baseline Profile locks the win. CI keeps it that way.

Compose performance is not about hope — it is about measurement.

✅ Ultimate Checklist

🔲 Benchmarked cold & warm startup
🔲 Measured scroll jank
🔲 Baseline Profile generated
🔲 CI guards regressions
🔲 Numbers documented

If you want:

📦 I can generate the actual GitHub template repo
📊 Add charts for dev.to
🧪 Write a CI-ready GitHub Action

👉 Just say the word 🚀

🚀 Jetpack Compose Performance Audit

ViO Tech — Fri, 02 Jan 2026 14:51:07 +0000

A practical, production-ready guide to auditing Jetpack Compose performance — from checklists, automated tests for excessive recompositions, real screen analysis, to a clear comparison with View-based performance traps.

🎯 Why this article?

Jetpack Compose is declarative, but performance problems don’t disappear — they just change shape.

In real production apps, most Compose performance issues come from:

Excessive recompositions
Wrong state boundaries
Unstable objects & lambdas
Animations running in the wrong phase

This article gives you:

✅ A Compose performance audit checklist
✅ A real automated test to catch excessive recompositions
✅ A step-by-step analysis of a Compose screen
✅ A Compose vs View performance comparison with concrete examples & tests

1️⃣ Performance Audit Checklist for Jetpack Compose

Use this checklist whenever you review a Compose screen or PR.

🧠 A. Composition & Recomposition

✔ Are states read at the lowest possible composable?

❌ Anti-pattern:

@Composable
fun Screen(vm: VM) {
    val state by vm.state.collectAsState()
    List(state.items)
}

✔ Better:

items(state.items, key = { it.id }) {
    Item(it)
}

✔ Checklist:

No frequently-changing state read at screen root
Use derivedStateOf for computed values
Composables recompose only when their inputs change

🧠 B. Object Allocation

✔ Are objects created inside composition?

❌ Anti-pattern:

Brush.linearGradient(colors)

✔ Fix:

val brush = remember { Brush.linearGradient(colors) }

✔ Checklist:

Brush, Shape, TextStyle, Path, Outline are remembered
Prefer drawBehind for purely visual effects

🧠 C. Stability

✔ Are your models stable?

@Immutable
data class UiItem(
    val id: String,
    val title: String
)

✔ Checklist:

@Immutable / @Stable used where applicable
Avoid MutableList, MutableMap in UI models

🧠 D. Lazy Layouts

✔ Are keys provided?

items(items, key = { it.id }) { ... }

✔ Checklist:

No index-based keys
Item-level state isolated

🧠 E. Animations

✔ Where does the animation run?

Animation type	Correct phase
Layout change	Composition
Visual only	Draw / graphicsLayer

✔ Checklist:

No animate*AsState driving layout unintentionally
Use graphicsLayer for translations, alpha, scale

2️⃣ Demo: Automated Test to Catch Excessive Recompositions

🎯 Goal

Turn recomposition behavior into something testable & enforceable.

Step 1: Create a recomposition counter modifier

val RecomposeCountKey = SemanticsPropertyKey<Int>("RecomposeCount")
var SemanticsPropertyReceiver.recomposeCount by RecomposeCountKey

fun Modifier.trackRecompositions(): Modifier = composed {
    var count by remember { mutableStateOf(0) }

    SideEffect { count++ }

    semantics {
        recomposeCount = count
    }
}

Step 2: Use it in your composable

@Composable
fun ProfileCard(user: User) {
    Box(
        modifier = Modifier.trackRecompositions()
    ) {
        Text(user.name)
    }
}

Step 3: Write a Compose UI test

@Test
fun profileCard_shouldNotRecomposeExcessively() {
    composeRule.setContent {
        ProfileCard(User("1", "Vio"))
    }

    composeRule.waitForIdle()

    val count = composeRule
        .onNode(hasAnyAncestor(isRoot()))
        .fetchSemanticsNode()
        .config[RecomposeCountKey]

    assertThat(count).isLessThan(3)
}

✔ This test fails automatically if someone introduces excessive recompositions later.

3️⃣ Real-world Analysis: A Compose Screen

📱 Example: Recording List Screen

@Composable
fun RecordingScreen(vm: RecordingVM) {
    val state by vm.state.collectAsState()

    LazyColumn {
        items(state.records) {
            RecordingItem(it)
        }
    }
}

❌ Problems

Entire list recomposes on any state change
No item keys
RecordingItem recreated unnecessarily

✅ Refactored Version

@Composable
fun RecordingScreen(vm: RecordingVM) {
    val records by vm.records.collectAsState()

    LazyColumn {
        items(
            items = records,
            key = { it.id }
        ) {
            RecordingItem(it)
        }
    }
}

🎯 Result

Only changed items recompose
Scroll remains smooth
Predictable performance

4️⃣ Compose vs View Performance Traps

🔴 Trap #1: "Compose is slower than Views"

❌ Wrong comparison:

Unoptimized Compose vs optimized RecyclerView

✔ Fair comparison:

Stable models
Keys
Proper state scoping

🔴 Trap #2: Frequent invalidation

View system

view.invalidate() // redraw only

Compose equivalent

Modifier.drawBehind { }

❌ Bad Compose equivalent:

mutableStateOf(x++) // triggers recomposition

🔴 Trap #3: Measuring everything again

System	Cost
View	`requestLayout()` expensive
Compose	Layout skipped if inputs stable

✔ Compose wins if stability is respected.

5️⃣ How to Test Performance (Compose & View)

🧪 Tools

Layout Inspector (Recomposition Count)
Recomposition Highlighter
Macrobenchmark

📊 Macrobenchmark example

measureRepeated(
    packageName = "com.vio.app",
    metrics = listOf(FrameTimingMetric()),
    iterations = 5
) {
    startActivityAndWait()
}

🧠 Final Mental Model

Compose performance = state boundaries + stability + correct phase (composition vs draw)

If you control those three, Compose is:

Faster than Views
More predictable
Easier to test

✅ TL;DR Checklist

🔲 No unnecessary recompositions
🔲 Stable models & lambdas
🔲 Keys everywhere in Lazy layouts
🔲 Animations in draw phase when possible
🔲 Performance covered by tests

If you want:

🔍 A performance audit template for your app
🧪 A ready-to-use testing module
🧠 A deep dive into Compose internals (slot table, skipping, groups)

👉 Let me know — happy to go deeper 🚀

Android Session Tracking — A Senior Engineer’s Perspective: When the OS Promises You Nothing

ViO Tech — Tue, 30 Dec 2025 15:09:40 +0000

Android makes no promise about telling you when a user leaves your app.
Yet analytics, ads, and business logic are forced to assume such a thing exists.

This article is not about tricks. It is about thinking correctly about session tracking on Android — at production and SDK level.

1. The real problem is not APIs — it’s illusion

Most Android developers have believed at least one of these at some point:

onStop() means the user left
onDestroy() means the app ended
Swiping from Recents ends a session

All of these are fundamentally wrong.

Android does not run apps for you.
Android runs itself. Your app is a guest.

2. OS truths senior engineers must accept

Processes can be killed without callbacks
SIGKILL / LMK offer zero cleanup guarantees
Lifecycle events only exist while the process is alive

In other words:

If you are waiting for a callback to detect session end,
you already lost — conceptually.

3. How real SDKs actually work

Firebase, AdMob, Adjust, AppsFlyer do not “detect kills”.

They do three things:

Track process foreground / background
Apply timeout heuristics
Infer session end on the next launch

No events. No guarantees. Only probabilistic modeling.

This is senior thinking: accept uncertainty and design around it.

4. A session is not an event — it’s a state machine

A real session has states:

Created
Active
Background
Expired
Restored (inferred)

A session does not end when the app dies.
It ends when we decide it is no longer valid.

That decision is based on:

Background duration
Next launch timing
Persisted metadata

5. ProcessLifecycleOwner: the right tool, not a magic one

ProcessLifecycleOwner gives you:

ON_START: process enters foreground
ON_STOP: process goes to background

It does not give you:

App kill
Swipe from Recents
Native crashes

And it shouldn’t.

Senior engineers do not demand APIs do the impossible.

6. Timeout is not a workaround — it’s a definition

Timeout is not a hack.

Timeout is a business rule:

“If the user stays away longer than X ms, the session is considered ended.”

30 seconds? 1 minute? 5 minutes?

There is no correct value — only product-appropriate ones.

7. App kill: no callback, only traces

When the app is killed:

No onSessionEnd
No cleanup
No flush

What remains:

Last background timestamp
Session ID
Inferred reason

On the next launch, the SDK must:

Load persisted state
Infer the previous session ended
Emit a logical session end

This is a two-phase design — familiar to senior engineers.

8. Exit reasons: be honest, not confident

Exit reasons should be modeled as:

USER_BACKGROUND_TIMEOUT
PROCESS_KILLED_INFERRED
APP_UPGRADE
CRASH_DETECTED

The key word is inferred.

Good SDKs do not say “the user did X”.
They say “based on evidence, we infer X”.

9. Why this module is testable — and why that matters

If session tracking:

depends on Activities
relies on system callbacks
depends on real time

→ it is not testable, and therefore not trustworthy.

A proper SessionTracker:

is pure logic
injects its clock
fakes lifecycle signals

Testable means understandable.
Understandable means reliable.

10. How to use the Session Tracking SDK

The theory matters. Now the practice.

This SDK is designed to:

avoid Activity dependencies
never crash on process kill
never block the main thread

10.1 Initialize in Application

The SDK must be initialized in Application.onCreate().

class App : Application() {

    private lateinit var sessionObserver: AndroidSessionObserver

    override fun onCreate() {
        super.onCreate()

        sessionObserver = AndroidSessionObserver(
            context = this,
            timeoutMs = 30_000L,
            callback = object : SessionTracker.Callback {
                override fun onSessionStart(session: Session) {
                    // analytics / ads init
                }

                override fun onSessionEnd(
                    session: Session,
                    reason: ExitReason
                ) {
                    // flush analytics / revenue sync
                }
            }
        )

        ProcessLifecycleOwner.get()
            .lifecycle
            .addObserver(sessionObserver)
    }
}

Key points:

No Activity lifecycle usage
No UI references
Callbacks may never fire if the app is killed

The SDK is designed with this assumption.

10.2 What happens when the app is killed?

No callback is invoked.

Instead, the SDK:

persists session state on background
stores timestamp and session ID

On the next launch, it:

restores previous state
infers the session ended
emits ExitReason.PROCESS_KILLED_INFERRED

This behavior is intentional.

10.3 Interpreting ExitReason correctly

Exit reasons are not absolute truth.

Examples:

USER_BACKGROUND_TIMEOUT → time-based evidence
PROCESS_KILLED_INFERRED → missing resume inference

Analytics and backend systems must treat these as inferred data.

The SDK does not hide this.

10.4 Unit testing: why you should trust this SDK

All session logic:

is framework-independent
injects time
is fully testable

Example:

@Test
fun `session ends after timeout`() {
    val fakeClock = FakeClock()
    val tracker = SessionTracker(fakeClock, timeoutMs = 30_000)

    tracker.onForeground()
    fakeClock.advance(31_000)
    tracker.onForeground()

    assertTrue(tracker.lastExitReason is ExitReason.Timeout)
}

Testable logic produces deterministic behavior.

11. Full source code

The complete SDK, including:

Pure SessionTracker logic
AndroidSessionObserver
ExitReason model
Unit tests

is available on GitHub:

🔗 https://github.com/vinhvox/ViO---Android-Session-Tracker

This repository is designed to:

read like documentation
be copy-paste friendly
and, most importantly, not pretend Android is controllable

12. Final words for senior engineers

Session tracking on Android is never perfect.

Good SDKs do not hide that.
They:

state their limits clearly
model uncertainty explicitly
help the business make correct, not just pretty, decisions

Android does not give you absolute truth.
But it gives enough signals to infer — if you design correctly.

Building a Modern Android UI Stack with Jetpack Compose (Senior Guide

ViO Tech — Tue, 30 Dec 2025 14:17:43 +0000

A practical, scalable, and testable UI architecture using

Jetpack Compose + Navigation 3 + MVVM + MVI + Koin + Ktor + Room

🎯 Goal

This article presents a production-ready UI stack for modern Android apps, focusing on:

Predictable state management
Navigation as state (Navigation 3)
Performance & recomposition safety
Scalability for large teams
High testability
Fast feature development

This is not a beginner tutorial — it’s a Senior-level playbook.

🧱 Tech Stack (Final Choice)

Layer	Technology
UI	Jetpack Compose
Navigation	Navigation 3 (State-driven)
Architecture	MVVM + MVI hybrid
DI	Koin
Networking	Ktor
Local Storage	Room
Async	Coroutines + Flow

🧠 Core Philosophy

1️⃣ UI is a pure function of State

2️⃣ Navigation is State

3️⃣ ViewModel never knows UI or Navigation

4️⃣ Side-effects are explicit

5️⃣ Everything must be testable without Android runtime

📦 Project Structure

feature-home/
├── HomeContract.kt
├── HomeViewModel.kt
├── HomeRoute.kt
├── HomeScreen.kt

🧭 Navigation 3 – Navigation as State

Define Screens

@Immutable
sealed interface Screen {
    object Home : Screen
    data class Detail(val id: String) : Screen
}

BackStack as State

val backStack = rememberSaveable {
    mutableStateListOf<Screen>(Screen.Home)
}

Navigate → add(Screen)
Back → removeLast()
No NavController.
No NavGraph.
Just state.

🧭 AppNavigationHost

@Composable
fun AppNavigationHost(
    backStack: List<Screen>,
    onNavigate: (Screen) -> Unit,
    onBack: () -> Unit
) {
    when (val screen = backStack.last()) {
        Screen.Home -> HomeRoute(
            onNavigateDetail = { onNavigate(Screen.Detail(it)) }
        )

        is Screen.Detail -> DetailRoute(
            id = screen.id,
            onBack = onBack
        )
    }
}

✔ Explicit
✔ Testable
✔ No magic

🧩 MVVM + MVI Hybrid
Contract

data class State(
    val items: List<String> = emptyList(),
    val loading: Boolean = false
)

sealed interface Event {
    object Load : Event
    data class ItemClicked(val id: String) : Event
}

sealed interface Effect {
    data class NavigateDetail(val id: String) : Effect
}

🧠 ViewModel (Pure Logic)

class HomeViewModel(
    private val repo: ItemRepository
) : ViewModel() {

    private val _state = MutableStateFlow(State())
    val state: StateFlow<State> = _state

    private val _effect = Channel<Effect>()
    val effect = _effect.receiveAsFlow()

    fun onEvent(event: Event) {
        when (event) {
            Event.Load -> loadItems()
            is Event.ItemClicked ->
                sendEffect(Effect.NavigateDetail(event.id))
        }
    }

    private fun loadItems() {
        viewModelScope.launch {
            _state.update { it.copy(loading = true) }
            val items = repo.getItems()
            _state.update { it.copy(items = items, loading = false) }
        }
    }

    private fun sendEffect(effect: Effect) {
        viewModelScope.launch { _effect.send(effect) }
    }
}

❌ No Compose
❌ No Navigation
✅ 100% testable

🧩 Route – Glue Layer

@Composable
fun HomeRoute(
    onNavigateDetail: (String) -> Unit,
    vm: HomeViewModel = koinViewModel()
) {
    val state by vm.state.collectAsStateWithLifecycle()

    LaunchedEffect(Unit) {
        vm.effect.collect { effect ->
            when (effect) {
                is Effect.NavigateDetail ->
                    onNavigateDetail(effect.id)
            }
        }
    }

    HomeScreen(
        state = state,
        onEvent = vm::onEvent
    )
}

📌 Only place where:

Flow is collected

Navigation happens

🎨 Screen – Pure UI

@Composable
fun HomeScreen(
    state: State,
    onEvent: (Event) -> Unit
) {
    LazyColumn {
        items(
            items = state.items,
            key = { it }
        ) { item ->
            Text(
                text = item,
                modifier = Modifier.clickable {
                    onEvent(Event.ItemClicked(item))
                }
            )
        }
    }
}

✔ Stateless
✔ Previewable
✔ Reusable

🧬 Dependency Injection – Koin
Why Koin?

No code generation
No annotation processing
Fast build time
Compose-friendly
Easy to reason about in large teams

DI should not be the hardest part of your architecture.

*App Module
*

val appModule = module {

    // Network
    single { provideHttpClient() }
    single { ApiService(get()) }

    // Database
    single { AppDatabase.create(androidContext()) }
    single { get<AppDatabase>().itemDao() }

    // Repository
    single<ItemRepository> {
        ItemRepositoryImpl(
            api = get(),
            dao = get()
        )
    }
}

Feature Module

val homeModule = module {
    viewModel { HomeViewModel(get()) }
}

📌 ViewModels depend on interfaces only

🌐 Networking – Ktor

HttpClient Setup

fun provideHttpClient(): HttpClient =
    HttpClient(Android) {

        install(ContentNegotiation) {
            json(Json {
                ignoreUnknownKeys = true
                explicitNulls = false
            })
        }

        install(Logging) {
            level = LogLevel.BODY
        }

        install(HttpTimeout) {
            requestTimeoutMillis = 15_000
            connectTimeoutMillis = 15_000
        }

        defaultRequest {
            contentType(ContentType.Application.Json)
        }
    }

📌 Configure everything in one place.

ApiService

class ApiService(
    private val client: HttpClient
) {
    suspend fun getItems(): List<String> =
        client.get("/items").body()
}

🗄 Local Storage – Room

Entity

@Entity(tableName = "items")
data class ItemEntity(
    @PrimaryKey val id: String
)

DAO

@Dao
interface ItemDao {

    @Query("SELECT * FROM items")
    suspend fun getAll(): List<ItemEntity>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertAll(items: List<ItemEntity>)
}

Database

@Database(
    entities = [ItemEntity::class],
    version = 1
)
abstract class AppDatabase : RoomDatabase() {

    abstract fun itemDao(): ItemDao

    companion object {
        fun create(context: Context): AppDatabase =
            Room.databaseBuilder(
                context,
                AppDatabase::class.java,
                "app.db"
            ).build()
    }
}

🔁 Repository (Single Source of Truth)

interface ItemRepository {
    suspend fun getItems(): List<String>
}

class ItemRepositoryImpl(
    private val api: ApiService,
    private val dao: ItemDao
) : ItemRepository {

    override suspend fun getItems(): List<String> {
        val remote = api.getItems()
        dao.insertAll(remote.map { ItemEntity(it) })
        return remote
    }
}

📌 ViewModel never knows:

Remote or local source
Caching logic
Mapping rules

⚡ Performance Guidelines

Use @Immutable for state & screen
Use derivedStateOf for UI-only logic
Key every LazyColumn item
Collect Flow only in Route

DON'T

Create objects in Composable body
Collect Flow inside list items
Put ViewModel in Screen
Navigate from ViewModel

🧪 Testing Example

@Test
fun click_item_emit_navigation_effect() = runTest {
    val vm = HomeViewModel(fakeRepo)
    vm.onEvent(Event.ItemClicked("1"))

    assertEquals(
        Effect.NavigateDetail("1"),
        vm.effect.first()
    )
}

🏁 Final Thoughts

This stack provides:

✅ Predictable state
✅ Navigation without magic
✅ Excellent testability
✅ High performance
✅ Scales well for large team

Jetpack Compose + Navigation 3 + MVI is the future-ready Android UI architecture.

Jetpack Compose Performance – System Trace, Recomposer, and the Truth About Frames

ViO Tech — Wed, 17 Dec 2025 19:26:57 +0000

Jetpack Compose Performance – System Trace, Recomposer, and the Truth About Frames

Jetpack Compose did not eliminate performance problems.

It changed their shape.

Apps no longer suffer from deep view hierarchies,

but they now suffer from:

uncontrolled recomposition,
expensive state propagation,
missed frame deadlines hidden behind “low CPU usage”.

This article explains how Compose performance truly behaves at runtime, using System Trace as the source of truth.

Frames Are the Only Currency Users Care About

Users do not experience:

recompositions,
allocations,
CPU percentages.

They experience frames.

Every frame has:

a deadline (~16.6 ms at 60 Hz),
a strict schedule,
zero tolerance for excuses.

Miss the deadline, and users feel it immediately.

The Rendering Pipeline (Compose Edition)

Before profiling Compose, you must understand the pipeline:

VSYNC arrives
Choreographer schedules a frame
Compose recomposes (if needed)
applyChanges updates the UI tree
RenderThread submits GPU commands

Profiler data only makes sense inside this sequence.

System Trace: The Only Place Where Frames Exist

CPU Profiler tells you what ran.

System Trace tells you when frames were missed.

📸 Figure 8 – System Trace: Compose Frame Lifecycle

(Insert image here)

Android System Trace showing the full Compose frame lifecycle from VSYNC through recomposition and rendering.

Annotations (number these on the image):

VSYNC – frame start signal
Choreographer#doFrame – scheduling phase
Recomposer.runRecomposeAndApplyChanges
applyChanges duration
RenderThread execution

Critical insight:

If applyChanges misses the deadline, no optimization elsewhere matters.

Recomposer: Friend, Not Foe

Recomposition is cheap by design.

What hurts performance is what you do during recomposition.

📸 Figure 9 – Recomposer Activity in System Trace

(Insert image here)

System Trace highlighting Recomposer activity and applyChanges duration impacting frame rendering.

Annotations:

Recomposer scheduling
Long applyChanges blocks
Back-to-back recompositions

Senior insight:

Frequent recomposition is fine.

Expensive recomposition is fatal.

SnapshotStateObserver: The Messenger You Blame

When Compose state is read, SnapshotStateObserver tracks it.

When performance is bad, it shows up everywhere.

That does not make it the villain.

📸 Figure 10 – SnapshotStateObserver Hotspots

(Insert image here)

CPU flame chart showing SnapshotStateObserver overhead caused by inefficient state reads in Jetpack Compose.

Annotations:

SnapshotStateObserver dominating CPU time
recordReadOf in hot paths
State read at the wrong composable scope

Root cause:

One state change invalidates too much UI.

Skipped Frames: When Users Feel Jank Before Logs Do

Profiler only flags severe jank.

Users feel:

uneven pacing,
subtle stutters,
animation inconsistency.

These appear as VSYNC gaps.

📸 Figure 11 – Skipped Frames via VSYNC Gaps

(Insert image here)

System Trace revealing skipped frames through large gaps between VSYNC signals during animations.

Annotations:

Large VSYNC gaps
Frame duration exceeding deadline
Idle RenderThread waiting for Main thread

Reality check:

Smoothness is statistical, not binary.

Why “Low CPU Usage” Means Nothing in Compose

Compose work often:

runs in short bursts,
blocks at terrible moments,
hides behind averages.

A 4 ms stall at the wrong time breaks a frame.

CPU charts will not scream.

System Trace will.

Pre-Release Compose Performance Checklist

Before shipping a Compose-heavy screen:

Recomposition is scoped and intentional
applyChanges consistently finishes within frame budget
No large VSYNC gaps during scroll or animation
SnapshotStateObserver does not dominate hot paths

If any of these fail, users will notice.

What This Part Ties Together

Part 1 explained threads and deadlines
Part 2 explained memory pressure
This part shows how everything collapses into frames

Frames are where all performance debts are paid.

Final Thought

Junior developers ask:

“Why is Compose recomposing so much?”

Senior developers ask:

“Which frame missed its deadline, and why?”

System Trace already knows.

You just need to listen.

Series Navigation

Part 1 – CPU & Thread Reality
Part 2 – Memory, GC, and Leaks
Part 3 – Compose, System Trace, and Frames ← you are here
Part 4 – Common Profiler Misreads

Android Profiler – Memory, GC, and Leaks That Slowly Kill Performance

ViO Tech — Wed, 17 Dec 2025 19:20:53 +0000

Android Profiler – Memory, GC, and Leaks That Slowly Kill Performance

Memory problems rarely crash your app.

They slow it down quietly, then surface as:

jank after minutes of usage,
ANRs that only happen on older devices,
“works fine after restart” reports.

This article explains how memory behavior becomes a performance bug—long before a crash ever happens.

GC Is Not Cleanup. It Is Damage Control.

Garbage Collection exists to prevent failure, not to guarantee performance.

If GC runs frequently, it means:

your app allocates too much,
the runtime is constantly recovering,
CPU time is stolen from frame rendering.

GC is the symptom. Allocation is the disease.

Memory Profiler Timeline: Trends Over Time Matter Most

One memory spike means nothing.

A memory trend tells the truth.

📸 Figure 5 – Memory Profiler Timeline

(Insert image here)

Android Memory Profiler timeline showing heap usage and garbage collection events to identify long-term memory growth.

Annotations (number these on the image):

Heap size growth over time
Garbage collection events
Memory failing to return to baseline

Senior insight:

If memory never stabilizes after GC, you do not have a spike.

You have a leak—or sustained allocation pressure.

Allocation Tracking: Where Performance Quietly Dies

Allocations feel harmless.

Until they happen inside:

scrolling,
animations,
repeated UI updates.

📸 Figure 6 – Allocation Tracking by Class

(Insert image here)

Memory allocation tracking grouped by class to reveal excessive object creation during UI interactions.

Annotations:

Frequently allocated classes
Allocations triggered by scroll or animation
Short-lived objects creating GC pressure

Reality check:

Small objects allocated frequently are worse than large objects allocated rarely.

GC and UI Jank: The Hidden Relationship

GC pauses are usually short.

But they:

interrupt Main thread work,
shift frame timing,
accumulate into visible jank.

A single GC pause might not hurt.

Repeated pauses always do.

Heap Dumps: When You Suspect a Leak, Prove It

Memory Profiler timelines suggest problems.

Heap dumps confirm them.

📸 Figure 7 – Heap Dump Dominator Tree

(Insert image here)

Heap dump dominator tree highlighting retained objects and reference chains responsible for memory leaks.

Annotations:

Activity instances still retained after destruction
Retained size dominating heap
Reference chain through singleton or static field

Senior rule:

Shallow size explains object weight.

Retained size explains damage.

Classic Leak Patterns That Survive Code Reviews

Leaks often look reasonable in isolation.

Common culprits:

Activities held by singletons,
listeners never unregistered,
callbacks capturing Context,
caches with no eviction strategy.

The leak is rarely where memory grows.

It is where references never die.

Memory Pressure Is a CPU Problem in Disguise

As memory pressure increases:

GC frequency increases,
CPU time is stolen,
frame deadlines are missed.

This is why memory bugs often show up as:

“The app feels slow after a while.”

It is not imagination.

It is physics.

Why “It Gets Fixed After Restart” Is a Red Flag

Restarting the app:

clears the heap,
resets allocation history,
hides the real bug.

If performance only recovers after restart,

you have not fixed the problem.

You have reset it.

What This Part Intentionally Did Not Cover

Thread scheduling
System Trace
Jetpack Compose recomposition

Those connect memory behavior to frame rendering.

They come next.

Final Thought

Junior developers ask:

“Why is memory high?”

Senior developers ask:

“Why does memory never come back down?”

Android Profiler already knows the answer.

You just need to read it over time.

Series Navigation

Part 1 – CPU & Thread Reality
Part 2 – Memory, GC, and Leaks ← you are here
Part 3 – Compose, System Trace, and Frames
Part 4 – Common Profiler Misreads

Android Profiler – CPU & Thread Reality Every Senior Developer Learns the Hard Way

ViO Tech — Wed, 17 Dec 2025 19:17:54 +0000

Android Profiler – CPU & Thread Reality Every Senior Developer Learns the Hard Way

Most Android performance bugs are not memory problems.

They are CPU and thread problems wearing a memory costume.

This article focuses on one thing only:

Why the UI feels slow, even when “nothing heavy” seems to be running.

No leaks.

No Compose deep dive yet.

Just threads, CPU time, and frame deadlines.

Why CPU Problems Are Subtle (and Dangerous)

CPU performance issues rarely look dramatic.

They appear as:

occasional stutter,
“only on some devices” lag,
ANRs that QA never reproduces.

The reason is simple:

UI performance lives at the scale of frames, not averages.

Android Profiler Overview: Read the Timeline First

Before diving into any chart, you must learn to read the timeline as a story.

📸 Figure 1 – Android Studio Profiler Overview

(Insert image here)

Android Studio Profiler overview showing real-time CPU, Memory, Network, and Energy timelines used to correlate performance with user actions.

Annotations (number these on the image):

Global timeline – select the suspicious time window
CPU usage track – spikes often align with UI jank
Memory track – useful for correlation, not conclusions
Event markers – anchor charts to user interactions

Key insight:

Profiler data without a user action context is meaningless.

CPU Profiler: Sampled vs Instrumented Is a Strategy Choice

Many developers treat CPU profiler modes as “accuracy levels”.

They are not.

They are different tools for different questions.

📸 Figure 2 – Sampled CPU Flame Chart

(Insert image here)

Sampled CPU flame chart visualizing method execution time and call stack hierarchy to identify performance bottlenecks.

Annotations:

Horizontal axis – wall-clock execution time
Vertical axis – call stack depth
Wide blocks on Main thread – UI lag suspects
Background threads – usually harmless unless synchronized

Senior rule:

Optimize wide blocks, not tall stacks.

📸 Figure 3 – Instrumented CPU Trace

(Insert image here)

Instrumented CPU trace showing precise method entry and exit timing for short, focused investigations.

Annotations:

Precise method boundaries
High tracing overhead
Best used on short interactions only

Reality check:

Instrumented tracing answers why, not how often.

The Main Thread Myth: “Nothing Heavy Is Running”

This sentence has killed more frame rates than any single bug.

The Main thread rarely dies from one big task.

It dies from:

many small allocations,
repeated view invalidations,
logging in hot paths,
synchronous callbacks.

Each one is cheap.

Together, they miss frame deadlines.

System Trace: Where the Truth Actually Lives

CPU charts tell you who is busy.

System Trace tells you when it matters.

📸 Figure 4 – System Trace: Main Thread, RenderThread, VSYNC

(Insert image here)

Android System Trace visualizing Main thread, RenderThread, and VSYNC signals to diagnose frame drops and UI jank.

Annotations:

VSYNC – frame heartbeat (16.6 ms)
Choreographer#doFrame – frame scheduling starts
Main thread – layout & draw preparation
RenderThread – GPU command submission
Large VSYNC gaps – skipped frames

Critical insight:

GPUs are rarely the first problem.

The CPU usually fails to feed frames on time.

Frame Deadlines: The Only Metric Users Feel

Users do not perceive CPU percentage.

They perceive:

missed frames,
uneven pacing,
delayed input response.

A single 20 ms stall is invisible on a CPU chart

and painfully obvious to a human hand.

Early Warning Signs of CPU Trouble

Before jank becomes obvious, you will often see:

Main thread slices creeping closer to VSYNC boundaries,
RenderThread idle while Main is late,
CPU usage that looks “fine” but poorly timed.

These are the moments seniors fix problems—

before users start complaining.

What This Part Intentionally Did Not Cover

Memory leaks
Garbage collection
Jetpack Compose internals

Those deserve their own mental models.

They come next.

Final Thought

Junior developers ask:

“Why is CPU usage high?”

Senior developers ask:

“Which thread missed the frame deadline?”

Android Profiler already knows the answer.

You just need to ask the right question.

Series Navigation

Part 1 – CPU & Thread Reality ← you are here
Part 2 – Memory, GC, and Leaks
Part 3 – Compose, System Trace, and Frames
Part 4 – Common Profiler Misreads

Android Profiler – Common Misreads That Lead to False Optimizations

ViO Tech — Wed, 17 Dec 2025 19:15:33 +0000

Android Profiler – Common Misreads That Lead to False Optimizations

Android Profiler does not lie.

But developers misread it constantly.

This article focuses on the most common profiler misinterpretations that lead to:

wasted optimization effort,
placebo performance fixes,
bugs that disappear in debug builds and return in production.

If Parts 1–3 explained how to read profiler data, this part explains how developers fool themselves while doing it.

Misread #1 – “CPU usage is low, so performance must be fine”

Low CPU usage is often a warning sign, not reassurance.

If the UI is janky while CPU usage looks calm, it usually means:

work is split into small bursts,
those bursts still block frame deadlines.

CPU charts average over time. Frames do not.

Correct mental model

UI performance lives at the 16.6 ms frame boundary.
A short stall at the wrong moment is enough to cause jank.

Misread #2 – “GC happened, so memory is under control”

Garbage Collection is not cleanup.

It is damage control.

Frequent GC means:

excessive allocation,
increased CPU pressure,
higher chance of dropped frames.

Red flag

Memory oscillates but never returns to baseline.
GC frequency increases during scroll or animation.

Fix allocation sources, not GC behavior.

Misread #3 – “This method is called a lot, so it must be slow”

Call count is seductive. Time is truth.

A method called 5,000 times at 0.01 ms is irrelevant.
A method called once at 12 ms kills a frame.

Profiler rule

Optimize by wall-clock time, not invocation count.

Wide blocks matter more than tall stacks.

Misread #4 – “Nothing heavy runs on the Main thread”

Nothing big runs.

That does not mean nothing harmful runs.

Main thread death usually comes from:

many small allocations,
repeated state reads,
layout thrashing,
logging inside hot paths.

Each operation is cheap.
Together, they miss deadlines.

Misread #5 – “Compose recomposes too much, so recomposition is the problem”

Recomposition is not the enemy.

Expensive recomposition is.

Common mistake:

count recompositions,
panic.

Correct questions:

How long does applyChanges take?
What work happens during recomposition?

Cheap recomposition is healthy.
Heavy recomposition is poison.

Misread #6 – “SnapshotStateObserver dominates CPU, so Compose is slow”

SnapshotStateObserver is a messenger.

It appears when:

state is read,
dependencies are tracked.

The real bug is usually:

state read at the wrong composable scope,
state shared too broadly.

One state change invalidates half the UI.

Misread #7 – “No skipped frames reported, so animations are smooth”

Profiler reports severe jank by default.

Users feel:

uneven pacing,
micro-stutters,
subtle animation inconsistency.

Profiler can stay silent.

Senior check

VSYNC spacing consistency
Frame durations flirting with deadlines
RenderThread idle gaps

Smoothness is statistical, not binary.

Misread #8 – “Benchmarks improved, so the issue is fixed”

Benchmarks lie politely.

Production lies creatively.

Performance depends on:

thermal state,
background services,
memory pressure,
real user behavior.

Rule

If it wasn’t verified with Profiler after the fix, it isn’t fixed.

Misread #9 – “Energy Profiler doesn’t matter for my app”

Energy issues manifest as:

thermal throttling,
CPU frequency drops,
delayed jank after minutes of use.

Ignoring energy means chasing ghosts later.

Energy problems are performance bugs with a timer.

Misread #10 – “Profiler will tell me what to optimize”

Profiler shows where reality happens.

It does not decide what matters.

That requires:

understanding frame deadlines,
knowing rendering pipelines,
recognizing allocation patterns,
correlating data with user perception.

Tools amplify understanding.
They do not replace it.

Final Thought

Junior developers ask:

“What should I optimize?”

Senior developers ask:

“What problem is the runtime actually experiencing?”

Android Profiler answers honestly.

Whether we read it honestly is the real skill.

Series Index

Part 1 – CPU & Thread Reality
Part 2 – Memory, GC, and Leaks
Part 3 – Compose, System Trace, and Frames
Part 4 – Common Profiler Misreads

Android Performance: Những thứ thật sự làm app chậm (và cách xử lý thực tế)

ViO Tech — Tue, 16 Dec 2025 15:45:27 +0000

1️⃣ Hiểu đúng về “Android Performance”

Rất nhiều bài viết nói về performance theo kiểu:

tránh object allocation
optimize code nhỏ lẻ

👉 Nhưng trong app thật, 80% vấn đề performance đến từ:

**Main Thread bị block
Memory leak
Startup quá nặng
UI rendering kém hiệu quả**

Nếu không đo được → tối ưu chỉ là đoán.

2️⃣ Main Thread – nguyên nhân số 1 gây lag & ANR

❌ Sai lầm phổ biến

Gọi API trên main thread
Parse JSON nặng trong ViewModel
Inflate layout phức tạp liên tục
Xử lý Ads / SDK trong onCreate ✅ Cách làm đúng (Kotlin)

viewModelScope.launch(Dispatchers.IO) {
    val data = repository.loadData()
    withContext(Dispatchers.Main) {
        _uiState.value = data
    }
}

📌 Nguyên tắc:

Main thread = render UI
Tất cả IO / computation → background

3️⃣ Startup Time – lý do user thoát app sớm

❌ Những thứ làm startup chậm

Init SDK quá sớm (Ads, Analytics)
Dùng ContentProvider không cần thiết
Inflate layout phức tạp ngay màn đầu

✅ Chiến lược tối ưu

Defer initialization
Lazy load SDK
Dùng SplashScreen API đúng cách

lifecycleScope.launch {
    delay(300)
    initAds()
}

👉 User thấy app mở nhanh hơn, dù logic vẫn load sau.

4️⃣ Memory Leak – app chạy lâu là sập

❌ Leak hay gặp

Context bị giữ trong singleton
Callback không unregister
Fragment reference trong Adapter

✅ Best practice

Không giữ Activity context
Dùng WeakReference khi cần
Clear reference trong onDestroyView

override fun onDestroyView() {
    super.onDestroyView()
    binding = null
}

📌 LeakCanary là tool bắt buộc ở production build nội bộ.

5️⃣ UI Performance: XML vs Compose

XML

❌ Layout lồng quá sâu
❌ RecyclerView không dùng DiffUtil

✅ Giải pháp:

ConstraintLayout
Flatten hierarchy
DiffUtil + ViewHolder chuẩn Compose

❌ Recomposition quá nhiều
❌ State đặt sai chỗ

✅ Giải pháp:

State hoisting
rememberSaveable
Tránh tạo object trong Composable

6️⃣ Ads & Performance – phần nhiều dev bỏ qua

Ads là nguồn gây lag rất phổ biến, nhất là:

Load Ads trên main thread
Show Ads khi UI chưa ổn định

✅ Best practice Ads

Preload Ads
Không init Ads trong Application.onCreate
Chỉ show Ads khi UI idle

if (ad.isLoaded && lifecycle.currentState.isAtLeast(Lifecycle.State.RESUMED)) {
    ad.show(activity)
}

7️⃣ Đo lường – không đo thì đừng tối ưu

Tool nên dùng

Android Profiler
Layout Inspector
Systrace / Perfetto
Firebase Performance

📌 Chỉ optimize khi thấy số liệu xấu

8️⃣ Checklist nhanh (dùng cho team)

Main thread không bị block
Startup < 2s
Không memory leak
UI scroll mượt
Ads không gây jank

9️⃣ Kết luận

Performance không phải là viết code “thông minh hơn”,
mà là viết code có ý thức về runtime.

This article is inspired by various Android performance discussions and my own production experience.