preface

There is almost zero tolerance for crashes in mobile apps, so there will be many causes of crashes in iOS, such as the most common array transgression and adding null values.

**YCBStability** is recommended if you want to solve most of the possible crashes and keep your code robust without making too many changes

An improved iOS stability, effectively prevent flash back framework

YCBStability

Making the download

Or you can integrate it through Cocoapods and add it to your Podfile

pod 'YCBStability'
Copy the code

Terminal input command:

pod install
Copy the code

Remember to import the < YCBStability/YCBStability. H >

Without adding any code,

Release: Does not crash Debug: Still crashes for better tracing of problems, but provides more crash information

Common CARSH summaries

Now let’s look at some of the methods that can cause crashes, and of course, as mentioned above, introducing YCBStability will make your code more robust. I implemented method intercepts in the Runtime to avoid carsh

So, you just import YCBStability without adding any code, and your code will be strong enough

Making the address

The principle is introduced

I’ve written a lot about YCBStability solving crash problems, but if you just want to solve problems in your code, that’s all you need to read.

But if you want to know more about crash, let me summarize it and hope it can help you.

The pits in the OC method

The method provided by OB is not robust. The most common one is that setting a nil or array will cause crash if it goes out of bounds. Many friends like to add some judgments, which I think is a good sense, but not the best practice.

For the sake of brevity, I suggest you get rid of the if-else and introduce YCBStability

But if you’ve already used categories to avoid crashes caused by these methods, THEN I suggest you continue with categories

NSArray

methods Crash:
– (ObjectType)objectAtIndex:(NSUInteger)index Causes an array out of bounds when index is greater than array count
– (NSUInteger)indexOfObject:(ObjectType)anObject Carsh when anObject is nil

NSMutableArray

Methods | crash: – | : –

  • (void) addObject (ObjectType) anObject | carsh when anObject as nil
  • (void) insertObject: (ObjectType) anObject atIndex: (NSUInteger) index | when the anObject is nil carsh, when the index > mutArray. Count, crossing the line
  • (void) removeObjectAtIndex: (NSUInteger) index | when the index > mutArray. Count, crossing the line

NSMutableSet

methods Crash that
– (void)addObject:(ObjectType)object Carsh when anObject is nil

NSMutableDictionary

methods Crash that
– (void)setObject:(ObjectType)anObject forKey:(KeyType)aKey When anObject is nil, or key is nil, it causes a crash

The pit of the generic type

In NSDictionary, we use this method a lot

- (nullable ObjectType)objectForKey:(KeyType)aKey;
Copy the code

This return value type can easily produce a pit, for example:

The project API document server returns the following data

 {
   list :(
      'a'.'b')}Copy the code

At this point, you pass

NSArray *array = [dic objectForKey:@"list"];
NSString *str = [array firstObject];
Copy the code

Normally, there is no problem, but you should know that the server data is not trusted, and one day there is a bug in the server code, the list is not an array, and the APP will Crash

{
    list: {}
 }
Copy the code

[dic objectForKey:@”list”]; It returns Dic, and you still think it’s NSArray, and you call firstObject, and there’s no firstObject in Dic, and your APP crashes

Faced with the trust problem of the server returning data, some students have formed the good habit of adding if-else, but I want you to introduce YCBStability, using the following method:

@interface NSDictionary (YCBStability) /** get the string corresponding to key */ - (NSString *)getStringForKey:(id)key; - (NSArray *)getArrayForKey:(id)key; */ - (NSDictionary *)getDictinaryForKey (id)key; - (int)getIntForKey:(id)key; - (float)getFloatForKey:(id)key;

- (BOOL)getBoolForKey:(id)key;

@end

Copy the code

Choose different methods depending on the type you want,

Debug mode: If it does not match the expected type, crash will occur, which is convenient for tracing problems. Release mode: I make fault tolerant processing to avoid crash

Judge not empty

To better support type determination, I provide the following methods to use

@interface YCBNonEmpty: NSObject /** Check whether the array is non-empty */ + (BOOL)isArray:(id)object; */ + (BOOL)isSet:(id)object; /** check whether a non-empty string */ + (BOOL)isString:(id)text; */ (BOOL)isDictionary:(id)object; @endCopy the code

Non-empty judgment is a technique often used in code to ensure robustness of code. In YCBNonEmpty, I judge non-empty based on type and count, which is safer and more accurate.

Welcome everyone to pay attention to me, exchange and learn together!