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.