DEV Community: David Rufai

Yet Another Article on Media Streaming: Manifest parsing, Buffer management, Demuxing, Decoding.

David Rufai — Tue, 21 Jul 2026 00:49:43 +0000

Hey there! In Part 1 and Part 2, we covered the network side of streaming: why chunked delivery beats downloading, how manifests and ABR work, and how DRM protects content in transit. That's the "getting the bytes to the device" story.

This part picks up right where the bytes land. A segment has arrived on the device, encrypted or not, and now something has to turn it into pixels and sound coming out of your speakers within milliseconds. That's the playback pipeline, and it's where a lot of my day to day work as an Android engineer actually lives. I'll be leaning on Media3/ExoPlayer for the code examples since that's the stack I know best, but the concepts apply broadly to any modern player(AVFoundation/ShakaPlayer).

Here's the rough shape of what we're covering, in the order it actually happens:

Manifest → Segment Fetch → Buffer → Demux → Decode → Sync → Render

Let's Dive into them.

Manifest Parsing

Before anything can play, the player needs to know what it's dealing with, how many renditions exist, where the segments live, what codecs are in use, whether there's DRM involved. That's what the manifest (.m3u8 for HLS, .mpd for DASH) tells it.

Parsing this isn't just abount reading a file, the player builds an internal representation of the whole stream structure: available tracks (video, audio, subtitles), the rendition ladder for each, segment URLs or byte ranges, and timing information. In Media3, this is handled by a MediaSource for adaptive content specifically, HlsMediaSource or DashMediaSource.

val mediaItem = MediaItem.Builder()
    .setUri("https://example.com/stream.mpd")
    .setMimeType(MimeTypes.APPLICATION_MPD)
    .build()

val mediaSource = DashMediaSource.Factory(dataSourceFactory)
    .createMediaSource(mediaItem)

exoPlayer.setMediaSource(mediaSource)
exoPlayer.prepare()

That prepare() call is doing more than it looks like, under the hood, ExoPlayer fetches the manifest, parses it, and builds out the track structure before it can fetch a single video segment.

Segment Fetching

Once the player knows what's available, it needs to actually pull segments over the network and this is where the ABR decision from Part 2 gets executed in practice. For every segment, the player's track selector picks a rendition, and a DataSource fetches the corresponding chunk.

The Player prefetches chunks ahead of the playback position to keep the buffer healthy, and the LoadControl in ExoPlayer is what governs how aggressively that happens.

val loadControl = DefaultLoadControl.Builder()
    .setBufferDurationsMs(
        /* minBufferMs = */ 15_000,
        /* maxBufferMs = */ 50_000,
        /* bufferForPlaybackMs = */ 2_500,
        /* bufferForPlaybackAfterRebufferMs = */ 5_000
    )
    .build()

val exoPlayer = ExoPlayer.Builder(context)
    .setLoadControl(loadControl)
    .build()

bufferForPlaybackMs is worth calling out specifically as it's the minimum amount of buffered media required before playback starts at all, which is a direct trade off between "start playing fast" and "don't stall two seconds in."

Buffer Management

Fetched segments don't go straight to the decoder. They land in a buffer first, which exists for one reason: to absorb network variability so playback doesn't stall every time throughput dips for a moment.

The buffer isn't one undifferentiated pool, either. There's a distinction worth knowing:

Media buffer compressed segment data that's been downloaded but not yet decoded
Decoded/output buffer frames that have already been decoded and are waiting to be rendered

The minBufferMs/maxBufferMs values above are what keep the media buffer in a healthy range too little, and any network hiccup causes a stall; too much, and you're wasting memory and bandwidth on segments that might get abandoned anyway if the ABR algorithm decides to switch renditions.

Demuxing

Here's a term from Part 1 worth revisiting: a container (like an .mp4 or .ts segment) holds multiple streams bundled together — video, audio, sometimes subtitles. Before any of those can be decoded, they need to be pulled apart. That's demuxing (short for demultiplexing).

A demuxer reads the container format, identifies each embedded stream, and routes the compressed video frames to a video decoder and the compressed audio frames to an audio decoder, in parallel. This matters because video and audio are decoded completely independently at this stage they only get reunited later, at the sync stage.

In ExoPlayer, this is handled by an Extractor (there's one per container format — Mp4Extractor, TsExtractor, FragmentedMp4Extractor, and so on), and it's mostly invisible to us as developers unless you're working with a custom or unusual container format(we'll talk about this another article).

Decoding

This is where compressed data actually becomes raw, playable frames, and it's also the most hardware-dependent stage in the whole pipeline.

On Android, this is MediaCodec's job. Every device ships with a set of hardware decoders (fast, power-efficient, but fixed at the chip level) for common codecs like H.264/AVC and often H.265/HEVC. When a hardware decoder is available for the stream's codec, the player uses it.

