「このアプリケーションは、自動レイアウトエンジンをバックグラウンドスレッドから変更しています」エラーが発生しましたか？

私のOS Xでswiftを使用してこのエラーが頻繁に発生しています：

「このアプリケーションは、自動レイアウトエンジンをバックグラウンドスレッドから変更しているため、エンジンの破損や奇妙なクラッシュにつながる可能性があります。これにより、将来のリリースで例外が発生します。」

私のNSWindowがcontentViewあり、ウィンドウのビューにスワップしています。ウィンドウでを実行しようとしたり、ウィンドウにを追加したりすると、エラーが発生します。自動サイズ変更機能を無効にしてみましたが、自動レイアウトを使用するものはありません。何かご意見は？NSApp.beginSheetsubview

時にはそれは大丈夫で何も起こりません、他の時にはそれは完全に私UIを壊し、何もロードしません

スレッド関数の実行が完了するとすぐにUIを更新できるように、別のスレッド内に配置する必要があります。

モダンスウィフト：

DispatchQueue.main.async {
    // Update UI
}

Swift 3より前の古いバージョンのSwift。

dispatch_async(dispatch_get_main_queue(){
    // code here
})

Objective-C：

dispatch_async(dispatch_get_main_queue(), ^{
    // code here
});

'dispatch_async'を使用せずにprintステートメントでデバッグしているときに同様のエラーメッセージが表示されるので、そのエラーメッセージが表示されたら、使用する時間

スウィフト4

DispatchQueue.main.async { //code }

スウィフト3

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

以前のSwiftバージョン

dispatch_async(dispatch_get_main_queue()){ //code }

「このアプリケーションは、自動レイアウトエンジンをバックグラウンドスレッドから変更しています」というエラーは、実際の問題が発生してからかなり後にコンソールに記録されるため、ブレークポイントを使用しないとデバッグが困難になる可能性があります。

@markussvenssonの回答を使用して問題を検出し、このシンボリックブレークポイントを使用してそれを見つけました（デバッグ>ブレークポイント>シンボリックブレークポイントの作成）：

1. 記号：[UIView layoutIfNeeded]または[UIView updateConstraintsIfNeeded]
2. 状態： !(BOOL)[NSThread isMainThread]

エミュレーターでアプリをビルドして実行し、エラーメッセージがスローされる原因となる手順を複製します（アプリは通常より遅くなります！）。Xcodeはアプリを停止し、バックグラウンドスレッドからUIにアクセスしているコード行（たとえば、funcの呼び出し）をマークします。

テキストフィールドの値を更新するか、バックグラウンドスレッド内にサブビューを追加しようとすると、この問題が発生する可能性があります。そのため、この種のコードはメインスレッドに配置する必要があります。

メインキューを取得するには、dispatch_asynchでUI更新を呼び出すメソッドをラップする必要があります。例えば：

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

編集-SWIFT 3：

今、私たちは次のコードに従ってそれを行うことができます：

// 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"
   }
}

私にとって、このエラーメッセージはAdmob SDKのバナーから発信されました。

条件付きブレークポイントを設定することで、「WebThread」の起点を追跡できました。

次に、バナーの作成を次のようにカプセル化することで問題を取り除くことができました。

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

このコードが非メインスレッドからどのように呼び出されたかがわからないので、なぜこれが役に立ったのかわかりません。

それが誰にも役立つことを願っています。

NSURLConnection非同期要求完了ハンドラー内でUIを更新するブロックを呼び出しているときにiOS 9 SDKに更新してから、この問題が発生しました。dispatch_main_queueを使用してブロック呼び出しをdispatch_asyncに配置すると、問題が解決しました。

iOS 8では問題なく動作しました。

私が使用していたため、同じ問題がありましたperformSelectorInBackground。

メインスレッド以外でUIを変更しないでください。UIKitはスレッドセーフではないため、これを行うと上記の問題やその他の奇妙な問題が発生します。アプリがクラッシュすることさえあります。

したがって、UIKit操作を行うには、ブロックを定義してメインキューで実行できるようにする必要があります。

NSOperationQueue.mainQueue().addOperationWithBlock {

}

明らかに、バックグラウンドスレッドでUIの更新を行っています。コードを見ずに、正確な場所を予測できません。

これらはそれが起こるかもしれないいくつかの状況です：-

