A Practical Guide to Unity Addressables Bundle Splitting and LZ4/LZMA Compression

Overview

In the previous article, we looked at Addressables download concurrency, label design, and batch downloads using labels.

One important point there was this:

Labels are only the entry point for specifying what you want to download. The actual files downloaded are AssetBundles.

In other words, even if your label design looks clean, a rough Bundle layout can still cause unexpected assets to be downloaded together.

This time, we will look at how to split AssetBundles and how to choose compression settings.

In particular, this article covers:

• Whether Bundles should be split into smaller units or grouped together
• How to handle many small files, such as VN / adventure game scenario text files
• How to split assets that will keep increasing over time, such as character 3D models
• How to think about Pack Together, Pack Separately, and Pack Together By Label
• How to choose between LZ4 and LZMA

This is not an introduction to the official features. The focus is on practical decision-making for real projects.

Label design and Bundle splitting must be considered together

In Addressables, you can use Addresses and Labels to specify which assets to load or download.

However, the actual files downloaded are AssetBundles.

For example, suppose you define labels like this:

If you only look at the labels, it may seem like the assets are managed in a fine-grained way.

But if the actual Bundle is packed as one large Bundle, downloading only chapter_01 may still download other assets included in the same Bundle.

So, in Addressables, these two concepts need to be considered separately:

Label design alone does not determine the download unit.

Label design and Bundle splitting must be designed together.

What does Bundle splitting affect?

Bundle splitting is not just a way to organize things in the Editor.

In practice, it affects the following:

Splitting Bundles into smaller units makes it easier to download only what is needed and reduce update size.

On the other hand, if the number of Bundles increases too much, download requests, cached files, file open operations, catalog complexity, and dependency management cost all increase.

So with Addressables, “smaller is always better” is not the right answer.

The basic approach is:

Group what should be grouped, and split what should be split, based on how the assets are actually used.

Bundle Mode options

In Addressables Group settings, you can choose a Bundle Mode.

The main options are:

One important detail is that Pack Separately does not mean “one asset per Bundle.”

It means one Bundle per Addressable entry.

If a folder is marked as an Addressable entry, the contents under that folder may be packed into one Bundle.

Also, scene assets are handled as separate Bundles from normal assets. Even with Pack Together, everything is not necessarily packed into a single file.

Avoid casually saying “one address, one file”

In real projects, people sometimes describe Pack Separately as “one address, one file.”

That may be fine for a rough conversation, but it is better to be careful when writing design documents or articles.

As an Addressables setting, the accurate term is Pack Separately.

Pack Separately creates a separate Bundle for each Addressable entry in the group.

So the following cases are not as simple as “one asset = one Bundle”:

• A folder is registered as an Addressable entry
• Sprite Atlases or Sub Assets are involved
• Scenes and normal assets are mixed
• Dependencies are moved into separate Bundles

For a rough explanation, “one address, one file” may be understandable.

But for actual design, it is safer to think in terms of Pack Separately.

Cases where grouping Bundles is acceptable

First, let’s look at cases where grouping assets into Bundles is reasonable.

Typical examples include:

• VN / adventure game scenario text
• Dialogue text
• Small .txt files
• Small configuration files
• Master data
• Localization text
• Lightweight ScriptableObject assets

For this kind of data, creating one Bundle per file may not be the easiest approach to operate.

Especially when each file is only a few KB to a few dozen KB, and there are hundreds or thousands of them, the downside of increasing the number of files can become more noticeable than the benefit of fine-grained Bundles.

Many small files, such as VN scenario text

VN / adventure game scenario text is an easy example where grouping often makes sense.

For example, suppose you have a structure like this:

Scenario/
  Chapter01/
    scene_001.txt
    scene_002.txt
    scene_003.txt
    ...
  Chapter02/
    scene_001.txt
    scene_002.txt
    scene_003.txt
    ...

If every .txt file is packed into its own Bundle, the number of files increases quickly.

When the file count increases, the following costs also increase:

• More download requests
• More cached files
• More file open operations
• More file lookup and management cost
• Catalog and dependency checks become more tedious

Of course, if you need to update each scenario file independently, or if you absolutely do not want to download a scenario until the user is about to read it, splitting into smaller units may be valid.

But in many cases, grouping like this is easier to operate:

For scenario text, users often play by chapter or event.

So grouping Bundles by those units usually makes operation easier.

Cases where Bundles should be split

On the other hand, there are also cases where splitting Bundles is better.

Typical examples include:

• Character 3D models
• Character-specific Meshes
• Character-specific Textures
• Character-specific Materials
• Character-specific Animations
• Costumes
• Weapons
• Stages
• Large Prefabs
• VFX
• Voice assets