val trackSelector = DefaultTrackSelector(context)
trackSelector.parameters = trackSelector.buildUponParameters()
    .setTunnelingEnabled(true)
    .build()

(Tunneling here lets the hardware decoder pipe decoded frames directly toward the display in supported cases, cutting out extra copies, a small optimization, but a good example of how much is happening below the API surface you normally touch.)

What happens when the device can't decode a codec?

This is worth its own section, because it's a real problem, not a theoretical edge case. Say your stream was encoded in AV1, but you're playing it on a mid-range device from a few years back with no AV1 hardware decoder. What now?

we've got a few options, roughly in order of preference:

Serve a different rendition. If the manifest includes a fallback codec (say, H.264 alongside AV1), the player can just pick a rendition it can actually decode. This is the cleanest fix and why most large platforms encode in multiple codecs, not just the newest/most efficient one.
Fall back to software decoding. Every codec also has a software decoder implementation that runs on the CPU instead of dedicated hardware. It works everywhere, but it's slower and burns significantly more battery fine for short clips, rough for a two-hour movie on a phone at 30% battery(faced a similar issue earlier in my career with FFmpeg).
Register a custom decoder extension. Media3 supports this directly, you can plug in a software codec implementation (Google publishes extensions for AV1 and others) that ExoPlayer will fall back to when no hardware decoder matches.

val renderersFactory = DefaultRenderersFactory(context)
    .setExtensionRendererMode(
        DefaultRenderersFactory.EXTENSION_RENDERER_MODE_ON
    )

val exoPlayer = ExoPlayer.Builder(context, renderersFactory).build()

Setting EXTENSION_RENDERER_MODE_ON tells ExoPlayer to consider extension decoders (like the AV1 software extension) as a fallback if the platform's built-in MediaCodec decoders can't handle the stream — it tries hardware/platform decoders first, and only falls back to the extension if nothing else works. There's also EXTENSION_RENDERER_MODE_PREFER, which flips that priority, though that's a less common choice since hardware decoding is almost always the better default.

This is a genuinely practical thing to get right: pick the wrong strategy and you either get playback failures on real devices in the field, or you get playback that "works" but tanks battery life and generates support tickets you can't easily explain.

Audio/Video Synchronization

Remember how demuxing split audio and video into separate decode paths? They now need to come back together — and this is trickier than it sounds, because audio and video decode at different rates and have different latency characteristics.

The mechanism that ties them back together is the presentation timestamp (PTS) every decoded frame, audio or video, carries a timestamp saying exactly when it should be presented to the viewer. The player picks one clock as the reference (almost always the audio clock, since audio glitches are far more noticeable to human ears than a dropped video frame) and continuously adjusts video rendering to match it — dropping a video frame if it's fallen behind, or holding one briefly if it's ahead.

This is also why you'll occasionally see a video frame get skipped entirely under heavy load rather than the whole playback stalling — the player is prioritizing staying in sync over rendering every single frame.

Rendering to the Screen

The final stage: decoded frames need to actually reach the display, and decoded audio needs to reach the speakers.

For video, decoded frames are typically handed off to a Surface — on Android, this is usually backed by a SurfaceView or TextureView, which composites with the rest of the UI and gets pushed to the display at the device's refresh rate. For audio, decoded PCM data goes to an AudioTrack, which queues it for playback through the device's audio pipeline.

playerView.player = exoPlayer

That one line is doing a lot of quiet work — PlayerView wires up the Surface the video renderer writes to, alongside playback controls, subtitle rendering, and the various render-state callbacks.

How ExoPlayer Orchestrates All of This

Pulling it together: ExoPlayer itself doesn't do the demuxing, decoding, or rendering directly. It's an orchestrator — it owns the playback timeline and state machine, and delegates the actual work to a set of collaborating components:

MediaSource manifest parsing and segment/track structure
LoadControl buffer thresholds and prefetch behavior
TrackSelector which rendition and codec to use, including ABR decisions
Renderer (one per track type, video, audio, text) demuxing, decoding, and rendering for that track
MediaClock the timing authority that keeps renderers in sync

Each Renderer runs its own decode loop, pulling samples from the MediaSource, feeding them to a decoder (MediaCodec or an extension), and pushing output toward the display or audio track all while checking in against the shared clock to stay synchronized.

If you take one thing away from this article, it's this: everything from "the video looks blurry for a second" to "the app crashed trying to play this file" traces back to one of these seven stages. Knowing which stage you're debugging is most of the battle when something goes wrong in a media player.

Wrapping Up

Quick recap:

