iOS開發--應用崩潰日誌揭秘（二）

標籤：

情境 4: 吃棒棒糖時閃退!

使用者郵件說, “當rage master吃棒棒糖時應用就閃退…” 另一使用者說, “我讓rage master 吃棒棒糖，沒幾次應用就閃退了!”
崩潰日誌如下:

Incident Identifier: 081E58F5-95A8-404D-947B-5E104B6BC1B1CrashReporter Key: 5a56599d836c4f867f6eec76afee451bf9ae5f31Hardware Model: iPhone4,1OS Version: iPhone OS 6.0 (10A403)Kernel Version: Darwin Kernel Version 13.0.0: Sun Aug 19 00:28:05 PDT 2012; root:xnu-2107.2.33~4/RELEASE_ARM_S5L8940XDate: 2012-11-03 13:39:59 -0400Time since snapshot: 4353 msFree pages: 968Active pages: 7778Inactive pages: 4005Throttled pages: 92319Purgeable pages: 0Wired pages: 23347Largest process: Rage Masters

Processes Name <UUID> rpages recent_max [reason] (state)  lsd <6a9f5b5f36b23fc78f87b6d8f1f49a9d> 331 331 [vm] (daemon) (idle) afcd <b0aff2e7952e34a9882fec81a8dcdbb2> 141 141 [vm] (daemon) (idle) itunesstored <4e0cd9f873de3435b4119c48b2d6d13d> 1761 1761 [vm] (daemon) (idle)softwareupdatese <2bc4b5ae016431c98d3b34f81027d0ae> 311 311 [vm] (daemon) (idle) Amazon <4600481f07ec3e59a925319b7f67ba14> 2951 2951 [vm] (suspended) accountsd <ac0fce15c1a2350d951efc498d521ac7> 519 519 [vm] (daemon) (idle)coresymbolicatio <edba67001f76313b992056c712153b4b> 126 126 [vm] (daemon) (idle) Skype <504cf2fe60cb3cdea8273e74df09836b> 3187 3187 [vm] (background) MobileMail <bff817c61ce33c85a43ea9a6c98c29f5> 14927 14927 [vm] (continuous) MobileSMS <46778de076363d67aeea207464cfc581> 2134 2134 [vm] (background) MobilePhone <3fca241f2a193d0fb8264218d296ea41> 2689 2689 [vm] (continuous) librariand <c9a9be81aa9632f0a913ce79b911f27e> 317 317 [vm] (daemon) kbd <3e7136ddcefc3d77a01499db593466cd> 616 616 [vm] (daemon) tccd <eb5ddcf533663f8d987d67cae6a4c4ea> 224 224 [vm] (daemon) Rage Masters <90b45d6281e934209c5b06cf7dc4d492> 28591 28591 [vm] (frontmost) (resume) ptpd <04a56fce67053c57a7979aeea8e5a7ea> 879 879 (daemon) iaptransportd <f784f30dc09d32078d87b450e8113ef6> 230 230 (daemon) locationd <892cd1c9ffa43c99a82dba197be5f09e> 1641 1641 (daemon) syslogd <cbef142fa0a839f0885afb693fb169c3> 237 237 (daemon) mediaserverd <80657170daca32c9b8f3a6b1faac43a2> 4869 4869 (daemon) dataaccessd <2a3f6a518f3f3646bf35eddd36f25005> 1786 1786 (daemon) aosnotifyd <d4d14f2914c3343796e447cfef3e6542> 549 549 (daemon) wifid <9472b090746237998cdbb9b34f090d0c> 455 455 (daemon) SpringBoard <27372aae101f3bbc87804edc10314af3> 18749 18749 backboardd <5037235f295b33eda98eb5c72c098858> 5801 5801 (daemon) UserEventAgent <6edfd8d8dba23187b05772dcdfc94f90> 601 601 (daemon) mediaremoted <4ff39c50c684302492e396ace813cb25> 293 293 (daemon) pasteboardd <8a4279b78e4a321f84a076a711dc1c51> 176 176 (daemon)springboardservi <ff6f64b3a21a39c9a1793321eefa5304> 0 0 (daemon) syslog_relay <45e9844605d737a08368b5215bb54426> 0 0 (daemon) DTMobileIS <23303ca402aa3705870b01a9047854ea> 0 0 (daemon)notification_pro <845b7beebc8538ca9ceef731031983b7> 169 169 (daemon) syslog_relay <45e9844605d737a08368b5215bb54426> 0 0 (daemon) ubd <74dc476d1785300e9fcda555fcb8d774> 976 976 (daemon) twitterd <4b4946378a9c397d8250965d17055b8e> 730 730 (daemon) configd <4245d73a9e96360399452cf6b8671844> 809 809 (daemon) absinthed.N94 <7f4164c844fa340caa940b863c901aa9> 99 99 (daemon)filecoordination <fbab576f37a63b56a1039153fc1aa7d8> 226 226 (daemon) distnoted <a89af76ec8633ac2bbe99bc2b7964bb0> 137 137 (daemon) apsd <94d8051dd5f5362f82d775bc279ae608> 373 373 (daemon) networkd <0032f46009f53a6c80973fe153d1a588> 219 219 (daemon) aggregated <8c3c991dc4153bc38aee1e841864d088> 112 112 (daemon) BTServer <c92fbd7488e63be99ec9dbd05824f5e5> 522 522 (daemon) fairplayd.N94 <7bd896bd00783a48906090d05cf1c86a> 210 210 (daemon) fseventsd <996cc4ca03793184aea8d781b55bce08> 384 384 (daemon) imagent <1e68080947be352590ce96b7a1d07b2f> 586 586 (daemon) mDNSResponder <3e557693f3073697a58da6d27a827d97> 295 295 (daemon) lockdownd <ba1358c7a8003f1b91af7d5f58dd5bbe> 389 389 (daemon) powerd <2d2ffed5e69638aeba1b92ef124ed861> 174 174 (daemon) CommCenter <1f425e1e897d32e8864fdd8eeaa803a8> 2212 2212 (daemon) notifyd <51c0e03da8a93ac8a595442fcaac531f> 211 211 (daemon) ReportCrash <8c32f231b2ed360bb151b2563bcaa363> 337 337 (daemon)

