背景
遠在iOS 11時期（2017年），蘋果就發公告要求所有需要上架的應用都必須支持64位 。32位應用不再支持上架與運行 。
升級64位應用有什么好處呢？（以下內容純摘抄 ， 客官可以直接跳過）
寄存器更多，減少內存讀寫，加快執行速度
這里我們要注意的是：虛擬內存確實比純32位多了，但是App到底能用多少，是否跟宣傳一樣接近16EB？下面將會展開聊聊，我們先來看一個Crash 。
一個長期存在的幽靈
我們先來看下面的一個內存導致的崩潰，JSC在使用嘗試進行內存分配時，提示OOM導致了 。
Last Exception :0JavaScriptCore0x000000018b777570 _pas_panic_on_out_of_memory_error1JavaScriptCore0x000000018b72e918 _bmalloc_try_iso_allocate_impl_impl_slow2JavaScriptCore0x000000018b73d3d8 _bmalloc_heap_config_specialized_local_allocator_try_allocate_small_segregated_slow +59523JavaScriptCore0x000000018b7276f8 _bmalloc_allocate_impl_casual_case +8004JavaScriptCore0x000000018c60d494 JSC::PropertyTable::create(JSC::VM&, unsigned int) +2445JavaScriptCore0x000000018c66ba74 JSC::Structure::materializePropertyTable(JSC::VM&, bool) +3246JavaScriptCore0x000000018c66dfac JSC::Structure::changePrototypeTransition(JSC::VM&, JSC::Structure*, JSC::JSValue, JSC::DeferredStructureTransitionWatchpointFire&) +6127JavaScriptCore0x000000018c559930 JSC::JSObject::setPrototypeDirect(JSC::VM&, JSC::JSValue) +1928JavaScriptCore0x000000018c559e40 JSC::JSObject::setPrototypeWithCycleCheck(JSC::VM&, JSC::JSGlobalObject*, JSC::JSValue, bool) +3169JavaScriptCore0x000000018c4f580c JSC::globalFuncProtoSetter(JSC::JSGlobalObject*, JSC::CallFrame*) +19210 JavaScriptCore0x000000018ba1f7a8 _vmEntryToNative +28011 JavaScriptCore0x000000018c1b0cd0 JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) +61612 JavaScriptCore0x000000018c474ecc JSC::GetterSetter::callSetter(JSC::JSGlobalObject*, JSC::JSValue, JSC::JSValue, bool) +21213 JavaScriptCore0x000000018c5b6264 JSC::JSGenericTypedArrayView::put(JSC::JSCell*, JSC::JSGlobalObject*, JSC::PropertyName, JSC::JSValue, JSC::PutPropertySlot&) +61214 JavaScriptCore0x000000018c2c2ecc _llint_slow_path_put_by_id +3244// 忽略多余重復堆棧37 JavaScriptCore0x000000018ba1f5fc _vmEntryToJavaScript +26438 JavaScriptCore0x000000018c1b0c7c JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) +53239 JavaScriptCore0x000000018bac7ae4 _JSObjectCallAsFunction +56840 mttlite0x0000000102a54914 hippy::napi::JSCCtx::CallFunction(std::__1::shared_ptr const&, unsigned long, std::__1::shared_ptr const*) (js_native_api_value_jsc.cc:406)41 mttlite0x0000000102a664e0 _ZNSt3__110__function6__funcIZN11TimerModule5StartERKN5hippy4napi12CallbackInfoEbE3$_4NS_9allocatorIS8_EEFvvEEclEv (memory:3237)42 mttlite0x0000000102a63018 hippy::base::TaskRunner::Run() (memory:3237)43 mttlite0x0000000102a64974 ThreadEntry (thread.cc:0)44 libsystem_pthread.dylib0x00000001dc129348 __pthread_start +116------Exception Type: SIGTRAP Exception Codes: fault addr: 0x000000018b777570Crashed Thread: 48 hippy.js這個OOM問題 ， 與iOS上常見的OOM不一樣 。按照常規的理解 ， 當App內存不足的時候，正常會觸發系統的機制殺死App 。在系統日志中會留下相關日志，理論上不會在Bugly等異常上報中發現 。但這一類崩潰卻一直在產生上報軟件運行出錯誤代碼1，并且低內存的崩潰堆棧表現形式有很多種 。
以上的JSC崩潰問題已經存在很長一段時間了（至少2年），而且崩潰堆棧都集中在JSC執行JS代碼的過程中，長期缺乏JS相關的監控與Debug工具導致該問題一直無法解決 。
雖然堆棧上有明確的原因說明是OOM，但我們觀察到有不少用戶實際上物理內存空間還是足夠的：
兩年前，沖浪的時候偶然看來了來自微視同學的Case總結：《OOM與內存》
當時跟hippy SDK的同事也討論過是否存在類似的內存不足情況 。但由于大家對JSC黑盒都不熟悉，而且崩潰的JS堆棧也不確切 。當時的建議是：少在后臺加載JSC 。最終也并沒有解決該問題 。
兩年后，當瀏覽器集成，類似的JS崩潰直接翻倍（21H2 0.08% -> 22H1 0.16%） 。沒辦法，還是要看類似JSC和Dart VM的內存分配機制是怎樣的，再挖掘一下是否存在解（緩）決（解）方案 。
JSC、的虛擬內存分配
翻閱相關虛擬機的內存管理相關代碼 ， 可以找到底層的內存分配基本實現都是基于mmap處理的 。
// WebKit bmalloc VMAllocateinline void* tryVMAllocate(size_t vmSize, VMTag usage = VMTag::Malloc){vmValidate(vmSize);void* result = mmap(0, vmSize, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | BMALLOC_NORESERVE, static_cast(usage), 0);if (result == MAP_FAILED)return nullptr;return result;}// Dart VM的虛擬內存VirtualMemory* VirtualMemory::Allocate(intptr_t size,bool is_executable,const char* name) {ASSERT(Utils::IsAligned(size, PageSize()));const int prot = PROT_READ | PROT_WRITE | (is_executable ? PROT_EXEC : 0);int map_flags = MAP_PRIVATE | MAP_ANONYMOUS;#if (defined(DART_HOST_OS_MACOS) && !defined(DART_HOST_OS_IOS))if (is_executable && IsAtLeastOS10_14()) {map_flags |= MAP_JIT;}#endif// defined(DART_HOST_OS_MACOS)// Some 64-bit microarchitectures store only the low 32-bits of targets as// part of indirect branch prediction, predicting that the target's upper bits// will be same as the call instruction's address. This leads to misprediction// for indirect calls crossing a 4GB boundary. We ask mmap to place our// generated code near the VM binary to avoid this.void* hint = is_executable ? reinterpret_cast(&Allocate) : nullptr;void* address = mmap(hint, size, prot, map_flags, -1, 0);if (address == MAP_FAILED) {return nullptr;}return new VirtualMemory(address, size);}VirtualMemory::~VirtualMemory() {if (address_ != nullptr) {if (munmap(address_, size_) != 0) {int error = errno;const int kBufferSize = 1024;char error_buf[kBufferSize];FATAL("munmap error: %d (%s)", error,Utils::StrError(error, error_buf, kBufferSize));}}}當包含時 ， 并且fd傳入-1時 ， mmap將直接使用虛擬內存進行分配，不需要依賴文件描述符 。
mmap在xnu上的實現
/* * mmap stub, with preemptory failures due to extra parameter checking * mandated for conformance. * * This is for UNIX03 only. */void *mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t off){/** Preemptory failures:** ooff is not a multiple of the page size* oflags does not contain either MAP_PRIVATE or MAP_SHARED* olen is zero*/extern void cerror_nocancel(int);if ((off & PAGE_MASK) ||(((flags & MAP_PRIVATE) != MAP_PRIVATE) &&((flags & MAP_SHARED) != MAP_SHARED)) ||(len == 0)) {cerror_nocancel(EINVAL);return(MAP_FAILED);}void *ptr = __mmap(addr, len, prot, flags, fildes, off);if (__syscall_logger) {int stackLoggingFlags = stack_logging_type_vm_allocate;if (flags & MAP_ANON) {stackLoggingFlags |= (fildes & VM_FLAGS_ALIAS_MASK);} else {stackLoggingFlags |= stack_logging_type_mapped_file_or_shared_mem;}__syscall_logger(stackLoggingFlags, (uintptr_t)mach_task_self(), (uintptr_t)len, 0, (uintptr_t)ptr, 0);}return ptr;}上面的調用會傳遞到內核.c的實現函數mmap( p, *uap, *)
/* * XXX Internally, we use VM_PROT_* somewhat interchangeably, but the correct * XXX usage is PROT_* from an interface perspective.Thus the values of * XXX VM_PROT_* and PROT_* need to correspond. */intmmap(proc_t p, struct mmap_args *uap, user_addr_t *retval){/** 上面忽略了一部分代碼*/result = vm_map_enter_mem_object(user_map,&user_addr, user_size,0, alloc_flags, vmk_flags,tag,IPC_PORT_NULL, 0, FALSE,prot, maxprot,(flags & MAP_SHARED) ?VM_INHERIT_SHARE :VM_INHERIT_DEFAULT);/* If a non-binding address was specified for this anonymous* mapping, retry the mapping with a zero base* in the event the mapping operation failed due to* lack of space between the address and the map's maximum.*/if ((result == KERN_NO_SPACE) && ((flags & MAP_FIXED) == 0) && user_addr && (num_retries++ == 0)) {user_addr = vm_map_page_size(user_map);goto map_anon_retry;}/** 下面忽略了一部分代碼*/}其中又會調用.c內部的ect，而該方法最終會在中依據對象進行內存分配：
// 下面這個只截了個頭 ， 大概帶一下，我也沒調過代碼~/* *Routine:vm_map_enter * *Description: *Allocate a range in the specified virtual address map. *The resulting range will refer to memory defined by *the given memory object and offset into that object. * *Arguments are as defined in the vm_map call. */kern_return_tvm_map_enter(vm_map_tmap,vm_map_offset_t*address,/* IN/OUT */vm_map_size_tsize,vm_map_offset_tmask,intflags,vm_map_kernel_flags_tvmk_flags,vm_tag_talias,vm_object_tobject,vm_object_offset_toffset,boolean_tneeds_copy,vm_prot_tcur_protection,vm_prot_tmax_protection,vm_inherit_tinheritance)其中在分配過程中會對→作判斷，即最大的可分配空間 。
xnu上虛擬內存的分配范圍
本來我只是觀察到蘋果在iOS15上增加了com.apple…–limit的能力聲明 。本著死馬當活馬醫的想法，嘗試在新版本上添加該聲明以緩解一部分問題 。
結果偶然看到部分開發者提問：該能力可配合com.apple…–使用 。看到后我一下子反應過來 ， 順手搜到了今年二月國外有大佬做了相關的探索：

