Obtener un" Esta aplicación está modificando el motor de diseño automático de un hilo de fondo " error?

Recibe un mensaje de error similar mientras depura con instrucciones print sin usar 'dispatch_async' Así que cuando recibes ese mensaje de error, es hora de usar

Swift 4

DispatchQueue.main.async { //code }

Swift 3

DispatchQueue.main.async(){ //code }

Versiones anteriores de Swift

dispatch_async(dispatch_get_main_queue()){ //code }

Usé la respuesta de @markussvensson para detectar mi problema, la encontré usando este Punto de interrupción simbólico :

1. Símbolos: [UIView layoutIfNeeded] o [UIView updateConstraintsIfNeeded]
2. Condición: !(BOOL)[NSThread isMainThread]

Cuando intenta actualizar un valor de campo de texto o agregar una subview dentro de un hilo de fondo, puede obtener este problema. Por esa razón, usted debe poner este tipo de código en el hilo principal.

Necesita empaquetar los métodos que llaman a las actualizaciones de la interfaz de usuario con dispatch_asynch para obtener la cola principal. Por ejemplo:

dispatch_async(dispatch_get_main_queue(), { () -> Void in
   self.friendLabel.text = "You are following \(friendCount) accounts"
})

EDITADO - SWIFT 3:

Ahora, podemos hacerlo siguiendo el siguiente código:

// Move to a background thread to do some long running work
DispatchQueue.global(qos: .userInitiated).async {
   // Do long running task here
   // Bounce back to the main thread to update the UI
   DispatchQueue.main.async {
      self.friendLabel.text = "You are following \(friendCount) accounts"
   }
}

Para mí, este mensaje de error se originó a partir de un banner de Admob SDK.

Pude rastrear el origen a "WebThread" estableciendo un punto de interrupción condicional.

Entonces pude deshacerme del problema encapsulando la creación del Banner con:

dispatch_async(dispatch_get_main_queue(), ^{
   _bannerForTableFooter = [[GADBannerView alloc] initWithAdSize:kGADAdSizeSmartBannerPortrait];
   ...
}

No se por qué esto ayudó, ya que no puedo ver cómo se llamó a este código desde un subproceso no principal.

Espero que pueda ayudar a cualquiera.

Tuve este problema desde la actualización al SDK de iOS 9 cuando estaba llamando a un bloque que realizaba actualizaciones de interfaz de usuario dentro de un controlador de finalización de solicitud asíncrona de NSURLConnection. Poner la llamada de bloque en un dispatch_async usando dispatch_main_queue resolvió el problema.

Funcionó bien en iOS 8.

Tenía el mismo problema porque estaba usando performSelectorInBackground.

¡No debe cambiar la interfaz de usuario fuera del hilo principal! UIKit no es seguro para hilos, por lo que el problema anterior y también algunos otros problemas extraños surgirán si lo haces. La aplicación puede incluso bloquearse.

Por lo tanto, para hacer las operaciones de UIKit, necesita definir block y dejar que se ejecute en la cola principal: como,

NSOperationQueue.mainQueue().addOperationWithBlock {

}

Obviamente estás haciendo alguna actualización de la interfaz de usuario en el hilo de tierra posterior. No puedo predecir exactamente dónde, sin ver su código.

Estas son algunas situaciones que podrían suceder:-

Es posible que esté haciendo algo en el hilo de fondo y no lo esté usando. Al estar en la misma función, este código es más fácil de detectar.

DispatchQueue.main.async { // do UI update here }

Llamando a un func haciendo llamada de solicitud web en el hilo de fondo y su controlador de finalización llamando a otro func haciendo actualización de interfaz de usuario. para resolver esto, intente verificar el código donde tiene se ha actualizado la interfaz de usuario después de la llamada webrequest.

// Do something on background thread
DispatchQueue.global(qos: .userInitiated).async {
   // update UI on main thread
   DispatchQueue.main.async {
                // Updating whole table view
                self.myTableview.reloadData()
            }
}

Tuve este problema al recargar datos en UITableView. Simplemente enviando recarga de la siguiente manera solucionó el problema para mí.

    dispatch_async(dispatch_get_main_queue(), { () -> Void in
        self.tableView.reloadData()
    })

Yo tenía el mismo problema. Resulta que estaba usando UIAlerts que necesitaba la cola principal. Pero, han sido obsoletos.
Cuando cambié el UIAlerts a UIAlertController, ya no tuve el problema y no tuve que usar ningún código dispatch_async. La lección-prestar atención a las advertencias. Ayudan incluso cuando no lo esperas.

Ya tienes la respuesta correcta del código de @Mark pero, solo para compartir mis hallazgos: El problema es que está solicitando un cambio en la vista y asumiendo que sucederá instantáneamente. En realidad, la carga de una vista depende de los recursos disponibles. Si todo se carga lo suficientemente rápido y no hay retrasos, entonces no nota nada. En escenarios, donde hay algún retraso debido a que el subproceso del proceso está ocupado, etc., la aplicación se encuentra en una situación en la que se supone que mostrar algo a pesar de que no está listo todavía. Por lo tanto, es aconsejable enviar estas solicitudes en colas asíncronas para que se ejecuten en función de la carga.

Tuve este problema cuando estaba usando TouchID si eso ayuda a alguien más, envuelva su lógica de éxito que probablemente hace algo con la interfaz de usuario en la cola principal.

Podría ser algo tan simple como establecer un valor de campo / etiqueta de texto o agregar una subview dentro de un hilo de fondo, lo que puede causar que el diseño de un campo cambie. Asegúrate de que todo lo que hagas con la interfaz solo suceda en el hilo principal.

Compruebe este enlace: https://forums.developer.apple.com/thread/7399

Tuve el mismo problema al intentar actualizar el mensaje de error en UILabel en el mismo ViewController (tarda un poco en actualizar los datos cuando intenta hacerlo con codificación normal). Usé DispatchQueue en Swift 3 Xcode 8 y funciona.

Para mí el tema era el siguiente. Asegúrese de que performSegueWithIdentifier: se realiza en el hilo principal:

dispatch_async (dispatch_get_main_queue(), ^{
  [self performSegueWithIdentifier:@"ViewController" sender:nil];
});

Swift 4,

Supongamos que, si está llamando a algún método usando la operación queue

operationQueue.addOperation({
            self.searchFavourites()
        })

Y supongamos que la función searchFavourites es como,

func searchFavourites() {
     DispatchQueue.main.async {
                    //Your code
                }
}

Si llamas a todo el código dentro del método "searchFavourites" en el hilo principal, todavía dará un error si estás actualizando alguna interfaz de usuario en él.

Esta aplicación está modificando el motor de diseño automático desde un fondo hilo después de que se accedió al motor desde el hilo principal.

Así que use solución,

operationQueue.addOperation({
            DispatchQueue.main.async {
                self.searchFavourites()
            }
        })

Para este tipo de escenario.

También me encontré con este problema, al ver una tonelada de estos mensajes y rastros de pila que se imprimen en la salida, cuando cambié el tamaño de la ventana a un tamaño más pequeño que su valor inicial. Pasando mucho tiempo resolviendo el problema, pensé en compartir la solución bastante simple. Una vez había habilitado Can Draw Concurrently en un NSTextView a través de IB. Eso le dice a AppKit que puede llamar al método draw(_:) de la vista desde otro hilo. Después de desactivarlo, ya no recibí ningún mensaje de error. No tuve ningún problema antes de actualizar a macOS 10.14 Beta, pero al mismo tiempo, también comencé a modificar el código para realizar trabajos con la vista de texto.