大家好，我是坤哥

今天和大家探討一個話題：技術的穩定性到底有多重要。

上周用三天的時間把原本預計至少一周才能改造完成的 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」的場景呢，還不是出于穩定性考慮。

任何新技術的引入都要考慮以下幾個因素：

1. 新技術對開發效率/程序性能的提升是否顯著
2. 對此新技術熟悉的人是否足夠多（人員足夠多意味著方便交接，方便定位問題，方便開發功能）
3. 新技術從短期或長期來看對業務是否穩定

一般我們考慮的重要性按上面三點是依次遞減，但實際上第三點可能反而是最重要的。

其實我們這個項目雖然還未等 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 來重構的時間，這點時間幾乎可以忽略不計。