WebCatalog masaüstü uygulamasıyla oluşturduğunuz her uygulama, macOS’te yaklaşık 320 MB disk alanı kaplıyordu. Bu, Electron tabanlı bir uygulama için alışılmadık bir durum değil; ancak WebCatalog, çok sayıda web uygulamasını masaüstü uygulaması olarak kullanan kişiler için tasarlandı. Bu uygulamalardan on tane yüklediğinizde, içlerindeki verilerin çoğu birebir aynı olmasına rağmen 3 GB’tan fazla yer kaplayabiliyorlardı.
Yakın zamanda WebCatalog masaüstü uygulamasının macOS’te uygulama oluşturma biçimini değiştirdik. İlk uygulama, yerel olarak saklanan hazırlanmış bir uygulama motoru kopyası da dahil olmak üzere artık yaklaşık 340 MB fiziksel disk alanı kullanıyor. Bundan sonra eklenen her uygulama ise genellikle yalnızca 1–2 MB gerçek disk kullanımı ekliyor. Testlerimizde on uygulamanın kapladığı alan 3 GB’ın üzerinden yaklaşık 360 MB’a düştü.
Bunu, macOS’te zaten bulunan bir özellik olan APFS klonlarını kullanarak yaptık. İşin ilginç yanı yalnızca dosyaları klonlamak değildi. Her uygulama bağımsız, doğru şekilde kod imzalı ve eski yöntemle oluşturulmuş bir uygulamayla işlevsel olarak eşdeğer kalırken klonlamanın çalışmasını sağlamaktı.
Her uygulama neden 320 MB daha kullanıyordu?
WebCatalog masaüstü uygulaması, web sitelerini bağımsız masaüstü uygulamalarına dönüştürür. Oluşturduğunuz her uygulama, Electron üzerine kurulu uygulama motorumuz Photon üzerinde çalışır. macOS’te bunların her biri Electron (Chromium ve Node.js), Photon ve ilgili uygulamaya özgü dosyaları içeren normal bir .app paketidir.
Örneğin Slack ve Discord uygulamalarını ele alalım. Adları, simgeleri, paket tanımlayıcıları ve yapılandırmaları farklıdır; ancak büyük Electron çatısı ve Photon’un büyük bölümü aynıdır.
Şimdiye kadar her uygulama, tamamen ayrı bir kopya olarak oluşturuluyordu.
Slack.app
Electron
Photon
Slack’e özgü dosyalar
Discord.app
Electron
Photon
Discord’a özgü dosyalar
Electron çatısı ve Photon her iki uygulamada bayt bayt aynı olsa bile macOS, her uygulama için bir fiziksel kopya daha saklıyordu. Dolayısıyla on uygulama, neredeyse aynı 320 MB’lık uygulama paketinin yaklaşık on kopyası anlamına geliyordu.
Bu mimarinin korumak istediğimiz bir özelliği vardı: Her uygulama tamamen bağımsızdı. Birini silmek diğerini etkileyemiyordu ve yüklü uygulamaların çalışmaya devam etmesi, WebCatalog masaüstü uygulamasının sistemde bulunmasına bağlı değildi.
Ortadan kaldırmak istediğimiz şey, bunların temelindeki gereksiz veri tekrarlarıydı.
İhtiyacımız olan temel mekanizma APFS’de zaten vardı
Modern Mac’ler Apple’ın APFS dosya sistemini kullanır. APFS, iki bağımsız dosyanın biri değişene kadar aynı fiziksel verileri paylaşmasını sağlayan bir kopyalama sırasında yazma mekanizması olan klonlamayı destekler.
300 MB’lık bir dosyayı kopyaladığınızı düşünün. Normal bir kopyalamada macOS diske 300 MB daha yazar; böylece iki dosya toplamda yaklaşık 600 MB yer kaplar.
APFS klonunda ise yeni dosya hâlâ eksiksiz bir 300 MB’lık dosya gibi görünür ve davranır, ancak başlangıçta orijinaliyle aynı fiziksel blokları işaret eder.
Dosya A ───┐
├── paylaşılan fiziksel bloklar
Dosya B ───┘
Dosya B’nin bir bölümü daha sonra değişirse APFS yalnızca değişen veriler için yeni bloklar yazar. Aynı kalan her şey orijinal blokları paylaşmaya devam edebilir.
Dosya A ──────── paylaşılan bloklar
Dosya B ──────── paylaşılan bloklar
└─────── değişen bloklar
Uygulama açısından Dosya A ve Dosya B ayrı dosyalardır. SSD açısından ise aynı verinin yalnızca bir kez saklanması yeterlidir.
İhtiyacımız olan davranış neredeyse tam olarak buydu.
Uygulamaları ortak bir tabandan oluşturmak
WebCatalog masaüstü uygulaması artık Electron ve Photon sürümlerinin her birleşimi için bir taban hazırlıyor. Photon taban uygulaması; Electron, Photon, çatı yapısı ve ortak imzalar dahil, uygulamalar arasında aynı olan bölümleri içeriyor.
Masaüstü uygulaması aynı sürümleri kullanan başka bir uygulama oluşturduğunda, artık sıfırdan başka bir tam kopya çıkarıp oluşturmuyor. Bunun yerine Photon taban uygulamasının bir APFS klonunu oluşturuyor ve yalnızca farklı olması gereken bölümleri özelleştiriyor.
Bunlar arasında uygulama adı, simgesi, paket tanımlayıcısı, ayarları, yürütülebilir dosya adları, derleme tanımlayıcısı ve uygulamaya özgü diğer meta veriler bulunuyor.
Paketin büyük bölümü değişmeden kaldığı için APFS, Electron ve Photon’u içeren fiziksel blokları paylaşmaya devam ediyor. Yalnızca uygulamaya özgü, görece küçük miktardaki veri yeni alan kullanıyor.
Neden yalnızca Electron’u paylaşmıyoruz?
Daha bariz bir yaklaşım, Electron’u bir kez yükleyip bütün uygulamaların onu kullanmasını sağlamak olurdu.
Bunu değerlendirdik, ancak güvenilirlik modelini temelden değiştirirdi. Paylaşılan Electron kurulumu ortadan kalkarsa ona bağlı bütün uygulamalar çalışmayı durdurabilir. Bir önbellek temizleme aracı onu silebilir, WebCatalog masaüstü uygulamasını kaldırmak onu kaldırabilir ve tek bir uygulamayı taşımak veya geri yüklemek daha karmaşık hâle gelirdi.
Ayrıca eski sürümlerin güvenle temizlenebilmesi için hangi yüklü uygulamaların hangi çalışma ortamı sürümlerine bağlı olduğunu izlemek gerekirdi.
macOS kod imzalama da başka bir sorun yaratıyor. Katı imza doğrulaması, uygulama paketinin dışına işaret eden sembolik bağlantıları reddediyor.
APFS klonları, böyle bir bağımlılık oluşturmadan paylaşımın faydalı kısmını sağlıyor. Yüklü uygulamalar, eksiksiz ve bağımsız uygulama paketleri olarak kalırken fiziksel disk bloklarını paylaşabiliyor.
Photon taban uygulamasını silmek, ondan oluşturulan uygulamaları bozmaz. Yüklü uygulamalardan birini silmek diğerini etkilemez. Uygulama mimarisi bağımsız kalırken paylaşımı dosya sistemi yönetir.
Kod imzalama, tasarrufu neredeyse ortadan kaldırıyordu
Uygulamayı klonlamak, sorunun yalnızca bir kısmıydı. macOS uygulamalarının kod imzasına da ihtiyacı var.
Eski oluşturma sürecimiz, özelleştirmeden sonra her uygulama paketini iç içe bileşenleriyle birlikte yeniden imzalıyordu. Normal bir kopyada bu sorun değil. Ancak kopyalama sırasında yazma yönteminde, büyük bir ikili dosyayı değiştirmek APFS’nin ona yeni fiziksel bloklar ayırmasına neden olabilir.
Geliştirme sırasında yaptığımız ölçümlerde, Electron çatısını yeniden imzalamanın uygulama başına yaklaşık 194 MB fiziksel depolama alanı eklediğini gördük. Uygulama oluştururken Electron’u kopyalamaktan kaçınmış, ancak imzalama sırasında büyük bölümünü yeniden çoğaltmıştık.
Bu yüzden imzalama sürecinin de değişmesi gerekiyordu.
Büyük ortak çatı artık Photon taban uygulamasının bir parçası olarak imzalanıyor. Masaüstü uygulaması bu tabanı klonladığında, paylaşılan büyük ikili dosyaları değiştirmiyoruz ve yalnızca uygulamalar arasında farklı olması gereken daha küçük bölümleri yeniden imzalıyoruz.
Uygulama tamamlandığında, her şeyin geçerli kaldığından emin olmak için bitmiş paket üzerinde katı imza doğrulaması çalıştırıyoruz.
Böylece hem macOS’in kod imzalama güvencelerini hem de APFS’nin sağladığı depolama tasarrufunu koruyabiliyoruz.
Node.js’den klonlama istediğimizde aslında klonlama yapmaması
Beklenmedik bir sorun daha vardı: klonlama işleminin kendisi.
Node.js, kopyalama sırasında yazma davranışını istemek için COPYFILE_FICLONE ve COPYFILE_FICLONE_FORCE dahil bazı kopyalama bayrakları sunuyor. Kâğıt üzerinde bunlar tam da ihtiyacımız olan API’ler gibi görünüyordu.
Node.js 24 üzerinde yaptığımız testlerde aynı 288 MB’lık Electron uygulamasını çeşitli yöntemlerle kopyaladık ve her işlemin ne kadar ek fiziksel disk alanı kullandığını ölçtük:
fs.cpSync +288 MB
fs.cpSync + COPYFILE_FICLONE +288 MB
fs.cpSync + COPYFILE_FICLONE_FORCE +288 MB
/bin/cp -c -R ~0 MB
Testimizde Node.js’nin her iki klonlama modu da tam bir fiziksel kopya oluşturdu. Beklenen klonlama gerçekleşmediğinde FORCE seçeneği bile hata bildirmedi.
macOS’in yerel cp -c işlemi beklendiği gibi davrandığından WebCatalog masaüstü uygulaması doğrudan bu mekanizmayı kullanıyor.
Bu, dosya sistemi optimizasyonlarını dosya sisteminin kendisini ölçerek doğrulamak gerektiğini de hatırlattı. Kopyalama sırasında yazma davranışı isteyen bir API’yi çağırmak, ortaya çıkan dosyaların fiziksel depolama alanını gerçekten paylaştığı anlamına gelmiyor.
Optimizasyon başarısız olsa da kurulumun sürmesini sağlamak
Disk alanından tasarruf etmek bir optimizasyondur. Bir uygulamayı başarıyla yüklemek ise zorunluluktur.
Yeni süreci, klonlama başarısız olsa bile uygulama kurulumunun aksamayacağı şekilde tasarladık. Photon taban uygulamasının hazırlanması başarısız olursa, önbellekteki taban bozulursa, klonlama başarısız olursa veya imza doğrulaması geçmezse masaüstü uygulaması, tam çıkarma ve tam imzalama kullanan önceki oluşturma sürecine geri dönüyor.
Dolayısıyla en kötü durumda kurulum başarısız olmuyor; yalnızca eskisi kadar disk alanı kullanılıyor.
Eşzamanlılığı da hesaba katmamız gerekiyordu. Photon taban uygulaması önce geçici bir dizinde hazırlanıyor ve ancak tamamlandığında nihai konumuna taşınıyor. Böylece aynı anda yürütülen iki uygulama oluşturma işlemi, yanlışlıkla yarım kalmış bir tabanı göremiyor.
Eski tabanlar da güvenle kaldırılabiliyor. Yüklü bir APFS klonu, orijinal tabanın varlığını sürdürmesine bağlı değil. Taban silinirse klon, kullanmaya devam ettiği fiziksel blokları koruyor.
Bu yöntem, her modern Mac’te varsayılan dosya sistemi olan APFS üzerinde çalışıyor. Uygulamalarınız harici bir HFS+ veya exFAT sürücüsü gibi klonlamayı desteklemeyen bir diskteyse WebCatalog masaüstü uygulaması normal kopyalamaya dönüyor. Böylece uygulamalar eskisi gibi çalışıyor, ancak alan tasarrufu sağlanmıyor. Windows ve Linux şimdilik değişmedi.
Mantıksal boyut ile fiziksel boyut aynı şey değildir
Biraz kafa karıştırabilecek bir yan etki, Finder’ın her uygulamanın boyutunu hâlâ yaklaşık 320 MB olarak gösterebilmesi.
Bu sayı, uygulamanın mantıksal boyutunu temsil ediyor. Uygulama gerçekten yaklaşık 320 MB’lık dosya içeriyor ve bu dosyalar klonlama yapılmadan başka bir yere kopyalansaydı yaklaşık bu kadar veri yazılması gerekirdi.
Değişen şey fiziksel boyut, yani bu dosyaların diskte gerçekte kaç benzersiz blok kapladığı.
İki uygulama aynı 300 MB’lık çatıyı içeriyorsa ve APFS alttaki blokları paylaşmalarına izin veriyorsa, her uygulama mantıksal olarak 300 MB içerebilir; buna karşılık ikinci uygulama neredeyse hiç yeni fiziksel veri eklemez.
Finder’ın Bilgi Ver görünümü ve du gibi araçlar bu paylaşımı mutlaka görünür kılmaz. Tasarruf en belirgin biçimde diskte gerçekte kalan boş alan miktarında görülür.
Bunu yedi gerçek uygulamayla doğruladık: Discord, Facebook, Instagram, Messenger, TikTok ve iki özel uygulama. Bu yöntemle oluşturulduklarında, eski oluşturma sürecine kıyasla yaklaşık 1,9 GB disk alanı tasarrufu sağladılar.
Altta yatan fiziksel disk ofsetlerini de kontrol ederek uygulamaların ortak Electron ve Photon verilerini blok düzeyinde paylaştığını doğruladık. Eski oluşturma süreciyle oluşturulmuş bir uygulama bu blokların hiçbirini paylaşmıyordu; bu da bize yararlı bir karşılaştırma sundu.
Sonuç
WebCatalog masaüstü uygulamasıyla yalnızca bir uygulama oluşturan biri için fark küçük. İlk uygulama, masaüstü uygulaması sonraki klonları oluşturmak için kullanılan Photon taban uygulamasını da sakladığından, eskisinden biraz daha fazla disk alanı kullanıyor.
Bundan sonra fayda hızla artıyor.
Önce
1 uygulama ~320 MB
10 uygulama >3 GB
APFS klonlamasıyla:
Sonra
1 uygulama ~340 MB
10 uygulama ~360 MB
İlk taban oluşturulduktan sonra eklenen her uygulama genellikle yalnızca 1–2 MB fiziksel disk kullanımı ekliyor.
Önemli olan, bunu paylaşılan bir çalışma ortamına bağımlılık getirmeden başarmış olmamız. APFS, aynı Electron ve Photon verilerini yalnızca bir kez saklarken her uygulama normal, bağımsız ve kendi kendine yeterli bir macOS uygulaması olarak kalıyor. Yaklaşık on uygulama yüklüyken bu, gerçek disk kullanımını sekiz kattan fazla azaltabiliyor.
Bu özellik, WebCatalog masaüstü uygulamasının macOS için en son sürümünde mevcut. Açmanız gereken bir ayar yok: Yeni uygulamalar bu özelliği otomatik olarak kullanıyor; mevcut uygulamalarınız ise bir sonraki güncellemelerinde daha az yer kaplamaya başlıyor.