UNİTY ADDRESSABLES MANTIĞINI KURMAK VE ASSET YÖNETİMİNİ OPTİMİZE ETMEK

Projeler büyüdükçe “hangi varlık nereden geliyor, ne zaman yükleniyor, ne kadar bellek yiyor?” soruları hızla kritik hale gelir. Unity Addressables, bu soruları yönetilebilir bir sisteme dönüştürür: varlıkları adreslenebilir yapar, yüklemeyi asenkronlaştırır, paketlemeyi kontrol altına alır ve güncelleme akışlarını daha güvenli kılar.

Ancak Addressables’ı sadece kurmak yetmez; mantığını doğru kurmak, etiketleme disiplinini oturtmak, paket stratejisini belirlemek ve ölçümlemeyle optimize etmek gerekir. Aksi halde katalog karmaşası, gereksiz indirmeler, uzun açılış süreleri ve “release sonrası sürpriz” riskleri artar.

Bu yazıda Unity Addressables için sağlam bir temel kurmayı, adreslenebilir varlıkların yaşam döngüsünü anlamayı ve asset yönetimi tarafında performans ile sürdürülebilirlik dengesini yakalamayı adım adım ele alacağız. Son bölümde, ekiplerin eğitim planına ekleyebileceği pratik kontrol listeleri ve ölçüm odaklı yaklaşım da var.

Unity Addressables temeliyle adreslenebilir varlıkları kurgulamak

Addressables’ın ana fikri basittir: sahne, prefab, texture, audio ya da ScriptableObject gibi varlıkları bir “adres” üzerinden çağırmak ve ihtiyaç anında yüklemek. Bu yaklaşım, büyük projelerde yükleme sürelerini kontrol altına almak ve gereksiz bellek kullanımını azaltmak için güçlü bir çerçeve sağlar.

İlk adım, adreslenebilir varlıkların kapsamını netleştirmektir. Her şeyi Addressables’a taşımak çoğu zaman doğru değildir. Örneğin çekirdek UI, açılışta mutlaka gereken küçük ikon setleri veya sabit şablonlar bazen yerel build içinde kalabilir. Buna karşılık, bölüm içerikleri, kozmetikler, etkinlik paketleri veya indirilebilir eklentiler Addressables için ideal adaylardır.

Adresleme mantığını ekipçe standartlaştırmak ve sürdürmek

Adresler “iş isimleri” gibi davranır. Kişiye göre değişen, rastgele konmuş isimler ileride kırılganlığa yol açar. Bu yüzden adres formatını baştan belirlemek gerekir: örneğin kategori/altKategori/ad gibi. Ayrıca adres yerine label kullanımını teşvik etmek de iyi bir pratiktir; çünkü label, paket stratejisi ve yükleme senaryolarında daha esnek bir kontrol sağlar.

Gruplar, şemalar ve etiketlerle düzeni oturtmak

Addressables Group, varlıkların nasıl paketleneceğini, nereden yükleneceğini ve build pipeline içinde nasıl davranacağını belirleyen bir katmandır. Burada amaç “güzel görünmesi” değil, operasyonel sürdürülebilirlik sağlamasıdır. Grupları genellikle kullanım senaryosuna göre ayırmak iyi sonuç verir: temel UI, bölüm içerikleri, sezonluk içerikler, test paketleri gibi.

Asset yönetimi için grup stratejisi ve bundle planı oluşturmak

Addressables’ın gerçek gücü, paketleme ve dağıtım stratejisinin doğru tasarlanmasıyla ortaya çıkar. Burada “bundle stratejisi” kritik kavramdır: hangi varlıklar birlikte paketlenecek, hangi varlıklar ayrı kalacak, hangileri yerel, hangileri uzak olacak?

Genel kural: birlikte kullanılacak varlıkları mümkün olduğunca aynı paket içinde tutmak; farklı zamanlarda kullanılanları ayırmak. Ancak bunun da bir sınırı var. Çok büyük paketler ilk indirmeyi ağırlaştırır; çok küçük paketler ise aşırı istek sayısı ve katalog karmaşasına yol açar.

Bağımlılık zincirlerini sadeleştirmek ve tekrarları önlemek

