- Katılım
- 17 Kasım 2023
- Mesajlar
- 5.755
- Makaleler
- 2
- Çözümler
- 8
Öncelikle şunu netleştirmek isterim: Bu yazı “iOS Android'den iyidir” tartışması yapmak için değil.
Amacım, aralarındaki teknik farkları bilmeyip, IOS'un daha az RAM ile çalıştığı için daha kötü performans vereceği algısını ve Android'in daha fazla RAM ile çalıştığı için daha kötüdür algısını kırmak.
Android de ihtiyacı kadar RAM kullanınca gayet güçlü ve stabil çalışan bir işletim sistemi.
Detayları kapsamlı şekilde açıkladım ama okumak istemeyenler için yazının sonunda kısa bir özet bölümü de hazırladım.
Felsefe farkı
Apple'ın en güçlü stratejisi, donanım konusunda her şeyin kendi elinde olması, işletim sistemi (iOS) ve yazılım geliştirme araçlarını (Xcode, Swift) tamamen kendi bünyesinde tutar. Bu kapalı ekosistem sayesinde Apple, cihazlarıyla mükemmel uyumlu ve yüksek performanslı yazılımlar geliştirebiliyor. iOS, sadece sınırlı ve homojen bir donanım için optimize edildiğinden, hem sistem hem de uygulama geliştiricileri, kodların nasıl çalışacağını çok net bir şekilde öngörebiliyor ve maksimum verim alabiliyor.
Android yazılım geliştiricileri birçok farklı donanım kombinasyonu için optimize etmesi gerekirken iOS tarafında bu çok sınırlı ve kontrol altında.
Yürütme motoru
iOS uygulamaları, Swift veya objective-C ile yazılır ve doğrudan IPhone'un ARM tabanlı işlemcisi için derlenir bu derleme işlemi araya herhangi bir katmana ihtiyaç duymaz.
Sonuç olarak uygulamalar, maksimum performans ve minimum bellek kullanımıyla doğrudan donanım üzerinde çalışır. Sanal katmanlar olmadığından bellek daha verimli kullanılır ve işlemci kodu en etkili şekilde çalıştırır.
Android uygulamaları genellikle Java veya Kotlin ile yazılır ve doğrudan makine koduna değil, önce bytecode adı verilen ara bir formata derlenir. Bu bytecode, Android runtime (art) adlı sanal makine tarafından çalıştırılır.
Art, Bytecode'u ya çalışma anında (just-ın-time - jıt) ya da uygulama yüklenirken (ahead-of-time - AOT) derleme yoluyla yerel makine komutlarına çevirir.
Bu iki aşamalı sistem, “bir kez yaz, her yerde çalıştır” mantığıyla farklı donanımlarda uyumluluk sağlar. Ancak bu esneklik, performans ve bellek açısından bir bedel getirir:
Art katmanı, ek RAM tüketir. Çeviri süreci, doğrudan donanımda çalışan iOS uygulamalarına kıyasla daha fazla kaynak kullanır.
Sonuç olarak, Android cihazlar benzer görevler için genellikle daha fazla bellek ihtiyacı duyar.
Art sanal makinesinin RAM yükünün ölçülmesi
Art'nin getirdiği teorik yük, gerçek dünya verileriyle de destekleniyor. Android Authority'nin yaptığı bir analiz, Android'deki popüler sosyal medya ve verimlilik uygulamalarının, IOS'taki muadillerine göre ortalama %40 daha fazla RAM tükettiğini ortaya koyuyor. Bazı uygulamalarda bu fark %70'e kadar çıkabiliyor.
Bu da şu anlama geliyor: Sadece uygulama çalıştırma yükü açısından bakıldığında, 8 GB RAM'li bir Android cihaz, yaklaşık 6 GB RAM'li bir IPhone'la aynı seviyede çoklu görev performansı sunabiliyor.
(Apple vs Android RAM management: Who does it better?)
Yerel kod ve oyun performansı
Burada dikkat çekici bir istisna ise yüksek performanslı oyunlar. Android'de birçok oyun, kritik performans gerektiren bölümlerde Art'yi tamamen devre dışı bırakıp doğrudan native development kit (ndk) kullanıyor. Bu sayede geliştiriciler, tıpkı IOS'ta olduğu gibi C++ gibi dillerle doğrudan yerel makine koduna derleme yapabiliyorlar.
Bu yaklaşım sayesinde, oyunlarda RAM kullanım farkı büyük ölçüde azalıyor. Aynı Android authority raporu, iOS oyunlarının Android muadillerine göre ortalama sadece %10 daha az RAM kullandığını gösteriyor.
Bu oran, genel uygulamalarda görülen %40'a varan farktan çok daha düşük.
Bu da bize şunu net şekilde gösteriyor: Oyun dışındaki uygulamalarda RAM farkının asıl kaynağı, Android'in ART/JVM sanal makine katmanıdır.
Otomatik referans sayımı (Arc)
IOS'un programlama dilleri Swift ve objective-C, bellek yönetimi için otomatik referans sayımı (Arc) adlı bir sistem kullanır. Bu sistem, derleme zamanında çalışır; yani uygulama çalışmadan önce derleyici gerekli bellek yönetim kodlarını otomatik olarak ekler.
Derleyici, her nesneye kaç tane strong (güçlü) referans olduğunu takip eden kodlar ekler. Bir nesneye artık hiçbir güçlü referans kalmadığında, Arc bunu fark eder ve o nesneyi hemen bellekten temizler. Bu yöntem, hem geliştiriciye manuel bellek yönetimi yükü bindirmez hem de uygulamaların daha verimli ve kararlı çalışmasını sağlar.
Arc'nin etkisi
Bu sistem son derece verimli, öngörülebilir ve deterministik çalışır. Yani bellek, artık ihtiyaç kalmadığı anda anında serbest bırakılır. Bu da şu avantajları getirir:
Daha düşük RAM kullanımı.
Arka planda sürekli tarama yapmadığı için daha az CPU yükü.
Sonuç olarak, daha iyi pil ömrü.
Ancak Arc'nin de bir zayıf noktası var: Referans döngüleri (retain cycles).
Bu durum, iki nesnenin birbirine güçlü referanslarla bağlı kalması sonucu oluşur. Arc, bu nesnelerin artık kullanılmadığını anlayamaz ve bellek sızıntısı ortaya çıkar.
Bu nedenle geliştiriciler, bu tür döngüleri fark edip weak/unowned referanslar kullanarak sorunu manuel olarak çözmelidir.
Nesilsel çöp toplama (gc)
Android'de bellek yönetimi: Garbage Collection (gc)
Java ve Kotlin gibi Android dilleri, bellek yönetiminde çalışma zamanı (runtime) sürecine dayanan garbage Collection (gc) sistemini kullanır.
Nasıl çalışır?
Gc, arka planda periyodik olarak çalışarak bellek yığınını (heap) tarar. Artık referans verilmeyen, yani uygulama tarafından erişilemeyen nesneleri bulur ve onların kapladığı belleği temizler.
Android, bu süreci daha verimli hâle getirmek için nesneleri yaşam süresine göre sınıflandıran "nesilsel gc" modelini kullanır.
etkileri:
Gc, bellek temizliğini geliştirici için otomatikleştirir, bu da kullanım kolaylığı sağlar.
Ancak Arc'ye göre daha az verimlidir:
Bellek, nesne kullanımı bittiği anda değil, ancak gc devreye girdiğinde temizlenir.
Bu gecikme, uygulamanın RAM kullanımını gereğinden fazla artırabilir.
Üstelik gc döngüsü yüksek CPU kullanabilir ve yanlış zamanda (örneğin animasyon sırasında) tetiklenirse arayüzde takılmalara (jank) neden olabilir?
Bellek sıkıştırma ve jetsam olayları
iOS, bellek basıncı yükseldiğinde hemen uygulamaları kapatmak yerine önce bellek sıkıştırma mekanizmasını devreye sokar. Burada kullanılan wkdm adlı özel algoritma, aktif olmayan uygulamaların uzun süredir kullanılmayan bellek sayfalarını alıp sıkıştırarak (örneğin 128 KB'ı 64 KB'a indirir) RAM'de tutar. Böylece bellek boşaltılmış olur ama uygulama sonlandırılmaz. Kullanıcı uygulamaya geri döndüğünde bu sayfalar hızla açılarak kullanıma hazır hale gelir.
Eğer bu sıkıştırma bellek ihtiyacını karşılamazsa, iOS sistem kaynaklarını korumak için arka plandaki uygulamaları kapatmaya başlar. Bu sürece “jetsam olayı” denir. Sistem, uygulamaları öncelik sırasına göre sonlandırır ve eğer bir uygulama cihazın belirlenen bellek sınırını aşarsa, exc_resource_exceptıon hatasıyla zorunlu olarak kapanır.
Bu durum, kullanıcıların uygulamaların aniden kapanıp yeniden başlamasından şikayet etmelerinin ana nedenidir.
zram, kswapd ve düşük bellek katili (lmk)
Android, bellek sıkıştırmayı Linux çekirdeğine bağlı bir şekilde uygular. RAM'in bir bölümü olan zram, sıkıştırılmış takas alanı (swap space) olarak kullanılır. Sistem boş bellek kritik bir seviyenin altına düştüğünde, kswapd adlı çekirdek süreci devreye girer.
Bu süreç, aktif olmayan uygulamalardan "kirli" (değiştirilmiş) bellek sayfalarını alır ve sıkıştırarak Zram'e taşır. Değişmemiş "temiz" sayfalar ise gerektiğinde diskten yeniden okunabileceği için atılır.
Eğer kswapd ve zram yeterince bellek boşaltamazsa, Android'in daha agresif arka plan aracı olan düşük bellek katili (Low-Memory Killer - lmk) devreye girer. Lmk, sistemin bellek kazanması için uygulama süreçlerini kapatır.
Ancak lmk süreçleri rastgele kapatmaz; bunu belirlemek için her sürece bir oom_adj_score (out_of_memory_adjustment_score) adı verilen öncelik puanı verir.
Yüksek puana sahip (düşük öncelikli) süreçler ilk kapatılanlar,
Düşük puanlı (öncelikli) süreçler ise en son kapatılanlar olur.
Böylece, arka plandaki uygulamalardan başlayarak ön plandaki uygulama ve sistem süreçlerine doğru net bir sonlandırma sırası belirlenir.
sonuç
iOS, bellek verimliliğini üç ana unsurun birleşimiyle sağlar:
-Dikey entegrasyon sayesinde özel donanım ve yazılım uyumu,
-Uygulamaların işlemci üzerinde doğrudan çalışan yerel kod ile yürütülmesi.
Belleği anında serbest bırakan, proaktif ve deterministik bellek yönetimi (Arc).
Bu sayede iOS, daha az RAM ile çok akıcı ve stabil bir kullanıcı deneyimi sunar. Ancak bunun bedeli; kapalı ekosistem, geliştirici esnekliğinde kısıtlamalar ve sınırlı çoklu görev yetenekleridir.
Öte yandan Android, açık ve esnek yapısı nedeniyle daha yüksek RAM ihtiyacına sahiptir.
-Donanımlara uyum sağlamak için kullanılan art sanal makinesi,
-Daha bağışlayıcı ama sistem için maliyetli olan çöp toplama (gc) mekanizması,
-Android'in daha izin verici arka plan görev politikası, bellek kullanımını artırır.
Android üreticileri ise bu yazılımsal yükü dengelemek için daha fazla RAM donanımsal olarak sunarak rekabetçi çoklu görev performansı sağlamaya çalışır.
Özellikle Android tarafında yapılan son güncellemler ile RAM kullanımda azalma konusunda ciddi adımlar atıldı ama daha fazla uzatmamak için detayına girmedim.
Öncelikle şunu belirtmek isterim ki; bu yazıyı tamamen sen mi yazdın diyecekler olabilir. Doğrusu, bu konuda zaten belli bir araştırmam ve bilgim vardı ama bu kadar derin ve kapsamlı değil. Yazıyı, kendi bilgimle birlikte çeşitli yabancı kaynaklardan edindiğim bilgileri harmanlayarak, forumda bulunması gerektiğini düşündüğüm için hazırladım.
www.nextpit.com
medium.com
www.androidpolice.com
Amacım, aralarındaki teknik farkları bilmeyip, IOS'un daha az RAM ile çalıştığı için daha kötü performans vereceği algısını ve Android'in daha fazla RAM ile çalıştığı için daha kötüdür algısını kırmak.
Android de ihtiyacı kadar RAM kullanınca gayet güçlü ve stabil çalışan bir işletim sistemi.
Detayları kapsamlı şekilde açıkladım ama okumak istemeyenler için yazının sonunda kısa bir özet bölümü de hazırladım.
Felsefe farkı
Apple'ın en güçlü stratejisi, donanım konusunda her şeyin kendi elinde olması, işletim sistemi (iOS) ve yazılım geliştirme araçlarını (Xcode, Swift) tamamen kendi bünyesinde tutar. Bu kapalı ekosistem sayesinde Apple, cihazlarıyla mükemmel uyumlu ve yüksek performanslı yazılımlar geliştirebiliyor. iOS, sadece sınırlı ve homojen bir donanım için optimize edildiğinden, hem sistem hem de uygulama geliştiricileri, kodların nasıl çalışacağını çok net bir şekilde öngörebiliyor ve maksimum verim alabiliyor.
Android yazılım geliştiricileri birçok farklı donanım kombinasyonu için optimize etmesi gerekirken iOS tarafında bu çok sınırlı ve kontrol altında.
Yürütme motoru
iOS uygulamaları, Swift veya objective-C ile yazılır ve doğrudan IPhone'un ARM tabanlı işlemcisi için derlenir bu derleme işlemi araya herhangi bir katmana ihtiyaç duymaz.
Sonuç olarak uygulamalar, maksimum performans ve minimum bellek kullanımıyla doğrudan donanım üzerinde çalışır. Sanal katmanlar olmadığından bellek daha verimli kullanılır ve işlemci kodu en etkili şekilde çalıştırır.
Android uygulamaları genellikle Java veya Kotlin ile yazılır ve doğrudan makine koduna değil, önce bytecode adı verilen ara bir formata derlenir. Bu bytecode, Android runtime (art) adlı sanal makine tarafından çalıştırılır.
Art, Bytecode'u ya çalışma anında (just-ın-time - jıt) ya da uygulama yüklenirken (ahead-of-time - AOT) derleme yoluyla yerel makine komutlarına çevirir.
Bu iki aşamalı sistem, “bir kez yaz, her yerde çalıştır” mantığıyla farklı donanımlarda uyumluluk sağlar. Ancak bu esneklik, performans ve bellek açısından bir bedel getirir:
Art katmanı, ek RAM tüketir. Çeviri süreci, doğrudan donanımda çalışan iOS uygulamalarına kıyasla daha fazla kaynak kullanır.
Sonuç olarak, Android cihazlar benzer görevler için genellikle daha fazla bellek ihtiyacı duyar.
Art sanal makinesinin RAM yükünün ölçülmesi
Art'nin getirdiği teorik yük, gerçek dünya verileriyle de destekleniyor. Android Authority'nin yaptığı bir analiz, Android'deki popüler sosyal medya ve verimlilik uygulamalarının, IOS'taki muadillerine göre ortalama %40 daha fazla RAM tükettiğini ortaya koyuyor. Bazı uygulamalarda bu fark %70'e kadar çıkabiliyor.
Bu da şu anlama geliyor: Sadece uygulama çalıştırma yükü açısından bakıldığında, 8 GB RAM'li bir Android cihaz, yaklaşık 6 GB RAM'li bir IPhone'la aynı seviyede çoklu görev performansı sunabiliyor.
| Uygulama | Android RAM Kullanımı (MB) | iOS RAM Kullanımı (MB) | Android'in Ekstra Kullanım Oranı | |
| eBay | 466 | 212 | +120% | |
| Amazon | 422 | 239 | +77% | |
| Google Haritalar | 213 | 125 | +70% | |
| Spotify | 171 | 108 | +58% | |
| Gmail | 212 | 158 | +34% | |
| 245 | 185 | +32% | ||
| 301 | 245 | +23% | ||
| 275 | 245 | +12% | ||
| Ortalama | ~+40% |
Yerel kod ve oyun performansı
Burada dikkat çekici bir istisna ise yüksek performanslı oyunlar. Android'de birçok oyun, kritik performans gerektiren bölümlerde Art'yi tamamen devre dışı bırakıp doğrudan native development kit (ndk) kullanıyor. Bu sayede geliştiriciler, tıpkı IOS'ta olduğu gibi C++ gibi dillerle doğrudan yerel makine koduna derleme yapabiliyorlar.
Bu yaklaşım sayesinde, oyunlarda RAM kullanım farkı büyük ölçüde azalıyor. Aynı Android authority raporu, iOS oyunlarının Android muadillerine göre ortalama sadece %10 daha az RAM kullandığını gösteriyor.
Bu oran, genel uygulamalarda görülen %40'a varan farktan çok daha düşük.
Bu da bize şunu net şekilde gösteriyor: Oyun dışındaki uygulamalarda RAM farkının asıl kaynağı, Android'in ART/JVM sanal makine katmanıdır.
Otomatik referans sayımı (Arc)
IOS'un programlama dilleri Swift ve objective-C, bellek yönetimi için otomatik referans sayımı (Arc) adlı bir sistem kullanır. Bu sistem, derleme zamanında çalışır; yani uygulama çalışmadan önce derleyici gerekli bellek yönetim kodlarını otomatik olarak ekler.
Derleyici, her nesneye kaç tane strong (güçlü) referans olduğunu takip eden kodlar ekler. Bir nesneye artık hiçbir güçlü referans kalmadığında, Arc bunu fark eder ve o nesneyi hemen bellekten temizler. Bu yöntem, hem geliştiriciye manuel bellek yönetimi yükü bindirmez hem de uygulamaların daha verimli ve kararlı çalışmasını sağlar.
Arc'nin etkisi
Bu sistem son derece verimli, öngörülebilir ve deterministik çalışır. Yani bellek, artık ihtiyaç kalmadığı anda anında serbest bırakılır. Bu da şu avantajları getirir:
Daha düşük RAM kullanımı.
Arka planda sürekli tarama yapmadığı için daha az CPU yükü.
Sonuç olarak, daha iyi pil ömrü.
Ancak Arc'nin de bir zayıf noktası var: Referans döngüleri (retain cycles).
Bu durum, iki nesnenin birbirine güçlü referanslarla bağlı kalması sonucu oluşur. Arc, bu nesnelerin artık kullanılmadığını anlayamaz ve bellek sızıntısı ortaya çıkar.
Bu nedenle geliştiriciler, bu tür döngüleri fark edip weak/unowned referanslar kullanarak sorunu manuel olarak çözmelidir.
Nesilsel çöp toplama (gc)
Android'de bellek yönetimi: Garbage Collection (gc)
Java ve Kotlin gibi Android dilleri, bellek yönetiminde çalışma zamanı (runtime) sürecine dayanan garbage Collection (gc) sistemini kullanır.
Nasıl çalışır?
Gc, arka planda periyodik olarak çalışarak bellek yığınını (heap) tarar. Artık referans verilmeyen, yani uygulama tarafından erişilemeyen nesneleri bulur ve onların kapladığı belleği temizler.
Android, bu süreci daha verimli hâle getirmek için nesneleri yaşam süresine göre sınıflandıran "nesilsel gc" modelini kullanır.
etkileri:
Gc, bellek temizliğini geliştirici için otomatikleştirir, bu da kullanım kolaylığı sağlar.
Ancak Arc'ye göre daha az verimlidir:
Bellek, nesne kullanımı bittiği anda değil, ancak gc devreye girdiğinde temizlenir.
Bu gecikme, uygulamanın RAM kullanımını gereğinden fazla artırabilir.
Üstelik gc döngüsü yüksek CPU kullanabilir ve yanlış zamanda (örneğin animasyon sırasında) tetiklenirse arayüzde takılmalara (jank) neden olabilir?
Bellek sıkıştırma ve jetsam olayları
iOS, bellek basıncı yükseldiğinde hemen uygulamaları kapatmak yerine önce bellek sıkıştırma mekanizmasını devreye sokar. Burada kullanılan wkdm adlı özel algoritma, aktif olmayan uygulamaların uzun süredir kullanılmayan bellek sayfalarını alıp sıkıştırarak (örneğin 128 KB'ı 64 KB'a indirir) RAM'de tutar. Böylece bellek boşaltılmış olur ama uygulama sonlandırılmaz. Kullanıcı uygulamaya geri döndüğünde bu sayfalar hızla açılarak kullanıma hazır hale gelir.
Eğer bu sıkıştırma bellek ihtiyacını karşılamazsa, iOS sistem kaynaklarını korumak için arka plandaki uygulamaları kapatmaya başlar. Bu sürece “jetsam olayı” denir. Sistem, uygulamaları öncelik sırasına göre sonlandırır ve eğer bir uygulama cihazın belirlenen bellek sınırını aşarsa, exc_resource_exceptıon hatasıyla zorunlu olarak kapanır.
Bu durum, kullanıcıların uygulamaların aniden kapanıp yeniden başlamasından şikayet etmelerinin ana nedenidir.
zram, kswapd ve düşük bellek katili (lmk)
Android, bellek sıkıştırmayı Linux çekirdeğine bağlı bir şekilde uygular. RAM'in bir bölümü olan zram, sıkıştırılmış takas alanı (swap space) olarak kullanılır. Sistem boş bellek kritik bir seviyenin altına düştüğünde, kswapd adlı çekirdek süreci devreye girer.
Bu süreç, aktif olmayan uygulamalardan "kirli" (değiştirilmiş) bellek sayfalarını alır ve sıkıştırarak Zram'e taşır. Değişmemiş "temiz" sayfalar ise gerektiğinde diskten yeniden okunabileceği için atılır.
Eğer kswapd ve zram yeterince bellek boşaltamazsa, Android'in daha agresif arka plan aracı olan düşük bellek katili (Low-Memory Killer - lmk) devreye girer. Lmk, sistemin bellek kazanması için uygulama süreçlerini kapatır.
Ancak lmk süreçleri rastgele kapatmaz; bunu belirlemek için her sürece bir oom_adj_score (out_of_memory_adjustment_score) adı verilen öncelik puanı verir.
Yüksek puana sahip (düşük öncelikli) süreçler ilk kapatılanlar,
Düşük puanlı (öncelikli) süreçler ise en son kapatılanlar olur.
Böylece, arka plandaki uygulamalardan başlayarak ön plandaki uygulama ve sistem süreçlerine doğru net bir sonlandırma sırası belirlenir.
sonuç
iOS, bellek verimliliğini üç ana unsurun birleşimiyle sağlar:
-Dikey entegrasyon sayesinde özel donanım ve yazılım uyumu,
-Uygulamaların işlemci üzerinde doğrudan çalışan yerel kod ile yürütülmesi.
Belleği anında serbest bırakan, proaktif ve deterministik bellek yönetimi (Arc).
Bu sayede iOS, daha az RAM ile çok akıcı ve stabil bir kullanıcı deneyimi sunar. Ancak bunun bedeli; kapalı ekosistem, geliştirici esnekliğinde kısıtlamalar ve sınırlı çoklu görev yetenekleridir.
Öte yandan Android, açık ve esnek yapısı nedeniyle daha yüksek RAM ihtiyacına sahiptir.
-Donanımlara uyum sağlamak için kullanılan art sanal makinesi,
-Daha bağışlayıcı ama sistem için maliyetli olan çöp toplama (gc) mekanizması,
-Android'in daha izin verici arka plan görev politikası, bellek kullanımını artırır.
Android üreticileri ise bu yazılımsal yükü dengelemek için daha fazla RAM donanımsal olarak sunarak rekabetçi çoklu görev performansı sağlamaya çalışır.
Özellikle Android tarafında yapılan son güncellemler ile RAM kullanımda azalma konusunda ciddi adımlar atıldı ama daha fazla uzatmamak için detayına girmedim.
Öncelikle şunu belirtmek isterim ki; bu yazıyı tamamen sen mi yazdın diyecekler olabilir. Doğrusu, bu konuda zaten belli bir araştırmam ve bilgim vardı ama bu kadar derin ve kapsamlı değil. Yazıyı, kendi bilgimle birlikte çeşitli yabancı kaynaklardan edindiğim bilgileri harmanlayarak, forumda bulunması gerektiğini düşündüğüm için hazırladım.
Apple vs Android RAM management: Who does it better?
iPhones tend to have less RAM than Android devices? Why is that? Does it mean iOS is better optimized? Which is better at RAM management?
www.androidauthority.com
Android vs iOS: how different is their RAM management?
In the ongoing debate between Android and iOS one key question has been which operating system uses more RAM? Here we examine how RAM management actually works for both.
www.nextpit.com
Title: Mastering Memory Management: A Deep Dive into Weak and Unowned References in Swift
Introduction
Why Android needs more RAM than iOS
The iPhone 14 Pro Max and the Google Pixel 6a both have 6GB of RAM 🤔
www.androidpolice.com
Ama işin aslı öyle değil. Apple işletim sisteminin gerektirdiği donanım neyse onu koyuyor. Fazla sandığın donanım aslında Android'in performans kayıplarını kapatmak için kullanılıyor. Halbuki aynı seviyedeki işi yukarıda belirttiğim üzere daha az işlemci gücü ve bellek kullanarak yapıyor. Zaten pil testlerinde bunu görmek mümkün. 4500 mAh pilli iPhonelar 5000 mAh pilli Androidlerden daha uzun kullanım süreleri sunuyorlar.