If you group these too aggressively, operation can become painful.

In particular, assets such as characters and stages often increase over time. Splitting Bundles by the unit in which they are added makes them easier to manage.

Assets that keep increasing, such as character 3D models

Character 3D models are an easy example where splitting Bundles often makes sense.

Suppose all characters are packed into one Bundle:

character_all.bundle
  Alice
  Bob
  Carol
  Dave
  Eve

With this layout, adding just one new character can make the entire character_all.bundle an update target.

Even if a user only needs Alice, they may still download Bob and the other characters because they are in the same Bundle.

On the other hand, if you split Bundles by character, the update and download units become clearer:

character_alice.bundle
character_bob.bundle
character_carol.bundle
character_dave.bundle
character_eve.bundle

With this layout, if only Alice is needed, only Alice’s Bundle can be downloaded.

When adding a new character, you can add a new Bundle and avoid updating existing character Bundles as much as possible.

A character Bundle may contain assets like this:

character_alice.bundle
  Alice.prefab
  Alice.mesh
  Alice.material
  Alice_texture_base
  Alice_texture_normal
  Alice_animation_idle
  Alice_animation_run

This kind of layout is practical because larger assets that are used together are grouped by their addition and update unit.

Pack Together By Label is useful, but depends on label design

Pack Together By Label packs assets with the same label set into Bundles.

If your label design is clean, this can make it easier to create Bundles by label.

For example:

However, if labels are messy, relying on Pack Together By Label can easily produce an unintended Bundle layout.

For example, if management labels, download labels, event labels, and search labels are mixed together, the number of label combinations increases and the Bundle layout becomes hard to read.

When using Pack Together By Label, it is safer to separate label responsibilities:

Increasing the number of labels is not bad by itself.

But when using Pack Together By Label, the label set directly affects the Bundle layout, so you need operation rules.

How to decide whether to group or split

As a rough guide:

In more practical terms:

• Group many small files
• Split large assets with clear addition units
• Group assets that are used together
• Split assets that may not be used
• Split assets with different update units

These are the basic rules for Bundle splitting.

Difference between LZ4 and LZMA

Next, let’s look at compression settings.

In Addressables Group settings, you can choose the compression format for Bundles.

The common choices are LZ4 and LZMA.

LZMA treats the entire Bundle as one compressed stream.

This usually gives a higher compression ratio, but the decompression cost during loading can become larger.

LZ4 compresses data in chunks.

Its compression ratio is usually lower than LZMA, but it is easier to read only the needed parts, and it tends to be lighter to handle at load time.

Cases where LZMA is easy to recommend

LZMA is useful when you want to reduce download size.

However, in real projects, it is safer to decide based on what is inside the Bundle.

As a rule of thumb:

If 1 Bundle is close to 1 asset, LZMA is easy to recommend.
If 1 Bundle contains multiple assets, LZ4 should be the default.

Here, “1 Bundle = 1 asset” means cases like:

• One large binary file
• One large TextAsset
• One video file
• One audio file
• One Prefab packed into its own Bundle
• One Texture packed into its own Bundle

These Bundles are likely to be loaded almost entirely when used.

That makes it easier to benefit from LZMA’s high compression ratio.

On the other hand, be careful with a Bundle like this:

character_alice.bundle
  Alice.prefab
  Alice.mesh
  Alice.material
  Alice_texture_base
  Alice_texture_normal
  Alice_animation_idle
  Alice_animation_run

This is a “one character, one Bundle” layout, but the Bundle still contains multiple assets.

Even if it looks like one unit called Alice at the application level, the Bundle itself is a collection of multiple assets.

So it is safer not to casually decide “one character Bundle means LZMA.”

LZMA is easy to recommend only when the layout is close to 1 Bundle = 1 asset.

Use LZ4 as the default for Bundles containing multiple assets

LZMA treats the entire Bundle as one compressed stream.

So even if you only want to read part of the Bundle, the decompression cost of the whole Bundle can become an issue at load time.

When multiple independent assets are grouped into one Bundle, LZ4 is usually easier to operate.

The important point is:

“One character, one Bundle” and “one Bundle, one asset” are different things.

Even if a character has its own Bundle, if that Bundle contains a Prefab, Meshes, Textures, Materials, and Animations, it is still a multi-asset Bundle.

In that case, using LZ4 as the default usually makes load-time behavior more stable.

Cases where LZ4 should be the default

LZ4 is suitable when you care about load-time handling.

