Hi, very cool. For what it's worth, there are a series of event logs already in the platform for key parts of the user space boot:
I/boot_progress_start( 67): 31384 I/boot_progress_preload_start( 67): 33117 I/boot_progress_preload_end( 67): 37614 I/boot_progress_system_run( 98): 38330 I/boot_progress_pms_start( 98): 38853 I/boot_progress_pms_system_scan_start( 98): 39432 I/boot_progress_pms_data_scan_start( 98): 43593 I/boot_progress_pms_scan_end( 98): 44363 I/boot_progress_pms_ready( 98): 44668 I/boot_progress_ams_ready( 98): 51363 I/boot_progress_enable_screen( 98): 63810 I/boot_progress_start( 1362): 921726 I/boot_progress_preload_start( 1362): 923816 I/boot_progress_preload_end( 1362): 925516 I/boot_progress_system_run( 1365): 925798 I/boot_progress_pms_start( 1365): 926173 I/boot_progress_pms_system_scan_start( 1365): 926628 I/boot_progress_pms_data_scan_start( 1365): 930639 I/boot_progress_pms_scan_end( 1365): 931158 I/boot_progress_pms_ready( 1365): 931426 I/boot_progress_ams_ready( 1365): 938074 I/boot_progress_enable_screen( 1365): 945150 Zygote pre-loading is definitely an issue, though since it is necessary for good performance later it is a challenge. The only thing I could think of is on user builds to have the already initialized zygote as some kind of memory dump that can be read directly back in, instead of going through the re-loading of classes. Bleah. Package scanning is also a good target. This is basically an iteration through all .apks to build the in-memory data structures for them, and you can consider all of the work to be scanPackageLI for each of those .apks. Most of the optimization work so far has been on optimizing the loading and reading of .apks, since that also benefits many other things such as app launch time. That is probably getting pretty well optimized at this point, and it would be worth looking at things specifically to improve scanPackageLI. Note it isn't true that only AndroidManifest.xml is needed -- this is the file that is read, but it can have references to other things in the .apk. In particular, it will always need the resource table. Also we shouldn't need to page in all of an .apk to open it as a zip... the TOC is at the end of the zip, and that is all we should need to read to build the in-memory data structures. If something in the code is causing the entire .apk to be touched to open it, that is a great candidate for optimization (and would be of benefit to all the other things that open .apks). I definitely wouldn't want to remove the signature checks... these are important sanity checks for the package manager. In general I am worried about doing optimizations that retain unchecked data about apps across boots, because it has the potential to include bugs that cause very bad behavior. We have already seen such things in production devices where manufacturers were apparently trying to optimize this code. So I'd focus solely on speeding up the work it currently does first, before eliminating work by retaining state across boots. As far as package management being misdesigned because it isn't sitting on a file system, this really misses the point. An application is an .apk, which is a representation that can be transfered across devices. We deliberately do not want to have an install operation where we decompose that .apk on to a file system, and lose the original app, because there is very likely no way to get back to that .apk for transporting elsewhere. Note that this is not "building a persistent container and compression architecture in user space" -- it is just dealing with a representation of an application that is actually transportable. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
