iOS development-app crash log disclosure (ii)

Scenario 4: When you eat a lollipop, you are back!

User email says, "When rage Master eats lollipops, the app will flash back ..." Another user said, "I let rage master eat Lollipop, and not a few times the app just flashed back!"
The crash log is as follows:

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 00:28:05 PDT; root:xnu-2107.2.33~4/release_arm_s5l8940xdate:< c5/>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&amp ; gt; 331 331 [VM] (daemon) (idle) AFCD <b0aff2e7952e34a9882fec81a8dcdbb2> 141 141 [VM] (daemon) (idle) itunesstored <4e0cd9f873de3435b4119c48b2d6d1 3d> 1761 1761 [VM] (daemon) (idle) Softwareupdatese <2bc4b5ae016431c98d3b34f81027d0ae&gt ; 311 311 [VM] (daemon) (idle) Amazon <4600481f07ec3e59a925319b7f67ba14> 2951 2951 [VM] (suspended) ACCOUNTSD <AC0FCE15C1A2350D951EFC498D521AC7&A MP;GT; 519 519 [VM] (daemon) (idle) Coresymbolicatio <edba67001f76313b992056c712153b4b> 126 126 [VM] (daemon) (idle) Skype <504cf2fe60cb3cdea8273e74df09836b&am P;GT; 3187 3187 [VM] (background) Mobilemail <bff817c61ce33c85a43ea9a6c98c29f5> 14927 14927 [VM] (continuous) mobilesms <46778DE076363D67AEEA207464CFC581&A MP;GT; 2134 2134 [VM] (background) Mobilephone <3fca241f2a193d0fb8264218d296ea41> 2689 2689 [VM] (continuous) Librariand <C9A9BE81AA9632F0A913CE79B911F27E&A MP;GT; 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& AMP;GT; 879 879 (daemon) IAPTRANSPORTD <f784f30dc09d32078d87b450e8113ef6> (daemon) Locationd <892cd1c9ffa43c99a82dba197be5f09e> 1641 1641 (daemon) syslogd <cbef142fa0a839f0885afb693fb169c3&gt ; 237 237 (daemon) Mediaserverd <80657170daca32c9b8f3a6b1faac43a2> 4869 4869 (daemon) DATAACCESSD <2a3f6a518f3f3646bf35eddd36f25005> 1786 1786 (daemon) aosnotifyd <d4d14f2914c3343796e447cfef3e6542&gt ; 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&g T 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&g T 730 730 (daemon) CONFIGD <4245d73a9e96360399452cf6b8671844> 809 809 (daemon) absinthed. N94 <7f4164c844fa340caa940b863c901aa9> (daemon) Filecoordination <fbab576f37a63b56a1039153fc1aa7d8> 226 226 (daemon) distnoted <a89af76ec8633ac2bbe99bc2b7964bb0> 137 137 (daemon) apsd <94d8051dd5f5362f82d775bc279ae608> 373 373 (daemon) networkd <0032f46009f53a6c80973fe153d1a588> 219 219 (daemon) aggregated <8c3c991dc4153bc38aee1e841864d088&gt ; Btserver <c92fbd7488e63be99ec9dbd05824f5e5> (daemon) 522 522 (daemon) Fairplayd. N94 <7bd896bd00783a48906090d05cf1c86a> FSEVENTSD <996cc4ca03793184aea8d781b55bce08> (daemon) 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&gt ; 2212 2212 (daemon) notifyd <51c0e03da8a93ac8a595442fcaac531f> 211 211 (daemon) Reportcrash <8c32f231b2ed360bb151b2563bcaa363> 337 337 (daemon)

This log is quite different from what we saw earlier.

This is a low memory crash log from iOS 6. As we said earlier, low memory crash logs are very different from other types of crash logs, and they do not point to specific files and lines of code. Instead, they draw a graph of the memory usage on the device during the flash-back.

At the very least, the head is similar to other crash logs: it provides Incident Identifier, Crashreporter Key, Hardware Model, OS version, and more.

The next section is specific to the low memory crash log:

• Free pages refers to the number of available memory pages. The size of each page is approximately 4KB, the above log, the available memory is approximately 3,872 KB (or 3.9 MB).
• Purgeable pages is the portion of memory that can be purged or reused. In the above log, it is 0KB.
• Largest process is the name of the app that uses most of the memory when it's rolled back, and it's your app in the log above!
• Processes shows the list of processes at the time of the flashback and also contains memory usage. Contains the process name (first column), the process unique identifier (second name), the number of memory pages used by the process (third column). The last column is the status of each app. Typically, the state of the app that has a flashback is frontmost. Here is Rage Masters, using 28591 pages (or 114.364 MB) of memory--Too much memory!

The

Passes, the application of the maximum process and the frontmost state is the same, and it is the application process that causes the low memory flash back. However, it is also possible to see the maximum process and frontmost states applying different examples. For example, if the maximum process is springboard, ignore it, because the springboard process is the app that displays the home screen, appears when you double-click the Home button, and so on, and it's always active.
When low memory occurs, iOS emits a low memory warning to the active app and terminates the background app. If the foreground app continues to grow memory, iOS will terminate it.
to find the cause of a low memory problem, you must use instruments to profile your app. If you don't know what to do, take a look at one of our tutorials on this. :] In addition, you can take shortcuts to respond to low memory warning notifications to resolve partial flashback issues.
go back to Xcode to view the rmlollipoplicker.m file. This is the realization of eating lollipop view controller. Look at the source code:

#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

When the user clicks the Run button, the app starts a background thread, calls the Licklollipop method several times, and then updates the interface to reflect the number of lollipops eaten. The Licklollipop method reads a long string from the property list file (PLIST) file and then adds it to the array. This data is not important and can be recreated without compromising the user experience.
It's good practice to use every situation that clears and rebuilds data without impacting the user experience. This makes it easy to free up memory and reduce low memory warnings.
So how do you improve the quality of your code? Implement the Didreceivememorywarning method, which processes the data as follows:

-(void) didreceivememorywarning {[Lollipops removeallobjects];[ Super didreceivememorywarning];}

Get!

When the user clicks the Run button, the app starts a background thread, calls the Licklollipop method several times, and then updates the interface to reflect the number of lollipops eaten. The Licklollipop method reads a long string from the property list file (PLIST) file and then adds it to the array. This data is not important and can be recreated without compromising the user experience.
It's good practice to use every situation that clears and rebuilds data without impacting the user experience. This makes it easy to free up memory and reduce low memory warnings.
So how do you improve the quality of your code? Implement the Didreceivememorywarning method, which processes the data as follows:

-(void) didreceivememorywarning {[Lollipops removeallobjects];[ Super didreceivememorywarning];}

Get!

When the user clicks the Run button, the app starts a background thread, calls the Licklollipop method several times, and then updates the interface to reflect the number of lollipops eaten. The Licklollipop method reads a long string from the property list file (PLIST) file and then adds it to the array. This data is not important and can be recreated without compromising the user experience.
It's good practice to use every situation that clears and rebuilds data without impacting the user experience. This makes it easy to free up memory and reduce low memory warnings.
So how do you improve the quality of your code? Implement the Didrceivememorywarning method, which processes the data as follows:

-(void) didreceivememorywarning {[Lollipops removeallobjects];[ Super didreceivememorywarning];}

Get!

iOS development-app crash log disclosure (ii)