周三下午，一個(gè)開發(fā)者把他寫的新聞客戶端的源碼倉庫設(shè)成了公開。不是那種“僅供學(xué)習(xí)”的演示項(xiàng)目——這個(gè)應(yīng)用已經(jīng)上架Google Play，用的是一個(gè)Compose Multiplatform代碼庫，所有屏幕都寫在commonMain里，沒有一行平臺(tái)專屬的界面代碼。他在項(xiàng)目說明里寫得很直白：“這是一份誠實(shí)的實(shí)戰(zhàn)報(bào)告，關(guān)于在生產(chǎn)環(huán)境里這么做到底要付出什么代價(jià)?！?/p>

倉庫是MIT協(xié)議開源的，這意味著里面每一行代碼、每一個(gè)決策都可以被核實(shí)。開發(fā)者給這份報(bào)告起了個(gè)名字，叫“97%的應(yīng)用代碼在commonMain里”。96.9%的共享模塊是這個(gè)數(shù)字的精確值——這不是估算，是從代碼統(tǒng)計(jì)工具里直接拉出來的數(shù)據(jù)。

那剩下的3%在哪里？答案不是“散布在各處”。平臺(tái)相關(guān)的代價(jià)被集中收攏在約10個(gè)expect/actual接口上，開發(fā)者在報(bào)告里列了一份完整的清單：應(yīng)用版本號(hào)、系統(tǒng)語言、User-Agent字符串這些平臺(tái)信息是一類；打開外部鏈接、打開系統(tǒng)設(shè)置、拉起系統(tǒng)分享菜單這些系統(tǒng)交互是第二類；埋點(diǎn)上報(bào)是一個(gè)單獨(dú)的trackEvent鉤子，安卓端對(duì)接了Aptabase，iOS端目前刻意留空；最后一個(gè)是WebView——開發(fā)者在這條后面加了個(gè)括號(hào)，寫的是“這個(gè)最麻煩”。

所有17個(gè)屏幕全部駐留在commonMain里。熱榜列表、聚合資訊流、README詳情頁、帶分頁的個(gè)人主頁、設(shè)置頁、收藏頁——沒有一個(gè)地方需要寫“if (isAndroid)”這種分支判斷。報(bào)告里特別強(qiáng)調(diào)了一點(diǎn)：凡是碰了平臺(tái)API的代碼，體量都很小，而且可以被一一枚舉。剩下的東西，按照他的說法，“都是白送的”。

為什么選expect/actual機(jī)制而不是接口加依賴注入？開發(fā)者在報(bào)告里給出了一個(gè)有意思的解釋。對(duì)于這大約10個(gè)接縫來說，expect/actual的方案“儀式感最少”——不需要搭依賴注入的架子，而且編譯器會(huì)在每個(gè)平臺(tái)都實(shí)現(xiàn)聲明之前拒絕構(gòu)建，這變成了一種強(qiáng)制性的安全檢查。但他也劃出了一條清晰的界限：一旦某個(gè)接縫有了不止一個(gè)實(shí)現(xiàn)，或者想在測試?yán)镒鰉ock，那么在commonMain里定義接口然后注入實(shí)現(xiàn)就立刻變成更好的選擇。他的判斷是，對(duì)于一套數(shù)量固定、職責(zé)明確的平臺(tái)基礎(chǔ)能力，expect/actual在摩擦成本上勝出。

WebView被單獨(dú)拎出來做了重點(diǎn)解剖，開發(fā)者寫得很精確，因?yàn)榇a就擺在那里。報(bào)告里描述了兩條路徑。第一條是渲染GitHub的README文件，從一個(gè)HTML字符串開始，用內(nèi)聯(lián)的expect/actual封裝了Android的WebView和iOS的WKWebView，禁用JavaScript，通過注入CSS顏色變量來保證亮色和暗色模式的一致性。這條路徑每個(gè)平臺(tái)大約30到50行代碼。第二條是在應(yīng)用內(nèi)打開外部鏈接，這一塊復(fù)雜得多，生命周期管理、配置文件處理、文件選擇器、媒體采集、標(biāo)題管理這些細(xì)節(jié)堆在一起，已經(jīng)臃腫到配得上擁有自己的獨(dú)立倉庫。所以開發(fā)者把它抽成了一個(gè)叫kmp-webview的獨(dú)立庫。他在報(bào)告的這段末尾寫了一句很坦誠的話：“如果你曾經(jīng)把WKWebView和Android WebView封裝到一個(gè)共通的Composable組件后面，我真心歡迎你對(duì)這個(gè)庫的API做個(gè)合理性檢查?！?/p>

應(yīng)用在安卓端的狀況是“舒適地達(dá)到了生產(chǎn)可用”，Google Play上可以下載到。iOS端所有Compose界面都能在模擬器里編譯和渲染，但開發(fā)者的用詞是“還沒打磨完”。報(bào)告里列了三個(gè)具體問題：iPad上分享功能會(huì)崩潰，因?yàn)闆]有設(shè)置popoverPresentationController的錨點(diǎn)，代碼里留著一個(gè)明晃晃的TODO；iOS端還沒有接入數(shù)據(jù)埋點(diǎn)；AI對(duì)話界面目前只有安卓版。他的原話是，“不是畫餅，只是還沒發(fā)布?！?/p>

真正讓跨平臺(tái)稅顯現(xiàn)出來的，不是共享代碼本身，而是圍繞iOS的工具鏈。報(bào)告里提到，開發(fā)者不得不接受Xcode作為殼工程的存在，而iOS端的干凈構(gòu)建速度比安卓慢得多。這句話沒有展開，但對(duì)任何一個(gè)做過移動(dòng)端跨平臺(tái)開發(fā)的人來說，它指向的那種體驗(yàn)是具體的：在某個(gè)下午，你改了commonMain里的一行代碼，然后坐在那里等著Xcode慢慢把Kotlin編譯成Objective-C的橋接層，再慢慢鏈接成IPA包。KMP稅這個(gè)詞在開發(fā)者社區(qū)里通常指接口設(shè)計(jì)上的妥協(xié)，但這篇報(bào)告暗示了一個(gè)更實(shí)際的痛點(diǎn)——它就是編譯等待時(shí)間本身。

報(bào)告最后的狀態(tài)是：對(duì)于內(nèi)容/列表/詳情這類應(yīng)用模式，Compose Multiplatform在安卓端已經(jīng)可以放心上生產(chǎn)。iOS端能用，但離“打磨完”還有距離。那3%的平臺(tái)代碼是可以在清單里一一指出的，不是散落在代碼庫各處的地雷。WebView仍然是整個(gè)方案里最不優(yōu)雅的一塊，而開發(fā)者對(duì)這塊的態(tài)度不是“已解決”，是“歡迎來挑毛病”。