Improving Android Boot Time Outline
From eLinux.org
Here is the outline for my talk:
- Title
- Outline
- Android boot overview
- Measuring boot times
- Problem areas
- Some gory details
- Ideas for improvements
- Android boot overview
- bootloader
- kernel
- init
- zygote
- building preload heap
- start package manager
- service manager
- start services
- measuring bootup time
- systems measured: adp1, n1, evm
- adp1 with donut
- n1 with eclair
- evm with eclair
- NOTE: used nfs root filesystem (file IO timings might be bogus)
- systems measured: adp1, n1, evm
- Tools for measuring and tracing boot time
- stopwatch
- grabserial
- printk times
- bootchart
- strace
- logcat
- method tracer*
- ftrace*
- stopwatch
- grabserial
- printk times
- bootchart
- strace
- logcat
- extra instrumentation for preloading classes
- PARSE_CHATTY flag for package scanning
- mention my own tool 'logdelta'
- method tracer*
- method traces is built in to
- ftrace?? (no)
- Problem Areas
- First, a bootchart for EVM board
- bootloader init
- kernel init
- zygote class preloading
- package scanning
- service initialization
- bootloader init
- outside scope of this talk
- didn't measure commercial bootloader, only development one (U-boot)
- kernel init
- is mostly the usual suspects
- (initcall_debug results)
- USB
- zygote class preloading
- zygote pre-loads just under 2000 classes, and instantiates them in its heap
- controlled by file:
- package manager package scan
- exact purpose is not known
- validation of certificates, permissions, capabilities and dependencies, etc.?
- EVERY package is scanned at boot time
- exact purpose is not known
- ideas for enhancements
- kernel speedups
- optimize package scan
- optimize class preloading
- miscellaneous optimizations
- sreadahead??
- kernel speedups
- outside the scope of this presentation
- see http://elinux.org/Boot_Time
- optimize package scan
- most definitely
- need to continue analysis
- most likely, should switch to a compressed flash file system
- use pre-constructed dalvik heap? (difficult?)
- thread the heap construction?
- sreadahead??
- could use sreadahead to pre-fill page cache
- however, this just masks bad behavior
- Contacts.apk (half of 1.6M) is read 4 times! during boot
- filling page cache makes reads after first one fast, but it would be better to avoid all these reads altogether
- better to just optimize or eliminate parseZipArchive()
- sreadahead should be used dead last (after all other enhancements)
- don't know how to preconstruct heap
- need to analyze heap
- FIXTHIS - is heap identical on every boot?
- how to dump heap memory
- how to dump any memory in Android??
- are parts identical??
- zoneinfo inefficiencies
- measure without strace, and see if time is a problem
- remaining questions
- future directions