1. 從iOS 9到iOS 19這十年的系統(tǒng)與生態(tài)變化1.1 2015年前后的黃金時(shí)代iOS 9和Swift 1.2的時(shí)代2015年入行iOS開發(fā)趕上的正好是iPhone 6s、iOS 9、Xcode 7那一波。那時(shí)候App Store的審核還沒有現(xiàn)在這么復(fù)雜上架一個(gè)工具類App甚至不需要太嚴(yán)格的隱私說明Apple Watch剛發(fā)布第一代iPad Pro也剛出12.9英寸。那會兒的iOS開發(fā)圈流傳著一句話會點(diǎn)OC、懂點(diǎn)storyboard就能找到一份體面的工作。現(xiàn)在回頭看基本屬實(shí)。當(dāng)時(shí)很多公司對iOS開發(fā)者的要求就是能獨(dú)立交付一個(gè)App技術(shù)棧極其簡單Objective-C、UIKit、Masonry做Auto Layout、AFNetworking做網(wǎng)絡(luò)請求、SDWebImage做圖片加載再加一個(gè)友盟統(tǒng)計(jì)一個(gè)完整的App就出來了。那個(gè)階段的技術(shù)生態(tài)是高度壟斷的Apple官方文檔和WWDC Session幾乎是唯一權(quán)威中文社區(qū)里活躍的博客就是那幾家唐巧、onevcat、王巍的ObjC.io、劉彥瑋的Swift專題還有cocoaChina論壇。我記得很清楚2015年Swift剛發(fā)布一年社區(qū)共識是學(xué)Swift可以但項(xiàng)目必須用OC因?yàn)镾wift 1.x的API不穩(wěn)定、編譯慢、第三方庫兼容性差任何一份公司代碼庫如果全部用Swift寫都相當(dāng)需要勇氣。我自己第一個(gè)正式項(xiàng)目就是純OC寫的電商App里面最好的架構(gòu)是單例天下通知滿天飛但那時(shí)候大家都不覺得有問題。今天看2015年的iOS開發(fā)技術(shù)門檻確實(shí)低但也意味著人人可入行競爭靠的不是深度而是廣度——會點(diǎn)HTML5、會點(diǎn)PHP甚至能加分。這種繁榮背后的隱患是行業(yè)內(nèi)大部分人寫的代碼都停留在能跑就行的水平對內(nèi)存管理MRC時(shí)代遺留的坑、RunLoop機(jī)制、多線程底層、編譯原理這些真正劃分水平的東西普遍缺乏理解。十年之后我招人的時(shí)候簡歷上寫精通iOS的人多了但能講清楚ARC在什么場景下會失效、為什么UITableView滾動(dòng)會掉幀、二進(jìn)制重排為什么能提升啟動(dòng)速度的人依然不多。這個(gè)現(xiàn)象也從側(cè)面說明技術(shù)生態(tài)的繁榮度并不等于技術(shù)深度的普及度。1.2 2017-2020iPhone X以來的交互革命與審核生態(tài)轉(zhuǎn)折2017年是iOS開發(fā)史上一個(gè)重要的分水嶺。iPhone X帶來了全面屏和Face IDiOS 11帶來了真正的文件App、ARkit和Core ML但我個(gè)人覺得對開發(fā)者影響最大的其實(shí)是兩個(gè)看起來不大的變化一是Home Indicator安全區(qū)概念很多老項(xiàng)目為了適配iPhone X不得不在Auto Layout之外引入系統(tǒng)安全區(qū)變量各種硬編碼的布局代碼開始崩壞二是App Store審核開始收緊蘋果在2017年底明確要求所有新提交的App必須支持64位大量的32位老App直接下架那一輪清掃之后iOS生態(tài)的低質(zhì)量App問題明顯緩解。從2018年開始訂閱制、內(nèi)購抽成的討論越來越熱蘋果對虛擬支付、用戶隱私、IDFA獲取的審查越來越嚴(yán)。我印象最深的是2019年那波蘋果大掃除很多做統(tǒng)計(jì)、推送、熱修復(fù)的SDK被點(diǎn)名限制國內(nèi)使用廣泛的JSPatch熱更新方案直接廢掉一大批依賴熱修解決線上的團(tuán)隊(duì)不得不轉(zhuǎn)向更合規(guī)的發(fā)布節(jié)奏。當(dāng)時(shí)我們團(tuán)隊(duì)恰好經(jīng)歷了從敢于發(fā)版熱修到嚴(yán)格灰度監(jiān)控的轉(zhuǎn)變習(xí)慣了用App Store審核周期倒推開發(fā)排期反而把代碼質(zhì)量和CI/CD體系做了起來。這個(gè)階段的iOS技術(shù)圈也在變。Swift經(jīng)過4.0的ABI穩(wěn)定、5.0的模塊穩(wěn)定終于在2019年達(dá)到了可以大規(guī)模用于生產(chǎn)的成熟度。RxSwift、Moya、SnapKit成為主流三件套組件化、模塊化、CocoaPods與Carthage之爭成為社區(qū)焦點(diǎn)MTL美團(tuán)技術(shù)、LPD荔枝FM等團(tuán)隊(duì)相繼輸出組件化方案推動(dòng)了很多中大型App的工程架構(gòu)升級。坦白說這個(gè)階段是iOS開發(fā)技術(shù)紅利最大的幾年。同樣一個(gè)功能用MVVMRxSwift實(shí)現(xiàn)和用MVC回調(diào)實(shí)現(xiàn)代碼量和可維護(hù)性完全是兩個(gè)世界。1.3 2020-2025大版本重構(gòu)與AI時(shí)代的iOS2020年之后Apple進(jìn)入了一個(gè)每年一個(gè)大版本迭代的快車道。iOS 14引入WidgetKit、App Clips、隱私標(biāo)簽iOS 15的專注模式、Text LiveiOS 16的鎖屏小組件、PasskeysiOS 17的StandBy、交互式WidgetiOS 18的Apple Intelligence、RCS到2025年的iOS 19整個(gè)系統(tǒng)的交互范式已經(jīng)被重塑成AI系統(tǒng)級服務(wù)的形態(tài)。開發(fā)者需要跟進(jìn)的新東西越來越多每年WWDC之后都要花一兩周時(shí)間消化新API。這一階段對老iOS開發(fā)者的挑戰(zhàn)是空前的。以前你掌握UIKit、掌握Auto Layout、掌握MRC/ARC的底層原理就能吃好多年現(xiàn)在Foundation、Composable Architecture、Concurrency、Observation、Macros、Predicate泛型化、Data Flow框架加上Apple自己的Declarative編程范式激進(jìn)轉(zhuǎn)變要求你必須持續(xù)處于學(xué)習(xí)狀態(tài)。更現(xiàn)實(shí)的壓力來自行業(yè)結(jié)構(gòu)跨平臺方案日益成熟小程序生態(tài)壯大Android系統(tǒng)級能力追趕鴻蒙的份額逐步擴(kuò)展再加上AI輔助編程工具對初級開發(fā)崗位的擠壓iOS開發(fā)是不是不行了這個(gè)話題每年都會被翻出來討論一次。但我的真實(shí)判斷是iOS原生開發(fā)本身沒有沒落沒落的是只會照著文檔寫UI、對底層一竅不通、離開第三方庫寸步難行這種初級開發(fā)模式。后面我會專門展開講這個(gè)問題先接著技術(shù)主線走。2. Swift十年演進(jìn)史從1.0到6.0真實(shí)項(xiàng)目遷移的得與失2.1 Swift各版本的關(guān)鍵能力與踩坑記錄Swift這十年的版本演進(jìn)幾乎可以看作iOS開發(fā)方式變革的縮影。我按自己的實(shí)際使用時(shí)間線把幾個(gè)關(guān)鍵版本盤點(diǎn)一遍版本發(fā)布時(shí)間關(guān)鍵變化我自己在實(shí)際項(xiàng)目中的感受1.x2014-2015基礎(chǔ)語法、可選類型、閉包API一個(gè)月一變Xcode自動(dòng)遷移工具經(jīng)常失敗純Swift項(xiàng)目沒人敢碰2.x2015錯(cuò)誤處理do-catch、guard、擴(kuò)展協(xié)議語法成熟了一些但編譯太慢大項(xiàng)目用Swift依然痛苦3.x2016Swift API設(shè)計(jì)規(guī)范全面調(diào)整大量API命名改動(dòng)社區(qū)第三方庫集體重寫遷移成本爆炸4.x2017-2018字符串重做、Codable、ABI穩(wěn)定性預(yù)告終于感覺Swift是正常的語言了Codable大幅簡化JSON解析5.x2019-2021ABI穩(wěn)定、模塊穩(wěn)定、SwiftUI伴隨誕生生態(tài)開始真正成熟可以放心把Swift引入生產(chǎn)環(huán)境6.x2024-2025嚴(yán)格并發(fā)檢查、孤兒隔離、所有權(quán)并發(fā)遷移成本高老項(xiàng)目開啟Swift 6語言模式需要謹(jǐn)慎單獨(dú)講幾個(gè)在真實(shí)項(xiàng)目里讓我印象深刻的坑。Swift 1、2時(shí)代最大的問題是第三方庫版本跟不上。你新寫一個(gè)Swift項(xiàng)目引一個(gè)第三方庫它只支持Swift 1.1你手頭是1.2可能就編譯不過。那時(shí)候有專門幫庫作者升級Swift版本的工具但實(shí)際體驗(yàn)非常一般升級一次API核心代碼要改的地方比想象中多得多。最讓我崩潰的是Swift 2到Swift 3的遷移蘋果把幾乎所有的API都改成了動(dòng)詞賓語風(fēng)格例如stringByAppendingString改成appending、CGSizeMake改成CGSize構(gòu)造器看起來只是命名變化但改完一個(gè)中大型項(xiàng)目基本是脫層皮的量級。到了Swift 4才真正好起來但整個(gè)社區(qū)對Swift升級會破壞代碼的PTSD持續(xù)了好幾年。另一個(gè)重要節(jié)點(diǎn)是Codable的引入。在Codable之前iOS開發(fā)轉(zhuǎn)JSON模型基本靠手寫KVC setValue:forKey:或者用YYModel、Mantle這類反射庫。Codable出來后struct直接聲明struct User: Codable一行代碼搞定解析簡單、安全、編譯期檢查體驗(yàn)是劃時(shí)代的。不過它也帶了幾個(gè)容易踩的坑JSONDecoder默認(rèn)的keyDecodingStrategy不處理駝峰和下劃線的轉(zhuǎn)換你返回的JSON字段是user_name結(jié)構(gòu)體里寫userName就解析不出來必須在CodingKeys里手動(dòng)映射[String: Any]類型字典解析成模型時(shí)Any在Codable里不是直接可用的類型需要用FailableDecodable之類的包裝方案。這些坑幾乎每個(gè)新人都踩一遍我在代碼 review 時(shí)看過無數(shù)幾道。2.2 OC與Swift混編的工程化經(jīng)驗(yàn)如果你的項(xiàng)目是2015年起步的大概率到今天還是OC為主、Swift為輔助的混編狀態(tài)。如何讓混編項(xiàng)目穩(wěn)定、不拖慢編譯、少出詭異問題是這一批iOS開發(fā)者的必修課。我的經(jīng)驗(yàn)可以濃縮成四點(diǎn)第一Swift調(diào)用OC要多用輕量橋接。Swift和OC互調(diào)是通過自動(dòng)生成的橋接頭文件實(shí)現(xiàn)的你不需要在每個(gè)文件里import但必須保證Swift能看到的OC頭文件都被正確放進(jìn)了YourProject-Bridging-Header.h。隨著項(xiàng)目變大這個(gè)橋接頭文件會越來越臃腫影響Swift編譯速度。建議只暴露真正需要給Swift用的類用#if __has_include或者按照模塊分區(qū)再建中間頭文件不要讓幾百個(gè)OC頭文件全部被拖進(jìn)Swift的編譯視野。第二OC調(diào)用Swift時(shí)注意泛型和可選類型。OC里看到Swift的生成接口泛型會變成id可選會變成nullablestruct會被視為普通類。我遇到過最典型的問題是Swift協(xié)議里有associatedtype或者where子句OC引用這個(gè)協(xié)議時(shí)經(jīng)常出現(xiàn)無法匹配的問題。所以凡是聲明給OC用的Swift協(xié)議一定要寫成objc protocol且避免用過復(fù)雜的泛型約束。第三混編項(xiàng)目的編譯時(shí)間控制。Swift文件一多增量編譯也會很耗時(shí)尤其在CI機(jī)器上。我們實(shí)踐下來比較有效的手段是把所有OC文件歸檔成靜態(tài)庫framework只在工程里暴露少量Bridge頭文件Swift代碼按照模塊拆成多個(gè)本地包Swift Package把不依賴OC的部分隔離出來減少跨語言解析依賴同時(shí)打開New Build System和Debug環(huán)境下的優(yōu)化關(guān)閉一些不必要的編譯歸檔。第四混編項(xiàng)目千萬別用objcMembers無腦暴露。它會讓編譯器為所有成員生成OC接口編譯時(shí)間和二進(jìn)制體積都會增加偶爾還有符號沖突。更合適的做法是只在被OC真正調(diào)用的成員上單獨(dú)加objc。2.3 遷移到Swift 6后的并發(fā)改動(dòng)到2025年新項(xiàng)目基本上可以按Swift 6的語言模式標(biāo)準(zhǔn)去寫了但存量項(xiàng)目要遷移到嚴(yán)格并發(fā)檢查依然是一塊硬骨頭。Swift 6最大的變化是編譯器強(qiáng)制檢查數(shù)據(jù)競爭所有跨并發(fā)域傳遞的閉包、狀態(tài)、可變類型都必須滿足Sendable協(xié)議否則編譯直接報(bào)錯(cuò)。我去年把一個(gè)中型Swift項(xiàng)目從Swift 5遷移到Swift 6語言模式整理了如下幾個(gè)必須處理的點(diǎn)DispatchQueue.main.async里的可逃逸閉包捕獲了可變對象報(bào)capture of non-sendable type。Timer的回調(diào)和NotificationCenter的selector方式在嚴(yán)格并發(fā)模式下會警告建議用Combine的Timer.publish或AsyncStream重構(gòu)。單例的static let shared本身是線程安全的但如果你在單例里持有可變屬性外部并發(fā)讀寫時(shí)編譯器會提示要加MainActor或者nonisolated標(biāo)注。ObservableObject在SwiftUI里跨線程更新Published屬性也會被嚴(yán)格檢查出來需要確保所有UI相關(guān)狀態(tài)在主線程更新。一些OC框架提供的block回調(diào)在橋接后可逃逸它們的參數(shù)默認(rèn)是Sendable如果你在回調(diào)里修改外部可變捕獲也要報(bào)錯(cuò)。整體的遷移順序我的建議是從葉子模塊不依賴UI、不依賴第三方庫的純工具類往上游推先把數(shù)據(jù)層做成Sendable struct再改服務(wù)層最后處理UI層。不要直接開全局嚴(yán)格模式先用Swift 5兼容模式搭配-strict-concurrencycomplete掃描出所有隱患再分批啟用nonisolated(unsafe)或者preconcurrency過渡。等并發(fā)檢查的告警清零之后最后一步才能把語言模式切到Swift 6。這個(gè)過程急不得我在實(shí)際項(xiàng)目中見過的教訓(xùn)是為了提早上架而硬開Swift 6模式結(jié)果并發(fā)崩潰反而增多最后又整體回退浪費(fèi)了一整個(gè)迭代周期。3. UIKit與SwiftUI共存五年漸進(jìn)式遷移的落地路線3.1 SwiftUI什么階段才真的能用于生產(chǎn)SwiftUI在2019年的WWDC上發(fā)布當(dāng)時(shí)的狀況非常大會Demo級堆疊、動(dòng)畫、圖片加載看起來很美但一旦遇到自定義導(dǎo)航、復(fù)雜列表、鍵盤處理、跨層級頁面刷新就寸步難行。我2019年試著用它寫了一個(gè)內(nèi)部工具App真正跑起來后才發(fā)現(xiàn)熱重載的坑、列表重繪的卡頓、State作用域混亂的問題都特別多。后來我把那個(gè)App重新用UIKit寫了一遍效率反而是SwiftUI寫的兩倍快。SwiftUI真正可以放心用于生產(chǎn)的時(shí)間點(diǎn)我認(rèn)為是iOS 16之后。iOS 15的SwiftUI還在大量補(bǔ)全中NavigationStack、NavigationSplitView、scrollContentBackground、safeAreaInset這些重要的基礎(chǔ)能力都是在那幾個(gè)版本才補(bǔ)齊的。特別是iOS 16引入的NavigationStack替代了混亂的NavigationView加上ObservableObject的狀態(tài)管理被Observable宏所改革整個(gè)SwiftUI的編程范式才趨于穩(wěn)定。到iOS 17、iOS 18這兩代SwiftUI已經(jīng)足以支撐完整的復(fù)雜AppContentUnavailableView、ScrollView的新scrollTargetLayout、Inspectable調(diào)試能力、Entry宏和Environment的改善讓開發(fā)體驗(yàn)和UIKit的差距明顯縮小。我的結(jié)論是新項(xiàng)目、新模塊如果目標(biāo)系統(tǒng)是iOS 16可以優(yōu)先考慮SwiftUI如果還需要兼容iOS 15以下除非團(tuán)隊(duì)的UIKit水平夠高且愿意花時(shí)間做橋接否則還是老老實(shí)實(shí)UIKit為主。現(xiàn)在很多團(tuán)隊(duì)還保留SwiftUI只做新功能頁面的策略目的就是降低整體風(fēng)險(xiǎn)。3.2 混合架構(gòu)UIHostingController與UIViewRepresentable的實(shí)戰(zhàn)邊界只要不是從零純SwiftUI的項(xiàng)目必然要處理UIKit和SwiftUI的互嵌問題。UIKit里嵌入SwiftUI頁面很簡單用UIHostingController包一層就可以let hostingVC UIHostingController(rootView: MySwiftUIView(model: model)) navigationController?.pushViewController(hostingVC, animated: true)但這里有幾個(gè)坑。第一UIHostingController的視圖在嵌入到已有的UINavigationBar時(shí)默認(rèn)會多出一塊安全區(qū)域邊距解決方案是設(shè)置hostingVC.additionalSafeAreaInsets .zero或者用rootView.ignoresSafeArea()配合safeAreaPadding處理。第二UIHostingController對導(dǎo)航欄隱藏狀態(tài)、大標(biāo)題模式的感知并不總是即時(shí)同步當(dāng)UIKit和SwiftUI混合頁面來回跳轉(zhuǎn)時(shí)可能出現(xiàn)導(dǎo)航欄樣式閃變。我一般的做法是讓所有導(dǎo)航欄樣式統(tǒng)一由UIKit端控制SwiftUI頁面只是普通內(nèi)容不做導(dǎo)航欄自定義。反向操作——在SwiftUI中嵌入U(xiǎn)IKit視圖用的是UIViewRepresentable。這里最常見的應(yīng)用就是集成地圖SDK、視頻播放器、富文本編輯器這些沒有SwiftUI替代的方案。寫UIViewRepresentable時(shí)關(guān)鍵是要處理好生命周期和更新時(shí)機(jī)makeUIView負(fù)責(zé)創(chuàng)建原生視圖updateUIView負(fù)責(zé)在SwiftUI狀態(tài)變化時(shí)刷新UI剩下的Coordinator負(fù)責(zé)接收UIKit側(cè)的回調(diào)事件再通過綁定或閉包轉(zhuǎn)發(fā)給SwiftUI側(cè)。有一個(gè)高頻踩坑點(diǎn)在updateUIView里頻繁創(chuàng)建對象或修改約束會引發(fā)SwiftUI的不必要重繪正確的做法是把重對象比如地圖View、ScrollView只創(chuàng)建一次把狀態(tài)刷新收斂到updateUIView的局部操作里。3.3 響應(yīng)式架構(gòu)選型MVVM、Combine與Observation從2018年到2023年MVVM Combine或者RxSwift是中大型iOS項(xiàng)目的絕對主流。我在實(shí)際項(xiàng)目中實(shí)踐下來的組合是ViewModel負(fù)責(zé)業(yè)務(wù)狀態(tài)和API交互View層通過Published屬性綁定數(shù)據(jù)頁面控制器負(fù)責(zé)組裝interactor如果項(xiàng)目有Clean Swift風(fēng)格承擔(dān)復(fù)雜業(yè)務(wù)用例。但Combine也有它自己的問題Operator的學(xué)習(xí)曲線陡峭調(diào)試鏈路過長Subject濫用會導(dǎo)致狀態(tài)變化不可追蹤加上Combine本身不支持Android和前端團(tuán)隊(duì)里如果有多端共享邏輯的需求維護(hù)起來特別費(fèi)勁。所以從iOS 17開始Apple推出Observable宏之后SwiftUI的數(shù)據(jù)流明顯走向了更輕、更原位的方式?，F(xiàn)在新寫的SwiftUI頁面我基本不再依賴ObservableObjectPublished而是直接用StateObservable模型Observable final class UserProfileModel { var name: String var age: Int 0 } struct ProfileView: View { State private var model UserProfileModel() var body: some View { VStack { TextField(Name, text: $model.name) Text(Age: \(model.age)) } } }從代碼量上看Observable比ObservableObject少了一堆Published和objectWillChange的噪音性能上也有優(yōu)化SwiftUI可以精確到屬性級別的依賴追蹤不會因?yàn)槟硞€(gè)無關(guān)屬性變化而觸發(fā)整棵視圖樹重建。如果你還在維護(hù)一個(gè)老項(xiàng)目完全可以在新頁面里逐步引入Observable舊的ViewModel接口不用動(dòng)兩套方案并存過渡并不沖突。4. 性能優(yōu)化與穩(wěn)定性治理的實(shí)戰(zhàn)清單4.1 啟動(dòng)速度的梳理與優(yōu)化實(shí)例App啟動(dòng)速度到底是不是一門玄學(xué)我的答案是它可以是但只要你按正確的順序去查大部分情況下都能找到可量化的瓶頸。我把啟動(dòng)階段分為四個(gè)可觀測區(qū)間進(jìn)程創(chuàng)建、UIKit初始化、首屏數(shù)據(jù)請求、首幀渲染完成。每個(gè)區(qū)間對應(yīng)的排查工具和技術(shù)手段都不一樣。進(jìn)程創(chuàng)建階段主要看動(dòng)態(tài)庫加載。每個(gè)App在啟動(dòng)時(shí)都會加載一組動(dòng)態(tài)庫包括系統(tǒng)的和你自己的framework。用DYLD_PRINT_STATISTICS環(huán)境變量在Xcode scheme里設(shè)置可以看每個(gè)動(dòng)態(tài)庫的加載耗時(shí)這個(gè)我看到很多團(tuán)隊(duì)都沒用起來。理論上動(dòng)態(tài)庫加載時(shí)間跟庫的依賴數(shù)量、符號表大小有關(guān)越多加載越慢。優(yōu)化方式兩個(gè)方向一是減少依賴庫的數(shù)量尤其是靜態(tài)鏈接的第三方庫能合并的合并二是用__builtin_return_address等工具做二進(jìn)制重排將啟動(dòng)路徑上的函數(shù)提前到頁面前部減少缺頁中斷的次數(shù)。這個(gè)優(yōu)化對包體積大、代碼量多的App效果尤其明顯我們在一個(gè)百萬行級別的App上做過冷啟動(dòng)時(shí)間下降了約25%。UIKit初始化和main函數(shù)到didFinishLaunching的區(qū)間主要看你有什么同步邏輯。很多App在didFinishLaunching里一口氣做了注冊推送、初始化統(tǒng)計(jì)、設(shè)置數(shù)據(jù)庫、拉取配置、啟動(dòng)網(wǎng)絡(luò)服務(wù)這些串行任務(wù)每一項(xiàng)都在拖慢啟動(dòng)。合理的做法是把可延后的任務(wù)全部丟到后臺隊(duì)列或者等首個(gè)頁面顯示后再執(zhí)行只保留最核心的初始化如崩潰收集SDK、必要的路由注冊。我們改造時(shí)就是先把統(tǒng)計(jì)、上報(bào)、推送注冊移到主線程外用DispatchQueue.main.async或OperationQueue延遲到首幀之后冷啟動(dòng)提升了300ms左右。首屏數(shù)據(jù)請求和首幀渲染完成階段關(guān)注點(diǎn)集中在網(wǎng)絡(luò)并發(fā)、緩存策略、圖片解碼時(shí)機(jī)。一個(gè)常見的坑是首屏接口必須等A接口返回后再請求B接口兩個(gè)接口沒有依賴關(guān)系卻寫成了串行白白多了幾百毫秒。優(yōu)化方式是并行請求或者預(yù)加載另一個(gè)坑是首屏大圖在主線程解碼會直接卡住首次滑動(dòng)。解決方案是使用ImageIO的downsample工具預(yù)先生成縮略圖避免加載原圖。4.2 內(nèi)存泄漏、卡頓與Instruments的實(shí)際用法Instruments在不少iOS開發(fā)者的印象里是個(gè)看過但不會用的工具這很可惜。實(shí)際用起來它的功能足夠強(qiáng)大只是入口和操作方式不如Xcode本身直觀。我把日常排查分成了三塊。內(nèi)存泄漏排查用Leaks工具配合Xcode的Memory Graph Debugger。Memory Graph Debugger可以顯示當(dāng)前所有對象之間的引用關(guān)系紅色感嘆號表示疑似泄漏。常見的泄漏場景NSTimer的target強(qiáng)引用循環(huán)、CADisplayLink沒有釋放、閉包捕獲了self導(dǎo)致循環(huán)、NotificationCenter的observer沒移除、單例持有頁面對象。我在實(shí)際項(xiàng)目里見過一個(gè)非常隱蔽的泄漏WKWebView的configuration.userContentController.add添加了JS bridge但頁面釋放時(shí)忘記調(diào)用removeScriptMessageHandler導(dǎo)致整個(gè)webView和它的父控制器都駐留內(nèi)存。這種泄漏普通工具掃描不出來需要配合deinit打點(diǎn)來定位?？D排查主要用Time Profiler和os_signpost自定義區(qū)間。Time Profiler可以看到CPU耗時(shí)集中在哪個(gè)方法但精度有限不如用os_signpost在代碼里埋點(diǎn)把關(guān)鍵操作比如列表cell的配置、圖片解碼的耗時(shí)量化。具體做法是在Signpost的begin/end事件里記錄自定義字符串然后通過Xcode的Instruments模板看區(qū)間耗時(shí)。如果列表滾動(dòng)卡頓還要檢查cellForRowAt里是否做了大量同步繪制、是否在cell復(fù)用邏輯里重復(fù)創(chuàng)建子視圖、layoutSubviews是否過于頻繁。用Core Animation模板可以看到是否發(fā)生離屏渲染圓角陰影是常見元兇解決辦法是預(yù)先繪制圓角圖片背景或者在后臺提前渲染mask避免觸發(fā)shouldRasterize的過度使用。4.3 包體積與二進(jìn)制化的治理包體積不是最核心的性能指標(biāo)但對于App Store分發(fā)和用戶首次下載體驗(yàn)影響還挺大的。在App Store限制蜂窩網(wǎng)絡(luò)下載App大小上限的背景下包體越大新增用戶的轉(zhuǎn)化損失越明顯。我們治理包體的方式分三層。第一層資源壓縮與優(yōu)化。圖片統(tǒng)一走無透明通道的壓縮格式盡量用Asset Catalog管理APNG/Lottie動(dòng)畫資源盡量以動(dòng)圖替代序列幀大圖、視頻、字體文件可以考慮云端下載但要注意首屏需要的資源必須打進(jìn)包體。第二層無用代碼與無用資源清理。iOS 15加入了一項(xiàng)新的打包配置Remove unused code and resources但系統(tǒng)級的無用代碼清理效果有限更有效的還是靠團(tuán)隊(duì)的靜態(tài)檢查工具。我們可以用FUI或LinkMap分析找出那些被引用但從未在代碼里使用的類、方法和資源。第三層架構(gòu)層面的瘦身。如果項(xiàng)目按模塊化拆分成了多個(gè)framework檢查是否有一些在全App層面根本不會被調(diào)用的模塊被打進(jìn)了包動(dòng)態(tài)庫無法被App Store裁剪但如果用的是靜態(tài)庫可以在鏈接階段去掉重復(fù)符號顯著減小可執(zhí)行文件大小。二進(jìn)制重排不僅能優(yōu)化啟動(dòng)對包體積也有間接幫助——把啟動(dòng)路徑函數(shù)前移頁面加載時(shí)更少出現(xiàn)缺頁中斷整體內(nèi)存占用會好看一些。這個(gè)技術(shù)我以前覺得是大廠專屬高深優(yōu)化后來發(fā)現(xiàn)只要用Order File 編譯參數(shù)就能實(shí)現(xiàn)流程并不復(fù)雜在Xcode的Build Settings里設(shè)置Order File路徑指向一個(gè)文本文件在Other Linker Flags里加-order_file生成方式通過靜態(tài)分析方法或者運(yùn)行通知機(jī)制采樣啟動(dòng)路徑的函數(shù)排序后寫入文件。實(shí)測中對一個(gè)啟動(dòng)路徑函數(shù)較多的大型App優(yōu)化效果非常明顯。5. 跨平臺圍攻戰(zhàn)uniapp、小程序、Android與鴻蒙的博弈5.1 跨平臺方案的真實(shí)體驗(yàn)與適用場景現(xiàn)在iOS開發(fā)者在社區(qū)里經(jīng)常被問到你們原生開發(fā)是不是要失業(yè)了uniapp、Flutter、React Native這么火小程序這么普及。說實(shí)話這個(gè)問題的答案取決于你的位置和項(xiàng)目類型。先看跨平臺技術(shù)的真實(shí)能力邊界。uniapp的優(yōu)點(diǎn)是開發(fā)效率高一份代碼可以同時(shí)出Android、iOS、小程序版語法基于Vue前端同學(xué)上手成本極低它對小程序的適配能力尤其強(qiáng)很多公司的做法是先做小程序驗(yàn)證業(yè)務(wù)再考慮包一層App殼。但uniapp的實(shí)際體驗(yàn)需要分層看純信息展示型、表單型、簡單頁面型的應(yīng)用它完成度很高一旦涉及復(fù)雜動(dòng)畫、原生能力深度調(diào)用、多線程、音視頻流處理問題就來了。跨端框架的這一層抽象天然要在原生能力上包一層JS bridge性能損耗和調(diào)試復(fù)雜度是不可避免的。以一個(gè)列表快速滾動(dòng)卡片點(diǎn)擊動(dòng)畫的例子來說原生實(shí)現(xiàn)可以做到60fps無壓力而跨端框架在低端Android機(jī)上幾乎必然掉幀iOS端略微好一點(diǎn)但也做不到和原生完全一致。Flutter是另一條技術(shù)路線渲染引擎自繪不依賴原生的UI控件性能和一致性比JS橋接方案好很多但它仍然繞不開和原生交互的邊界問題。只要你的App需要跟系統(tǒng)深度集成比如推送的廠商通道適配、掃碼、NFC、藍(lán)牙、自定義相機(jī)原生模塊的編寫和調(diào)試依然要原生開發(fā)者來做。而在App Store審核和大廠native能力的爭奪戰(zhàn)中原生應(yīng)用依然擁有最好的系統(tǒng)體驗(yàn)和最高權(quán)限尤其是對隱私、權(quán)限、后臺任務(wù)的控制。這套技術(shù)對比下來我的實(shí)際建議是項(xiàng)目類型推薦技術(shù)棧原因快速驗(yàn)證MVP、政府/企業(yè)展示型Appuniapp或Flutter開發(fā)快、多端復(fù)用成本低內(nèi)容平臺、電商、社交類App原生為主復(fù)雜交互與性能要求高長期迭代價(jià)值大工具類、企業(yè)辦公AppFlutter或uniapp開發(fā)和維護(hù)成本可控有大量原生能力依賴、長生命周期產(chǎn)品原生或原生跨端混編穩(wěn)定性和權(quán)限控制優(yōu)先5.2 Android與鴻蒙的發(fā)展對iOS開發(fā)者造成的影響很多iOS開發(fā)者可能低估了Android和鴻蒙技術(shù)棧對自己的影響。從2020年開始鴻蒙的開發(fā)者生態(tài)逐步建立一個(gè)完整的多設(shè)備連接體系到2025年已經(jīng)在手機(jī)、平板、車機(jī)、IoT多個(gè)設(shè)備上形成一定規(guī)模的用戶基礎(chǔ)。這就帶來一個(gè)很現(xiàn)實(shí)的問題以前做iOS的團(tuán)隊(duì)如果要開拓鴻蒙市場團(tuán)隊(duì)里得有人懂ArkTS/ArkUI而懂iOS的工程師在職場上第一次面臨單一技能不再夠用的局面。但換個(gè)角度看Android和鴻蒙的崛起也給iOS開發(fā)者的經(jīng)驗(yàn)提出了一種技術(shù)遷移能力的考驗(yàn)。iOS上很多積累——UI架構(gòu)設(shè)計(jì)思路、網(wǎng)絡(luò)層優(yōu)化、緩存策略、數(shù)據(jù)綁定范式、性能監(jiān)控體系——在Android和鴻蒙上都是可以平移的。我在團(tuán)隊(duì)里帶過幾個(gè)轉(zhuǎn)Android的iOS開發(fā)他們上手速度非?？煲?yàn)橐环矫嬲Z言層面的差異并沒有想象中那么大Swift和Kotlin在不少設(shè)計(jì)上是相通的ArkTS本質(zhì)上也是TypeScript的超集另一方面 iOS開發(fā)對系統(tǒng)底層機(jī)制的深入理解讓他們很容易觸類旁通。這里給還在做iOS的老哥一句實(shí)在話不要因?yàn)樾缕脚_的出現(xiàn)而心慌更不要因?yàn)閯e人喊一句iOS涼了就焦慮轉(zhuǎn)行。你已有的開發(fā)思維、調(diào)試方法論、性能優(yōu)化經(jīng)驗(yàn)在新平臺上仍然是核心價(jià)值。真正需要開始做的是花點(diǎn)時(shí)間了解一兩個(gè)新平臺的開發(fā)范式保持技術(shù)視野的廣度。5.3 原生iOS開發(fā)在2025年的真實(shí)生存空間到2025年原生iOS開發(fā)的定位已經(jīng)和十年前完全不同。在增量市場階段App多、功能簡單、競爭小原生開發(fā)者靠能把App做出來就能混得不錯(cuò)?，F(xiàn)在進(jìn)入存量市場App的功能復(fù)雜度、用戶對體驗(yàn)的要求、監(jiān)管對隱私合規(guī)的要求都在快速提高反而是能做深、做穩(wěn)、做細(xì)的原生開發(fā)更稀缺。從招聘行情看我認(rèn)識的獵頭和HR都在說初級iOS崗位確實(shí)在減少因?yàn)榭缍朔桨负虯I編程工具更容易替代初級開發(fā)者但高級崗位、資深性能和穩(wěn)定性專家、系統(tǒng)底層方向的技術(shù)人才招聘難度反而在上升。而真正值錢的iOS開發(fā)者一般具備三個(gè)特征能深入理解和解決復(fù)雜問題比如崩潰、卡頓、內(nèi)存、包體積能與跨端團(tuán)隊(duì)協(xié)作并主導(dǎo)原生邊界方案的架構(gòu)決策能在iOS生態(tài)的新技術(shù)方向如AI集成、新交互范式上保持快速學(xué)習(xí)。需要注意的一點(diǎn)是App Store的審核和隱私政策也一直在變原生開發(fā)者的合規(guī)能力越來越重要。iOS 14之后IDFA需要用戶授權(quán)iOS 17推出了全面的隱私清單要求到iOS 18、iOS 19蘋果對App追蹤透明度和數(shù)據(jù)收集的審查變得更加嚴(yán)格。如果你是一個(gè)獨(dú)立開發(fā)者或小團(tuán)隊(duì)光是把隱私清單、第三方SDK合規(guī)說明、收集數(shù)據(jù)用途說明整理清楚就是一筆不小的精力支出。這類問題跨端框架也沒法替你解決最終還是要回到原生側(cè)去適配。6. 十年之期給新人和還在猶豫的人的一些心里話6.1 一條從初級到資深的成長路徑有很多剛?cè)胄械呐笥褑栁襥OS開發(fā)到底該怎么學(xué)是不是背背面試題就夠了。我的回答是面試題只能幫你拿到面試機(jī)會真正決定你能走多遠(yuǎn)的是建立一套可持續(xù)的技術(shù)成長框架。如果讓我回看這十年我會建議新人在幾個(gè)方向投入時(shí)間第一打牢系統(tǒng)底層。iOS開發(fā)者最容易忽略但又最能拉開差距的知識點(diǎn)包括RunLoop的底層邏輯、Mach-O文件結(jié)構(gòu)、dyld加載過程、Block對變量的捕獲機(jī)制、ARC的底層實(shí)現(xiàn)與循環(huán)引用原理、GCD的隊(duì)列與線程模型、內(nèi)存頁與虛擬內(nèi)存。具備這些底子的開發(fā)者看問題都是從系統(tǒng)是如何工作的出發(fā)而不是背API。第二補(bǔ)齊跨端和通用技術(shù)棧。不是讓你去精通Flutter或React Native而是至少了解它們的架構(gòu)邊界和與原生交互的方式。當(dāng)團(tuán)隊(duì)在跨端方案和原生方案之間做選擇時(shí)你能給出有依據(jù)的權(quán)衡而不是只會說我只會寫iOS。第三工程化思維不是加分項(xiàng)是基礎(chǔ)項(xiàng)。代碼規(guī)范、Code Review、CI/CD、自動(dòng)化測試、崩潰監(jiān)控、承壓演練這些在成熟團(tuán)隊(duì)里都是日常。新人在簡歷上寫熟練使用Git可能不如真的學(xué)會用git rebase整理提交歷史、會用xccov做覆蓋率統(tǒng)計(jì)、會寫一個(gè)自定義的xcodebuild腳本來得實(shí)在。第四保持對產(chǎn)品的一線敏感度。很多技術(shù)人只看功能實(shí)現(xiàn)不思考需求背后的用戶動(dòng)機(jī)和商業(yè)目標(biāo)。我見過太多代碼能力不錯(cuò)但始終無法晉升到高級崗的開發(fā)者卡住他們的往往不是技術(shù)而是對業(yè)務(wù)的理解和對產(chǎn)品取舍的判斷力。6.2 AI時(shí)代iOS開發(fā)者的自我迭代最近兩年AI編程工具的爆發(fā)對每個(gè)開發(fā)者都產(chǎn)生了沖擊。GitHub Copilot、ChatGPT、Claude、國內(nèi)的各種AI Coding產(chǎn)品都讓代碼生成速度大幅提升。很多初級開發(fā)者的焦慮在于如果AI都能寫代碼了我還要不要學(xué)Swift我的觀點(diǎn)是AI確實(shí)會取代一部分低創(chuàng)造性的編碼工作但恰恰因?yàn)樗馨训蛯哟a寫得又快又好反而放了開發(fā)者的注意力去處理更高層的工程決策與技術(shù)深度。一個(gè)實(shí)際的例子是以前我們用一段時(shí)間去設(shè)計(jì)一個(gè)復(fù)雜的動(dòng)畫交互可能需要一兩天去調(diào)參數(shù)現(xiàn)在AI能直接生成可編譯的SwiftUI代碼我們做的事情變成了判斷它生成的代碼是否符合項(xiàng)目架構(gòu)、是否有性能隱患、是否遵守了團(tuán)隊(duì)的代碼規(guī)范。這種角色的轉(zhuǎn)變要求開發(fā)者不再是一個(gè)單純的書寫者而是一個(gè)能評審、優(yōu)化、把控方向的工程師。另外很重要的一點(diǎn)是Apple自身也在全面擁抱AIXcode 26加入了AI代碼補(bǔ)全、構(gòu)建緩存、輔助測試生成等能力Swift的宏Macro系統(tǒng)也在朝著元編程AI輔助的方向演進(jìn)iOS 18、iOS 19的AI功能也為App打開了很多新的可能性例如通過新的框架直接調(diào)用系統(tǒng)級智能能力。在這個(gè)背景下一個(gè)不具備用AI工具提效能力的開發(fā)者和一位能夠用AI加速開發(fā)并把更多精力投向架構(gòu)設(shè)計(jì)、性能優(yōu)化、產(chǎn)品創(chuàng)新的開發(fā)者差距只會越來越大。這不是販賣焦慮而是這五年我逐漸看清楚的事實(shí)。我對iOS開發(fā)這十年的感情很復(fù)雜它見證了移動(dòng)互聯(lián)網(wǎng)的黃金時(shí)代也經(jīng)歷了一輪又一輪的技術(shù)洗牌。有些人離開了有些人轉(zhuǎn)了方向但始終堅(jiān)持下來的大多還在享受用代碼創(chuàng)造產(chǎn)品的樂趣。技術(shù)永遠(yuǎn)在變不變的是對問題本質(zhì)的追問、對代碼質(zhì)量的堅(jiān)持以及對用戶體驗(yàn)的那份敬畏。這個(gè)行業(yè)永遠(yuǎn)需要能把事情做對、把細(xì)節(jié)做好的人無論你用的是Swift、SwiftUI、還是未來某個(gè)新興范式。