UIImageJPEGRepresentation - 內存釋放問題

在iPhone應用程序中，我需要通過郵件發送一個最大尺寸爲300Ko的JPG（我不是沒有Mail.app的最大大小，但這是另一個問題）。要做到這一點，我試圖降低質量，直到獲得低於300Ko的圖像。UIImageJPEGRepresentation - 內存釋放問題

爲了獲得良好的質量（compressionLevel）誰給我一個300Ko以下的JPG，我做了以下循環。它正在工作，但是每次執行循環時，儘管有「[tmpImage release]」，但我的jpg（700Ko）原始大小的內存增加了。

float compressionLevel = 1.0f; 
int size = 300001; 
while (size > 300000) { 
    UIImage *tmpImage =[[UIImage alloc] initWithContentsOfFile:[self fullDocumentsPathForTheFile:@"imageToAnalyse.jpg"]]; 
    size = [UIImageJPEGRepresentation(tmpImage, compressionLevel) length]; 
    [tmpImage release]; 
     //In the following line, the 0.001f decrement is choose just in order test the increase of the memory 
    //compressionLevel = compressionLevel - 0.001f; 
    NSLog(@"Compression: %f",compressionLevel); 
}

任何關於如何得到它的想法，或爲什麼會發生？謝謝

來源

2010-04-16 FredM

至少，在循環中的每次旅行中分配和釋放圖像都沒有意義。它不應該泄漏內存，但它是不必要的，所以將alloc/init和release移出循環。另外，由UIImageJPEGRepresentation返回的數據是自動釋放的，所以它會一直存在，直到當前發佈池耗盡爲止（當你回到主事件循環時）。考慮加入：

NSAutoreleasePool* p = [[NSAutoreleasePool alloc] init];

在循環的頂部，並

[p drain]

末。這樣你就不會泄漏所有的中間存儲器。

最後，對最佳壓縮設置進行線性搜索可能效率很低。改爲使用二進制搜索。

來源

2010-04-16 20:26:17

非常感謝。添加NSAutoreleasePool可以解決問題。現在內存很穩定。我知道做一個線性搜索根本沒有效率。我不想誇大，但是做二分查找是什麼意思？再次感謝您的快速回復 – FredM 2010-04-16 21:19:43

http://en.wikipedia.org/wiki/Binary_search_algorithm 基本上，從可能範圍的壓縮值的一端開始。在每個步驟中，使新值等於最後一次測試值的平均值和壓縮大小低於最大值的最後一個值。 – 2010-04-17 02:32:48

當然，binary_search更高效。我做了一個小測試： linear_search：圖像尺寸：249.764柯注意到：180.64s與81環二進制搜索：圖像尺寸：249.637柯注意到：22.94s與11環再次感謝。 – FredM 2010-04-18 13:25:05

UIImageJPEGRepresentation - 內存釋放問題

回答

相關問題