1、UITabBarItem里設(shè)置的文字不顯示
PersonViewController *vc3=[[PersonViewController alloc] init];
vc3.tabBarItem.title=@"我的";
vc3.tabBarItem.image=[[UIImage imageNamed:@"tabBar2n"] imageWithRenderingMode:UIImageRenderingModeAlwaysOriginal];
vc3.tabBarItem.selectedImage=[[UIImage imageNamed:@"tabBar2l"] imageWithRenderingMode:UIImageRenderingModeAlwaysOriginal];
UINavigationController *nav3=[[UINavigationController alloc] initWithRootViewController:vc3];
這樣設(shè)置不顯示。
IndexViewController *vc1=[[IndexViewController alloc] init];
UINavigationController *nav1=[[UINavigationController alloc] initWithRootViewController:vc1];
UITabBarItem *tabBar = [[UITabBarItem alloc]initWithTitle:@"首頁(yè)" image:[UIImage imageNamed:@"tabBar0n"] selectedImage:[UIImage imageNamed:@"tabBar0l"]];
nav1.tabBarItem = tabBar;
這樣設(shè)置就可以顯示了。
2、解決Collection <__NSArrayM: 0xb550c30> was mutated while being enumerated.-
ViewTest[2638:c07] *** Terminating app due to uncaught exception 'NSGenericException', reason: '
Collection <__NSArrayM: 0xb550c30> was mutated while being enumerated.'
當(dāng)程序出現(xiàn)這個(gè)提示的時(shí)候，是因?yàn)槟阋贿叡憷麛?shù)組，又同時(shí)修改這個(gè)數(shù)組里面的內(nèi)容，導(dǎo)致崩潰，最后發(fā)現(xiàn)確實(shí)是這樣的原因，不過(guò)問(wèn)題是，很多時(shí)候這樣的寫(xiě)法并不會(huì)造成崩潰，可見(jiàn)這樣的Bug是偶現(xiàn)的。
for (NSURLSessionTask *sub in self.requestArray) {
[sub cancel];
[self.requestArray removeObject:sub];
}
把for- in 循環(huán)修改為 for 循環(huán)即可。
3.正常的網(wǎng)路請(qǐng)求突然出錯(cuò)
- (void)cancelAllRunningRequest
{
for (int i = 0; i<self.requestArray.count; i++) {
NSURLSessionTask *sub = self.requestArray[i];
[sub cancel];
[self.requestArray removeObject:sub];
}
}
那是因?yàn)槲以诟割愔械?viewWillDisappear 中調(diào)用了上述方法，
忽略了 VC的生命周期造成的問(wèn)題，
因?yàn)樵?V2的 ViewDidLoad中發(fā)起的網(wǎng)路請(qǐng)求會(huì)在 V1 的viewWillDisappear中被取消，所以就會(huì)出現(xiàn)上面的Bug。
正確的方法是在 父類中的viewDidDisappear 調(diào)用上述的方法即可。
4.Auto property synthesis will not synthesize property 'title'; it will be implemented by its superclass, use @dynamic to acknowledge intention 警告！
這個(gè)問(wèn)題是因?yàn)椋割惡妥宇愑幸粋€(gè)相同名稱的屬性。
編譯器自動(dòng)給屬性delegate合成getter和setter的時(shí)候?qū)?huì)在它的父類上實(shí)現(xiàn),也就是說(shuō)其父類也有一個(gè)delegate屬性,現(xiàn)在它不知道到底是哪一個(gè)delegate.
所以遇到這個(gè)問(wèn)題怎么解決？在子類中顯式的聲明一個(gè)@synthesize name = _name;就好，這樣子類就會(huì)如愿的產(chǎn)生他的殼，編譯器也不糾結(jié)了。
5.一個(gè)匪夷所思的Bug
兩個(gè)工程中同樣的代碼，一個(gè)可以執(zhí)行Post請(qǐng)求，一個(gè)不可以，我一直以為是 網(wǎng)路請(qǐng)求設(shè)置出了問(wèn)題，因?yàn)橐恢眻?bào)的是網(wǎng)路請(qǐng)求錯(cuò)誤，貌似跟服務(wù)器無(wú)關(guān)。
URL :/baseinfos/dealResultForAppWarnCheckedBillDetail.gx?
data={"sysuserid":"10000950","fopinion":"Okkkk","fresult":"2","fwarnType":"IvFoodSalemas","fid":"43767","fwarnId":"303381"}
(lldb) po dic
{
msg = "\U5904\U7406\U6210\U529f";
status = 1;
}
URL :/baseinfos/dealResultForAppWarnCheckedBillDetail.gx?
參數(shù)：{"sysuserid":"20180111134320122911","fopinion":"ok","fresult":"2","fwarnType":"IvFoodSalemas","fid":"43767","fwarnId":"303381"}
糾結(jié)了很久，最后實(shí)在沒(méi)辦法了，就打印了兩個(gè)請(qǐng)求中的參數(shù)，發(fā)現(xiàn)只有 sysuserid 這個(gè)參數(shù)不一樣，貌似還是長(zhǎng)度不一樣造成的，難道因?yàn)閰?shù)的原因可以造成這樣的網(wǎng)絡(luò)請(qǐng)求錯(cuò)誤？？最后試了一下，還真是參數(shù)的問(wèn)題，把參數(shù)換成短的那個(gè)，就請(qǐng)求成功了，漲姿勢(shì)了。
6.多層級(jí)文件夾拖進(jìn)Xcode 工程中出錯(cuò)
這里說(shuō)下兩種錯(cuò)誤的操作：
（1）直接把多層級(jí)的文件拖到工程中
（2）add file 到工程中時(shí)選擇的文件夾不在工程中（比如在桌面）
【1】這里上面兩個(gè)操作的最終效果都是只是引用了文件夾中的文件，當(dāng)文件所在處的文件被刪除時(shí)，新工程中的對(duì)應(yīng)文件就會(huì)變成紅色，
【2】或者在新工程中修改文件，修改的相當(dāng)于原工程中的文件，原工程中的文件自然會(huì)被修改了。
正確的操作是：先把需要添加的文件夾拷貝并移動(dòng)到新工程文件夾中，然后右鍵 add file 到工程即可實(shí)現(xiàn)多層級(jí)文件夾的添加，而且不會(huì)出錯(cuò)。
7.Thread 1: EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
Class class = NSClassFromString(viewClassArray[i]);
baseItem[i] = [[class alloc]init];
[baseItem[i] setItemTitle:titleA[i]];
[self addSubview:baseItem[i]];
EXC_BAD_ACCESS 這個(gè)錯(cuò)誤，可以這么說(shuō)，90%的錯(cuò)誤來(lái)源在于對(duì)一個(gè)已經(jīng)釋放的對(duì)象進(jìn)行release操作(code=1,是已經(jīng)釋放的對(duì)象又進(jìn)行釋放；code=2，是對(duì)已經(jīng)釋放完的，即計(jì)數(shù)為零的對(duì)象又進(jìn)行使用——個(gè)人理解)。
開(kāi)啟僵尸模式，這個(gè)模式比較耗性能，一般Degub的時(shí)候可以使用，打包發(fā)布的時(shí)候注意取消這個(gè)模式。
最后發(fā)現(xiàn) baseItem[i] 在事先聲明中不多，比 viewClassArray 的個(gè)數(shù)少了很多，最后造成了這個(gè)內(nèi)存錯(cuò)誤。
8. &&的條件語(yǔ)句判斷中出錯(cuò)
if (baseItem[i].isMust&&(NilStr([baseItem[i] itemText]) ||[baseItem[i].itemText isEqualToString:@"-請(qǐng)選擇-"])) {
return YES;
}
這個(gè)條件判斷中有時(shí)候會(huì)出現(xiàn)前面成立后面不成立，但是整個(gè)判斷是成立的錯(cuò)誤狀態(tài)，這個(gè)出錯(cuò)是偶然的，不知道什么原因，反正 && 兩邊都用 （）包裹住，這樣更不容易出錯(cuò)。
9.一個(gè)UITbaleViewCell中下拉框的初始化失敗的Bug
場(chǎng)景：下拉框是在cell中初始化的，下拉框的初始化方法在 VC中，而且下拉框的初始化事件是利用 UIResponder 傳遞的。
問(wèn)題：第一個(gè)cell初始化的時(shí)候，里面的下拉框的初始化失敗，因?yàn)閂C中的對(duì)應(yīng)的初始化事件并沒(méi)有被調(diào)用，后續(xù)添加cell時(shí)，cell中的下拉框還是初始化失敗，但是滾動(dòng)UITbaleView 、或者 reLoad UITbaleView時(shí)卻可以正常的觸發(fā)，猜想是UITbaleView 初始化時(shí)，或者insertRowsAtIndexPaths 添加的cell在 cellForRowAtIndexPath 后才加載在UITbaleView上，所以在cellForRowAtIndexPath 的 setModel初始化時(shí)UIResponder是找不到其父視圖的。
解決辦法：把VC中的下拉框初始化方法移到 Cell中，這樣就不會(huì)出現(xiàn)上述的問(wèn)題了。而且移到cell中后詳情和新增頁(yè)面中都不用管理下拉框初始化方法了，更合理。
10.一個(gè) OS_dispatch_data 有關(guān)的網(wǎng)路請(qǐng)求
【1】首先這個(gè)網(wǎng)絡(luò)請(qǐng)求（http://XXXXXXXX:80XX/WebServiceServlet?method=getAllResourceDetailByOrg&orgCode=7654）只支持GET請(qǐng)求，POST請(qǐng)求沒(méi)有數(shù)據(jù)返回也是奇葩。
【2】OS_dispatch_data 不能用 JSON直接解析，是無(wú)法直接使用的。
【3】需要把 OS_dispatch_data 轉(zhuǎn)為 字符串，字符串去掉首尾非JSON的字符后，剩余的部分就可以使用 JSONKit 進(jìn)行解析了。
//OS_dispatch_data
NSString *str = [[NSString alloc]initWithData:data encoding:NSUTF8StringEncoding];
if (str.length<6)return ;
NSString *str1 = [str substringWithRange:NSMakeRange(5, str.length-6)];
NSArray *ss = [str1 objectFromJSONString];
ss 即為可以使用的數(shù)組數(shù)據(jù)了。