Manifest parsing builds the player's internal picture of the stream — tracks, renditions, timing
Segment fetching executes ABR decisions and prefetches ahead to keep the buffer healthy
Buffering absorbs network variability so playback doesn't stall on every dip
Demuxing splits a container into independent audio and video streams
Decoding turns compressed data into raw frames — hardware-first, with software fallback or custom extensions when the device can't handle the codec natively
A/V sync uses presentation timestamps, anchored to the audio clock, to keep everything aligned
Rendering pushes decoded frames and audio to the screen and speakers
ExoPlayer orchestrates all of it through MediaSource, LoadControl, TrackSelector, and per-track Renderers, all checking in against a shared clock

That's the full pipeline from segment arrival to pixels on screen. In Part 4, I want to go deeper into a couple of these stages specifically — likely MediaCodec internals and buffer/memory management under real-world constraints, since those are the areas with the least beginner-friendly documentation out there.

This is Part 3 of a multi-part series on media streaming internals. Catch Part 1 and Part 2 here.

Introduction to media streaming: Bitrate, Resolution, ABR, & DRM

David Rufai — Sun, 12 Jul 2026 22:38:00 +0000

Hey there! Alright so in Part 1, we covered why streaming beats downloading, how chunked delivery and manifest files work together, and the difference between containers and codecs. If you haven't read that yet, it's probably worth a quick look before proceeding with this one, we'll be building directly on top of it.

Bitrate vs Resolution

Bitrate and resolution correlate to the amount of data in a media file, it's easy to mix these two up so let's clarify how they differ.

Resolution measures the detail in a single video frame by counting the pixels across its width and height. For instance, a 1920 by 1080 display is made up of 1,080 stacked rows, with each row stretching 1,920 pixels wide. More pixels means more detail, and then a bigger picture.

Bitrate, think of it as the amount of digital information your audio or video is allowed to use per second. Giving it more information to work with creates a crisper, more detailed, media experience, usually measured in kbps or Mbps. This is where the actual compression trade off lives.

The thing is you can't judge video quality by resolution by itself. A 1080p file can look terrible, blurry, pixelated, and washed out if it's encoded in a very low bitrate. On the flip side, a lower 720p resolution with a healthy bitrate can produce a much, cleaner image than a poorly compressed 1080p video.

There's another piece of the puzzle too: the codec being used. Remember from Part 1 that codecs are responsible for compressing and decompressing video. Newer codecs are simply better at squeezing the same visual quality into fewer bits.

For example, a video encoded with H.265 (HEVC) or AV1 can often look just as good as an older H.264 (AVC) stream while using significantly less bandwidth. In other words, two videos with exactly the same resolution and bitrate don't necessarily look identical, the codec plays a huge role in how efficiently those bits are used.

Now you must be thinking why not just use the highest bitrate for everything? Hmm...well because bitrate is directly tied to file size and bandwidth. A higher bitrate means more data has to be transmitted every second, which affects latency, and if the viewer's connection can't keep up, you get the thing nobody wants, buffering.

Just like the issue with downloading, adaptive bitrate streaming (ABR) was invented as the direct solution to, finding the perfect balance between great video quality and a viewer's internet speed.

Adaptive Bitrate Streaming (ABR)

Remember the manifest files we talked about in Part 1 .m3u8 for HLS, .mpd for DASH? This is where they truly prove their value.

Preparing video for streaming involves generating multiple encodings instead of a single output file, this strategy is vital because it allows the stream to work seamlessly on the massive, ever increasing variety of screens, devices and browsers available today. The media is processed into various resolutions, bitrate, and container combinations called renditions or variants, typically structured into a ladder such as:

240p @ 400 kbps
480p @ 1000 kbps
720p @ 2500 kbps
1080p @ 5000 kbps

All of these get chunked up, and the manifest lists every rendition as an option. The player is the one that decides, chunk by chunk, which rendition to pull next based on the device's current network speed, buffer health, and sometimes device screen size.

Have you ever noticed a video go blurry when your network drops, only to clear up a moment later? Well this isn't a bug in the player, to prevent the video from freezing up, The player immediately requests the next segment at a lower quality, as you watch, it measures your real-time download speed and automatically steps up to a clearer picture as soon as it’s confident your connection can handle it.

Let's make that a little more concrete.

Imagine you're watching a football match in 1080p over your home Wi-Fi. Everything looks sharp because the player has determined your connection can comfortably sustain that bitrate. Halfway through the match, someone in your house starts downloading a large game update. Suddenly, your available bandwidth drops.

The player notices that the next few video segments are taking longer to download than before. Rather than waiting until playback stalls, it proactively requests the next segment at 720p, or even 480p if necessary. The picture becomes a little softer, but the video keeps playing without interruption.

