UIKit vs SwiftUI: Por qué elegí UIKit para la velocidad de inicio
Esta página es una traducción automática del original en japonés. Leer el original en japonés
1. ¿Por qué es UIKit en 2026?
Apple enfatiza la evolución de SwiftUI en la WWDC anual, y la conveniencia de la interfaz de usuario declarada ya no es dudosa.
Sin embargo, esta aplicación tiene requisitos inflexibles. Es para hacer Time-to-Text (tiempo desde el inicio hasta la entrada de texto) a 500ms o menos.
En SwiftUI, hay una sobrecarga declarativa específica del marco de la interfaz de usuario, como la inicialización de @StateObject, la reevaluación de body y el control de tiempo de .onAppear. Estos se pueden ignorar en aplicaciones generales, pero no se pueden ignorar en situaciones en las que la optimización se persigue en milisegundos.
Por otro lado, la ruta que llama a becomeFirstResponder() desde viewDidAppear en UIKit es determinísticamente rápida. El ciclo de vida de ViewController es claro, y puede controlar con precisión cuándo se muestra el teclado.
2. La razón para eliminar por completo el Storyboard
Solo elegir UIKit no es suficiente. El guión gráfico también tiene una sobrecarga que afecta el rendimiento inicial.
- Costo del análisis XML:Storyboard es un archivo XML interno y debe analizarse al inicio
- Coste de resolución de Segue:Se necesita tiempo para resolver la configuración de Segue para las transiciones de pantalla
- Complejidad innecesaria:Las herramientas de diseño visual de Storyboard son excesivas para aplicaciones de notas simples
En su lugar, se adoptó la creación directa del ViewController mediante SceneDelegate.
func scene(_ scene: UIScene, willConnectTo session: UISceneSession,
options connectionOptions: UIScene.ConnectionOptions) {
PerformanceLogger.shared.signpostBegin(name: "SceneConnect")
guard let windowScene = (scene as? UIWindowScene) else { return }
let window = UIWindow(windowScene: windowScene)
let composeVC = ComposeViewController()
let navController = UINavigationController(rootViewController: composeVC)
window.rootViewController = navController
window.makeKeyAndVisible()
PerformanceLogger.shared.signpostEnd(name: "SceneConnect")
}
Este enfoque logra Cero Tiempo de Perse para Storyboard y Tiempo de Resolución Cero Segue. Al generar el ComposeViewController directamente desde SceneDelegate, el procesamiento innecesario se ha eliminado por completo de la ruta de inicio.
3. La línea de vista 1DidAppear lo completa todo
La mayor fortaleza de UIKit es que el ciclo de vida de ViewController está claramente definido. Cuando se llama a viewDidAppear(_:), la vista se muestra completamente en la pantalla. Al llamar a becomeFirstResponder() a esta hora determinada, puede minimizar el retraso hasta que se muestre el teclado.
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
activateTextInput()
}
private func activateTextInput() {
textView.becomeFirstResponder()
PerformanceLogger.shared.endTimeToText()
}
os_signpost se mide con precisión de nanosegundos. PerformanceLogger.shared.endTimeToText() registra el evento de terminación de la señal y permite un análisis detallado en Instrumentos.
4. Mecanismo de medición del rendimiento
Las decisiones de diseño se toman en base a datos cuantitativos en lugar de un juicio sensorial de "rápido".
- PerformanceLogger:Loger personalizado envuelto con
os_signpost. Mida cada fase de inicio, transmisión y actualización de la interfaz de usuario - Cooperación de instrumentos:El seguimiento de precisión de nanosegundos es posible con el instrumento os_signpost de Xcode
- Métricas principales:Tiempo para enviar un mensaje de texto (inicio → entrada posible), Enviar para restablecer (botón de enviar → inicialización de la interfaz de usuario)
- Monitoreo continuo:Mediciones de rendimiento en todas las compilaciones en desarrollo para detectar instantáneamente la regresión
El rendimiento es una función. Incluso si los usuarios no requieren explícitamente "velocidad", las aplicaciones lentas no se utilizarán inconscientemente. Por eso es importante seguir gestionando el rendimiento numéricamente.
5. ¿Hay alguna situación en la que se use SwiftUI?
UIKit no es la única opción. Hay algunas situaciones en la aplicación en las que SwiftUI es adecuado.
- Pantalla de configuración:La interfaz de usuario declarativa de SwiftUI aumenta la productividad en pantallas no críticas que no afectan la velocidad de inicio
- Definición de ruta crítica:Inicio → Introduzca una nota → Mantenga el flujo central de envío con UIKit
- Complejidad híbrida:La mezcla de UIKit y SwiftUI requiere atención a la consistencia de la gestión de UIHostingController y el flujo de datos
- Juicio en este momento:La interfaz de usuario de la aplicación memo es simple, y es mejor unificarla con UIKit de pantalla completa para mantener la consistencia de la base de código
Si el rendimiento de SwiftUI mejora aún más en el futuro, hay espacio para la reevaluación, pero el camino crítico UIKit es una política para mantenerlo por el momento.
Preguntas frecuentes
@StateObjectybody añade procesamiento por su reevaluación. Para este desarrollo, centrado en la rapidez, elegimos UIKit por su control detallado del ciclo de vida. No es una conclusión obtenida midiendo ambas opciones bajo las mismas condiciones.os_signposty se analiza con Instrumentos.Referencias
- Apple Desarrollador — Documentación de UIKit — La referencia oficial al marco adoptado para la construcción de la interfaz de usuario de SimpleMemo
- Apple Desarrollador — Documentación de SwiftUI — Un marco de interfaz de usuario declarativo que se ha comparado. Tema de medición de rendimiento
- Apple Desarrollador — os_signpost / OSSignposter — Medición del rendimiento de la cooperación de instrumentos utilizada para la medición de tiempo a texto API
- WWDC 2023 - Analizar cuelga con instrumentos — Sesión de WWDC como referencia para la optimización de la respuesta de la interfaz de usuario