1. NSAssert() 和 NSCAssert()的使用
NSAssert()用于 OC 語(yǔ)法的斷言
NSCAssert()用于 C語(yǔ)言語(yǔ)法的斷言
2. Swift3.0使用NSNotification.name
let kOpenXcodePathNotification = "kOpenXcodePathNotification"
NotificationCenter.default.post(name: NSNotification.name, object: url)
上面的代碼錯(cuò)誤 需要用NSNotification.name進(jìn)行初始化字符串
let kOpenXcodePathNotification = NSNotification.Name("kOpenXcodePathNotification")
3. 自定義 NSTableView的 Cell
mac開(kāi)發(fā)中使用自定義NSTableCellView
4 . 設(shè)置 NSWindow 不允許用戶改變大小
設(shè)置 ReSize 屬性為 NO
5. Unable to find a pod with name, author, summary, or description matching
刪除緩存：rm ~/Library/Caches/CocoaPods/search_index.json
6.一個(gè)判斷的小坑
if ([PQAccountManager shareManager].isSignIn) {
// Do One
} else {
// Do Other
}
if (![PQAccountManager sharedManager].isSignIn) {
// Do Other
return;
}
// Do One
按我們平常的理解上述兩個(gè)判斷是一樣的生棍，但是這次我卻發(fā)現(xiàn)了有問(wèn)題，他們執(zhí)行的不一樣.
PS: 這塊的打印是沒(méi)有問(wèn)題的，正常操作后，都是在 0 和 1 切換的
NSLog(@"SignIn === %d,",[PQAccountManager sharedManager].isSignIn);
因此覺(jué)的很奇怪凉驻，為什么是這樣呢？改好了但是卻一下子真不懂啊好唯，于是我自己寫(xiě)了一個(gè) demo 測(cè)試鞋诗，發(fā)現(xiàn)在那塊類似的判斷是一樣的，所以其中的判斷是肯定沒(méi)問(wèn)題的撕捍，還是我們項(xiàng)目中有問(wèn)題的拿穴。
后來(lái)才發(fā)現(xiàn)原來(lái)是我們項(xiàng)目中有一個(gè)：
#import <Foundation/Foundation.h>
/*!
* 生成單例對(duì)象的分類
*/
@interface NSObject (Manager)
/*!
* 生成單例對(duì)象
* @return 基于 NSObject類的單例對(duì)象
*/
+ (instancetype)shareManager;
@end
然后之前管理類中 單例確是： sharedManager，差了一個(gè)字母的忧风，所以這種坑默色，一定要注意細(xì)節(jié)：
- 注意細(xì)節(jié)，字母阀蒂，單詞的準(zhǔn)確性
- 注意私有公用方法添加類似
作為區(qū)別该窗，同時(shí)也提醒了自己，一些 hook 類的方法蚤霞，能不用就盡量不用酗失，哈哈哈。- (void)pq_ sharedManager;
7 再次想私有成員變量
今天突然想起昧绣，為什么有屬性的時(shí)候规肴，為什么還要再直接用成員變量呢？它有什么方便之處呢夜畴？ 首先明確的是 ** 類內(nèi)使用成員變量{}, 類外使用屬性@property,** 所以拖刃，此處我說(shuō)的基本是 .m 文件中使用的成員變量。
@implementation ViewController {
NSString *_testName;
NSString *tempStr;
BOOL isStop;
}
為什么用它呢贪绘？
- 執(zhí)行速度更快兑牡，IPA體積更小 ( 從 iOS 開(kāi)發(fā)中的爭(zhēng)議（一）得知）
感覺(jué)個(gè)人平常很少用成員變量，當(dāng)然除了在 init 和 dealloc 税灌、getter均函、setter中 除外咯，其他地方例如臨時(shí)生成一個(gè)tempStr 或者臨時(shí)的判斷值 isStop, 此時(shí)是否需要用它呢菱涤？
想了想苞也，為了代碼的看起來(lái)的規(guī)范性，我是不愿這樣寫(xiě)的粘秆。
但是細(xì)細(xì)想來(lái)如迟，一些臨時(shí)的值確實(shí)沒(méi)必要經(jīng)過(guò) setter 和 getter 方法，所以想著還是直接用 成員變量的。
PS： 在 Block 中對(duì)于成員變量一定要 使用 self-> _testName, 否則直接使用 _testName, 就算添加了 weakSelf/strongSelf 還是會(huì)有循環(huán)引用的殷勘。
8 this class is not key value coding-compliant for the key 錯(cuò)誤
對(duì)于這種 Bug 此再，最常見(jiàn)的是我們用 stroyboard 時(shí)，某個(gè)設(shè)置IBAction和IBOutlet時(shí)有多余或錯(cuò)誤的連線劳吠。但是我此處不是的哦引润，而且這個(gè)問(wèn)題在 stackoverflow 處 已經(jīng)討論很多了，而我此處的場(chǎng)景是使用 謂詞 時(shí)遇到的痒玩。
NSPredicate *tempPredicate = [NSPredicate predicateWithFormat:@"cateId == %d", key];
NSArray *filteredTempArray = [array filteredArrayUsingPredicate:tempPredicate];
其實(shí)也是很簡(jiǎn)單淳附，就是一個(gè)字母寫(xiě)錯(cuò)了，相當(dāng)于 key 值換了蠢古， 改成正確的值就好了奴曙。
（cateId === 》 catId （catId 才是之前設(shè)置的））。
9 用了 UIImageRenderingModeAlwaysOriginal , 圖片顏色倒是變化啦
這個(gè)問(wèn)題是草讶，我們項(xiàng)目中最近在 改變 UITabBarItem 的圖片時(shí) 使用了獲取網(wǎng)絡(luò)圖片洽糟，然后對(duì)于 selectedImage 必然的做 UIImageRenderingModeAlwaysOriginal 處理，結(jié)果卻發(fā)現(xiàn)那個(gè) 顏色變了堕战。坤溃。
先再次熟悉下： UIImageRenderingModeAlwaysOriginal 這個(gè)屬性值。
typedef NS_ENUM(NSInteger, UIImageRenderingMode) {
UIImageRenderingModeAutomatic, // Use the default rendering mode for the context where the image is used
//根據(jù)圖片的使用環(huán)境和所處的繪圖上下文自動(dòng)調(diào)整渲染模式
UIImageRenderingModeAlwaysOriginal, // Always draw the original image, without treating it as a template
// 繪制圖片原始狀態(tài)嘱丢，不使用Tint Color
UIImageRenderingModeAlwaysTemplate, // Always draw the image as a template image, ignoring its color information
// 根據(jù)Tint Color繪制圖片薪介，忽略圖片的顏色信息
} NS_ENUM_AVAILABLE_IOS(7_0);
![]()
網(wǎng)上超經(jīng)典的圖
UIImage *selectImage = [
[[YYWebImageManager sharedManager].cache getImageForKey:@"https://example.com/test.png"]
imageWithRenderingMode:UIImageRenderingModeAutomatic
];
tabBarItem.selectedImage = selectImage;
UIImage *selectImage = [
[[YYWebImageManager sharedManager].cache getImageForKey:@"https://example.com/test.png"]
imageWithRenderingMode:UIImageRenderingModeAlwaysOriginal
];
tabBarItem.selectedImage = selectImage;
后來(lái)發(fā)現(xiàn)其實(shí)我沒(méi)錯(cuò)，只是恰好后臺(tái)配置的是藍(lán)色：
這個(gè)錯(cuò)很湊巧越驻，因?yàn)?剛好后臺(tái) 返回的圖片也是藍(lán)色 和 灰色汁政，然后就陰差陽(yáng)錯(cuò)的錯(cuò)了，畢竟看起來(lái)是正常的缀旁。畢竟 UITabBarItem 默認(rèn)選中的顏色是 藍(lán)色 和灰色的