A few minutes later, the download finishes. Segment downloads become faster again, the player's confidence in the available bandwidth increases, and it gradually moves back up through higher quality renditions until you're watching in 1080p again all without restarting the stream or you having to do anything manually.

The paragraph above overly simplifies what happens under the hood with ABR. What is the player actually measuring, and how does it decide? We need to go a level deeper.

How ABR algorithms actually decide

Broadly, these algorithms fall into a few categories.

Throughput-based, which is the simplest approach: you measure how fast recent segments downloaded, estimate the device's available bandwidth from that, and then pick the highest rendition whose bitrate comfortably fits under that estimate. The catch is that throughput is rather unstable, an increase in latency on a single segment doesn't necessarily mean your connection became poor, it might just be a momentary dip, or an issue with the CDN serving that segment.

Switching too aggressively on every fluctuation and you get quality flapping, where the video visibly jumps between resolutions every few seconds, which is arguably worse for viewer experience than just staying at a slightly lower quality. Instead of panicking and reacting to a single slow download, most players use a moving average to smoothly track network speed, once that average confirms your connection is stable, the player then steps back up to a clearer quality.

Buffer-based. Instead of just staring at download speeds, this approach looks at the actual runway the player has left, the amount of segments currently sitting in the buffer. The logic is simple: if the buffer is healthy and growing, you can afford to take a risk and bump up the quality, but if the buffer starts shrinking toward empty, then the need to hit the brakes and drop to a lower resolution immediately, even if your download speed looks fine.

A viewer can tolerate a blurry video for a few seconds, but they absolutely hate it when the video freezes completely to reload. Because a frozen screen is the ultimate mood killer, real world video players are built to keep the video moving, even if it means dropping the quality for a bit.

Hybrid approaches. In practice, most modern players (ExoPlayer, AVFoundation, Shaka Player) combine both signals along with a few extras: device screen size, past switching history to avoid flapping, and sometimes prediction models trying to anticipate network drops before they happen. In practice, most modern players build on some combination of throughput and buffer health.

So what is the player actually trying to optimise? Every ABR algorithm is ultimately balancing three competing goals:

Quality give the viewer the best resolution their connection can handle
Stability don't switch renditions so often that it's distracting
Rebuffer risk never let the buffer run dry

The player can optimize for any one of these, but trade off against the other two. Tuning this balance well is most of what makes one player's ABR implementation "feel" better than another's, even when they're pulling from the same manifest.

Next let's look at how to protect these files when transmitting them over the internet.

Protecting Premium Content: DRM

ABR solves the problem of keeping video playing smoothly. But it doesn't solve a completely different problem that studios and streaming platforms care about a lot: how to stop people from just copying and stealing the video the second it reaches their device.

That's where Digital Rights Management (DRM) comes in.

At a high level, DRM encrypts the media so that even though the chunks are sitting on the device, or passing through the network, they're useless without a decryption key. That key is only handed over by a license server after checking that the request is legitimate, the user has a valid subscription, the device is authorized, that kind of thing.

The three major DRM systems you'll run into are:

Widevine: Google, used across Android, Chrome, and most smart TVs
FairPlay: Apple, used across iOS, Safari, and Apple devices
PlayReady: Developed by Microsoft, used across Windows and some smart TVs/consoles

Because no single DRM system covers every platform, most large streaming services encrypt their content with multiple DRM systems at once, and the player picks whichever one matches the device it's running on. This is usually paired with Common Encryption (CENC), a standard that lets the same encrypted media file be decrypted by different DRM systems, so you're not re-encoding your entire catalog three times over.

It’s worth noting that encoding/decoding a video is totally different from encrypting it with DRM. Encoding is just a way of compressing a video file so it’s small enough to travel smoothly over the internet. Encryption, on the other hand, is all about locking the file down to protect it from being stolen.

What actually happens when a license gets requested

"Gate the key behind a license server" is easy to say. Here's what that exchange actually looks like step by step, using Widevine as the running example (FairPlay and PlayReady follow the same general shape, with system-specific details):