Prefab’lar, material’lar ve texture’lar arasındaki bağımlılıklar paket davranışını doğrudan etkiler. Aynı texture farklı paketlerde tekrar tekrar yer alıyorsa, indirme ve disk kullanımında gereksiz şişme olur. Bu yüzden sık kullanılan ortak varlıkları “shared” mantığında ayırmak, bağımlılıkları görünür kılmak ve tekrarları azaltmak önemlidir.

Profil tabanlı ayrım yapmak: geliştirme ve yayın ortamı farkı

Addressables Profiles ile geliştirme ortamında yerel sunucu, yayın ortamında CDN gibi farklı kaynaklara geçiş kolaylaşır. Ekipler genellikle test ve yayın akışını aynı profil üzerinde yürütmeye çalışır; bu da “neden canlıda farklı davrandı?” sorusunu büyütür. Profil ayrımı, hem kalite güvence sürecini hem de dağıtım güvenliğini güçlendirir.

Yükleme performansı için akış tasarlamak ve önbellekleme kurmak

Adreslenebilir varlıkların yüklenmesi, kullanıcı deneyiminin merkezindedir. Burada hedef, açılışta her şeyi yüklemek değil; kullanıcı akışına göre yükleme zamanlamasını planlamaktır. Örneğin ana menüye girerken sadece menü UI’ı, ilk bölüm yüklenirken o bölüme ait içerik paketi, mağaza açılırken mağaza varlıkları yüklenmelidir.

Bu noktada “yükleme performansı” konuşurken iki şeye bakılır: gecikme (latency) ve bellek baskısı. Aynı anda çok fazla handle açmak, gereksiz varlığı bellekte tutmak ve temizleme yapmamak zamanla performans düşüşüne yol açar.

Asenkron yükleme ve yaşam döngüsü yönetimini doğru yapmak

Addressables, asenkron akış için güçlü bir API sunar. Ancak handle yönetimi doğru yapılmazsa bellek sızıntısı benzeri sorunlar oluşabilir. Bir varlığı yüklediğinizde, işi bittiğinde release etmeyi unutmamak gerekir. Aşağıdaki örnek, label üzerinden yükleyip sonuçları yönetmenin temel bir yaklaşımını gösterir.

using System.Collections.Generic;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;

public class CatalogLoader : MonoBehaviour
{
    private AsyncOperationHandle<IList<GameObject>> _handle;

    public void LoadCosmeticsByLabel(string label)
    {
        // Label tabanlı yükleme: aynı anda çok sayıda öğe için ideal
        _handle = Addressables.LoadAssetsAsync<GameObject>(
            label,
            onAssetLoaded: go => Debug.Log($"Loaded: {go.name}")
        );

        _handle.Completed += op =>
        {
            if (op.Status == AsyncOperationStatus.Succeeded)
            {
                Debug.Log($"Total loaded: {op.Result.Count}");
            }
            else
            {
                Debug.LogError("Load failed");
            }
        };
    }

    public void Unload()
    {
        if (_handle.IsValid())
        {
            Addressables.Release(_handle);
            Debug.Log("Released handle");
        }
    }
}

Bu örnekte dikkat edilmesi gereken nokta, yüklemenin sonunda değil, kullanım bittiğinde release yapılmasıdır. Eğer varlıklar sahnede yaşamaya devam ediyorsa, “kullanan” tarafın yaşam döngüsünü belirlemek gerekir. Bu yaklaşım, ekip içinde net sorumluluk tanımı gerektirir.

Önbellek davranışını anlamak ve doğru beklenti kurmak

İndirilen paketler cihaz tarafında önbelleğe alınır. Bu sayede aynı paket tekrar çağrıldığında ağdan çekmek yerine yerelden kullanılır. Ancak “cache var, sorun kalmadı” yaklaşımı yanıltıcıdır; çünkü katalog güncellendiğinde veya paket hash’i değiştiğinde yeniden indirme tetiklenebilir. Bu yüzden içerik güncelleme stratejisi ile önbellek stratejisini birlikte düşünmek gerekir.

Remote Catalog ve Content Update ile canlı güncellemeyi yönetmek