這日誌跟我們前面見到的相差很多。

這個一個來自iOS 6的低記憶體崩潰日誌。正如我們前面所說的，低記憶體崩潰日誌與其他類型的崩潰日誌很不一樣，它們不指向特定的檔案和程式碼。相反，它們畫出了閃退時裝置上的記憶體使用量情況的圖表。

至少，頭部還是跟其他崩潰日誌很像的:  提供了 Incident Identifier, CrashReporter Key, Hardware Model, OS Version等資訊。

接下來部分是低記憶體崩潰日誌特有的:

• Free pages 指可用記憶體頁數。每頁大小約是4KB, 上面的日誌中，可用記憶體約為3,872 KB (或者說 3.9 MB)。
• Purgeable pages 是那部分可被清除或重用的記憶體。在上面的日誌中，是0KB。
• Largest process是閃退時使用大部分記憶體的應用程式名稱，在上面的日誌中，正是你的應用!
• Processes顯示了閃退時各進程列表，還包含記憶體使用量量。包含進程名 (第一列), 進程唯一識別碼(第二名), 進程使用的記憶體頁數(第三列)。最後一列是每個應用的狀態。通常，發生閃退的應用的狀態是 frontmost。 這裡是 Rage Masters, 使用28591 頁 (or 114.364 MB) 記憶體——這記憶體太多了!

通過，最大進程和frontmost狀態的應用是相同的， 而且也是引起低記憶體閃退的應用進程。但是也可能看到最大進程和 frontmost狀態應用不同的例子。比如，如果最大進程是SpringBoard, 忽略它 , 因為 SpringBoard 進程是顯示主畫面的應用，出現在你雙擊home按鈕等情況，而且它是一直活動的。
低記憶體發生時，iOS向活動的應用發出低記憶體警告並終止後台應用。如果前台應用仍然繼續增長記憶體，iOS將終止它。
為了尋找低記憶體問題的原因，你必需使用Instruments剖析應用。如果你不知道怎麼做，可以看一下我們 一篇關於這個方面的教程.。 :] 另外, 你也可以走捷徑，響應低記憶體警告通知，以解決部分閃退問題。
回到Xcode查看RMLollipopLicker.m檔案。 這是實現吃棒棒糖的視圖控制器。看看原始碼:

