Önceki
GCD (Grand Central Dispatch) iOS Geliştirme Süreçlerinde Thread Yönetiminin Anatomisi
Mobil uygulama geliştirirken bir noktada kaçınılmaz olarak şu soruyla yüzleşirsiniz: Kullanıcı bir butona bastığında ekran neden donuyor? Bu problemin kök nedeni çoğu zaman aynıdır: ağır bir işlemin ana iş parçacığı (main thread – ana iş parçacığı) üzerinde çalıştırılması.
Ana iş parçacığı, kullanıcı arayüzünün (User Interface – Kullanıcı Arayüzü, UI) çizildiği ve kullanıcı etkileşimlerinin işlendiği kritik alandır. Bu iş parçacığı üzerinde uzun süren herhangi bir işlem, kullanıcının uygulamayı “donmuş” olarak algılamasına neden olur. Teknik olarak uygulama çalışmaya devam eder; ancak kullanıcıdan gelen dokunma, kaydırma ve animasyon talepleri işlenemediği için deneyim bozulur.
Geliştirme sürecimin ilk dönemlerinde bu durumu birebir yaşadım. Bir servis çağrısı yapan bir ekranda kullanıcı etkileşimi tamamen kopuyordu; ne bir yükleniyor göstergesi (spinner) dönüyor ne de kullanıcıya anlamlı bir geri bildirim sunuluyordu. Sorunun kaynağını incelediğimde karşıma çıkan temel yapı GCD (Grand Central Dispatch) oldu.
Bu yazıda GCD’nin ne olduğunu, iOS geliştirme süreçlerinde hangi problemleri çözdüğünü ve neden hâlâ modern eş zamanlılık (concurrency) modellerinin temelinde yer aldığını; hem kişisel gözlemlerim hem de literatürde kabul görmüş prensipler ışığında ele alacağım. Özellikle Dispatch Queues (Dağıtım Kuyrukları), Dispatch Groups (Dağıtım Grupları), Dispatch Semaphores (Dağıtım Semaforları) ve Dispatch Sources (Dağıtım Kaynakları) başlıklarını kavramsal ve pratik yönleriyle inceleyeceğiz.
GCD (Grand Central Dispatch) Nedir?
GCD; Apple’ın iOS 4 ile birlikte sunduğu, C tabanlı düşük seviye (low‑level) bir eş zamanlılık API’sidir. Swift ve Objective‑C projelerinde doğrudan kullanılabilir. Temel hedefleri şunlardır:
- İşleri uygun iş parçacıklarına dağıtmak
- Thread oluşturma ve yönetme yükünü geliştiricinin üzerinden almak
- Sistem kaynaklarını en verimli şekilde kullanmak
GCD’yi çalışma prensibi açısından şöyle düşünebilirsiniz: Siz yalnızca “bu işi arka planda yap” dersiniz. Hangi thread’in kullanılacağına, kaç thread açılacağına ve iş yükünün nasıl dengeleneceğine GCD karar verir. Apple dokümantasyonunda da vurgulandığı üzere bu soyutlama, hem performansı artırır hem de hata yapma riskini azaltır.
Kurumsal projelerde backend tarafında çoklu isteklerin tek bir noktada birleştirilmesiyle (örneğin minimum round‑trip hedefleyen mimariler) elde edilen kazanımlara benzer biçimde; GCD de iOS tarafında iş yükünü akıllı şekilde dağıtarak kullanıcı deneyimini iyileştirir.
Bu noktada, Kuveyt Türk’te geliştirdiğimiz BOA mimarisindeki Multiple Request yaklaşımı ile benzerlik kurmak oldukça açıklayıcıdır. BOA mimarisinde arka uç (Back‑End) tarafında birden fazla servisin tek bir akış altında koordine edilmesi, ağ trafiğini azaltırken yanıt sürelerini iyileştirir. GCD de iOS tarafında benzer bir prensiple çalışır: Birden fazla işi uygun kuyruklar aracılığıyla organize ederek hem thread yönetimini sadeleştirir hem de sistem kaynaklarının daha verimli kullanılmasını sağlar.
GCD’nin Temel Bileşenleri
1. Dispatch Queues (Dağıtım Kuyrukları)
Dispatch Queue’lar, GCD’nin belkemiğini oluşturur. Bir kuyruk (queue) içine gönderilen işler, belirli kurallara göre yürütülür. Bir iş kuyruğuna görev atarken iki temel karar verilir:
- Çalışma tipi: Senkron (sync – eş zamanlı) mı, asenkron (async – zaman uyumsuz) mu?
- Kuyruk türü: Seri (serial – seri) mi, eş zamanlı (concurrent – eş zamanlı) mi?
Bu seçimler, uygulamanın performansını ve davranışını doğrudan etkiler.
Concurrency (Eş Zamanlılık) Kavramı
Concurrency (eş zamanlılık), bir sistemin birden fazla işi aynı zaman aralığında ilerletebilme yeteneğidir. Bu kavram, özellikle eş zamanlı kuyrukların (concurrent queue) nasıl çalıştığını anlamak için kritik öneme sahiptir.
Tek çekirdekli bir işlemcide bile concurrency mümkündür. İşletim sistemi, işleri çok kısa zaman dilimlerine bölerek (time slicing) sırayla çalıştırır; bu da işlemlerin aynı anda çalışıyormuş hissi vermesine neden olur.
Çok çekirdekli sistemlerde ise işler gerçekten paralel olarak farklı çekirdeklerde yürütülebilir. Ancak bu durumda dahi bu işlerin yaşam döngüsünün planlanması ve senkronizasyonu concurrency kavramı kapsamında ele alınır.
Serial Queue (Seri Kuyruk)
Seri kuyruklar, işleri FIFO (First In, First Out – İlk Giren İlk Çıkar) prensibiyle, birer birer çalıştırır. Bir görev tamamlanmadan sıradaki başlamaz. Bu davranış biçimi, sıralı bağımlılığı olan işlemler için idealdir (bkz. Kod 1).
Örnek kullanım alanları:
- Dosyaya ardışık yazma işlemleri
- Aynı paylaşılan kaynak üzerinde yarışma (race condition) riski taşıyan operasyonlar
Concurrent Queue (Eş Zamanlı Kuyruk)
Eş zamanlı kuyruklarda birden fazla iş, sistem kaynaklarının el verdiği ölçüde aynı anda çalışabilir. Görevlerin bitiş sırası garanti edilmez; önemli olan bu görevlerin birbirinden bağımsız olmasıdır (bkz. Kod 2).
Yukarıdaki örnekte müşteri oluşturma, log yazma ve giriş sayfasına yönlendirme işlemleri birbirinden tamamen bağımsız ve eş zamanlı olarak çalışmaktadır. Birinin bitmesini beklemeden diğerleri devam eder (bkz. Kod 2).
Gerçek projelerde loglama, analitik gönderme ve ağ işlemlerinin paralel yürütülmesi gibi senaryolarda concurrent queue kullanımı ciddi performans kazanımları sağlar.
Ana İş Parçacığı (Main Thread) ve Arka Plan Kuyrukları
Ana iş parçacığı, uygulamanın kullanıcıyla doğrudan temas ettiği yürütme bağlamıdır. Kullanıcı arayüzü çizimi, dokunma olayları, animasyonlar ve ekran geçişleri bu thread üzerinde gerçekleşir.
Ağ çağrıları, veritabanı sorguları veya büyük dosya işlemleri gibi uzun süren görevler ana iş parçacığında yürütüldüğünde bloklama (blocking) meydana gelir. Bu nedenle ağır işlemler arka plan kuyruklarında çalıştırılmalı, UI güncellemeleri ana iş parçacığına geri dönülerek yapılmalıdır (bkz. Kod 3).
2. Dispatch Groups (Dağıtım Grupları)
Dispatch Group’lar, birden fazla asenkron işlemin ne zaman tamamlandığını tek bir noktadan takip etmeyi sağlar. Tüm işlemler tamamlandığında tek bir aksiyon almak mümkündür (bkz. Kod 4).
Bu yapılarda her enter() çağrısı için mutlaka bir leave() çağrısı yapılması gerektiği unutulmamalıdır.
3. Dispatch Semaphores (Dağıtım Semaforları)
Dispatch Semaphore’lar, paylaşılan bir kaynağa aynı anda kaç işin erişebileceğini kontrol eder. Bu yapı, özellikle eş zamanlı çalışan çok sayıda görev arasında kaynak erişimini sınırlandırmak için kullanılır (bkz. Kod 5).
Bu yapıyı bir banka gişesine benzetebiliriz. Gişe sayısı 2 ise aynı anda sadece 2 müşteri işlem yapabilir; diğerleri sıraya girer. Bir müşteri işini bitirip kalktığında, sıradaki bir sonraki müşteri masaya geçer.
Projelerimizde bu ihtiyaç genellikle şu şekilde ortaya çıkıyor: Eş zamanlı 10 arka plan işlemi var ve hepsi aynı veritabanı bağlantısına yazmak istiyor. Bu durumda veri bütünlüğünü korumak için erişimi kısıtlamak gerekiyor.
4. Dispatch Sources (Dağıtım Kaynakları)
Dispatch Sources, GCD'nin belki de en az bilinen ama en güçlü özelliklerinden biridir. Sistem seviyesindeki olayları — dosya değişiklikleri, zamanlayıcılar, sinyaller, işlemci olayları gibi — izlemek ve bu olaylara tepki vermek için kullanılır.
Bir proje için düşünün: Kullanıcı uygulamadan çıkmadan önce arka planda otomatik kaydetme işlemi yapılması gerekiyor ya da belirli aralıklarla token yenilemesi tetiklenmeli (bkz. Kod 6). İşte burada Dispatch Sources devreye giriyor.
Timer ile Periyodik İşlem:
Dosya Değişikliklerini İzleme:
Dosya sistemi olaylarını Dispatch Source aracılığıyla izleyebiliriz (bkz. Kod7).
Dispatch Sources ile ilgili dikkat edilmesi gereken önemli bir nokta: Başlatılan her kaynak, iş bittiğinde cancel() ile durdurulmalıdır. Aksi takdirde bellek sızıntısı ve gereksiz sistem kaynağı tüketimi söz konusu olabilir. Özellikle ViewController'ın deinit() metodunda kaynaklarınızı temizlemeyi alışkanlık haline getirmenizi öneririm.
Sonuç
GCD, iOS geliştirme süreçlerinde performans ve kullanıcı deneyimi açısından vazgeçilmez bir yapı taşıdır. Apple’ın resmi dokümantasyonunda da vurgulandığı üzere, görevlerin uygun kuyruklara dağıtılması ve ana iş parçacığının bloklanmaması, uygulama yanıt süresini ve algılanan performansı doğrudan etkiler (bkz. Apple Dispatch Dokümantasyonu). Kod örnekleriyle (Kod 1–7) ele aldığımız bu yapı taşları doğru kullanıldığında, hem kararlı hem de yüksek performanslı uygulamalar geliştirmek mümkündür (bkz. DispatchQueue, DispatchGroup ve Concurrency Programming Guide).
Kaynakça
- Apple Inc. (2025). Dispatch (Grand Central Dispatch) Documentation. https://developer.apple.com/documentation/dispatch
- Apple Inc. (2025). DispatchQueue. https://developer.apple.com/documentation/dispatch/dispatchqueue
- Apple Inc. (2025). DispatchGroup. https://developer.apple.com/documentation/dispatch/dispatchgroup
- Apple Inc. (2025). DispatchSemaphore. https://developer.apple.com/documentation/dispatch/dispatchsemaphore
- Apple Inc. (2012). Concurrency Programming Guide – Dispatch Sources. https://developer.apple.com/documentation/dispatch/dispatch-source
- Wikipedia Contributors. (2026). Grand Central Dispatch. https://en.wikipedia.org/wiki/Grand_Central_Dispatch
Sağlıklı kodlar dilerim! 🚀
