Swift protokolleri ilişkili türler (PATs) veya Self gereksinimleri ile birlikte birinci sınıf varlık türleri olarak işlev göremez (örneğin, [MyProtocol]) çünkü derleyici, ilişkili türler için tanık tablolarını derleme zamanında oluşturmak için gereken somut tür meta verilerine sahip değildir. Bu sınırlama, heterojen koleksiyonların doğrudan örnekleri depolamasını engeller, çünkü ilişkili türlerin bellek düzeni uyumlu türler arasında değişir. Geliştiriciler, protokol tanık tablolarını veya kapalı tabanlı dağıtımı kullanarak arayüz erişimini homojenleştiren ve altında yatan ilişkili tür karmaşıklığını kapsülleyen tür silme kalıpları aracılığıyla bu kısıtlamayı aşarlar.
Bir çapraz platform medya motoru tasarlarken, ekibimizin MP3, AAC ve FLAC dahil olmak üzere çeşitli ses codec'lerini yönetebilen bir PlaylistController'a ihtiyacı vardı. Her biri Playable protokolünü uyguluyordu ve bu protokol, dekode edilmiş ses örneklerini temsil eden ilişkili bir Buffer türü içeriyordu. İlişkili Buffer, formatlar arasında önemli ölçüde farklıydı: FLAC için sıkıştırılmamış PCM verisi, MP3 için ise sıkıştırılmış paketler; bu da standart çok biçimlilik depolamasını engelleyen uyumsuz bellek düzenleri yarattı.
Bir yaklaşım, genel sınıflama kullanarak Playlist<T: Playable> oluşturmaktır ve bu, tüm koleksiyonu tek bir somut türe kısıtlar. Bu, çalışma zamanı dağıtım aşamasını ortadan kaldırır ve iç içe geçirme gibi yoğun derleyici optimizasyonlarını mümkün kılar. Ancak bu yaklaşım, tamamen çok biçimlilikten vazgeçer ve kullanıcıların MP3 ve FLAC parçalarını aynı çalma listesi yapısında karıştırmasını engeller.
Alternatif olarak, geliştiriciler modern Swift'te mevcut olan [any Playable] sözdizimini kullanarak Swift'in yerel varlık konteynerlerinden yararlanabilir. Bu, heterojen depolamayı desteklerken, ilişkili Buffer türüne erişim, her çağrı noktasında varlıkları manuel olarak açmayı gerektirir ve bu da ayrıntılı bir boilerplate oluşturur ve büyük değer türleri için yığın tahsisi zorunlu kılar. Ayrıca, somut tür bilgisi kaybı, derleyicinin yöntem çağrılarını sanallaştırmasını engeller, bu da sıkı ses işleme döngülerinde ölçülebilir bir yük getirir.
En uygun çözüm, play() ve stop() yöntemlerini devretmek için kapalı tabanlı tanık tabloları kullanan AnyPlayable adlı manuel bir tür silme kutusunu uygulamaktır. Bu sarıcı, somut örneği sınıf tabanlı bir konteynerde veya varlık tamponunda saklar, ilişkili tür karmaşıklığını gizlerken, tek tip bir arayüz sunar. Bu, sanal dağıtıma benzer bir dolaylılık yükü getirse de, tampon uygulama farklılıklarını başarılı bir şekilde soyutlar ve çalışma zamanı dönüştürme karmaşıklığı olmadan gerçek heterojen koleksiyonları destekler.
Medya uygulamalarının, birleşik çalma listeleri içinde çeşitli codec'leri karıştırmak zorunda kalması nedeniyle tür silme sarıcı yaklaşımını seçtik ve sanal dağıtımın yükü, ses akışı sırasında I/O gecikmesine göre önemsizdir. Uygulama, özel DRM formatlarının standart codec'lerle entegre edilmesini sağladı ve Controller'ın mimarisini değiştirmeden kullanıcı tarafından hazırlanmış içerik kütüphaneleri için gerekli çalışma zamanı esnekliğini sağladı. Sonuçta, parça başlatma sırasında derleme zamanı tür güvenliğini korurken, kullanıcıya özel içerik kütüphaneleri için gerekli çalışma zamanı esnekliğini sağladı.
Soru 1: Neden somut türleri varolmuş türlere as! any Playable olarak basitçe dönüştüremiyoruz?
Swift, ilişkili türlerle birlikte protokolleri çıplak varlıklar olarak kullanmayı yasaklar çünkü varlık konteynerinin sabit boyutlu iç depolama (tipik olarak üç kelime) gereksinimi vardır ve ilişkili türler keyfi olarak büyük bellek alanları talep edebilir. Buffer ilişkili türü FLAC için 512 byte'lık bir dekode çerçevesini ancak MP3 için 4 byte'lık bir paket indeksini temsil ettiğinde, varlık her ikisini de sabit ön bellekte depolayamaz. Sonuç olarak, derleyici bellek güvenliğini sağlamak için tür silme veya genel kısıtlamaları zorlar ve yığın bozulması veya tampon taşmaları nedeniyle çalışma zamanı çökmelerini önler.
Soru 2: Swift 5.1'in Opak Sonuç Türleri (some Collection), tür silme kutuları açısından performans ve API evrimi bakımından nasıl farklılık gösterir?
Opak sonuç türleri, derleyiciye somut tür bilgilerini tamamen koruma imkanı tanıyan ters genel türler ve derleme zamanı özel insanları kullanır ve arama ayrıntılarını arayanlardan gizler. Bu, manuel tür silme kutularında bulunan sanal dağıtım ceza ve yığın tahsis maliyetlerinden kaçınır. Ancak, opak türlerin dönüş noktasında alt türün sabit tutulmasını gerektirmesi (birden fazla opak sonuç için SE-0368 hariç), tür silme kutularının aynı konteyner içinde somut türlerin dinamik değişimini sağlar, bu da performans karşılığında çok biçimlilik esnekliği sağlar.
Soru 3: Tür silme kutuları, çoklu iş parçacığı ortamlarında öz referanslı protokolleri (örneğin, Self döndüren yöntemleri olan protokoller) yakaladığında hangi bellek yönetim tehlikeleri ortaya çıkar?
Tür silme kutuları genellikle somut örnekleri depolamak için sınıf tabanlı sarıcılar veya kapalı yakalamalar kullanır. Protokol Self döndürmeyi veya Self'e atıfta bulunan ilişkili türleri gerektiriyorsa, kutunun tür kimliğini referans mantığıyla koruması gerekir; bu da somut türün kutuya geri referans tuttuğu durumlarda potansiyel tutma döngüleri oluşturur. Paralel bağlamlarda, kutulmuş durumu değiştiren birden fazla iş parçacığı, referans sayısını veya iç tamponları üzerinde yarış durumları tetikleyebilir. Geliştiricilerin, genellikle kutu içinde Actor izolasyonu veya değişmez değer mantığı uygulayarak Sendable'a uygun olmasını sağlamaları gerekir; böylece veri yarışı önlenir ve silinmiş arayüz soyutlama korunur.