Jetsam模型

iOS使用的是低內存處理機制Jetsam，這是一個基于優先級隊列的機制。相關的探究推薦這篇文章

Jetsam可以簡單的抽象為：前臺應用程序，在觸發某個或多個條件時，觸發系統事件，被系統kill掉。而OOM也就是因為觸發了內存相關的系統事件，被系統kill掉了。

Memory Footprint

Footprint是蘋果推薦的內存度量及優化的指標。而Memory Footprint的值達到Limit line時，就會觸發內存警告，并進一步導致OOM，相關可以參考這條Stack Overflow。以下是摘抄的部分OOM時的Memory Footprint Limit Line。

device: (crash amount/total amount/percentage of total)

iPad1: 127MB/256MB/49%
iPad2: 275MB/512MB/53%
iPad3: 645MB/1024MB/62%
iPad4: 585MB/1024MB/57% (iOS 8.1)
iPad Mini 1st Generation: 297MB/512MB/58%
iPad Mini retina: 696MB/1024MB/68% (iOS 7.1)
iPad Air: 697MB/1024MB/68%
iPad Air 2: 1383MB/2048MB/68% (iOS 10.2.1)
iPad Pro 9.7": 1395MB/1971MB/71% (iOS 10.0.2 (14A456))
iPad Pro 10.5”: 3057/4000/76% (iOS 11 beta4)
iPad Pro 12.9” (2015): 3058/3999/76% (iOS 11.2.1)
iPad Pro 12.9” (2017): 3057/3974/77% (iOS 11 beta4)
iPod touch 4th gen: 130MB/256MB/51% (iOS 6.1.1)
iPod touch 5th gen: 286MB/512MB/56% (iOS 7.0)
iPhone4: 325MB/512MB/63%
iPhone4s: 286MB/512MB/56%
iPhone5: 645MB/1024MB/62%
iPhone5s: 646MB/1024MB/63%
iPhone6: 645MB/1024MB/62% (iOS 8.x)
iPhone6+: 645MB/1024MB/62% (iOS 8.x)
iPhone6s: 1396MB/2048MB/68% (iOS 9.2)
iPhone6s+: 1392MB/2048MB/68% (iOS 10.2.1)
iPhoneSE: 1395MB/2048MB/69% (iOS 9.3)
iPhone7: 1395/2048MB/68% (iOS 10.2)
iPhone7+: 2040MB/3072MB/66% (iOS 10.2.1)
iPhone X: 1392/2785/50% (iOS 11.2.1)

OOM觸發的其他事件

這個是本文想要討論的重點。我們已知，Compressed Image是Dirty Memory，也就是在Memory Footprint中的。在最新的Xcode 9.3升級后，發現某些特殊的圖片，在加載后并不會引起Memory Footprint的升高，且不會受到Memory Footprint Limit Line的限制。

比如，以iPhone 6+為例，通常Memory Footprint值到達645MB時，就會crash掉，同時Xcode的console中有memory issue的提示。然而，當我們加載特殊的圖片時，根據圖片加載內存計算，當其加載到1100MB左右時，才會crash，并且同樣在console中有memory issuer的提示。簡要的說：

通過Xcode9.3打包出的程序，加載特殊圖片可以使用更多內存。比如原來加載15張圖片就會內存警告，OOM。現在則可以加載20張圖片。

這個發現告訴我們，OOM的觸發事件不只是footprint，至少還有另一個指標。目前已經向蘋果提交了TSI，反饋給蘋果的郵件如下。然而并未收到有效的回復，僅回復查看WWDC2018的session

上述現象的條件是使用Xcode9.3及以后打包，對iOS9~12有效，懷疑是LLVM的優化。我看了WWDC2018的內存和LLVM的session未發現有效的信息。

PLATFORM AND VERSION
iOS
IDE: Xcode 9.3 and above.
iOS:iOS 9 and above.
Device:iPhone 6p, iPhone 5s, iPhone x, iPhone 6sp, etc.

This appeared after I update Xcode 9.3, and 
performed normal when I downgrade to Xcode 9.2. 


DESCRIPTION OF PROBLEM
Memory Tool:IDE footprint memory, instruments-Allocations, source code;
Usually, when I load a 6000(px)*4000(px) image, it will cost 96MB memory. But I fount that, when I load some kind of picture, the footprint memory did not change obviously. And I can't find any memory increase in instruments-Allocations.

In addition, I find OOM is closely related to footprint memory level. But when I use this kind of picture, it can breakthroughs footprint memory limit.In other words, I can load more picture in my App when I use this kind of picture.


So, my question is, why this kind of picture has this feature, and what kind of picture will have this feature.

Usual picture:https://monkeytest.oss-cn-shanghai.aliyuncs.com/TestImageLarge.jpg

Unusual picture:https://monkeytest.oss-cn-shanghai.aliyuncs.com/gratisography-400H.jpg

or:https://gratisography.com/fullsize/gratisography-400H.jpg

Demo project:https://github.com/LululuSir/testDemo.git

STEPS TO REPRODUCE
1.Load some kind of picture.
2.Check the footprint memory use Xcode memory tool or source code.


NAME AND APPLE ID OF APP