The player requests encrypted content. The video chunks arrive encrypted the player can download them fine, but can't decode them yet.
The player extracts protection info. Encrypted content includes metadata (in Widevine's case, called PSSH data) that tells the player's Content Decryption Module (CDM) which DRM system is in use and which key is needed.
The CDM generates a license request. This is a device-specific, cryptographically signed request, it proves the request is in fact coming from a legitimate, unmodified player/device combination, not something spoofing it.
The request goes to the license server. This is a server the streaming platform controls, separate from the server hosting the video segments. It checks things like if the user's subscription is active, if the device is authorised, if the account has rights to the particular title, and if the region is licensed.
The license server responds with an encrypted license. If everything checks out, the server sends back a license containing the decryption key, but the key itself is encrypted so that only the specific CDM that made the request can unlock it.
The CDM decrypts content locally. From here, decryption happens inside a protected, isolated part of the device - ideally hardware backed, so the key never becomes accessible to the OS, the app, or anything that could extract it, then the decoded frames get handed to the video player for playback.

This is way more complicated than just checking a password. With normal auth, the app only needs to ask: "Is this the right user?" But with video security, the question is: "Can we let this exact video play on this exact device without letting the user, or any unauthorised software on their machine ever touch the actual video file or the secret key?"

A note on security levels. Not all decryption happens with the same level of protection. DRM systems support different tiers of security, Widevine, for example, ranges from L1 - which is hardware backed, keys and decryption happen in a trusted execution environment down, to L3 which is software only with no TEE backup. Premium content (think 4K, HDR) is often gated to only play on devices that support the higher security level, because software only decryption is more exposed to extraction attacks. This is part of why a 4K stream might quietly downgrade to a lower resolution on an older or rooted device because the device doesn't meet the security requirement for that content tier, so the platform serves a rendition it's comfortable protecting less strictly.

Tools like Shaka Packager (mentioned back in Part 1 for encoding), and FFMpeg also handle the encryption step, tagging the encrypted chunks with the right metadata so the player knows which license server to talk to and which key to ask for.

Wrapping Up

Quick recap:

Resolution determines how many pixels are displayed, bitrate determines how much data is available each second, and the codec determines how efficiently those bits are used.
ABR works by encoding multiple quality renditions and letting the player switch between them, usually driven by a combination of throughput and buffer level signals, balanced against quality, stability, and rebuffer risk
DRM protects content by encrypting it and gating decryption keys behind a license server via a signed request/response handshake, with Widevine, FairPlay, and PlayReady covering the major platforms, and security levels (like Widevine's L1/L3) determining what quality tiers a device is even allowed to play

That covers the client-side fundamentals I set out to write about from the basic "why streaming exists" question all the way down to what happens in a DRM handshake. If you're building or debugging a media player and want to go even further, the ExoPlayer and Shaka Player source/docs are genuinely excellent references a lot of what's above is drawn from spending time reading and understanding them and on OTTVerse.

This is Part 2 of a multi-part series on media streaming internals. Catch Part 1 here.

Introduction to media streaming: Download, Containers & Codecs.

David Rufai — Tue, 07 Jul 2026 20:51:52 +0000

I recently interviewed with a popular streaming platform for a Senior Software Engineer role focused on low-level media streaming. As someone with prior experience in this space, I used the prep process to go deeper into the internals of how streaming actually works. The interview went well, but the role wasn't quite the right fit at the time. In an effort not let that knowledge go to waste, I thought I'd write an article to share what I learned during this period.

This article is the first in a series introducing how media streaming works on the client side: the steps involved in getting a piece of media from a server onto a client device over the internet, so off we go!

The Problem with Downloading

I believe at some point you've consume some sort of media on the internet today with either your phone, your laptop, maybe even a pager if you're reading this from 1998. Whether it's a short clip on Instagram or X(formerly Twitter), or a two-hour film on Netflix or Amazon Prime, or maybe even listening to your favourite music on Spotify that content had to get to your device somehow.

These media content can be delivered in various ways but we'd be looking at two of them. In the early days of the internet, there was really just one go-to option, downloading the entire file before playback actually starts. Yeah that's works fine for a few second clip, but where the problem lies is when a long form media content is being served to a user. Downloading an hour of 720p video over a 4G connection can take several minutes depending on your connection quality, now imagine how that scales when the media resolution is larger with a longer duration. Nobody wants to stare at a loading bar for ten minutes before a movie starts.

Enters Streaming

The solution to this was streaming. In context media, streaming is the process of continually delivering multimedia content, like video, audio, or subtitles over the internet in near realtime.

Instead of waiting for the entire file to download, streaming breaks the media into small chunks (typically a few seconds each) that are delivered and buffered continuously. Playback can start as soon as the first chunk of the media arrives, rather than waiting for the whole file. See how that solves the download problem?...now let's dive a bit deeper into how these streaming technologies work.

Before playback can start with streaming, the player(client) needs to know what to fetch and in what order. That's the job of a manifest file, a kind of playlist that lists the available chunks and quality levels. depending on the streaming protocol, this manifest file can be formatted differently. HLS uses a .m3u8 manifests, while MPEG-DASH uses .mpd manifests. We won't go deep on these yet, but it's worth knowing they exist: they're the reason a player can jump between quality levels mid-playback without you noticing something we'll cover properly in Part 2 when we get into adaptive bitrate streaming.

The Two Big Streaming Technologies

Since streaming's early days, several technologies have emerged, but two dominate today RIP Adobe Flash:

HTTP Live Streaming (HLS) — developed by Apple
Dynamic Adaptive Streaming over HTTP (DASH), also known as MPEG-DASH

Both work on the same core idea described above: chunked delivery guided by a manifest. Before any video can be delivered this way, though, it needs to be prepared, encoded, packaged, and often encrypted. Tools like FFmpeg and Shaka Packager handle this: taking a raw, hour long video file and turning it into the chunks and manifests a streaming player can actually use.

Containers and Codecs

To support an the vast array of browsers, OS, and devices available today you can't rely on just a single media format. This is where containers and codecs come in, two terms that get used interchangeably but mean different things.

think of container as just that, a shell for housing multiple data streams maybe an audio, video and or subtitle stream, bundled into one file. An MP4 file, for example, is a container that might hold an H.264 video stream and an AAC audio stream inside it.

Each of those individual streams is compressed using a codec(encoder/decoder), an algorithm designed to shrink raw, usually oversized media data into something efficient to store and transmit over the internet. some of the common video codecs include:

H.264 / AVC (Advanced Video Coding)
H.265 / HEVC (High Efficiency Video Coding), the successor to H.264
AV1, a newer, royalty-free codec

And common audio codecs include:

AAC (Advanced Audio Coding)
Opus
FLAC

The codec is what does the heavy lifting of compression; the container is just the box everything ships in ;)

What's Next

To keep this article from running longer than the Dead Sea Scrolls, I'll stop here. Quick recap of what we covered:

Why downloading doesn't scale for long-form video, and how streaming solves it
How chunked delivery and manifest files work together
HLS and DASH as the two dominant streaming protocols
The difference between containers (the shell) and codecs (the compression)

In Part 2, we'll dig into bitrate vs. resolution and how they affect playback quality, how adaptive bitrate streaming actually decides what to switch to and when, and how premium content gets protected with DRM and how the client platform handle securing these files.

Part 2 available here

Jetpack Compose Optimization - Making Your App Run Like a Well-Oiled Machine

David Rufai — Wed, 30 Oct 2024 18:56:55 +0000

I think we all know how easy it has become when it comes to building the UI in our Android apps since the introduction of Jetpack Compose, we've gone from the days of requiring 3 separate components to display a simple list(no shades to RecyclerView), to achieving the same with just a simple composable - 😍 the LazyColumn. But the thing with new technologies is that they often introduce a new level of complexity, in the case of Compose minimizing the number of re-compositions can be a very huge performance booster. This article aims at providing tips/techniques on how to do just that.

Before jumping right in we first need to understand how a composable is rendered on screen.

Composition: In this initial phase, Compose constructs a UI tree, a hierarchical representation of your UI. It executes your composable functions and reading state and builds the structure of your UI. This phase determines what UI elements to display and their relationships.

Layout: Once the UI tree is established, the Layout phase takes over. It measures and positions each UI element within the tree, calculating its size and placement on the screen. This phase ensures that elements are arranged correctly and don't overlap.

Drawing: Finally, the Drawing phase renders the UI to the screen. It takes the layout information generated in the previous phase and translates it into pixels, visually displaying your app's interface. This phase uses the device's graphics hardware to optimize performance.

When the device configuration(e.g, a screen rotation) or a state that the Composable depends on changes, the Composable is "re-composed". meaning it goes through these three phases again, updating the UI if necessary. This ensures that the UI remains consistent with the current state and configurations.

Now that we understand how Compose renders its UI components, let's jump into optimizing our apps.

Writing stable Composables

One way of reducing unnecessary recomposition in your app is by writing stable composables, but what do I mean by that? Stable composables are composables whose parameters are immutable or can be determined to have not changed between recompositions, on the other hand, Unstable composables have parameters that are mutable or cannot be determined to have changed, requiring full recomposition even if only a portion of the data has changed.

take the code block below for example.

@Composable
fun ItemList(items: List<String>) {
    Column {
        items.forEach { item ->
            Text(item)
        }
    }
}

// Usage with un-stable state
@Composable
fun MainScreen() {
    val items =  mutableListOf("Apple", "Banana", "Cherry")
    DisplayItems(items)
}

while this seems normal, this code would always cause DisplayItems to recompose even when the items hasn't particularly changed, this is because items is of a mutable data type, and the compose compiler doesn't know when it actually changes, so to err on the side of caution re-composition is always triggered. To fix this we can use the DisplayItems composable this way.

@Composable
fun MainScreen() {
    // Immutable list is stable
    val items = remember { listOf("Apple", "Banana", "Cherry") } 
    DisplayItems(items)
}

Here, items is stable because it’s created as an immutable list and wrapped in remember, meaning Compose will treat it as stable and won’t trigger recompositions unless items actually changes.

Use derivedStateOf for Computed States

Using derivedStateOf in Compose is helpful when you need to create a computed state that depends on other states, especially if the computation is expensive or the UI doesn’t need constant updates. With using this method computed values could trigger recompositions anytime the dependent state changes, even if the actual computed value doesn’t change.

@Composable
fun SearchScreen() {
    var query by remember { mutableStateOf("") }
    val items = listOf("Apple", "Banana", "Cherry", "Date")

    // Filtering directly without derivedStateOf
    val filteredItems = items.filter { it.contains(query, ignoreCase = true) }

    Column {
        TextField(
            value = query,
            onValueChange = { query = it },
            label = { Text("Search") }
        )
        filteredItems.forEach { item ->
            Text(item)
        }
    }
}

In the example above, filteredItems is recomputed every time the user types in the search bar, even if the filtered list remains unchanged, which isn't really efficient. With derivedStateOf, we ensure that filteredItems only updates when the query value actually changes, minimizing recompositions.

@Composable
fun SearchScreen() {
    var query by remember { mutableStateOf("") }
    val items = listOf("Apple", "Banana", "Cherry", "Date")

    // Using derivedStateOf for optimized filtering
    val filteredItems by remember(query) {
        derivedStateOf { items.filter { it.contains(query, ignoreCase = true) } }
    }

    Column {
        TextField(
            value = query,
            onValueChange = { query = it },
            label = { Text("Search") }
        )
        filteredItems.forEach { item ->
            Text(item)
        }
    }
}

Using Lazy Composables Effectively

The LazyColumn and LazyRow components in Compose are handy, but they’re only as efficient as your use of them. Avoid nesting too many Lazy components, and use item scopes smartly to minimize view updates. Use the LazyListState to manage scroll positions and track updates efficiently.

Using the Profiler

One of the most reliable ways to ensure an optimized app is by measuring its performance. The Android Studio Profiler is like a diagnostic tool, showing you where bottlenecks are in your app. Keep an eye on the CPU and memory usage of composables, particularly the frequency of recomposition events. You can also consider using the 'Profile GPU Rendering' *or *'Profile HWUI Rendering' tool in your device's developer options settings screen, to view frame rendering times and ensure smooth animations. For Compose, a smooth operation is usually 60 frames per second or better.

Final Thoughts

Jetpack Compose offers plenty of ways to write clean, fast, and stunning apps. And just like a car needs regular maintenance, your app needs its optimizations to stay slick and speedy. In my experience, a few small adjustments can prevent a lot of user frustration and keep them coming back to your app. Keep building & write clean code :)

