大家好，我是坤哥

今天和大家探討一個(gè)話題：技術(shù)的穩(wěn)定性到底有多重要。

上周用三天的時(shí)間把原本預(yù)計(jì)至少一周才能改造完成的 iOS 項(xiàng)目在最新的 Xcode 15（iOS 開(kāi)發(fā) IDE）上成功跑起來(lái)了！

其實(shí)說(shuō)實(shí)話這個(gè) iOS 項(xiàng)目用兩周的時(shí)間在 Xcode 15 上能不能跑起來(lái)我心里都沒(méi)底，好在結(jié)果是好的。

這個(gè)項(xiàng)目過(guò)去四年了，是我司的主要盈利產(chǎn)品（返利 app），不過(guò)技術(shù)棧還比較陳舊，一些依賴(lài)用的 swift 3.0 寫(xiě)的（最新的 swift 版本是 5.5），在最新的 Xcode 15 上跑不起來(lái)，也就無(wú)法打包，那還了得，萬(wàn)一碰到什么 bug 無(wú)法打包解決問(wèn)題可就大了。

其實(shí)五一前兩周我們?cè)诘_(kāi)發(fā)產(chǎn)品時(shí)就發(fā)現(xiàn) 4.29 日之后必須用 Xcode 15 打包，還好提前一周我們發(fā)現(xiàn)了這個(gè)問(wèn)題，這樣可以先降級(jí)到 Xcode 14 來(lái)開(kāi)發(fā)打包，迭代的功能也順利上線了。

但是 app 不能在 Xcode 15 上啟動(dòng)打包的問(wèn)題終究是要解決的，于是五一回來(lái)之后我又馬不停蹄地迭代這個(gè) APP，以讓它能在 Xcode 15 上跑起來(lái)，好在運(yùn)氣比較好，經(jīng)過(guò)一番魔改（之后會(huì)提到）終于跑起來(lái)了。

四年對(duì)一個(gè)項(xiàng)目其實(shí)說(shuō)長(zhǎng)也長(zhǎng)，說(shuō)短也短，理論上像 Java 開(kāi)發(fā)的項(xiàng)目，由于 JDK 通常設(shè)計(jì)為向后兼容的（兼容老版本），老項(xiàng)目通常能跑起來(lái)，為啥我們的這個(gè) iOS 項(xiàng)目會(huì)有這樣在最新版 Xcode 15 上跑不起來(lái)的問(wèn)題呢。

主要原因其實(shí)是因?yàn)檫@個(gè)項(xiàng)目的 Pod（iOS 項(xiàng)目中的 Pod 類(lèi)似 Java 中 Maven 管理的第三方依賴(lài)庫(kù)）不少是由 Swift 開(kāi)發(fā)（蘋(píng)果 2014 年推出的編程語(yǔ)言），這些 Pod 庫(kù)中有不少引用 OC（Objective-C，蘋(píng)果系之前的主流開(kāi)發(fā)語(yǔ)言）的代碼。

在之前的 Xcode 中，工程是可以跑起來(lái)的，但是最新的 Xcode 15 對(duì)編譯器等做了大量的的修改導(dǎo)致這些 Pod 都無(wú)法編譯通過(guò)了，然后就跑不起來(lái)了，試了網(wǎng)上各種方法都不行。

這事其實(shí)很要命，試想如果發(fā)現(xiàn)線上有個(gè) bug 需要緊急修復(fù)（比如無(wú)法提現(xiàn)），然后你的 app 卻無(wú)法打包導(dǎo)致短時(shí)間內(nèi)無(wú)法修復(fù)，很可能導(dǎo)致用戶(hù)流失，業(yè)務(wù)停滯甚至公司倒閉的嚴(yán)重后果。

假使我們當(dāng)時(shí)的技術(shù)人員統(tǒng)一在工程中都用 OC，而不是用 Swift 來(lái)寫(xiě)代碼，那壓根就不會(huì)出現(xiàn)這樣的問(wèn)題，如果一定要用 Swift，至少要等到 ABI 穩(wěn)定之后再用。

「這里簡(jiǎn)單解釋一下什么是 ABI 穩(wěn)定：想象一下，有一座橋，這座橋連接了兩座島嶼：一個(gè)島是 Swift 語(yǔ)言自身，另一個(gè)島則是操作系統(tǒng)，比如 macOS 或 iOS。這座橋就像是一個(gè)協(xié)議，確保兩邊可以互相理解和交流。在軟件的世界里，這座橋就是“應(yīng)用程序二進(jìn)制接口”（Application Binary Interface，簡(jiǎn)稱(chēng) ABI）。

Swift 的 ABI 穩(wěn)定性可以比作這座橋的結(jié)構(gòu)變得堅(jiān)固且不再改變。初期，Swift 還在不斷發(fā)展，這座橋每隔一段時(shí)間就需要重建一次，這意味著開(kāi)發(fā)者如果使用了新版本的 Swift，他們可能需要重新編譯他們的應(yīng)用程序，以確保它能在新橋上運(yùn)行?！?/p>

Swift 作為一種新技術(shù)，其實(shí)還是存在不少坑的，手淘也是在 ABI 穩(wěn)定后才開(kāi)始在項(xiàng)目中引入 Swift 的，這就好比 JDK 22 出來(lái)了，但國(guó)內(nèi)大部分還是使用的 Java 8。