あなたはバックグラウンドスレッドで何かをしていて、使用していないかもしれません。同じ関数であるため、このコードを見つけるのは簡単です。

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

バックグラウンドスレッドでWeb要求呼び出しを行うfuncを呼び出し、その完了ハンドラーがui更新を行う他のfuncを呼び出します。これを解決するには、webrequest呼び出し後にUIを更新したコードを確認してください。

// 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()
            }
}

「このアプリケーションは自動レイアウトエンジンをバックグラウンドスレッドから変更しています」の主な問題は、実際の問題が発生してから長い時間が経過するとログに記録されるように見えるため、トラブルシューティングが非常に困難になる可能性があります。

私は3つのシンボリックブレークポイントを作成することで問題を解決しました。

デバッグ>ブレークポイント>シンボリックブレークポイントの作成...

ブレークポイント1：

• シンボル： -[UIView setNeedsLayout]

• 状態： !(BOOL)[NSThread isMainThread]

ブレークポイント2：

• シンボル： -[UIView layoutIfNeeded]

• 状態： !(BOOL)[NSThread isMainThread]

ブレークポイント3：

• シンボル： -[UIView updateConstraintsIfNeeded]

• 状態： !(BOOL)[NSThread isMainThread]

これらのブレークポイントを使用すると、非メインスレッドで誤ってUIメソッドを呼び出す実際の行で簡単にブレークすることができます。

UITableViewでデータを再読み込み中にこの問題が発生しました。次のようにリロードをディスパッチするだけで問題が解決しました。

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

同じ問題がありました。UIAlertsメインキューが必要なものを使用していたことがわかりました。しかし、それらは廃止されました。
をに変更したUIAlertsところ、UIAlertController問題がなくなり、dispatch_asyncコードを使用する必要がなくなりました。レッスン-警告に注意してください。彼らはあなたがそれを期待しないときでも助けます。

@Markからの正しいコードの回答は既にありますが、私の発見を共有するだけです。問題は、ビューの変更を要求し、それが即座に発生すると想定していることです。実際には、ビューの読み込みは利用可能なリソースに依存します。すべてが十分に速く読み込まれ、遅延がない場合は、何も気づきません。プロセススレッドがビジーであるなどの理由で遅延が発生するシナリオでは、アプリケーションは、まだ準備ができていなくても何かを表示することになっている状況に陥ります。したがって、これらの要求を非同期キューにディスパッチして、負荷に基づいて実行されるようにすることをお勧めします。

TouchIDを使用しているときにこの問題が発生しました。それが他の誰かを助ける場合、メインキューのUIで何かを行う可能性のある成功ロジックをラップします。

これは、テキストフィールドやラベルの値を設定したり、バックグラウンドスレッド内にサブビューを追加したりするような単純なもので、フィールドのレイアウトが変更される可能性があります。インターフェースで行うことはすべて、メインスレッドでのみ行われるようにしてください。

このリンクを確認してください：https : //forums.developer.apple.com/thread/7399

同じViewControllerのUILabelでエラーメッセージを更新しようとすると、同じ問題が発生しました（通常のコーディングでデータを更新しようとすると、少し時間がかかります）。私DispatchQueueはSwift 3 Xcode 8で使用しましたが、動作します。

このエラーをハントしたい場合は、メインスレッドチェッカーを使用して問題を一時停止するチェックボックスを使用します。修正はほとんどの場合簡単で、問題のある行をメインキューにディスパッチします。

私にとっての問題は次のとおりです。performSegueWithIdentifier:メインスレッドで実行されることを確認してください：

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

Swift 4

操作キューを使用してメソッドを呼び出す場合を想定します。

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

そして関数searchFavouritesが

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

呼び出すと、メインスレッドの「searchFavourites」メソッド内のすべてのコードで、UIを更新している場合でもエラーが発生します。

このアプリケーションは、メインスレッドからエンジンにアクセスした後、バックグラウンドスレッドから自動レイアウトエンジンを変更しています。

だからソリューションを使用して、

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

このようなシナリオの場合。

ここでログからこの行を確認してください

$S12AppName18ViewControllerC11Func()ySS_S2StF + 4420

このようなメインスレッドから関数を呼び出すために必要なバックグラウンドスレッドまたはAPIメソッドを呼び出している場所から呼び出す関数を確認できます。

