[TIMOB-5352] iOS: Turn on local caching for images
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2011-11-22T11:12:40.000+0000 |
Affected Version/s | Release 1.7.2 |
Fix Version/s | Sprint 2011-38, Release 1.8.0 |
Components | iOS |
Labels | branch-5062, module_imageview, qe-testadded |
Reporter | Stephen Tramer |
Assignee | Stephen Tramer |
Created | 2011-09-23T02:55:26.000+0000 |
Updated | 2011-11-22T11:12:40.000+0000 |
Description
Extensive stress on the system of loading local images can lead to memory warnings and jetsam purges. This is easily demonstrated by constantly setting a badge on an icon which uses a custom image (setting a badge refreshes the tab, which reloads the image). The best way to see this effect cascade is by tying available memory to the badge value via a timer, which will force repeated refreshes.
SAMPLE APP
----
Titanium.UI.setBackgroundColor('#000');
var tabGroup = Titanium.UI.createTabGroup({id:'tabGroup1'});
var win1 = Titanium.UI.createWindow({backgroundColor:'white'});
var tab1 = Titanium.UI.createTab({
icon:'bug.png',
window:win1
});
setInterval(function() {
tab1.badge = parseInt(Ti.Platform.availableMemory);
}, 50);
tabGroup.addTab(tab1);
tabGroup.open();
Ideally, this will be run on device since it is more memory-constrained and jetsam will kill the app. Do NOT fix the side-effects of the caching problem (namely, that tabs are reloaded in this manner).
TESTING
----
The bug is not fixed as long as the badge number on the app goes down. This app is specifically designed to not allocate additional memory beyond the occasional autoreleased value. jetsam won't necessarily terminate, and you may need to watch the app for an extended period of time (several minutes) before seeing decreases of the magnitude that will lead to the badge number fluctuating (indicating allocation/reclamation) or plummeting.
Attachments
File | Date | Size |
---|---|---|
bug.png | 2011-09-23T02:55:26.000+0000 | 3297 |
localloader.js | 2011-09-24T05:52:48.000+0000 | 1804 |
remoteloader.js | 2011-09-24T05:50:25.000+0000 | 1418 |
Added the branch-5062 label.
I've created a very stressful app.js for you to test caching of local images. The following will download a remote image, and then progressively copy it out to disk until it reaches numberOfLocalImages (a variable at the top of the app.js). Then it will just repeatedly load those images in, for the rest of eternity. Tested with 1.8.0 master, and confirmed that memory leaks and the app will crash. In this case, it will crash very quickly. Enjoy! version=1.8.0 timestamp=09/06/11 10:54 githash=2888f72...
And here is a remote version of the above. This one seems to stabilize, so remote caching probably works (*shrug*):
Test for remote image loading (remoteloader.js). This test passes when: - Memory stabilizes eventually - Suspending/resuming app does not disrupt the changing of the image view (and memory is stable) - After force-terminating the app (but not reinstalling), images do not download; they load from disk (rapid redisplay, low latency, etc.)
Test for local image loading (localloader.js) - more strenuous than the initial test submitted. For this test to pass: - Memory should eventually stabilize (but may be VERY LOW on device - this image is 205k!) - Forcing a memory panic should bring memory usage down significantly (on simulator); turn on DEBUG_IMAGE_CACHE and look for the "pages freed" message. Memory panics on device (if they occur) should also free up a large amount of space. Note that the initial image IS downloaded from a remote source, so have a fast connection available (otherwise the image download will time out).
Merged in typo fix from pull request #495.
Pass: Tested with 1.8.0.1.v20111114102656 on iPad 2 4.3.5 iPhone 4s 5.0 iPod 3g 4.0.2
Open to add tag