Addressables’ı seçmenin temel motivasyonlarından biri, içerik güncellemeyi daha az riskle yönetmektir. Remote Catalog (uzak katalog) sayesinde, uygulamayı mağazaya yeniden göndermeden içerik paketlerini güncelleyebilirsiniz. Burada ana zorluk, content update sürecinin disiplinli yürütülmesidir.

Canlı güncellemelerde üç temel hedef vardır: yanlış paketi dağıtmamak, doğru sürümle eşleşmek ve kullanıcıya gereksiz indirme yaptırmamak. Bunun için sürümleme, build raporu okuma ve yayın öncesi doğrulama adımlarının standart hale getirilmesi gerekir.

Katalog sürümleme ve geri dönüş senaryosu tasarlamak

Bir katalog güncellemesi yayınlandığında, eski kullanıcıların yeni katalogla uyumluluğu önemlidir. Bazı projeler “her katalog değişikliğinde büyük yeniden indirme” yaşar; bunun nedeni genellikle paket stratejisinin ve bağımlılıkların stabil olmamasıdır. Katalog sürümleme ve geri dönüş planı, özellikle riskli dönemlerde (etkinlik/season) iş sürekliliği açısından değerli bir güvenlik ağıdır.

İçerik güncelleme akışı için küçük ama kritik kontrol listesi

• Değişen varlıklar gerçekten değişti mi, yoksa yeniden import kaynaklı mı?
• Paketlerin boyutu ve sayısı beklenen aralıkta mı?
• Remote Catalog hedefi (CDN yolu) doğru profile bağlı mı?
• Önbellek temizliği gerektiren kırılım var mı, kullanıcı iletişimi hazır mı?
• Test cihazında ağ kesintisi ve düşük hız senaryosu denendi mi?

Bellek ve indirme maliyetini ölçümleyerek optimize etmek

Optimize etmek, tahmin etmek değil ölçmektir. Addressables tarafında ölçümleme; indirme boyutu, açılış süresi, sahne geçiş süresi, bellek kullanımı ve GPU yükü gibi metrikleri birlikte ele almayı gerektirir. Bu metrikler izlenmeden yapılan değişiklikler, bir alanı iyileştirirken başka bir alanı bozabilir.

Unity Profiler, Memory Profiler ve Addressables Analyze araçları burada güçlü yardımcıdır. Özellikle Analyze penceresi, bağımlılık tekrarlarını ve paketlemeye dair riskleri erken yakalamanıza destek olur. Ekipler bu çıktıları “sadece teknik not” olarak değil, yayın kontrol sürecinin parçası olarak görmelidir.

Analyze kurallarıyla paket tekrarlarını yakalamak

Analyze tarafında “Check Duplicate Bundle Dependencies” gibi kontroller, şişen indirmenin temel nedenini gösterebilir. Eğer ortak texture setleri farklı paketlerde tekrar ediyorsa, bunu “shared group” ile düzeltmek mümkündür. Burada amaç, her şeyi tek pakete doldurmak değil; mantıklı ortaklaşmayı bulmaktır.

Ölçüm odaklı optimizasyon için mini hedef seti belirlemek

Pratikte ekipler şu hedefleri koyduğunda hızlı ilerler: ilk açılışta indirilen toplam boyutu X MB altında tutmak, ilk menüye geliş süresini Y saniye altında tutmak, bölüm geçişlerinde ek indirmeyi Z MB altında sınırlamak. Bu hedefler, paketi bölme kararlarını netleştirir ve tartışmayı “hissettim” düzeyinden “veri” düzeyine taşır.

Build pipeline ve otomasyonla Addressables sürecini güvenceye almak

Addressables kurulumunun sürdürülebilir olması için build pipeline içinde otomasyon şarttır. Manuel adımlar arttıkça hata olasılığı yükselir: yanlış profile ile build almak, yanlış hedefe upload etmek veya yanlış katalogla test etmek gibi. Bu yüzden build sürecini standardize etmek, yayın güvenliğini artırır.

Aşağıdaki örnek, basit bir editör menüsüyle Addressables build almayı ve ardından rapor üretmeyi temsil eden bir yaklaşımı gösterir. Gerçek projelerde bu akış CI/CD’ye taşınabilir ve dağıtım adımlarıyla entegre edilebilir.