In Addressables, it is common to group multiple assets into one Bundle. In practice, LZ4 is usually the default choice for multi-asset Bundles.

For Bundles that group multiple files, such as VN scenario text, LZ4 is often easier to handle.

Group the Bundle to reduce the number of files.

But use LZ4 because you may only read part of the Bundle.

This combination is very practical.

Practical recommended settings

As a starting point, the following rules are easy to work with:

The key point is to think about Bundle granularity and compression format separately.

Splitting Bundles, such as one Bundle per character, is useful for reducing download and update units.

However, if that Bundle contains multiple assets, LZ4 should be the default compression choice.

Conversely, if a Bundle contains only one asset, LZMA is easy to recommend.

Of course, the final decision should be based on real device measurements.

Even with “1 asset per Bundle,” the perceived behavior changes depending on asset type, size, device performance, and load timing.

Measure download size, load time, and memory usage on real devices before making the final decision.

Notes on Bundle splitting

There are a few additional things to keep in mind when splitting Bundles.

Duplicate dependencies

When Bundles are split into smaller units, shared dependencies become important.

For example, if multiple characters reference the same Material or Texture, the dependency layout can become complicated depending on how you split the Bundles.

You need operation rules for whether shared assets should be moved into a shared Bundle or kept with each character.

Do not look only at update diffs

Splitting Bundles into smaller units makes update diffs easier to reduce.

But the trade-off is an increased number of Bundles.

If you only look at update size, you may want to split everything. But download requests, cache count, and load-time management cost should be considered together.

Think about initial downloads and additional downloads separately

Assets needed for the initial download and assets downloaded later should not be judged by the same rule.

For initial downloads, grouping more aggressively can be easier.

For additional downloads, making the unit clear is usually easier to operate.

Do not mix the responsibilities of labels and Bundle Mode too much

Labels are useful, but trying to solve everything with labels can break the design.

• Labels for specifying download targets
• Labels for search or classification
• Labels for management
• Labels for events
• Labels for debugging

If all of these are mixed together and you use Pack Together By Label, the Bundle layout becomes difficult to understand.

When adding labels, consider whether each label is allowed to affect Bundle splitting.

Practical checklist

Finally, here is a checklist for deciding Bundle layout.

Group or split

• [ ] Are these assets used together?
• [ ] Do you want to download them individually?
• [ ] Do you want to update them individually?
• [ ] Is each file large?
• [ ] Is the number of files getting too high?
• [ ] Is there a clear unit such as character, chapter, stage, or event?
• [ ] Is this part of the initial download or an additional download?
• [ ] Are unnecessary assets being downloaded?

Compression settings

• [ ] Is download size the priority?
• [ ] Is load time the priority?
• [ ] Is the layout close to 1 Bundle = 1 asset?
• [ ] Does the Bundle contain multiple assets?
• [ ] Is there a chance that only part of the Bundle will be read?
• [ ] Did you measure download size on a real device?
• [ ] Did you measure load time on a real device?
• [ ] Did you measure memory usage on a real device?

Operation

• [ ] Does the label design match the Bundle layout?
• [ ] Are you relying too much on Pack Together By Label?
• [ ] Have you decided how to handle shared dependencies?
• [ ] Are you balancing update size and file count?
• [ ] Will the design still work after more assets are added post-release?

Summary

With Addressables Bundle splitting, neither “split everything” nor “group everything” is always correct.

The important thing is to decide based on how the assets are used, update units, download units, file count, and load-time cost.

For data such as VN scenario text, where each file is small but there are many files, grouping by chapter or event can be easier to operate.

This is because increasing the number of files also increases download requests, cached files, file open operations, file lookup cost, and management cost.

On the other hand, for assets such as character 3D models, where each asset is large and new assets are likely to be added over time, splitting by character can be easier to manage.

For compression, the rule of thumb is:

If 1 Bundle is close to 1 asset, LZMA is recommended. If the Bundle contains multiple assets, use LZ4 by default.

LZMA is useful when compression ratio is the priority, but because whole-Bundle decompression can become an issue, it is safer to avoid it when multiple independent load targets are grouped into one Bundle.

On the other hand, if the Bundle effectively contains one asset, such as one large TextAsset, one binary file, or one Texture, LZMA is easy to recommend.

In the end, always measure download size, load time, and memory usage on real devices before making the final decision.

Addressables can look complicated if you only look at the settings.

But in practice, the basic idea is simple:

Group small files. Split large assets with clear addition units. For compression, use LZMA when 1 Bundle is close to 1 asset, and use LZ4 by default for multi-asset Bundles.

Starting from this policy makes it easier to build a Bundle layout that does not break down over time.