2014-09-15 26 views
46

iOS 8'de bu tür bir özel durumun ne olduğunu bilen var mı? Kilitlenme raporu === gelenEXC_RESOURCE, WAKEUPS istisnasıyla kapatma uygulaması iOS 8 GM

===

Exception Type: EXC_RESOURCE 
Exception Subtype: WAKEUPS 
Exception Message: (Limit 150/sec) Observed 206/sec over 300 secs 
Triggered by Thread: 14 

sadece .. ... Bizim uygulaması bu istisna ile keyfi aralıklarla oldukça rastgele kapatıldığında iOS 8

Herhangi gerçekleşmesi görünüyor ipuçları hoşgeldin. Teşekkürler!

+0

Bununla herhangi bir şansın var mı? Ben suçlu ile aynı hatayı alıyorum: 'Konu 4 adı: WebThread' – ohhh

+0

Tam olarak aynı hatayı var. Xamarin ve OpenTok'u kullanma –

+0

Uygulamamızla, Ryan'ın aşağıda söyledikleriyle ilgili olabilecek benzer bir sorun yaşıyoruz. Temel olarak SKAction playSoundFileNamed kullanarak ses efektleri çalıyoruz: ama bazen, rastgele bir şekilde, uygulamadan çıkıp daha sonra devam etmedikçe hiç bir ses çalmıyor, sonra hepsi bir anda çalıyor, bu da bir şeyin bu eylemleri engellediğini gösteriyor ... Bir süre bu durumda oynamaya devam ederseniz, sonunda bu kazayı görürsünüz ... – gzafra

cevap

18

Uygulamanız, uygulamada belirli bir konuya uyandırma komutunu oldukça sık gönderiyor - görünüşe göre saniyede ortalama 206 kez. IOS 8'deki arka plandaki iş parçacıkları, saniyede her iş parçacığında bir uyku/uyanma döngüsünü kaç kez çalıştırabileceğiniz konusunda kesin bir sınırlamaya sahiptir ve burada yüksek bir sayıma sahip olmak, genellikle iş parçacığınızın yönetiminde bir şeyin yanlış/verimsiz olduğuna dair bir işarettir.

Kodunuzu görmeden, benim önerim C++ algoritmalarınızı uyku/uyandırma çağrıları için kontrol etmenizi veya her bir döngüde yeni iş parçacıkları başlatmak için arka plan işlemine birden çok kez basmanızdır.

Ray Wenderlich da sizin için iyi bir kaynaktır olabilir çoklu kullanım Apple'ın sistemine Grand Central Dispactch üzerinde fantastik bir öğretici vardır: http://www.raywenderlich.com/60749/grand-central-dispatch-in-depth-part-1

+0

Belirli bir iş parçacığında uyandırma çağrılarının sayısını denetlemek ve sınırlamak için herhangi bir yolu var mı? Çünkü, iş parçacığı iş bittikten sonra durma noktasına gelecektir, bunu sık sık uyandırmanın bir anlamı yoktur! –

+0

Bu sorunu daha iyi anlamama yardımcı olacak bir kod örneği sunabilir misiniz? –

+0

Arka plan iş parçacıklarında @synchronized kullanımı bu soruna neden olabilir mi? –

2

Xamarin kullanarak, biz de bu sorunu var. Aynı zamanda çok uzun bir süre beklediğimiz 4 SemaphoreSlim kullanıyorduk. SemaphoreSlim'in başka bir ilkel senkronizasyonla değiştirilmesi (Bizim durumumuzda AutoResetEvent, 1 maddelik bir Semaforu simüle etmek için) sorunu çözdü. ios 9.1 benim durumda

0

bu ben GPUTools için herhangi bir referans görmüyorum proje kaynaklar aracılığıyla arama gles sürücüsü neden için bazı işçi gibi görünüyor iplik 2 tarafından indirilmiş.

Thread 2 name: gputools.smt_poll.0x145722df0 
Thread 2 Attributed: 
0 libsystem_kernel.dylib   0x000000019a8b7440 __semwait_signal + 8 
1 libsystem_c.dylib    0x000000019a7c9e2c nanosleep + 212 
2 libsystem_c.dylib    0x000000019a7c9d4c 0x19a7bc000 + 56652 
3 GPUToolsCore     0x0000000100ba0ae0 0x100b98000 + 35552 
4 libsystem_pthread.dylib   0x000000019a97fb28 _pthread_body + 156 
5 libsystem_pthread.dylib   0x000000019a97fa8c _pthread_body + 0 
6 libsystem_pthread.dylib   0x000000019a97d028 thread_start + 4 

bu bakınız: Ben elma hata 23389472 bulundum iOS 7 and OpenGL issues/crashes , benim durumumda nedenini thusly, bu bir iş parçacığı ben değil veya bazı 3. parti kod yarattı ve bu çok olduğunu Muhtemelen benim hatam değil. Alt satır şudur: rahatsız edici iş parçacığınız size aitse (3. taraf yazılımları içeren), Ryan'ın yanıtı geçerlidir. Aksi halde, Apple ile iletişime geçmek için ya da/veya bunun için bir geçici çözüm aramanız gerekir.