DispatchQueue.main.async { func()}

func（）は、API呼び出しの成功またはその他の結果として呼び出す関数です。

ここにログ

This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes.
 Stack:(
    0   Foundation                          0x00000001c570ce50 <redacted> + 96
    1   Foundation                          0x00000001c5501868 <redacted> + 32
    2   Foundation                          0x00000001c5544370 <redacted> + 540
    3   Foundation                          0x00000001c5543840 <redacted> + 396
    4   Foundation                          0x00000001c554358c <redacted> + 272
    5   Foundation                          0x00000001c5542e10 <redacted> + 264
    6   UIKitCore                           0x00000001f20d62e4 <redacted> + 488
    7   UIKitCore                           0x00000001f20d67b0 <redacted> + 36
    8   UIKitCore                           0x00000001f20d6eb0 <redacted> + 84
    9   Foundation                          0x00000001c571d124 <redacted> + 76
    10  Foundation                          0x00000001c54ff30c <redacted> + 108
    11  Foundation                          0x00000001c54fe304 <redacted> + 328
    12  UIKitCore                           0x00000001f151dc0c <redacted> + 156
    13  UIKitCore                           0x00000001f151e0c0 <redacted> + 152
    14  UIKitCore                           0x00000001f1514834 <redacted> + 868
    15  UIKitCore                           0x00000001f1518760 <redacted> + 104
    16  UIKitCore                           0x00000001f1543370 <redacted> + 1772
    17  UIKitCore                           0x00000001f1546598 <redacted> + 120
    18  UIKitCore                           0x00000001f14fc850 <redacted> + 1452
    19  UIKitCore                           0x00000001f168f318 <redacted> + 196
    20  UIKitCore                           0x00000001f168d330 <redacted> + 144
    21  AppName                        0x0000000100b8ed00 $S12AppName18ViewControllerC11Func()ySS_S2StF + 4420
    22  AppName                        0x0000000100b8d9f4 $S12CcfU0_y10Foundation4DataVSg_So13NSURLResponseCSgs5Error_pSgtcfU_ + 2384
    23  App NAme                        0x0000000100a98f3c $S10Foundation4DataVSgSo13NSURLResponseCSgs5Error_pSgIegggg_So6NSDataCSgAGSo7NSErrorCSgIeyByyy_TR + 316
    24  CFNetwork                           0x00000001c513aa00 <redacted> + 32
    25  CFNetwork                           0x00000001c514f1a0 <redacted> + 176
    26  Foundation                          0x00000001c55ed8bc <redacted> + 16
    27  Foundation                          0x00000001c54f5ab8 <redacted> + 72
    28  Foundation                          0x00000001c54f4f8c <redacted> + 740
    29  Foundation                          0x00000001c55ef790 <redacted> + 272
    30  libdispatch.dylib                   0x000000010286f824 _dispatch_call_block_and_release + 24
    31  libdispatch.dylib                   0x0000000102870dc8 _dispatch_client_callout + 16
    32  libdispatch.dylib                   0x00000001028741c4 _dispatch_continuation_pop + 528
    33  libdispatch.dylib                   0x0000000102873604 _dispatch_async_redirect_invoke + 632
    34  libdispatch.dylib                   0x00000001028821dc _dispatch_root_queue_drain + 376
    35  libdispatch.dylib                   0x0000000102882bc8 _dispatch_worker_thread2 + 156
    36  libsystem_pthread.dylib             0x00000001c477917c _pthread_wqthread + 472
    37  libsystem_pthread.dylib             0x00000001c477bcec start_wqthread + 4
)

また、ウィンドウのサイズを初期値よりも小さいサイズに変更したときに、これらの大量のメッセージとスタックトレースが出力に出力されるのを確認して、この問題にも遭遇しました。問題を理解するのに長い時間を費やしていたので、かなり簡単な解決策を共有したいと思いました。私はかつてIBで有効Can Draw ConcurrentlyにしNSTextViewていました。これにより、AppKit draw(_:)は別のスレッドからビューのメソッドを呼び出すことができることがわかります。無効にすると、エラーメッセージが表示されなくなります。macOS 10.14 Betaにアップデートする前は問題はありませんでしたが、同時に、テキストビューで動作するようにコードを変更し始めました。