文章插圖
Size : An of on iOS
文章闡述了iOS的內存管理機制和虛擬內存空間分配在不同的機型上存在上限 ， 代碼如下：
#define ARM64_MIN_MAX_ADDRESS (SHARED_REGION_BASE_ARM64 + SHARED_REGION_SIZE_ARM64 + 0x20000000) // end of shared region + 512MB for various purposesconst vm_map_offset_t min_max_offset = ARM64_MIN_MAX_ADDRESS; // end of shared region + 512MB for various purposesif (arm64_pmap_max_offset_default) {max_offset_ret = arm64_pmap_max_offset_default;} else if (max_mem > 0xC0000000) {max_offset_ret = min_max_offset + 0x138000000; // Max offset is 13.375GB for devices with > 3GB of memory} else if (max_mem > 0x40000000) {max_offset_ret = min_max_offset + 0x38000000;// Max offset is 9.375GB for devices with > 1GB and <= 3GB of memory} else {max_offset_ret = min_max_offset;}并且總結了一個上限值與機型表格：
RAM
Space
> 3 GiB
15.375 GiB
7.375 GiB
– XS – 13
– iPad Air (4th )
– iPad Pro (12.9-inch), (10.5-inch), (11-inch)
> 1 GiB
11.375 GiB
3.375 GiB
– 6s – X, SE, XR
– iPad (5th ) – iPad (8th )
– iPad Air 2, iPad Air (3rd )
– iPad mini 4, iPad mini (5th )
– iPad Pro (9.7-inch)
（64位系統下1008字節，32位系統下496）
內存擴展前失敗閾值約 * 1009 = 6.63 GB
內存擴展后失敗閾值約 * 1009 = 53.33 GB
當然，在xnu的單元測試代碼中，也可找到jumbo mode相關的測試代碼 ， 與上面的測試結果完全一致，即最多可分配53GB的空間 。
#define GB (1ULL * 1024 * 1024 * 1024)/* * This test expects the entitlement to be the enabling factor for a process to * allocate at least this many GB of VA space. i.e. with the entitlement, n GB * must be allocatable; whereas without it, it must be less. * This value was determined experimentally to fit on applicable devices and to * be clearly distinguishable from the default VA limit. */#define ALLOC_TEST_GB 53T_DECL(TESTNAME,"Verify that a required entitlement is present in order to be granted an extra-large ""VA space on arm64",T_META_NAMESPACE("xnu.vm"),T_META_CHECK_LEAKS(false)){int i;void*res;if (!dt_64_bit_kernel()) {T_SKIP("This test is only applicable to arm64");}T_LOG("Attemping to allocate VA space in 1 GB chunks.");for (i = 0; i < (ALLOC_TEST_GB * 2); i++) {res = mmap(NULL, 1 * GB, PROT_NONE, MAP_PRIVATE | MAP_ANON, 0, 0);if (res == MAP_FAILED) {if (errno != ENOMEM) {T_WITH_ERRNO;T_LOG("mmap failed: stopped at %d of %d GB allocated", i, ALLOC_TEST_GB);}break;} else {T_LOG("%d: %pn", i, res);}}#if defined(ENTITLED)T_EXPECT_GE_INT(i, ALLOC_TEST_GB, "Allocate at least %d GB of VA space", ALLOC_TEST_GB);#elseT_EXPECT_LT_INT(i, ALLOC_TEST_GB, "Not permitted to allocate %d GB of VA space", ALLOC_TEST_GB);#endif}可見，當開啟com.apple…–時，內核的可分配空間確實有明顯提升 。
上線效果與結論
從QQ瀏覽器的上線效果來看，JS相關的內存分配Crash在14.0以上系統幾乎全部消失 。上線第一天App崩潰率環比下降接近50%，效果顯著 。
簡單總結：
蘋果很少在公開文檔中說明64位App在虛擬內存使用上存在限制 。而且很多App也并沒有像瀏覽器內一樣，為業務靈活性而選擇將hippy、等技術進行大規模的組合使用，所以可能很多App其實并不會遇到虛擬內存不足的情況 。上線效果也說明瀏覽器在混合開發的場景下，內存優化仍然存在很大的空間 。因為 僅能緩解虛擬內存不足的情況，并不意味著App的物理內存也得到增加，對FOOM的治理仍然需要持續 。鑒于司內有不少的著名組件都會使用mmap機制進行內存管理軟件運行出錯誤代碼1，建議在使用相關組件時 ， 控制好mmap的大小 。如果有需要在 12 Pro、M1 iPad、M1上運行應用，并希望解放更多的物理內存，建議增加com.apple…–limit的能力聲明，實測在 13 Pro下可以增加1GB的可用物理內存 。和類似框架在項目中使用較多的，建議需要考慮多個的復用，減少創建重復內容，司內外都有實踐證明該措施十分有效 。對于一類的內存優化 ， 可翻閱的相關代碼 。vm在創建時允許外部傳參控制vm行為，包括：old heap size、leak vm等 。合適的參數可比較有效控制內存占用 。
以上源碼相關的內容僅個人閱讀理解，如有錯誤請指出 。
【一鍵釋放iOS 64位App潛力】本文到此結束，希望對大家有所幫助 。

• iOS16不能忍受的五大槽點匯總
• iOS17什么時候發布，支持什么機型
• iOS重大更新發布 ?prores視頻拍攝是什么意思
• 16 個 iOS 16 隱藏功能盤點
• iPhone 12怎么截圖？
• 4個iOS使用小技巧
• 怎么找回iOS設備序列號和IMEI，趕緊看！
• 華為一鍵測速App值得擁有：免費下載無廣告 安卓用戶獨享
• 總結了excel小技能之技巧篇
• 糖果媽媽：原創寶寶釋放了這些信號，可能是進入了“肛欲期”，家長還應認真對待