16 KB sayfa boyutlarını destekleme

Android, geçmişte yalnızca 4 KB bellek sayfası boyutlarını desteklemişti. Bu da Android cihazların genellikle sahip olduğu toplam bellek miktarı için sistem belleği performansını optimize etmişti. Android 15'ten itibaren AOSP, 16 KB sayfa boyutu kullanacak şekilde yapılandırılmış cihazları (16 KB cihazlar) destekler. Uygulamanız doğrudan veya bir SDK üzerinden dolaylı olarak NDK kitaplıkları kullanıyorsa uygulamanızı 16 KB'lık cihazlarda çalışacak şekilde yeniden oluşturmanız gerekir.

Cihaz üreticileri daha fazla fiziksel bellek (RAM) içeren cihazlar üretmeye devam ettikçe bu cihazların çoğu, cihazın performansını optimize etmek için 16 KB (ve sonunda daha büyük) sayfa boyutlarını kullanacak. 16 KB sayfa boyutuna sahip cihazlar için destek eklemek, uygulamanızın bu cihazlarda çalışmasını sağlar ve uygulamanızın ilgili performans iyileştirmelerinden yararlanmasına yardımcı olur. Yeniden derlenmeyen uygulamalar, gelecekteki Android sürümlerinde 16 KB'lık cihazlarda çalışmayacaktır.

Uygulamanıza destek eklemenize yardımcı olmak için uygulamanızın etkilenip etkilenmediğini kontrol etme, uygulamanızı yeniden oluşturma (geçerliyse) ve emülatörleri (Android Emulator için Android 15 sistem görüntüleri dahil) kullanarak uygulamanızı 16 KB ortamında test etme hakkında rehberlik sağladık.

Google Play uyumluluk şartı

Uygulamanızın Android'in en son sürümlerinde doğru şekilde çalışmasını sağlamak için Android 15 (API düzeyi 35) ve sonraki sürümleri hedefleyen tüm uygulamaların Google Play'deki 64 bit cihazlarda 16 KB bellek sayfası boyutlarını desteklemesi gerekir. 1 Şubat 2027'den itibaren, uygulama güncellemeleriniz 16 KB'lık bellek sayfası boyutlarını desteklemiyorsa bu güncellemeleri yayınlayamazsınız.

Avantajlar ve performans artışları

16 KB sayfa boyutlarıyla yapılandırılan cihazlar, ortalama olarak biraz daha fazla bellek kullanır. Ancak, hem sistem hem de uygulamalar için çeşitli performans iyileştirmeleri sağlar:

• Sistem bellek baskısı altındayken daha düşük uygulama başlatma süreleri: Test ettiğimiz bazı uygulamalarda daha belirgin iyileştirmeler (%30'a varan) ile birlikte ortalama %3, 16 daha düşük
• Uygulama başlatma sırasında güç tüketimi azaltıldı: Ortalama% 4,56 oranında azalma
• Daha hızlı kamera başlatma: Ortalama% 4,48 daha hızlı çalışır durumda başlatma ve ortalama% 6,60 daha hızlı soğuk başlatma
• İyileştirilmiş sistem önyükleme süresi: Ortalama %8 (yaklaşık 950 milisaniye) iyileşme

Bu iyileştirmeler, ilk testlerimizi temel almaktadır ve gerçek cihazlardaki sonuçlar büyük olasılıkla farklılık gösterecektir. Testlerimizi sürdürürken uygulamaların olası kazanımlara ilişkin ek analizler sağlayacağız.

Uygulamanızın etkilenip etkilenmediğini kontrol edin

Uygulamanız yerel kod kullanıyorsa uygulamanızı 16 KB cihazları destekleyecek şekilde yeniden oluşturmanız gerekir. Uygulamanızın yerel kod kullanıp kullanmadığından emin değilseniz APK Analiz Aracı'nı kullanarak yerel kod olup olmadığını belirleyebilir ve ardından bulduğunuz paylaşılan kitaplıklar için ELF segmentlerinin hizalamasını kontrol edebilirsiniz. Android Studio, hizalama sorunlarını otomatik olarak algılamanıza yardımcı olan özellikler de sunar.

Uygulamanızda yalnızca Java programlama dilinde veya Kotlin'de yazılmış kodlar (tüm kitaplıklar veya SDK'lar dahil) kullanılıyorsa uygulamanız 16 KB cihazları zaten destekliyor demektir. Bununla birlikte, uygulama davranışında beklenmedik bir gerileme olmadığını doğrulamak için uygulamanızı 16 KB ortamında test etmenizi öneririz.

