ได้รับข้อผิดพลาด“ แอปพลิเคชันนี้กำลังแก้ไขข้อผิดพลาด autolayout engine จากเธรดพื้นหลัง” หรือไม่

เคยพบข้อผิดพลาดนี้มากมายใน OS X ของฉันโดยใช้ swift:

"แอปพลิเคชันนี้กำลังแก้ไขเอ็นจิ้น autolayout จากเธรดแบ็คกราวน์ซึ่งอาจนำไปสู่ความเสียหายของเครื่องยนต์และข้อผิดพลาดแปลก ๆ ซึ่งจะทำให้เกิดข้อยกเว้นในการเปิดตัวในอนาคต"

ฉันมีNSWindowของฉันและฉันเปลี่ยนมุมมองไปcontentViewที่หน้าต่าง ฉันได้รับข้อผิดพลาดเมื่อฉันพยายามทำNSApp.beginSheetหน้าต่างหรือเมื่อฉันเพิ่มsubviewหน้าต่าง พยายามปิดใช้งานการเก็บข้อมูลอัตโนมัติและฉันไม่มีอะไรที่ใช้เค้าโครงอัตโนมัติ ความคิดใด ๆ

บางครั้งมันก็โอเคและไม่มีอะไรเกิดขึ้นบางครั้งมันก็ทำให้ฉันUIและไม่มีอะไรเหลือ

จำเป็นต้องอยู่ภายในเธรดอื่นที่อนุญาตให้ UI อัปเดตทันทีที่การดำเนินการของฟังก์ชันเธรดเสร็จสมบูรณ์:

Modern Swift:

DispatchQueue.main.async {
    // Update UI
}

Swift เวอร์ชันเก่ากว่าก่อน Swift 3

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

Objective-C:

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

คุณได้รับข้อความแสดงข้อผิดพลาดที่คล้ายกันขณะทำการดีบั๊กด้วยคำสั่งพิมพ์โดยไม่ต้องใช้ 'dispatch_async' ดังนั้นเมื่อคุณได้รับข้อความแสดงข้อผิดพลาดนั่นคือเวลาที่ใช้

สวิฟต์ 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 จะหยุดแอพและทำเครื่องหมายบรรทัดของโค้ด (เช่นการเรียก func) ที่เข้าถึง UI จากเธรดพื้นหลัง

เมื่อคุณพยายามอัปเดตค่าฟิลด์ข้อความหรือเพิ่มมุมมองย่อยภายในเธรดพื้นหลังคุณจะพบปัญหานี้ ด้วยเหตุนี้คุณควรใส่รหัสประเภทนี้ในเธรดหลัก

คุณต้องตัดวิธีที่เรียกการปรับปรุง UI ด้วย dispatch_asynch เพื่อรับคิวหลัก ตัวอย่างเช่น:

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];
   ...
}

ฉันไม่รู้ว่าทำไมสิ่งนี้ช่วยได้เพราะฉันไม่เห็นว่ารหัสนี้ถูกเรียกมาจาก non-main-thread

หวังว่ามันจะช่วยให้ทุกคน

ฉันมีปัญหานี้ตั้งแต่อัปเดตเป็น iOS 9 SDK เมื่อฉันเรียกบล็อกที่อัปเดต UI ภายใน NSURLConnection async ตัวจัดการการร้องขอเสร็จสิ้น การเรียกการบล็อกใน dispatch_async โดยใช้ dispatch_main_queue แก้ปัญหาได้

มันทำงานได้ดีใน iOS 8

performSelectorInBackgroundมีปัญหาเดียวกันเพราะผมใช้

คุณต้องไม่เปลี่ยน UI หลักในเธรดหลัก! UIKit นั้นไม่ปลอดภัยสำหรับเธรดดังนั้นปัญหาข้างต้นและปัญหาแปลกอื่น ๆ ก็จะเกิดขึ้นถ้าคุณทำเช่นนั้น แอพอาจผิดพลาดได้

ดังนั้นในการดำเนินการของ UIKit คุณต้องกำหนด block และปล่อยให้มันทำงานบนคิวหลัก: เช่น,

NSOperationQueue.mainQueue().addOperationWithBlock {

}

เห็นได้ชัดว่าคุณกำลังทำการอัปเดต UI บนเธรดพื้นหลัง ไม่สามารถทำนายได้อย่างแม่นยำว่าที่ไหนโดยไม่เห็นรหัสของคุณ