#import "RMLollipopLicker.h" #define COUNT 20 @interface RMLollipopLicker ()@property (weak, nonatomic) IBOutlet UIProgressView *progressView;@property (weak, nonatomic) IBOutlet UILabel *label;@property (weak, nonatomic) IBOutlet UILabel *lickedTimeLabel;@end @implementation RMLollipopLicker {NSOperationQueue *queue;NSMutableArray *lollipops;} #pragma mark - Life cycle - (void)viewDidLoad {[super viewDidLoad]; self.progressView.progress = 0.0;self.label.text = [NSString stringWithFormat:@"Tap on run and I‘ll lick a lollipop %d times!", COUNT];self.lickedTimeLabel.text = @""; lollipops = [[NSMutableArray alloc] init];queue = [[NSOperationQueue alloc] init];} - (void)lickLollipop {NSURL *fileURL = [[NSBundle mainBundle] URLForResource:@"Lollipop" withExtension:@"plist"];NSDictionary *dictionary = [NSDictionary dictionaryWithContentsOfURL:fileURL];NSString *lollipop = [dictionary objectForKey:@"Lollipop"];[lollipops addObject:lollipop];} #pragma mark - IBActions - (IBAction)doneButtonPressed:(id)sender { [self dismissViewControllerAnimated:YES completion:nil];} - (IBAction)runButtonPressed:(id)sender { [sender setEnabled:NO];[queue addOperationWithBlock:^{ for (NSInteger i = 0 ; i = COUNT) {self.label.text = [NSString stringWithFormat:@"Tap on run and I‘ll lick a lollipop %d times!", COUNT];self.progressView.progress = 0.0;[sender setEnabled:YES];}}];}}]; } @end

當使用者點擊運行按鈕, 應用開始一個背景線程，調用 lickLollipop 方法若干次，然後更新介面反映吃棒棒糖的數量。 lickLollipop 方法從屬性列表檔案(PLIST）檔案讀取一個長字串，然後添加到數組上。這些資料並不重要, 能在不影響使用者體驗的前提下重新建立。
利用每種能夠清除和重建資料而不影響使用者體驗的情況是好習慣。這樣能夠方便地釋放記憶體，減少低記憶體警告。
那麼，如何提高代碼品質呢? 實現 didReceiveMemoryWarning 方法，像下面這樣處理資料:

-(void)didReceiveMemoryWarning {[lollipops removeAllObjects];[super didReceiveMemoryWarning];}

搞定!

當使用者點擊運行按鈕, 應用開始一個背景線程，調用 lickLollipop 方法若干次，然後更新介面反映吃棒棒糖的數量。 lickLollipop 方法從屬性列表檔案(PLIST）檔案讀取一個長字串，然後添加到數組上。這些資料並不重要, 能在不影響使用者體驗的前提下重新建立。
利用每種能夠清除和重建資料而不影響使用者體驗的情況是好習慣。這樣能夠方便地釋放記憶體，減少低記憶體警告。
那麼，如何提高代碼品質呢? 實現 didReceiveMemoryWarning 方法，像下面這樣處理資料:

-(void)didReceiveMemoryWarning {[lollipops removeAllObjects];[super didReceiveMemoryWarning];}

搞定!

當使用者點擊運行按鈕, 應用開始一個背景線程，調用 lickLollipop 方法若干次，然後更新介面反映吃棒棒糖的數量。 lickLollipop 方法從屬性列表檔案(PLIST）檔案讀取一個長字串，然後添加到數組上。這些資料並不重要, 能在不影響使用者體驗的前提下重新建立。
利用每種能夠清除和重建資料而不影響使用者體驗的情況是好習慣。這樣能夠方便地釋放記憶體，減少低記憶體警告。
那麼，如何提高代碼品質呢? 實現 didRceiveMemoryWarning 方法，像下面這樣處理資料:

-(void)didReceiveMemoryWarning {[lollipops removeAllObjects];[super didReceiveMemoryWarning];}

搞定!

iOS開發--應用崩潰日誌揭秘（二）