#if UNITY_EDITOR
using UnityEditor;
using UnityEditor.AddressableAssets.Settings;
using UnityEditor.AddressableAssets.Build;
using UnityEditor.AddressableAssets;

public static class AddressablesBuildMenu
{
    [MenuItem("Build/Addressables/Build Player Content (Active Profile)")]
    public static void BuildAddressables()
    {
        AddressableAssetSettings settings =
            AddressableAssetSettingsDefaultObject.Settings;

        if (settings == null)
        {
            UnityEngine.Debug.LogError("AddressableAssetSettings not found.");
            return;
        }

        // Aktif profile ile içerik build alır
        AddressablesPlayerBuildResult result =
            AddressableAssetSettings.BuildPlayerContent();

        if (!string.IsNullOrEmpty(result.Error))
        {
            UnityEngine.Debug.LogError($"Addressables build failed: {result.Error}");
        }
        else
        {
            UnityEngine.Debug.Log("Addressables build completed successfully.");
            UnityEngine.Debug.Log($"Output: {result.OutputPath}");
        }
    }
}
#endif

Bu örneği geliştirirken, build çıktısını otomatik olarak raporlayıp boyut değişimlerini takip etmek faydalıdır. Ayrıca sürümleme politikasını netleştirmek gerekir: hangi durumda paket yeniden üretilecek, hangi durumda sadece katalog güncellenecek? Bu kararlar, canlı güncellemelerde sürprizleri azaltır.

Ekip akışı ve eğitim planıyla Addressables bilgisini kalıcılaştırmak

Addressables bilgisi tek kişinin omzunda kaldığında, süreç hızla kırılganlaşır. Bu yüzden ekip içi standartlar, kod inceleme maddeleri ve dokümantasyon gerekli olur. Özellikle yeni ekip üyeleri için “adresleme kuralları, label seti, grup mantığı, profil kullanımı ve release sorumluluğu” net olmalıdır.

Bu noktada hedef, herkesin aynı derinlikte uzman olması değil; ortak bir dilin oluşmasıdır. Ürün, tasarım ve yazılım ekipleri; “hangi içerik ne zaman gelir, indirme maliyeti nedir, güncelleme nasıl yapılır?” sorularında aynı çerçeveyi paylaşmalıdır. Eğitim planında pratik atölyelerle, örnek proje üzerinden group/label kurgulama, paketleme stratejisi kurma ve ölçümleme yapma gibi çalışmalar çok hızlı fayda sağlar.

Bu konuları uygulamalı ele almak isteyen ekipler için Unity eğitimi içinde Addressables, içerik güncelleme ve performans ölçümleme başlıklarını senaryolu şekilde ele almak, projeye doğrudan geri dönüş üretir.

Adresleme standardı, label disiplini ve kod sorumluluğu dağıtmak

Bir varlığı kim addressable yapacak, kim label atayacak, kim group’ları yönetecek? Bu soruların cevabı net değilse, düzen bozulur. Basit bir RACI yaklaşımıyla sorumluluk paylaşmak, özellikle birden fazla proje paralel ilerlerken önemli fark yaratır.

Yayın öncesi doğrulama senaryoları çalıştırmak ve raporlamak

Yayın öncesi test senaryoları; düşük ağ hızı, bağlantı kopması, eski katalogdan yeni kataloğa geçiş, ilk kurulumdan sonra içerik çekme gibi durumları kapsamalıdır. Bu testler rutin hale geldiğinde, canlı güncellemelerdeki risk belirgin biçimde azalır ve kalite algısı yükselir.

Hızlı uygulama özeti: doğru kurulumdan ölçümlü optimizasyona

Addressables ile başarı, tek bir “ayar”la gelmez; kurulum, disiplin ve ölçümün birleşimiyle gelir. Önce varlık kapsamını belirleyin, sonra grup ve label düzenini kurun. Ardından asenkron yükleme ve handle yaşam döngüsünü netleştirin. Son olarak remote catalog ve content update akışını standartlaştırıp metriklerle optimize edin.

Bu yaklaşım, büyük projelerde hem geliştirme hızını hem de yayın güvenliğini artırır. Üstelik sadece performans değil, ekipler arası iletişim de güçlenir; çünkü içerik yönetimi görünür ve yönetilebilir hale gelir.