นี่คือบางสถานการณ์ที่อาจเกิดขึ้น: -

คุณอาจจะทำอะไรกับเธรดพื้นหลังและไม่ได้ใช้ อยู่ในฟังก์ชั่นเดียวกันรหัสนี้ง่ายต่อการสังเกต

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

การเรียก func ที่ทำการร้องขอทางเว็บบนเธรดพื้นหลังและตัวจัดการความสมบูรณ์ของการเรียก func อื่น ๆ ที่กำลังทำการอัพเดท UI เพื่อแก้ปัญหานี้ให้ลองตรวจสอบรหัสที่คุณได้อัปเดต UI หลังจากการโทรผ่าน 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()
            }
}

ปัญหาหลักของ "แอปพลิเคชันนี้กำลังแก้ไขเอ็นจิ้นอัตโนมัติจากกระทู้พื้นหลัง" คือดูเหมือนว่าจะเข้าสู่ระบบเป็นเวลานานหลังจากเกิดปัญหาจริงซึ่งอาจทำให้แก้ไขปัญหาได้ยาก

ฉันจัดการเพื่อแก้ไขปัญหาโดยการสร้างจุดพักสัญลักษณ์สามแห่ง

Debug> เบรกพอยต์> สร้างเบรกพอยต์สัญลักษณ์ ...

เบรกพอยต์ 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

ฉันมีปัญหาเดียวกันเมื่อพยายามอัปเดตข้อความแสดงข้อผิดพลาดใน UILabel ใน ViewController เดียวกัน (ใช้เวลาเล็กน้อยในการอัปเดตข้อมูลเมื่อพยายามทำเช่นนั้นด้วยการเข้ารหัสปกติ) ฉันใช้DispatchQueueใน Swift 3 Xcode 8 และใช้งานได้

หากคุณต้องการตามล่าข้อผิดพลาดนี้ให้ใช้ตัวตรวจสอบเธรดหลักหยุดชั่วคราวในช่องทำเครื่องหมายปัญหา การแก้ไขเป็นเรื่องง่ายเกือบทุกครั้งโดยส่งบรรทัดปัญหาในคิวหลัก

สำหรับฉันปัญหาคือต่อไปนี้ ตรวจสอบให้แน่ใจว่าperformSegueWithIdentifier:มีการดำเนินการในหัวข้อหลัก:

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

สวิฟต์ 4

สมมติว่าถ้าคุณกำลังเรียกวิธีการบางอย่างโดยใช้คิวการดำเนินงาน

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

และสมมติว่าฟังก์ชัน searchFavourites เป็นเช่นนั้น

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

หากคุณโทรรหัสทั้งหมดในวิธีการ "searchFavourites" บนเธรดหลักจะยังคงมีข้อผิดพลาดหากคุณกำลังอัปเดต UI บางอย่างในนั้น

แอปพลิเคชันนี้กำลังแก้ไขเอ็นจิ้น autolayout จากเธรดพื้นหลังหลังจากเอ็นจินเข้าถึงจากเธรดหลัก

ดังนั้นใช้วิธีแก้

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
)

ฉันยังพบปัญหานี้ด้วยการเห็นข้อความเหล่านี้จำนวนมากและร่องรอยสแต็กที่ถูกพิมพ์ในเอาต์พุตเมื่อฉันปรับขนาดหน้าต่างให้มีขนาดเล็กกว่าค่าเริ่มต้น ใช้เวลานานในการหาปัญหาฉันคิดว่าฉันจะแบ่งปันวิธีแก้ปัญหาที่ค่อนข้างง่าย ผมได้เปิดใช้งานครั้งเดียวCan Draw ConcurrentlyบนNSTextViewผ่าน IB ที่บอก AppKit ว่าสามารถเรียกวิธีการดูdraw(_:)จากเธรดอื่น หลังจากปิดใช้งานฉันไม่ได้รับข้อความแสดงข้อผิดพลาดอีกต่อไป ฉันไม่พบปัญหาใด ๆ ก่อนที่จะอัปเดตเป็น macOS 10.14 Beta แต่ในเวลาเดียวกันฉันก็เริ่มแก้ไขรหัสเพื่อให้ทำงานกับมุมมองข้อความได้