[英]IOS Air Application crashes without info
我們的團隊經過2周的工作(個人和工作)苦苦掙扎,以下問題涉及Ios部署和Adobe Air。 以下是詳細信息,要求我們發布此應用程序。 如果有人可以幫助我們調試此任務,我們將不勝感激。
團隊正在將IntelliJ / Flashbuilder設置與airsdk 17配合使用,下面的描述也會影響AirSdk19和Beta Build AirSDK20。 我們試圖在IOS上編譯Adobe Air項目,但是在使用Apple委托的AOT編譯器編譯應用程序時遇到了很多麻煩(我們的android應用程序使用JIT編譯器運行得很好)。
在討論問題之前,我想討論一下我們正在開發的應用程序,以及在幫助會議中可能有幫助或無用的任何規范。
應用程序的工作方式:設置應用程序的方式是,我們在自己的瑞士法郎中都有一系列的Activity,並且主應用程序也在其自己的瑞士法郎中。 活動分為兩種類型:解釋活動和挑戰活動。 所有挑戰活動都繼承自ItemActivity類,而所有解釋活動都繼承自ItemActivityVideo類,而后者又繼承自ItemActivity。
我們的活動的繼承結構如下:
說明活動 :
主要(特定於每個活動)<-ItemActivityVideo <-ItemActivity
Challange活動:
主要(特定於每個活動)<-ItemActivity。
主Swf具有一系列屏幕,其中的“ ItemSelect”屏幕布局了一組按鈕,每個按鈕均指示應用程序加載外部活動SWF之一。 所有SWF文件都與主SWF文件一起托管在本地,因此在進行“加載”項時沒有網絡調用。
解釋活動是唯一利用位於“語音控制器”類內部的聲音的活動,每當引用該類時(僅通過諸如“ new VoiceController()之類的指令”),該Ios應用程序就會崩潰,某些項目也會崩潰在時間軸的各個部分上,沒有從Flash調試器或崩潰日志中獲得任何指示的原因,調試器僅打印“ Player Session Exited”,同時崩潰日志中產生了段錯誤信號“ SigSegV”,而沒有任何原因的提示內存濫用。
幫助我們的團隊調試此問題的任何幫助都將極大地幫助我們,由於當前的Apple架構和Adobe的過時文檔之間發生了巨大變化,因此使用dsymutils來表示崩潰日志也存在問題。
以下是我們的應用程序崩潰日志的一部分:
Incident Identifier: FC5E0968-20E5-4A52-BF7E-38FCBA425D00
CrashReporter Key: ----------------------------------------------
Hardware Model: iPad2,5
Process: myApp [1848]
Path: /private/var/mobile/Containers/Bundle/Application/30740408-6AAD-447E-8ED3-0ECAEF7A7B0A/myApp.app/myApp
Identifier: myApp
Version: 0.4.0 (0.4.0)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2015-12-04 13:29:38.38 -0500
Launch Time: 2015-12-04 13:29:22.22 -0500
OS Version: iOS 9.1 (13B143)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x00000083
Triggered by Thread: 0
Filtered syslog:
None found
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 myApp 0x0248debe 0x74000 + 37854910
1 myApp 0x00797598 0x74000 + 7484824
2 myApp 0x00797598 0x74000 + 7484824
3 myApp 0x00794b7c 0x74000 + 7474044
4 myApp 0x007b6794 0x74000 + 7612308
5 myApp 0x0247aab8 0x74000 + 37776056
6 myApp 0x0248f926 0x74000 + 37861670
7 myApp 0x024506b6 0x74000 + 37602998
8 myApp 0x02450648 0x74000 + 37602888
9 myApp 0x021fb188 0x74000 + 35156360
10 myApp 0x0225027c 0x74000 + 35504764
11 myApp 0x01facb90 0x74000 + 32738192
12 myApp 0x01fb2650 0x74000 + 32761424
13 myApp 0x0010b80c 0x74000 + 620556
14 myApp 0x007b74d0 0x74000 + 7615696
15 myApp 0x007eda9c 0x74000 + 7838364
16 myApp 0x0247aab8 0x74000 + 37776056
17 myApp 0x0248f926 0x74000 + 37861670
18 myApp 0x024506b6 0x74000 + 37602998
19 myApp 0x02450648 0x74000 + 37602888
20 myApp 0x021fb188 0x74000 + 35156360
21 myApp 0x021fbd08 0x74000 + 35159304
22 myApp 0x021fba9c 0x74000 + 35158684
23 myApp 0x021fb614 0x74000 + 35157524
24 myApp 0x021bd364 0x74000 + 34902884
25 myApp 0x00237d18 0x74000 + 1850648
26 myApp 0x00237dec 0x74000 + 1850860
27 myApp 0x0247aab8 0x74000 + 37776056
28 myApp 0x0248f926 0x74000 + 37861670
29 myApp 0x0219b9fc 0x74000 + 34765308
30 myApp 0x0219c198 0x74000 + 34767256
31 myApp 0x021f8bf8 0x74000 + 35146744
32 myApp 0x0208b79c 0x74000 + 33650588
33 myApp 0x0208c2f4 0x74000 + 33653492
34 myApp 0x01fc0a9c 0x74000 + 32819868
35 QuartzCore 0x2999b7f2 0x29941000 + 370674
36 QuartzCore 0x2999b63e 0x29941000 + 370238
37 IOMobileFramebuffer 0x2f87957a 0x2f874000 + 21882
38 IOKit 0x270524d8 0x2704e000 + 17624
39 CoreFoundation 0x25f48058 0x25ea2000 + 680024
40 CoreFoundation 0x25f5a3b2 0x25ea2000 + 754610
41 CoreFoundation 0x25f59ac6 0x25ea2000 + 752326
42 CoreFoundation 0x25f57ed8 0x25ea2000 + 745176
43 CoreFoundation 0x25eab118 0x25ea2000 + 37144
44 CoreFoundation 0x25eaaf04 0x25ea2000 + 36612
45 GraphicsServices 0x2f035ac8 0x2f02c000 + 39624
46 UIKit 0x2a0edf14 0x2a072000 + 507668
47 myApp 0x020b6e40 0x74000 + 33828416
48 libdyld.dylib 0x3819d872 0x3819b000 + 10354
任何事情都會使您的Ios應用程序崩潰,而不會導致Android版本崩潰,例如:文件名。 您可以加載一個名為“ test.mp3”的聲音,並在文件系統“ Test.mp3”中真正調用該聲音,它將在調試中工作,在Android中工作,甚至在Ios中播放幾次,然后使應用程序崩潰。 Ios中的所有文件名都應小寫,並且不包含花哨字符。 通常,在AIR中調試Ios應用程序實際上只能歸結為跟蹤,沒有真正簡單的方法可以將DYSM轉換為AS3中有意義的任何內容,例如跟蹤,跟蹤,跟蹤。 我在每個項目中都有一個擴展的Sprite類,該類可以在一個調用中刪除所有已注冊的偵聽器。 非常方便,但是第一個版本在Ios中幾乎是隨機崩潰的。 我遍歷了所有痕跡,最后發現我的最后一條痕跡恰好在“ removeListeners()”調用之前。 所以我注釋掉了方法代碼,不再崩潰。 然后,我對系統進行了重新設計,使其更加牢固,並且最終一切正常,而Ios中沒有崩潰。
總結一下:
在Ios中,如果從外部加載任何文件時請特別注意文件名,則文件名應為小寫字母且不包含奇特字符,否則...請注意崩潰!
要調試並真正知道發生了什么,只有跟蹤,將跟蹤放到任何地方,並注意最后一個,錯誤的代碼將在緊隨其后。 我確實有一個將所有跟蹤實時輸出到服務器的系統,因此即使在testflight安裝中也可以捕獲它們。 將類似的東西放在一起。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.