3 ms·
You are right, this is the best workaround possible. This is still a workaround since it need to memory map the whole APK file. In our case this is not really
by jlemoine 14y ago
You are right, this is the best workaround possible. This is still a workaround since it need to memory map the whole APK file.
In our case this is not really acceptable since we develop a SDK that is embedded by developers in their app and this would put constraints on their app if they want to embed an index.
Btw I think an evolution of the APK format could be to have 2 different parts:
- a part that contains compressed data and stay on disk to launch the app
- a part that is only used only for installation: extract uncompressed files and store them on file system.
- saurik 14y agoI do not understand why this would possibly be a concern. You do realize that there is no cost to memory mapping a very large file, right? You still are going to end up with only a single VMA ("virtual memory area", one of the more insidious costs of memory maps) in your memory map, and only pages you use will get paged in; if you wanted to memory map a 1GB large file, the only pain would be the loss of address space, and you have 2-3GB of that available. Additionally, you aren't even correct that you have to memory map the entire file: as you have a file descriptor for the file and know the offset you want into the file, you can memory map just the part of the file you need. Both the C-level mmap API and the Java-level FileChannel.map API allow you to provide a specific offset and length for the region you want to map from the file.