大家好，我是坤哥
今天和大家探讨一個話題：技術的穩定性到底有多重要。
上周用三天的時間把原本預計至少一周才能改造完成的 iOS 項目在最新的 Xcode 15（iOS 開發 IDE）上成功跑起來了！
其實說實話這個 iOS 項目用兩周的時間在 Xcode 15 上能不能跑起來我心裡都沒底，好在結果是好的。
這個項目過去四年了，是我司的主要盈利産品（返利 app），不過技術棧還比較陳舊，一些依賴用的 swift 3.0 寫的（最新的 swift 版本是 5.5），在最新的 Xcode 15 上跑不起來，也就無法打包，那還了得，萬一碰到什麼 bug 無法打包解決問題可就大了。
其實五一前兩周我們在疊代開發産品時就發現 4.29 日之後必須用 Xcode 15 打包，還好提前一周我們發現了這個問題，這樣可以先降級到 Xcode 14 來開發打包，疊代的功能也順利上線了。
但是 app 不能在 Xcode 15 上啟動打包的問題終究是要解決的，于是五一回來之後我又馬不停蹄地疊代這個 APP，以讓它能在 Xcode 15 上跑起來，好在運氣比較好，經過一番魔改（之後會提到）終于跑起來了。
四年對一個項目其實說長也長，說短也短，理論上像 Java 開發的項目，由于 JDK 通常設計為向後相容的（相容老版本），老項目通常能跑起來，為啥我們的這個 iOS 項目會有這樣在最新版 Xcode 15 上跑不起來的問題呢。
主要原因其實是因為這個項目的 Pod（iOS 項目中的 Pod 類似 Java 中 Maven 管理的第三方依賴庫）不少是由 Swift 開發（蘋果 2014 年推出的程式設計語言），這些 Pod 庫中有不少引用 OC（Objective-C，蘋果系之前的主流開發語言）的代碼。
在之前的 Xcode 中，工程是可以跑起來的，但是最新的 Xcode 15 對編譯器等做了大量的的修改導緻這些 Pod 都無法編譯通過了，然後就跑不起來了，試了網上各種方法都不行。
這事其實很要命，試想如果發現線上有個 bug 需要緊急修複（比如無法提現），然後你的 app 卻無法打包導緻短時間内無法修複，很可能導緻使用者流失，業務停滞甚至公司倒閉的嚴重後果。
假使我們當時的技術人員統一在工程中都用 OC，而不是用 Swift 來寫代碼，那壓根就不會出現這樣的問題，如果一定要用 Swift，至少要等到 ABI 穩定之後再用。
「這裡簡單解釋一下什麼是 ABI 穩定：想象一下，有一座橋，這座橋連接配接了兩座島嶼：一個島是 Swift 語言自身，另一個島則是作業系統，比如 macOS 或 iOS。這座橋就像是一個協定，確定兩邊可以互相了解和交流。在軟體的世界裡，這座橋就是“應用程式二進制接口”（Application Binary Interface，簡稱 ABI）。
Swift 的 ABI 穩定性可以比作這座橋的結構變得堅固且不再改變。初期，Swift 還在不斷發展，這座橋每隔一段時間就需要重建一次，這意味着開發者如果使用了新版本的 Swift，他們可能需要重新編譯他們的應用程式，以確定它能在新橋上運作。」
Swift 作為一種新技術，其實還是存在不少坑的，手淘也是在 ABI 穩定後才開始在項目中引入 Swift 的，這就好比 JDK 22 出來了，但國内大部分還是使用的 Java 8。
為什麼會出現這種「你升任你升，我用 Java 8」的場景呢，還不是出于穩定性考慮。
任何新技術的引入都要考慮以下幾個因素：
- 新技術對開發效率/程式性能的提升是否顯著
- 對此新技術熟悉的人是否足夠多（人員足夠多意味着友善交接，友善定位問題，友善開發功能）
- 新技術從短期或長期來看對業務是否穩定
一般我們考慮的重要性按上面三點是依次遞減，但實際上第三點可能反而是最重要的。
其實我們這個項目雖然還未等 ABI 穩定就引入了 Swift，但當時公司的發展如日中天，有幾十号 iOS，也有好幾位 iOS 架構師，是以工程一旦有啥技術問題，基本也能輕易解決。
但後來公司業務急轉直下，iOS 團隊被裁或離職導緻一個不剩，後來公司徹底轉型，幹掉了所有的技術，你沒看錯，iOS 開發全都沒了（你說這種情況誰能想到）。
那這時之前在項目中引入的 Swift 就成為了一顆随時會引爆的定時炸彈，後患無窮。
是以現在回頭看，Swift 如果未在 ABI 穩定前被引入，一直用的 OC，那壓根不會有這樣的問題。
之前有人吐嘈銀行技術棧太過陳舊，如相比于網際網路普遍采用的 JSON, 銀行的資料格式大都是萬能不變的 XML 等。
其實對于銀行來說可以了解，畢竟是金融，要以穩定為主，重構幾下代碼是好看了，但由于曆史遺留問題可能會有技術債，一不小心出現問題如金額對不了的問題就悲劇了，是以真的别炫技術，技術這東西夠用就行！
最後，問題已經出現了，抱怨解決不了問題，那我們該如何解決呢？
這裡我想簡單介紹一下我是如何修改以讓老項目在 Xcode 15 上跑起來的。
其實運作一個項目與大家熟悉一個項目或者說業務的思路都是相通的，抓大放小, 抓主線，跑通主流程，細枝末節之後再看。
老項目無法在最新的 Xcode 15 上跑主要原因是 Pod 中的 Swift 引用了 OC 中的類，那我可以先注釋這些邏輯，等跑通後再看看怎麼優化。
再比如有個防反編譯的第三方庫，發現它的存在也會導緻項目無法啟動，怎麼也繞不過去，于是直接把它幹掉，安全，相比于 app 不能啟動這事不是那麼重要，這問題可以等 app 跑起來後再想辦法補。
碰到難題，不要想着硬碰硬，可以繞過去的，千萬不要在細枝末節上死磕，撿了芝麻，丢了西瓜。
此外碰到問題千萬不要慌，要冷靜分析，比如項目在 Xcode 15 跑起來後，我發現幾個 weex（一種跨平台架構）頁面的展示有些錯亂，如下：
看到這個頁面第一眼我想的是得用 H5 來重構了，但用 H5 重構，工作量比較大，有沒其他的方法？
我發現這個頁面其實并不是每個 UI 都是錯亂的，隻是少數幾個 UI 的渲染有問題，那就可以分析一下這幾個出問題的 UI 和其他正常顯示的 UI 在 weex 的寫法有哪些差別，于是經過分析發現是三元運算符還有 text 的寫法有差別，經過改造，問題就解決了，相比于使用 H5 來重構的時間，這點時間幾乎可以忽略不計。
更多資訊，點選全場景直播解決方案-航天雲網解決方案