Dependency Injection in Jetpack Compose with Koin

David Rufai — Tue, 10 Sep 2024 13:02:31 +0000

Have you ever felt like your code is drowning in dependencies, tangled like some Italian spaghetti? Fear not! Dependency Injection (DI) is here to save the day, and this time with an elder wand Koin 😊, seriously, it’s as simple as flipping a coin 🌚! Let's dive into how you can inject dependencies in your Jetpack Compose app and give your code some much-needed structure—without breaking the spacetime continuum.

Well, what's the Deal with Koin?

Koin is a lightweight DI framework built in Kotlin. Think of it as a friendly neighborhood library that helps you manage your dependencies without all the boilerplate code. It’s like hiring an assistant who knows where everything is and hands it to you when you need it. Ready to make your code cleaner? Let’s get started!

1: Add Koin to your project

First, you’ll need to add Koin to your project. Head to your app module build.gradle file and include the following lines in the dependencies section and sync gradle files:

dependencies {
    implementation "io.insert-koin:koin-android:3.1.6"
    implementation "io.insert-koin:koin-androidx-compose:3.1.6"
}

that's it, we've just summon our very own Elder wand.

2: Define Your Modules

Think of a Koin module as your favorite meal prep service—it organizes all your dependencies so you don’t have to scramble at the last minute. Here’s how you can define a module to serve up some dependencies:

val appModule = module {
    single { Repository() }  // Singleton pattern
    factory { ViewModel(get()) }  // Factory pattern
}

In this module:

We have a Repository that’s served as a single instance (singleton).
The ViewModel gets created fresh every time, with the Repository injected like magic.

3: Start Koin in Your App

Before you can start injecting stuff, you need to initialize Koin in your app’s Application class. Don't worry, it’s a one-time setup.

class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidLogger()
            androidContext(this@MyApp)
            modules(appModule)
        }
    }
}

Note: Don't forget to define your application class in your app's AndroidManifest.xml file using the android:name attribute in the application tag.

4: Inject in Jetpack Compose

Alright! How do we inject dependencies into our Jetpack Compose UI? It’s Surprisingly easy, no rituals, sermons, or incantations needed.

@Composable
fun MyScreen(viewModel: ViewModel = get()) {
    val data = viewModel.loadData()
    Text(text = "Data: $data")
}

The magic here is get()—it tells Koin to inject the necessary dependencies. And just like that, you’ve turned a complicated mess into a clean, organized flow. You’re a magician at this point. 🎩✨

With Koin, you can wave goodbye to manual dependency management and say hello to clean, testable, and maintainable code. Your codebase & anyone
else who works on it will thank you, and you’ll wonder why you ever did it the hard way.

