一 在蘋果的api中,NSInteger是個封裝,它會自動識別當(dāng)前操作系統(tǒng)的位數(shù),返回最大數(shù)據(jù)類型,CGFloat在32位數(shù)是float 在64位位double,對于需要兼容的程序而言,需要用到CGFloat ,當(dāng)然從長久考慮盡量使用CGFloat 盡管32位上相比float增加了一些menory footprint的銷毀
二 CFindex;在core Foundation 框架中一般用于數(shù)組的序號和參數(shù)的返回值的大小,位數(shù)隨著機器的位數(shù)增加而增加,和int位數(shù)無關(guān)
三 iOS- "_OBJC_CLASS_$_WKWebView", referenced from:
解決方法: 在對ios8以上系統(tǒng)引進WK框架時候,還需要適配ios7出現(xiàn)的錯誤,若最低版本試ios8,沒有這個錯誤,解決辦法是需要導(dǎo)入webkit框
四 Swift Struct 和 Class相同點和不同點
相同點:
1 定義屬性用于存儲值
2 定義方法用于提供功能
3 定義附屬腳本用于訪問值
4 定義構(gòu)造器用于生成初始值
5 通過擴展以增加默認(rèn)實現(xiàn)的功能
6 通過協(xié)議以對某類提供標(biāo)準(zhǔn)功能
Class附加的功能
1 類允許被繼承
2 類型轉(zhuǎn)換允許在運行時檢查和解釋一個類實例的類型
3 允許一個類實例釋放任何所被分配的資源
4 引用計數(shù)允許對一個類的多次引用
與 Objective-C 語言不同的是夭委，Swift 允許直接設(shè)置結(jié)構(gòu)體屬性的子屬性
在 Swift 中，所有的結(jié)構(gòu)體和枚舉類型都是值類型由驹。這意味著它們的實例赋朦，以及實例中所包含的任何值類型屬性，在代碼中傳遞的時候都會被復(fù)制。
Swift 中摇天，許多基本類型，諸如String恐仑，Array和Dictionary類型均以結(jié)構(gòu)體的形式實現(xiàn)泉坐。這意味著被賦值給新的常量或變量，或者被傳入函數(shù)或方法中時裳仆，它們的值會被拷貝腕让。
Objective-C 中NSString，NSArray和NSDictionary類型均以類的形式實現(xiàn)歧斟，而并非結(jié)構(gòu)體纯丸。它們在被賦值或者被傳入函數(shù)或方法時，不會發(fā)生值拷貝静袖，而是傳遞現(xiàn)有實例的引用觉鼻。
在 Objective-C 中，你只能為 Objective-C 的類類型（classes）定義類型方法（type-level methods）队橙。在 Swift 中滑凉，你可以為所有的類统扳、結(jié)構(gòu)體和枚舉定義類型方法。每一個類型方法都被它所支持的類型顯式包含畅姊。
Swift 中的錯誤處理和其他語言中用try咒钟，catch和throw進行異常處理很像。和其他語言中（包括 Objective-C ）的異常處理不同的是若未，Swift 中的錯誤處理并不涉及解除調(diào)用棧朱嘴，這是一個計算代價高昂的過程。就此而言粗合，throw語句的性能特性是可以和return語句相媲美的萍嬉。
五 Taggend Pointer
在2013年9月,蘋果推出iPhone5s,與此同時,5s搭載采用64位的a7處理器 為了節(jié)省內(nèi)存和執(zhí)行效率,蘋果推出Taggend Pointer概念,對于64位系統(tǒng),引入Tagged Pointer后,相關(guān)邏輯內(nèi)存減少一半內(nèi)存,以及3倍的速度.就是把一個對象拆分成2部分,一部分直接保存數(shù)據(jù),另一部分作為特殊標(biāo)記,表示一個特殊的指針,不指向任何地址 在Taggend Pointer 對象中沒有isa指針,因為它沒有真正對象.
六 Multiple methods named 'count:' found with mismatched result, parameter type or attributes,意思是方法命名沖突，編譯器找不到合適的方法用在這里隙疚，這是在ARC環(huán)境下才會出現(xiàn)的問題壤追，非ARC就沒有這個問題，解決的方法有兩個供屉，1行冰，把程序改成非ARC，但是這樣工作量會很大伶丐，尤其是對一些大的項目來說很難實現(xiàn)悼做，2，在函數(shù)前面強轉(zhuǎn)一下哗魂，告訴編譯器到什么地方調(diào)用合適的方法肛走，比如在這個程序里我的解決辦法就是[(NSMutableArray*)[LetterResultArr objectAtIndex:section] count]，這樣就沒錯了
七 label同時設(shè)置sizeToFit录别，NSTextAlignmentCenter不起作用
入坑好長時間原因詳見:https://stackoverflow.com/questions/28579776/nstextalignmentcenter-for-uilabel-not-working/35066864#35066864?newreg=725179871da349d698d31b72bdbb3565
解決辦法:
sizeTofit方法調(diào)用必須在創(chuàng)建label frame之前,不能調(diào)換位置,alignment屬性同樣也是寫在frame之前,具體寫法詳見如下:
NSMutableAttributedString * attributedString = [[NSMutableAttributedString alloc] initWithString:tcinfo];? ? ? ? NSMutableParagraphStyle * paragraphStyle = [[NSMutableParagraphStyle alloc] init];? ? ? ? paragraphStyle.alignment = NSTextAlignmentCenter;? ? ? ? [paragraphStyle setLineSpacing:4];? ? ? ? [attributedString addAttribute:NSParagraphStyleAttributeName value:paragraphStyle range:NSMakeRange(0, [tcinfo length])];? ? ? ? ? ? ? CGRect cardRect = [tcinfo boundingRectWithSize:CGSizeMake(self.frame.size.width - 10, MAXFLOAT) options: NSStringDrawingUsesLineFragmentOrigin |NSStringDrawingUsesFontLeading attributes:@{NSFontAttributeName:gxAlterconectLable.font} context:nil];? ? ? ? [gxAlterconectLable sizeToFit];? ? ? ? gxAlterconectLable.frame = CGRectMake(5, self.frame.size.height/3.0, self.frame.size.width - 10, cardRect.size.height);? ? ? ? [self addSubview:gxAlterconectLable];? ? ? ? [gxAlterconectLable setAttributedText:attributedString];
八 ?iOS 常見的卡頓:
1 CPU卡頓:
? 原因:App主線程在CPU中顯示內(nèi)容,比如布局計算,圖形解碼,文本繪制等,隨后CPU把計算好的結(jié)果提交給GPU(圖形處理器),由GPU進行交換,合成,渲染,隨后GPU會把渲染結(jié)果提交到幀緩沖區(qū),等待下個垂直同步信號到來時顯示到屏幕上,由于垂直同步機制,在垂直同步機制時間內(nèi),CPU或者GPU沒有完成提交,則那一幀會被丟棄,等待下一次機會顯示,則這個時候顯示屏因為沒有新的刷新,會保留之前的內(nèi)容不變,就會造成卡頓.
優(yōu)化
* 盡量使用輕量級的對象.
* 不要頻繁使用UIView的相關(guān)屬性,如frame,bounds,transform等屬性,測試發(fā)現(xiàn)在UITabView上頻繁的創(chuàng)建視圖,修改視圖的frame等會造成32位系統(tǒng)機器卡頓,64位系統(tǒng)的不怎么明顯,UITabView使用頻繁,各種奇葩的需求,我們是在使用它時往往忽略了UITabView的性能.找工作面試官會問到UITabView的性能優(yōu)化相關(guān)的問題.
* 圖片的size最好和UIimageView的size保持一致,盡量不要做等比例壓縮等操作.
* 盡量把耗時的操作放在子線程中,比如網(wǎng)絡(luò)請求用block輕量級子線程完成,UI在主線程刷新.
2 GPU卡頓優(yōu)化
* 盡量避免在短時間內(nèi)加載大量的圖片,盡可能將多張圖片合成一張圖片顯示
* 盡量減少視圖層級和數(shù)量
* 減少透明的視圖(alpha<1),不透明的設(shè)置opaque為YES
* 盡量避免初選離屏渲染:
在openGL中,GPU渲染有2種渲染方式
(1) On - Screen Rendering :當(dāng)前屏幕渲染
(2) Off - Screen Rendering : 離屏渲染?
離屏渲染消耗的原因:
(1) 需要創(chuàng)建新的緩沖區(qū)
(2) 離屏渲染需要多次切換上下文環(huán)境朽色，先是從當(dāng)前屏幕（On-Screen）切換到離屏（Off-Screen）；等到離屏渲染結(jié)束以后组题，將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上纵搁，又需要將上下文環(huán)境從離屏切換到當(dāng)前屏幕.
那些操作會引起離線渲染?
* 光柵化:layer.shouldRasterize = YES
* 遮罩:layer,mask
*圓角,同時設(shè)置masksToBounds = YES
*陰影:layer.shadow,但是設(shè)置了layer.shadowPath就不會產(chǎn)生離屏渲染
九 WKWebview返回h5首頁
[self.webView goToBackForwardListItem:self.webView.backForwardList.backList.firstObject];
入坑記:
參考安卓的方法:
while (self.webView.canGoBack) { [self.webView goBack]; }
測試發(fā)現(xiàn)while為死循環(huán)
十 特殊閃退問題
malloc: *** error for object 0x7f9776e12150: double free*** set a breakpoint in malloc_error_break to debug?
十一 圖片的解壓縮
將壓縮圖片數(shù)據(jù)解碼成未壓縮圖片的位圖形式,這是個一個非常耗時的cpu操作,而且默認(rèn)是在主線程中進行,在界面滑動中,可能會內(nèi)存會飆升,引起出現(xiàn)閃退,甚至手機機身發(fā)燙的惡劣情況.
十二 UIwebview因PickView的數(shù)組越界崩
? ? ?最近有用戶反饋,h5界面常有有些選擇器(如地市的選擇),當(dāng)h5界面異常的時候,點擊彈出選擇器,滑動PickView會崩潰,發(fā)現(xiàn)這是UIwebview的引起數(shù)組越界的bug,UIwebview內(nèi)部閃退;客戶端沒法捕捉這個異常,待著好奇心,用WK,發(fā)現(xiàn)沒有閃退,更換WK;沒有對比,就沒有傷害,更換WK看樣子已經(jīng)迫在眉睫了
十三 iframe標(biāo)簽在ios失效和界面閃動問題
?詳見博客:https://blog.csdn.net/qq_28292937/article/details/78853921
https://blog.csdn.net/XinZhongYi/article/details/5518860
十四?引述cnBeta的消息，蘋果今天在其WebKit博客上宣布往踢，他們將從2020年3月開始終止對TLS 1.0和1.1的支持腾誉。
?十五 ?window.histroy.back 在iOS上無法后退
參考文章:http://www.it1352.com/550444.html ?https://bbs.csdn.net/topics/392067078?page=1
十六 ?iOS11 app內(nèi)自動連接WiFi?
?ios11 提供了NEHotspotConfigurationManager類直連周邊WiFi
引入:NetworkExtension?
Xcode - Capabilities - Hostpot Configuration 勾選
if (@available(iOS 11.0, *)) { NEHotspotConfiguration * hotspotConfig = [[NEHotspotConfiguration alloc] initWithSSID:@"Deli_L1050ADNW_1B0000"]; // 開始連接 (調(diào)用此方法后系統(tǒng)會自動彈窗確認(rèn)) [[NEHotspotConfigurationManager sharedManager] applyConfiguration:hotspotConfig completionHandler:^(NSError * _Nullable error) { NSLog(@"%@",error); if (error && error.code != 13 && error.code != 7) { }else if(error.code ==7){//error code = 7 ：用戶點擊了彈框取消按鈕 }else{// error code = 13 ：已連接 } }]; } else { // iOS11以下版本邏輯 }
十七
sms://106585185001&body=32018132;2;1:1:1;02,14,15,16,18,21^04
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:nil]]無法打開短信,原因是特殊字符^造成的需要將^編碼即可
十八 ?
檢測ios工程是否有p3照片或者16-bit照片的方法
1 .ipa文件解壓得到Payload文件夾
2 終端cd your.app
3 用find命令定位Assert.car文件:終端輸入:find . -name 'Assets.car'
4 assertutil 命令知道包含16-bit or p3的資源
? sudo xcrun --sdk iphoneos assetutil --info ./Assets.car > /tmp/Assets.json
? 5 打開/tmp/Assets.json open /tmp/Assets.json