為什么會(huì)出現(xiàn)這種「你升任你升，我用 Java 8」的場(chǎng)景呢，還不是出于穩(wěn)定性考慮。

任何新技術(shù)的引入都要考慮以下幾個(gè)因素：

1. 新技術(shù)對(duì)開(kāi)發(fā)效率/程序性能的提升是否顯著
2. 對(duì)此新技術(shù)熟悉的人是否足夠多（人員足夠多意味著方便交接，方便定位問(wèn)題，方便開(kāi)發(fā)功能）
3. 新技術(shù)從短期或長(zhǎng)期來(lái)看對(duì)業(yè)務(wù)是否穩(wěn)定

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

其實(shí)我們這個(gè)項(xiàng)目雖然還未等 ABI 穩(wěn)定就引入了 Swift，但當(dāng)時(shí)公司的發(fā)展如日中天，有幾十號(hào) iOS，也有好幾位 iOS 架構(gòu)師，所以工程一旦有啥技術(shù)問(wèn)題，基本也能輕易解決。

但后來(lái)公司業(yè)務(wù)急轉(zhuǎn)直下，iOS 團(tuán)隊(duì)被裁或離職導(dǎo)致一個(gè)不剩，后來(lái)公司徹底轉(zhuǎn)型，干掉了所有的技術(shù)，你沒(méi)看錯(cuò)，iOS 開(kāi)發(fā)全都沒(méi)了（你說(shuō)這種情況誰(shuí)能想到）。

那這時(shí)之前在項(xiàng)目中引入的 Swift 就成為了一顆隨時(shí)會(huì)引爆的定時(shí)炸彈，后患無(wú)窮。

所以現(xiàn)在回頭看，Swift 如果未在 ABI 穩(wěn)定前被引入，一直用的 OC，那壓根不會(huì)有這樣的問(wèn)題。

之前有人吐嘈銀行技術(shù)棧太過(guò)陳舊，如相比于互聯(lián)網(wǎng)普遍采用的 JSON, 銀行的數(shù)據(jù)格式大都是萬(wàn)能不變的 XML 等。

其實(shí)對(duì)于銀行來(lái)說(shuō)可以理解，畢竟是金融，要以穩(wěn)定為主，重構(gòu)幾下代碼是好看了，但由于歷史遺留問(wèn)題可能會(huì)有技術(shù)債，一不小心出現(xiàn)問(wèn)題如金額對(duì)不了的問(wèn)題就悲劇了，所以真的別炫技術(shù)，技術(shù)這東西夠用就行！

最后，問(wèn)題已經(jīng)出現(xiàn)了，抱怨解決不了問(wèn)題，那我們?cè)撊绾谓鉀Q呢？

這里我想簡(jiǎn)單介紹一下我是如何修改以讓老項(xiàng)目在 Xcode 15 上跑起來(lái)的。

其實(shí)運(yùn)行一個(gè)項(xiàng)目與大家熟悉一個(gè)項(xiàng)目或者說(shuō)業(yè)務(wù)的思路都是相通的，抓大放小, 抓主線，跑通主流程，細(xì)枝末節(jié)之后再看。

老項(xiàng)目無(wú)法在最新的 Xcode 15 上跑主要原因是 Pod 中的 Swift 引用了 OC 中的類(lèi)，那我可以先注釋這些邏輯，等跑通后再看看怎么優(yōu)化。

再比如有個(gè)防反編譯的第三方庫(kù)，發(fā)現(xiàn)它的存在也會(huì)導(dǎo)致項(xiàng)目無(wú)法啟動(dòng)，怎么也繞不過(guò)去，于是直接把它干掉，安全，相比于 app 不能啟動(dòng)這事不是那么重要，這問(wèn)題可以等 app 跑起來(lái)后再想辦法補(bǔ)。

碰到難題，不要想著硬碰硬，可以繞過(guò)去的，千萬(wàn)不要在細(xì)枝末節(jié)上死磕，撿了芝麻，丟了西瓜。

此外碰到問(wèn)題千萬(wàn)不要慌，要冷靜分析，比如項(xiàng)目在 Xcode 15 跑起來(lái)后，我發(fā)現(xiàn)幾個(gè) weex（一種跨平臺(tái)框架）頁(yè)面的展示有些錯(cuò)亂，如下：

圖片

看到這個(gè)頁(yè)面第一眼我想的是得用 H5 來(lái)重構(gòu)了，但用 H5 重構(gòu)，工作量比較大，有沒(méi)其他的方法？

我發(fā)現(xiàn)這個(gè)頁(yè)面其實(shí)并不是每個(gè) UI 都是錯(cuò)亂的，只是少數(shù)幾個(gè) UI 的渲染有問(wèn)題，那就可以分析一下這幾個(gè)出問(wèn)題的 UI 和其他正常顯示的 UI 在 weex 的寫(xiě)法有哪些區(qū)別，于是經(jīng)過(guò)分析發(fā)現(xiàn)是三元運(yùn)算符還有 text 的寫(xiě)法有區(qū)別，經(jīng)過(guò)改造，問(wèn)題就解決了，相比于使用 H5 來(lái)重構(gòu)的時(shí)間，這點(diǎn)時(shí)間幾乎可以忽略不計(jì)。