3 ms·
Android uses a similar approach to launch apps quickly. When you request to start an app the zygote process forks and the child does the work of starting the ap
by bhawks 2y ago
Android uses a similar approach to launch apps quickly. When you request to start an app the zygote process forks and the child does the work of starting the app. It allows the children to share all the upfront initialization that is done once per boot.
- saagarjha 2y agoiOS does this too now.
- lxgr 2y agoDo you know how Apple calls their version? I’m curious how they implement it.
- diggan 2y agoNot parent, but maybe they are possibly referring to "State Restoration"?
- saagarjha 2y agodyld closures and prewarming actually
- lxgr 2y agoThank you! That sounds pretty different in implementation from zygote processes though: Zygote processes do go through the initialization once, but then clone that pre-initialized state via forking. That makes launches faster, but importantly also reduces memory usage by sharing effectively read-only dirty memory across all processes (e.g. everything read into memory by each process via read() instead of memory mapping). dyld closures seem to be caching process-specific linking precalculations, and prewarming just opportunistically (pre-)launches an app in case it's needed later. Same effect (faster launch time), but probably no memory savings, and a very different implementation.
- saagarjha 2y agoYes to be clear when I said "iOS does this" I meant "kinda similar to the whole freeze and restore thing" (which is the general topic here) not "the exact thing Android is doing"
- lxgr 2y agoChrome does the same thing for (per ~tab) renderer processes! Arguably at least as important as the speed/CPU usage improvements is the fact that this lets all processes share all "initialize once read never" memory that would otherwise have to eventually be swapped out once per process (or, in the case of Android, hang around until the app gets killed, since I think Android does not swap).