Uygulamanızda yerel kod kullanılıyor mu?

Aşağıdakilerden herhangi biri geçerliyse uygulamanızda yerel kod kullanılıyor demektir:

• Uygulamanızda herhangi bir C/C++ (yerel) kodu kullanılıyor. Uygulamanız Android NDK'yı kullanıyorsa yerel kod kullanıyor demektir.
• Uygulamanız, bunları kullanan herhangi bir üçüncü taraf yerel kitaplığına veya bağımlılığına (ör. SDK'lar) bağlanıyor.
• Uygulamanız, cihazda yerel kitaplıklar kullanan üçüncü taraf bir uygulama oluşturucu tarafından geliştirilmiştir.

APK Analizcisi'ni kullanarak yerel kitaplıkları belirleme

APK Analizcisi, oluşturulmuş bir APK'nın çeşitli yönlerini değerlendirmenize olanak tanıyan bir araçtır. Uygulamanızın yerel kod kullanıp kullanmadığını kontrol etmek için (16 KB ile uyumlu olup olmadığına bakılmaksızın):

1. Android Studio'yu açın, ardından Dosya > Aç'ı tıklayın ve herhangi bir projeyi seçin.

2. Menü çubuğundan Build > Analyze APK... (Derleme > APK'yı analiz et...) seçeneğini tıklayın.

   

3. Analiz etmek istediğiniz APK'yı seçin.

4. Paylaşılan nesne (.so) dosyalarının bulunduğu lib klasörüne göz atın. Paylaşılan nesne dosyaları varsa uygulamanız yerel kod kullanıyordur. Hizalama sütununda, hizalama sorunları olan tüm dosyalarla ilgili uyarı mesajları gösterilir. Paylaşılan nesne dosyası yoksa veya lib klasörü bulunmuyorsa uygulamanız yerel kod kullanmıyordur.

   

Otomatik kontrollerle hizalama sorunlarını tespit etme

Android Studio, önceden oluşturulmuş kitaplıklarınız veya APK'larınız 16 KB'a uygun değilse sizi proaktif olarak uyarır. Hangi kitaplıkların güncellenmesi gerektiğini veya herhangi bir kod değişikliği gerekip gerekmediğini incelemek için APK Analyzer aracını kullanın.

Android Studio'daki Lint, 16 KB'a uygun olmayan yerel kitaplıkları da vurgular.

Paylaşılan kitaplıklar için ELF segmentlerinin hizalamasını kontrol etme

Paylaşılan kitaplıklar için, paylaşılan kitaplıkların ELF segmentlerinin 16 KB ELF hizalaması kullanılarak düzgün şekilde hizalandığını doğrulayın. Linux veya macOS'te geliştirme yapıyorsanız aşağıdaki bölümde açıklandığı gibi check_elf_alignment.sh komut dosyasını kullanabilirsiniz. Ayrıca komut satırı araçlarını doğrudan da kullanabilirsiniz.

check_elf_alignment.sh komut dosyasını kullanma (Linux veya macOS)

check_elf_alignment.sh komut dosyasını kullanarak ELF segmentlerinin hizalamasını kontrol etmek için aşağıdaki adımları uygulayın:

1. check_elf_alignment.sh komut dosyasını bir dosyaya kaydedin.

2. Komut dosyasını uygulamanızın APK dosyasında çalıştırın:

   check_elf_alignment.sh APK_NAME.apk
   

   Komut dosyası, tüm arm64-v8a paylaşılan kitaplıklar için ALIGNED veya UNALIGNED çıkışını verir.

3. arm64-v8a veya x86_64 paylaşılan kitaplıklarından herhangi biri UNALIGNED ise bu kitaplıkların paketini güncellemeniz, ardından uygulamanızı yeniden derlemeniz ve bu bölümdeki adımları uygulayarak yeniden test etmeniz gerekir.

Komut satırı araçlarını doğrudan kullanma

Komut satırı araçlarını doğrudan kullanarak ELF segmentlerinin hizalamasını kontrol etmek için aşağıdaki adımları uygulayın:

1. Hem Android SDK Build-Tools 35.0.0 veya sonraki sürümlerinin hem de Android NDK'nın Android Studio'daki SDK Manager veya sdkmanager komut satırı aracı kullanılarak yüklendiğinden emin olun.

2. Uygulamanızın APK dosyasını çıkarın:

   Linux veya macOS

   unzip APK_NAME.apk -d /tmp/my_apk_out
   

   Windows (PowerShell)

   Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out
   

3. APK dosyanızı çıkardığınız geçici dizinde, paylaşılan nesne (.so) dosyaları için lib dizininin içeriğini kontrol edin. Bunlar, APK Analiz Aracı'nı kullanarak yerel kitaplıkları tanımlarken gördüğünüz paylaşılan nesne dosyalarıdır. Her paylaşılan nesne dosyasında aşağıdaki komutu çalıştırın:

   Linux veya macOS

   SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
   

   Burada SDK_ROOT_LOCATION, Android SDK'yı yüklediğiniz dizinin yolu, SHARED_OBJECT_FILE, kontrol ettiğiniz paylaşılan nesne dosyasının adı ve NDK_VERSION, yüklediğiniz Android NDK'nın sürümüdür (örneğin, 28.0.12433566). Çıktı, kontrol ettiğiniz her dosya için aşağıdakine benzer bir şekilde görünür:

   LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
   LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
   LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
   

4. Yük segmentlerinin 2**14 değerinden küçük değerler içermediğinden emin olmak için çıkış satırlarını kontrol edin. Yükleme segmentlerinden herhangi biri 2**13, 2**12 veya daha düşük değerlere sahipse bu kitaplıkların paketini güncellemeniz, ardından uygulamanızı yeniden derlemeniz ve bu bölümdeki adımları uygulayarak yeniden test etmeniz gerekir.

5. Ardından, uygulamanızın APK dosyasında zipalign komut satırı aracını çalıştırın:

   Linux veya macOS

   SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
   

   Burada SDK_ROOT_LOCATION, Android SDK'yı yüklediğiniz dizinin yolu, APK_NAME ise uygulamanızın APK dosyasının adıdır. Paylaşılan tüm kitaplıklar doğru şekilde hizalanmışsa çıktının son satırında "Doğrulama başarılı" ifadesi yer alır.

   Doğrulama başarısız olursa bazı paylaşılan kitaplıkların yeniden hizalanması gerekir. Bu nedenle, bu kitaplıkların paketini güncellemeniz, ardından uygulamanızı yeniden derlemeniz ve bu bölümdeki adımları uygulayarak yeniden test etmeniz gerekir.

RELRO güvenlik işaretini kontrol etme

Güvenlik açıklarından yararlanmayı azaltmak için modern bağlayıcılar, paylaşılan nesne dosyasının yeniden konumlandırma bölümlerini yüklendikten sonra salt okunur hale getirmek üzere Relocation Read-Only (RELRO) işaretini kullanır. Derlemenizde RELRO işaretini etkinleştirin.

Başlangıç adresi ile segment boyutu (MemSize) 16 KB ile uyumlu olmayan bir RELRO bölümü, çalışma zamanında segmentasyon hatasıyla uygulamayı kilitler. Bu durum, .so dosyası ilgili işaretler etkinleştirilmeden NDK tool chain r27 ve daha eski sürümlerle oluşturulduysa meydana gelir.

Her paylaşılan nesne dosyasında (Linux veya macOS) aşağıdaki komutu çalıştırın:

SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-readelf -Wl SHARED_OBJECT_FILE.so | grep 'RELRO\|Type'

RELRO segmenti varsa GNU_RELRO dizesi yazdırılır.

Ardından, sanal uzaklık adresini (VirtAddr) segment bellek boyutuyla (MemSiz) toplayıp 16 KB'a (0x4000) bölerek RELRO segment hizalamasını kontrol edin. Kalan (modulo) sıfırsa RELRO segmenti 16 KB ile hizalanmıştır.

Aşağıda, hizalanmamış bir .so dosyası örneği verilmiştir:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align  
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x01510 R   0x1

Formül: (VirtAddr + MemSiz) % 0x4000 == 0

Sonuç: (0xdfaf0 + 0x01510) % 0x4000 = 0xE1000 % 0x4000 == 0x1000

0x1000 sıfır olmadığı için libbad.so, 16 KB ile uyumlu değildir. DC000'dan (önceki sayfa sonu) E4000'e kadar olan RELRO koruma aralığı salt okunurdur ancak Android bağlayıcı, E1000'den E4000'e kadar olan alt aralığın yazılabilir olmasını beklediğinden segmentasyon hatası oluşur. Bu durumda, .so dosyasını Uygulamanızı 16 KB ELF uyumluluğuyla derleme bölümünde açıklandığı şekilde yeniden oluşturun.

Aşağıda, RELRO segmenti içeren, hizalanmış bir .so dosyası örneği verilmiştir:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x00510 R   0x1  

Uygulamanızı 16 KB cihazları destekleyecek şekilde oluşturun

Uygulamanız yerel kod kullanıyorsa uygulamanızın 16 KB cihazları desteklediğinden emin olmak için aşağıdaki bölümlerde belirtilen adımları tamamlayın:

1. Paylaşılan kitaplıklarınızın paketini güncelleme
2. Uygulamanızı 16 KB ELF uyumluluğu kullanarak derleyin
3. Kodu düzeltme ve çalışma zamanı sorunlarını çözme
4. Özel bellek ayırıcıları optimize etme (varsa)
5. SDK'ların 16 KB desteğini kontrol etme

Paylaşılan kitaplıklarınızın paketini güncelleme

AGP 8.5.1 veya daha yeni bir sürüme yükseltin ve sıkıştırılmamış paylaşılan kitaplıkları kullanın.

Zip hizalamasını doğrulamak için bundletool öğesini kullanın.

Paketinizin hizalamasını görmek için:

bundletool dump config --bundle=<my .aab>  | grep alignment

PAGE_ALIGNMENT_16K simgesini görüyorsanız paketinizin 16 KB zip hizalaması istediğini anlarsınız. PAGE_ALIGNMENT_4K ifadesini görüyorsanız bu, bu AAB'den oluşturulan APK'nın zip dosyasında 4 KB'lık .so dosyaları olmasını sağlar.

AGP 8.5.1 veya sonraki sürümü

16 KB'lık cihazlar, sıkıştırılmamış paylaşılan kitaplıklarla birlikte gelen uygulamaların bunları 16 KB'lık zip ile uyumlu bir sınıra göre düzenlemesini gerektirir. Bunu yapmak için Android Gradle eklentisini (AGP) 8.5.1 veya sonraki bir sürüme yükseltmeniz gerekir. Yükseltme işlemiyle ilgili ayrıntılar için Android Gradle eklentisi Yükseltme Asistanı bölümüne bakın.

AGP 8.5 veya önceki sürümleri

AGP'yi 8.5.1 veya sonraki bir sürüme yükseltemiyorsanız alternatif olarak sıkıştırılmış paylaşılan kitaplıkları kullanmaya geçebilirsiniz. Uygulamanızı paketlerken Gradle'ın paylaşılan kitaplıklarınızı sıkıştırması için Gradle yapılandırmanızı güncelleyin. Böylece, hizalanmamış paylaşılan kitaplıklarla ilgili uygulama yükleme sorunlarını önleyebilirsiniz.

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

AGP 8.0 veya önceki sürümleri

8.0 veya daha eski bir AGP sürümü kullanıyorsanız gradle.properties dosyanızda App Bundle'lar için sıkıştırılmamış yerel kitaplık seçeneğini de devre dışı bırakmanız gerekir:

android.bundle.enableUncompressedNativeLibs=false

Uygulamanızı 16 KB ELF uyumluluğu kullanarak derleyin

16 KB'lık cihazlarda uygulamanızın çalışması için paylaşılan kitaplıkların ELF segmentlerinin 16 KB ELF uyumluluğu kullanılarak uygun şekilde uyumlu hale getirilmesi gerekir.

Oyun geliştiriciler için: Oyununuz Unity oyun motoru üzerinde çalışıyorsa Unity kılavuzuna bakın. Oyununuz Unreal oyun motoru üzerinde çalışıyorsa Unreal kılavuzuna bakın.Yerel oyun motorları için bu kılavuzla devam edin.

Uygulamanızı 16 KB ELF uyumluluğuyla derlemek için kullandığınız Android NDK sürümüne bağlı olarak aşağıdaki bölümlerden birindeki adımları tamamlayın.

Android NDK r28 ve sonraki sürümler

NDK'nın r28 ve sonraki sürümleri, varsayılan olarak 16 KB ile uyumlu olacak şekilde derlenir.

Android NDK r27 ve önceki sürümleri

Android NDK'nın r27 veya daha eski bir sürümüyle 16 KB uyumlu paylaşılan kitaplıkların derlenmesini desteklemek için aşağıdaki bağlayıcı işaretlerini kullanın:

-Wl,-z,max-page-size=16384
-Wl,-z,common-page-size=16384

Derleme sistemi yapılandırma dosyalarınızı nasıl güncelleyeceğiniz aşağıda açıklanmıştır:

LOCAL_LDFLAGS += -Wl,-z,max-page-size=16384 -Wl,-z,common-page-size=16384

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE
    "-Wl,-z,max-page-size=16384"
    "-Wl,-z,common-page-size=16384"
)

Kodu düzeltme ve çalışma zamanı sorunlarını çözme

Uygulamanız 16 KB ile uyumlu olsa bile kodunuzdaki yerlerde bir cihazın belirli bir sayfa boyutu kullandığı varsayılıyorsa uygulamanız hatalarla karşılaşabilir. Bunu önlemek için aşağıdaki adımları uygulayın:

1. Kod mantığınızda PAGE_SIZE sabitine veya bir cihazın sayfa boyutunun 4 KB (4096) olduğunu varsayan örneklere referans veren sabit kodlanmış bağımlılıkları kaldırın.

   Bunun yerine getpagesize() veya sysconf(_SC_PAGESIZE) kullanın.

2. mmap() ve sayfa hizalı bağımsız değişkenler gerektiren diğer API'lerin kullanımlarını bulun ve gerekirse alternatifleriyle değiştirin.

Bazı durumlarda, uygulamanız PAGE_SIZE değerini temel sayfa boyutuyla ilişkili olmayan uygun bir değer olarak kullanıyorsa bu durum, 16 KB modunda kullanıldığında uygulamanızın bozulmasına neden olmaz. Ancak bu değer, çekirdeğe MAP_FIXED olmadan mmap ile iletilirse çekirdek yine de tam bir sayfa kullanır ve bu da biraz bellek israfına neden olur. Bu nedenlerle, NDK r27 ve sonraki sürümlerde 16 KB modu etkinleştirildiğinde PAGE_SIZE tanımlanmamıştır.

Uygulamanız PAGE_SIZE değerini bu şekilde kullanıyorsa ve bu değeri hiçbir zaman doğrudan çekirdeğe iletmiyorsa PAGE_SIZE değerini kullanmak yerine, başka amaçlarla kullanıldığını ve gerçek bir bellek sayfasını yansıtmadığını belirten yeni bir adla yeni bir değişken oluşturun.

Özel bellek ayırıcıları optimize etme

16 KB sistemlerde, işletim sisteminin ayırdığı en küçük fiziksel bellek birimi, 4 KB sistemlerdekinden dört kat daha büyüktür. Özel bir ayırıcı 4 KB'lık varsayımlara göre tasarlanmışsa küçük nesneleri birden fazla 16 KB'lık sayfaya dağıtabilir ve boş belleği gereksiz yere tutabilir. Bu durum, fiziksel bellek kullanımını (RSS) önemli ölçüde artırabilir ve sıkıştırılmış takas (ZRAM) verimliliğini düşürebilir.

Kodunuz kendi bellek havuzlarını yönetiyorsa aşağıdaki önerileri uygulayın:

1. Belleği boşaltmak için sabit kodlanmış bayt eşiklerinden kaçının

Birçok ayırıcı, madvise(MADV_DONTNEED) kullanarak belleği işletim sistemine geri bırakma zamanına karar vermek için sabit bayt sınırları kullanır (örneğin, yalnızca etkin nesneler 8 KB'tan daha az yer kaplıyorsa belleği serbest bırakır).

16 KB'lık bir sistemde, 16 baytlık tek bir canlı nesne bile 16 KB'lık bir sayfanın tamamını (8 KB'tan büyük) sabitler. Sonuç olarak, yayın eşiği hiçbir zaman karşılanmaz ve ayırıcı, çevreleyen kullanılmayan belleği asla çekirdeğe geri döndürmez.

Yapılması gerekenler: Sayfa yayınlama sezgisel yöntemleri için asla sabit kodlanmış bayt sabitleri kullanmayın. sysconf(_SC_PAGESIZE) kullanarak, gerçek sayfa boyutuna göre yayın eşiklerini çalışma zamanında dinamik olarak ölçeklendirin.

2. Önceden kullanılan sayfaları önce doldurma (yoğunluğa göre ilk ayırma)

Bir ayırıcı, belleği ilk gelen ilk hizmet alır (FIFO) veya round-robin sırasına göre dağıtırsa yeni ayırmalar, kısmen doldurulmuş birçok 16 KB'lık sayfaya dağıtılır. Bir sayfadaki tek bir nesne, 16 KB'ın tamamını fiziksel RAM'de tutar.

Yapılması gerekenler: Boş veya az kullanılan sayfalara dokunmadan önce her zaman en dolu (en yoğun) sayfadan veya levhadan yeni nesneler ayırın. Yeni ayırmaları halihazırda kirli olan sayfalarda yoğunlaştırmak, az kullanılan sayfaların doğal olarak sıfır etkin nesneye düşmesini sağlar. Böylece 16 KB'lık sayfanın tamamı işletim sistemine bırakılabilir.

3. Bellek havuzlarını 16 KB'a hizalayın ve havuz boyutlarını orta düzeyde tutun

4 KB sistemler için tasarlanan çok sayfalı aralıklar, 16 KB çekirdeklerde aşırı miktarda yayınlanmamış bellek boşluğu tutabilir. Ayrıca, 16 KB'a eşit olarak bölünmeyen boyut sınıfları, her sayfanın sonunda parçalanmaya neden olur.

Yapılması gerekenler:

• Tüm bellek havuzlarının, slab sınırlarının ve arabellek hizalamalarının, çalışma zamanı sayfa boyutunun tam katları olduğundan emin olun.
• Boşta kalan belleği hapseden aşırı büyük bloklar ayırmamak için küçük nesne sınıflarında çok sayfalı aralık boyutlarını yeniden değerlendirin.

4. Önbelleğe alınmış büyük arabellekler için fiziksel belleği hemen serbest bırakma

Özel ayırıcılar, genellikle büyük arabellekleri (> 64 KB) bellek içi havuzda önbelleğe alır. Böylece, mmap veya munmap sistem çağrılarının ek yükü ödenmeden yeniden kullanılabilirler. Ancak, bu kirli arabellekleri bellekte tutmak, tahliye zamanlayıcısı beklenirken megabaytlarca fiziksel RAM'in boşa harcanmasına neden olur.

Yapılacak işlem: Sanal bellek adresi aralığını hızlı yeniden kullanım için ayrılmış durumda tutun ancak arabelleği önbelleğe döndürürken hemen madvise(..., MADV_DONTNEED) veya madvise(..., MADV_FREE) işlevini çağırın. İşletim sistemi fiziksel RAM'i hemen geri kazanır. Uygulamanız ise sanal adresi yeniden ayırmadan anında yeniden kullanabilir.

5. ZRAM sıkıştırması için bellek ayırma yerine boşta olan belleği sıfırlama

Android, arka plan uygulamalarını bellekte tutmak için sıkıştırılmış takas (ZRAM) kullanır. 16 KB'lık cihazlarda bir sayfada tek bir canlı nesne olsa bile 16 KB'lık sayfanın tamamı bellekte kalır veya ZRAM'e taşınır. Sayfanın daha önce boşaltılmış kısımlarındaki artık kullanılmayan çöp veriler (ör. eski işaretçiler ve dizeler) iyi sıkıştırılmaz.

Ayırıcınız belleği sıfırlıyorsa (ör. güvenlik veya sıfır olarak başlatılmış ayırmalar için) ayırma sırasında değil, ayırma kaldırılırken sıfırlamayı (free()) tercih edin:

• Sabitlenmiş sayfalar daha az maliyetlidir: Kısmen dolu 16 KB'lık sayfalardaki boşta kalan bellek, ZRAM'de neredeyse hiç yer kaplamayacak şekilde sıkıştırılır. Bu nedenle, sabitlenmiş sayfalar fiziksel takas alanını boşa harcamaz.
• Minimum önbellek ek yükü: free() çağrıldığında bellek, CPU önbelleğinde zaten sıcak olduğundan daha sonra ek önbellek hataları önlenir.

Önerilerin özeti

SDK'ların 16 KB desteğini kontrol etme

Birçok SDK, özellikle kendiniz oluşturduysanız veya son zamanlarda önceden oluşturulmuş SDK'lar edindiyseniz 16 KB sayfa boyutlarıyla uyumludur. Ancak bazı SDK önceden derlenmiş dosyaları veya SDK sürümleri 16 KB ile uyumlu olmadığından, 16 KB ile hangi sürümün kullanılacağını belirlemek için her SDK sağlayıcının web sitesini kontrol etmeniz gerekir.

Uygulamanızı 16 KB ortamında test etme

Uygulamanızı 16 KB cihazları destekleyecek şekilde oluşturduktan sonra, uygulamanızda herhangi bir gerileme olup olmadığını görmek için 16 KB ortamında test etmeniz gerekir. Bunu yapmak için aşağıdaki adımları uygulayın:

1. Android 15 SDK veya sonraki bir sürümü ayarlayın.

2. Aşağıdaki test ortamlarından birini ayarlayın:

   • Android Emulator'ı 16 KB tabanlı bir Android 15 sistem görüntüsüyle ayarlama
   • ARM64'te 16 KB sayfa boyutuyla Cuttlefish kullanma
   • x86-64'te 16 KB sayfa boyutuyla Cuttlefish'i simüle etme
   • Geliştirici seçeneklerini kullanarak cihazda 16 KB modunu etkinleştirme
   • 16 KB desteklenen cihazlarda Samsung Uzaktan Test Laboratuvarı'nı kullanma

3. Test cihazınızı başlatın ve 16 KB ortam kullandığını doğrulamak için aşağıdaki komutu çalıştırın:

   adb shell getconf PAGE_SIZE
   

   Komut, 16384 değerini döndürmelidir.

4. Uygulamanızın 16 KB ile hizalandığını doğrulamak için aşağıdaki zipalign komutunu çalıştırın. Burada APK_NAME, uygulamanızın APK dosyasının adıdır:

   zipalign -c -P 16 -v 4 APK_NAME.apk
   

5. Uygulamanızı kapsamlı bir şekilde test edin. Belirli sayfa boyutlarına referans veren kod örneklerinin değiştirilmesinden etkilenebilecek alanlara odaklanın.

Android Emulator'ı 16 KB tabanlı bir sistem görüntüsüyle kurma

Android Emulator'ı kullanarak 16 KB ortamı oluşturmak için aşağıdaki adımları uygulayın:

1. Android Studio'da Tools > SDK Manager'ı (Araçlar > SDK Yöneticisi) tıklayın.

2. SDK Platformları sekmesinde Paket Ayrıntılarını Göster'i seçin, ardından Android VanillaIceCream veya daha yüksek bir bölümü genişletin ve oluşturmak istediğiniz sanal cihazlara bağlı olarak aşağıdaki emülatör sistem görüntülerinden birini ya da her ikisini seçin:

   • Google APIs Experimental 16 KB Page Size ARM 64 v8a System Image
   • Google API'leri Deneysel 16 KB Sayfa Boyutu Intel x86_64 Atom Sistemi Görüntü

   

3. Seçtiğiniz sistem görüntülerini indirmek için Uygula > Tamam'ı tıklayın.

4. Android 15 için sanal cihaz oluşturma adımlarını uygulayın ve sistem görüntüsü seçmeniz istendiğinde indirdiğiniz 16 KB sistem görüntüsünü seçin. Otomatik olarak önerilmeyen 16 KB'lık sistem görüntüsünü Diğer Görüntüler sekmesinde bulabilirsiniz.

   

Emülatörü başlatma

Android Emulator ve sanal cihazların kurulumunu tamamladıktan sonra emülatörü hedef cihaz menüsünden veya komut satırından başlatın.

Geliştirici seçeneklerini kullanarak bir cihazda 16 KB modunu etkinleştirme

Cihazı 16 KB modunda başlatmak için 16 KB sayfa boyutuyla başlat geliştirici seçeneğini etkinleştirin.

Android 15'in QPR sürümlerinde, cihazı 16 KB modunda başlatmak ve cihaz üzerinde test yapmak için belirli cihazlarda bulunan geliştirici seçeneğini kullanabilirsiniz. Geliştirici seçeneğini kullanmadan önce Ayarlar > Sistem > Yazılım güncellemeleri'ne gidip varsa güncellemeleri uygulayın.

Bu geliştirici seçeneği aşağıdaki cihazlarda kullanılabilir:

• Pixel 8 ve 8 Pro (Android 15 QPR1 veya sonraki sürümlerle)

• Pixel 8a (Android 15 QPR1 veya sonraki sürümler)

• Pixel 9, 9 Pro ve 9 Pro XL (Android 15 QPR2 veya sonraki bir sürüm yüklü)

• Pixel 9a (Android 16 veya sonraki sürümler)

16 KB geriye dönük uyumluluk modu

Sayfa boyutu uyumluluk modunda uyarı

16 KB geri uyumluluk seçeneği, cihaz 16 KB çekirdekle çalışırken kullanılabilir. Paket yöneticisi, aşağıdaki koşullar karşılandığında bir uygulamayı 16 KB geriye dönük uyumluluk modunda çalıştırır:

• Uygulamada 4 KB LOAD segment hizalamasına sahip ELF dosyaları (.so uzantılı) varsa.
• Sıkıştırılmış APK'da 4 KB ZIP uyumlu sıkıştırılmamış ELF dosyaları varsa.

Paket yöneticisi bir uygulama için 16 KB geriye dönük uyumluluk modunu etkinleştirdiyse uygulama ilk kez başlatıldığında 16 KB geriye dönük uyumluluk modunda çalıştığını belirten bir uyarı gösterir.

16 KB geriye dönük uyumluluk modu, bazı uygulamaların çalışmasına olanak tanır ancak en iyi güvenilirlik ve kararlılık için uygulamalar yine de 16 KB ile uyumlu olmalıdır.

Uygulama bilgileri sayfasındaki Gelişmiş bölümünde, Uygulamayı sayfa boyutu uyumluluk moduyla çalıştır ayarını etkinleştirerek veya devre dışı bırakarak belirli bir uygulama için 16 KB geriye dönük uyumluluk modunu etkinleştirebilir ya da devre dışı bırakabilirsiniz. Bu ayar yalnızca cihaz 16 KB sayfa boyutuyla çalışırken görünür.

Sayfa boyutu uyumluluk modu ayarı

Cihazdaki her uygulamada 16 KB geriye dönük uyumluluğu zorunlu kılmak için:

adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false

Cihazdaki her uygulama için 16 KB geriye dönük uyumluluğu zorunlu olarak devre dışı bırakmak için:

adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true

Android 17'de, her uygulama için 16 KB geriye dönük uyumluluğu zorla devre dışı bırakabilir ve uyumsuz ikili programların hemen sonlandırılmasını sağlayabilirsiniz:

    adb shell setprop bionic.linker.16kb.app_compat.enabled fatal
    adb shell setprop pm.16kb.app_compat.disabled true

android:pageSizeCompat özelliğini etkin veya devre dışı olarak ayarlayarak belirli bir uygulamanın AndroidManifest.xml içinde geriye dönük uyumluluk modunu açın veya kapatın. Bu özellik ayarlandığında uygulama başlatılırken geriye dönük uyumluluk modu uyarıları gösterilmez.