Conclusion 🏁

Koin makes dependency injection in Jetpack Compose a walk in the park. It’s lightweight, easy to use, and saves you from writing boilerplate code—like a pocket-size superhero for your app. So, go ahead, flip the "Koin", and let it work its magic in your next project! Just remember, with great power comes great injectability.

Happy coding, and may your dependencies always be well-injected! 😌

Understanding Dependency Injection

David Rufai — Sun, 18 Aug 2024 18:07:08 +0000

Imagine you're working on an app that requires various components to interact seamlessly. You’ve written a class to handle user authentication, but it directly creates instances of several dependencies network services, data storage, and logging utilities. It works well at first, but as the project grows, testing becomes a nightmare. Every time you make a change, you must modify multiple classes, and mocking these dependencies for unit tests feels like a battle. You start to realize that your tightly coupled code is dragging down the entire project.

This is where Dependency Injection comes to the rescue.

Dependency Injection? What the heck is that?

Dependency Injection (DI) is a software engineering technique often used in object-oriented software development to handle object relationships. Rather than having an object create or manage its required components (dependencies), DI involves providing these components from an external source. This approach is like giving an object the tools it needs instead of letting it gather them. By implementing DI, developers can create systems where different parts are less tightly interconnected. This results in easier to modify, test, and maintain applications over time. It also allows seamless flexibility in swapping out components without affecting the overall system structure.

Here's a very basic example in Kotlin.

 class GenericEngine() {
   fun start() {
     print("engine started")
   }
 }


class Car() {   
   val engine = GenericEngine()

   fun drive() {
     engine.start()
   } 
}

Here, the Car is responsible for creating its engine, which seems pretty normal for now, right? But what happens when we want to build a car with a different type of engine? Do we create a different car class and then define our custom engine in it, or just change the GenericEngine instance to a different engine instance? This approach has some issues: the former being having to write more code for just a slightly different behavior, and the latter being having to modify a field which could cause breaking changes. This could go south quickly in large-scale applications. Fortunately for us, we have a magic trick up our sleeves... drumroll 🥁 ...Dependency Injection!!! 🙌

We could avoid all of that unnecessary modification by just requiring the engine to be passed as a dependency. This allows us to easily modify the engine type on our class object (talk about an upgrade 😉). Enough talk, here's how we do that.


class Car(private val engine: Engine) {  // Engine is injected via the constructor
    fun drive() {
        engine.start()
        println("Car is driving")
    }
}

fun main() {
    val engine = Engine()  // engine dependency is created outside the Car class
    val car = Car(engine)  // dependency is injected into the Car class
    car.drive()
}

We could take this a step further by defining an Engine interface. This provides more flexibility, enabling us to swap out different implementations of the dependency without changing the dependent class.

First, we define our interface and also two contracts (start & stop) that all engines must follow.

interface Engine {
    fun start()
    fun stop()
}

now let's create two implementations of the Engine interface.

class PetrolEngine() : Engine {
    override fun start() {
        println("engine started")
    }

    override fun stop() {
        println("engine stopped")
    }
}

class ElectricEngine() : Engine {
    override fun start() {
        println("Electric engine started, battery on 12% please find a charging station soon")
    }

    override fun stop() {
        println("electric engine stopped")
    }
}

now our Car class would depend on the Engine interface and not a specific implementation.

class Car(private val engine: Engine) {
    fun drive() {
        engine.start()
        println("Car is moving")
    }

    fun stop() {
        println("Car stopped turning off engine")
        engine.stop()
    }
}

finally here's how we can use both implementations.

    val petrolEngine: Engine = PetrolEngine()
    val electricEngine: Engine = ElectricEngine()

    val carWithPetrolEngine = Car(petrolEngine)
    carWithPetrolEngine.drive()

    val carWithElectricEngine = Car(electricEngine)
    carWithElectricEngine.drive()

This approach using an interface is more scalable and is a very common practice in software design, especially when building apps that need to be easily modified.

I guess now we could easily solve the world's energy crisis by implementing an Engine that runs on water 😅.