Barrapunto

Aquí entra ya la habilidad del diseñador, qué se puede parelizar y cómo, con objeto de mejorar el tiempo de carga. Cualquier sistema operativo actual te da herramientas más que suficientes para hacer asequibles diseños así. Desde frameworks para hacer aplicaciones componentizadas hasta primitivas de sincronización y bloqueo.

Además no hablamos de nada teórico: estás técnicas se usan. Observa por ejemplo el proceso de arranque del mismo MS Office, para no ir más lejos:

A pesar de lo que repiten los loritos para quien quiera escucharlos, el MS Office no precarga nada en el arranque del MS Windows. No hace falta tener el código fuente para ver que esto es así: basta con ver qué bibliotecas hay cargadas en memoria antes del inicio, cuáles va cargando el Office y las llamadas que va haciendo. Eso lo puedes comprobar con infinidad de herramientas de depuración.

Entonces, ¿por qué el arranque del MS Office es mucho más rápido que el del OpenOffice.org?. Sencillamente porque un programa como MS Word resuelve un número muy pequeño de bibliotecas en el inicio, y retrasa el resto de resoluciones para cuando el usuario las demande/pida esas características.

A la larga el número de resoluciones que hace Word y que hace Writter son similares, pero el Word se centra en mostrar algo útil en primer lugar y retrasa todo lo que no es imprescindible. No hace todas las resoluciones de golpe y la experiencia del usuario es mejor.

Normalmente un splash esconde un mal diseño y/o dejadez para optimizar el arranque. Algo bastante habitual en cientos de aplicaciones, libres o no, comerciales o gratuitas.

Otro ejemplo bastante claro: el programa Padre te muestre un splash y lo primero que sale al finalizar el arranque sea un diálogo de login/selección de declaración, algo que podría ser mostrado mucho antes en el proceso de carga.