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:@"首頁" 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í)是這樣的原因蒜哀，不過問題是，很多時(shí)候這樣的寫法并不會(huì)造成崩潰吏砂，可見這樣的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的生命周期造成的問題淀歇，
因?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è)問題是因?yàn)楸叮割惡妥宇愑幸粋€(gè)相同名稱的屬性。
編譯器自動(dòng)給屬性delegate合成getter和setter的時(shí)候?qū)?huì)在它的父類上實(shí)現(xiàn),也就是說其父類也有一個(gè)delegate屬性,現(xiàn)在它不知道到底是哪一個(gè)delegate.
所以遇到這個(gè)問題怎么解決井氢？在子類中顯式的聲明一個(gè)@synthesize name = _name;就好弦追，這樣子類就會(huì)如愿的產(chǎn)生他的殼，編譯器也不糾結(jié)了花竞。
5.一個(gè)匪夷所思的Bug
兩個(gè)工程中同樣的代碼劲件，一個(gè)可以執(zhí)行Post請(qǐng)求掸哑，一個(gè)不可以，我一直以為是 網(wǎng)路請(qǐng)求設(shè)置出了問題零远，因?yàn)橐恢眻?bào)的是網(wǎng)路請(qǐng)求錯(cuò)誤苗分，貌似跟服務(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í)在沒辦法了摔癣，就打印了兩個(gè)請(qǐng)求中的參數(shù)，發(fā)現(xiàn)只有 sysuserid 這個(gè)參數(shù)不一樣纬向，貌似還是長(zhǎng)度不一樣造成的择浊，難道因?yàn)閰?shù)的原因可以造成這樣的網(wǎng)絡(luò)請(qǐng)求錯(cuò)誤？逾条？最后試了一下琢岩，還真是參數(shù)的問題，把參數(shù)換成短的那個(gè)师脂，就請(qǐng)求成功了担孔，漲姿勢(shì)了。
6.多層級(jí)文件夾拖進(jìn)Xcode 工程中出錯(cuò)
這里說下兩種錯(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ò)誤完疫，可以這么說泰鸡，90%的錯(cuò)誤來源在于對(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è)人理解)。
開啟僵尸模式芳誓，這個(gè)模式比較耗性能余舶，一般Degub的時(shí)候可以使用，打包發(fā)布的時(shí)候注意取消這個(gè)模式锹淌。
最后發(fā)現(xiàn) baseItem[i] 在事先聲明中不多匿值，比 viewClassArray 的個(gè)數(shù)少了很多，最后造成了這個(gè)內(nèi)存錯(cuò)誤赂摆。
8. &&的條件語句判斷中出錯(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 傳遞的。
問題：第一個(gè)cell初始化的時(shí)候趟大，里面的下拉框的初始化失敗鹤树，因?yàn)閂C中的對(duì)應(yīng)的初始化事件并沒有被調(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)上述的問題了。而且移到cell中后詳情和新增頁面中都不用管理下拉框初始化方法了涤妒，更合理单雾。
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)求沒有數(shù)據(jù)返回也是奇葩她紫。
【2】OS_dispatch_data 不能用 JSON直接解析硅堆，是無法直接使用的。
【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ù)了民褂。
