差異到底怎么設(shè)計(jì)？從日志導(dǎo)出重構(gòu)看擴(kuò)展函數(shù)、interface 與 expect/actual)
在 KMP 項(xiàng)目里做到一定階段后很容易遇到一個(gè)問(wèn)題同一個(gè)功能Android 和 iOS 的底層實(shí)現(xiàn)完全不同到底應(yīng)該怎么處理常見(jiàn)方案似乎有很多。比如expect / actual或者commonMain 定義 interface androidMain / iosMain 提供實(shí)現(xiàn)類又或者直接在平臺(tái)層寫fun AppLogger.exportLogs(...)這種擴(kuò)展函數(shù)。它們看起來(lái)都在解決“跨平臺(tái)差異”所以非常容易混在一起。但實(shí)際上這幾種設(shè)計(jì)根本不是一個(gè)維度的問(wèn)題。而且在實(shí)際項(xiàng)目繼續(xù)重構(gòu)以后我還發(fā)現(xiàn)另外一個(gè)很容易忽略的問(wèn)題即使擴(kuò)展函數(shù)本身沒(méi)有問(wèn)題也不代表這個(gè)函數(shù)就應(yīng)該擴(kuò)展在某個(gè)對(duì)象上。這篇文章就以一個(gè)真實(shí)的 KMP Logger 日志導(dǎo)出功能為例從最開(kāi)始的AppLogger.exportLogs()一路講到最終的exportLogs(...)把Source Set 擴(kuò)展函數(shù) 頂層函數(shù) interface 多態(tài) expect / actual這些設(shè)計(jì)徹底串起來(lái)。一、先看第一版設(shè)計(jì)最開(kāi)始我們希望業(yè)務(wù)層導(dǎo)出日志時(shí)足夠簡(jiǎn)單。iOSAppLogger.exportLogs()AndroidAppLogger.exportLogs(context)看起來(lái)好像AppLogger自己知道當(dāng)前運(yùn)行的是 Android 還是 iOS。其實(shí)完全不是。這里沒(méi)有if (isAndroid) { ... } else if (isIos) { ... }真正決定平臺(tái)的是 KMP Source Set。例如commonMain androidMain iosMain編譯 Android Target 時(shí)commonMain androidMain編譯 iOS Target 時(shí)commonMain iosMain因此Android 看不到 iosMain iOS 看不到 androidMain所以 Android 可以擁有AppLogger.exportLogs(context)iOS 可以擁有AppLogger.exportLogs()兩套代碼互不沖突。這也是理解后面所有設(shè)計(jì)的基礎(chǔ)。但是這里需要特別注意Source Set 只能說(shuō)明這種代碼“可以正確工作”并不能說(shuō)明AppLogger.exportLogs()就一定是最合理的 API 設(shè)計(jì)。這兩個(gè)問(wèn)題要分開(kāi)看。二、第一版為什么會(huì)寫成 AppLogger.exportLogs()先看 iOS 第一版suspend fun AppLogger.exportLogs( config: LogExportConfig LogExportConfig(), ): ExportedLogFile exportLogs(createLogExporter(config))這段代碼定義在iosMain真正創(chuàng)建導(dǎo)出器的是fun createLogExporter( config: LogExportConfig LogExportConfig(), ): LogExporter LogExporter( IosLogExportStorage(iosLogDirectory()), config, )也就是說(shuō)AppLogger.exportLogs()本身并沒(méi)有實(shí)現(xiàn)讀取日志文件 寫 ZIP 刪除舊 ZIP 獲取文件大小這些底層能力。它主要承擔(dān)的是提供一個(gè)方便調(diào)用的入口 創(chuàng)建當(dāng)前平臺(tái)需要的對(duì)象Android 也是一樣fun createLogExporter( context: Context, config: LogExportConfig LogExportConfig(), ): LogExporter { val logDirectory File(androidLogDirectory(context.applicationContext)) return LogExporter( AndroidLogExportStorage(logDirectory), config, ) }因此第一版可以理解為iOS AppLogger.exportLogs() ↓ createLogExporter() ↓ IosLogExportStorage Android AppLogger.exportLogs(context) ↓ createLogExporter(context) ↓ AndroidLogExportStorage從“平臺(tái)差異怎么隔離”的角度來(lái)說(shuō)這個(gè)設(shè)計(jì)是成立的。真正的問(wèn)題出現(xiàn)在另外一個(gè)維度exportLogs()真的是AppLogger自己的職責(zé)嗎三、擴(kuò)展函數(shù)不是一種跨平臺(tái)機(jī)制這一點(diǎn)非常重要。很多人看到fun AppLogger.exportLogs()會(huì)下意識(shí)覺(jué)得這是 KMP 處理平臺(tái)差異的一種方式。其實(shí)不是。Kotlin 擴(kuò)展函數(shù)本質(zhì)上只是fun exportLogs(logger: AppLogger)換了一種調(diào)用形式AppLogger.exportLogs()所以擴(kuò)展函數(shù) ≠ 平臺(tái)抽象機(jī)制真正讓 Android 和 iOS 使用不同實(shí)現(xiàn)的是androidMain iosMain而不是擴(kuò)展函數(shù)。擴(kuò)展函數(shù)解決的是API 最終以什么形式暴露給調(diào)用者。例如Throwable.toAppError()和toAppError(throwable)能力上沒(méi)有本質(zhì)區(qū)別。前一種只是表達(dá)得更加自然。但擴(kuò)展函數(shù)還有第二個(gè)問(wèn)題以前我們只問(wèn)用擴(kuò)展函數(shù)調(diào)用是不是更方便繼續(xù)重構(gòu)以后發(fā)現(xiàn)這還不夠。還應(yīng)該繼續(xù)問(wèn)這個(gè)操作真的屬于 receiver 嗎例如Throwable.toAppError()非常合理。因?yàn)檎麄€(gè)操作圍繞Throwable展開(kāi)Throwable ↓ 轉(zhuǎn)換 ↓ AppError所以把它寫成throwable.toAppError()語(yǔ)義很自然。但是AppLogger.exportLogs()就不太一樣了。日志導(dǎo)出真正的流程其實(shí)是AppLogger.flush() ↓ LogExporter.export() ↓ LogExportStorageAppLogger在這里僅僅負(fù)責(zé)flush它只是整個(gè)日志導(dǎo)出流程中的一個(gè)參與者。真正負(fù)責(zé)日志篩選 ZIP 壓縮 日志文件讀取 舊文件清理 導(dǎo)出結(jié)果生成的是LogExporter。因此AppLogger.exportLogs()雖然寫起來(lái)方便卻容易給人一種錯(cuò)覺(jué)日志導(dǎo)出是 AppLogger 自己的能力。這就是第一版 API 最終被調(diào)整的原因。四、最終為什么改成頂層 exportLogs()最終 Common 層的日志導(dǎo)出入口改成suspend fun exportLogs( exporter: LogExporter, ): ExportedLogFile { AppLogger.flush() return exporter.export() }這段代碼非常簡(jiǎn)單。先AppLogger.flush()確保 Logger 當(dāng)前隊(duì)列中的日志已經(jīng)完成寫入。然后exporter.export()正式執(zhí)行導(dǎo)出流程。這里和之前最大的變化不是代碼量。而是調(diào)用形式終于和真實(shí)職責(zé)對(duì)齊了。以前AppLogger.exportLogs(exporter)看起來(lái)像AppLogger ↓ 擁有 exportLogs 能力現(xiàn)在exportLogs(exporter)表達(dá)的是這是一個(gè)“日志導(dǎo)出流程” 它會(huì)協(xié)調(diào) AppLogger LogExporter所以它更像一個(gè)流程協(xié)調(diào)函數(shù)。五、為什么流程協(xié)調(diào)適合頂層函數(shù)繼續(xù)看suspend fun exportLogs( exporter: LogExporter, ): ExportedLogFile { AppLogger.flush() return exporter.export() }它沒(méi)有自己的狀態(tài)。也沒(méi)有復(fù)雜生命周期。更沒(méi)有一個(gè)需要替換的“ExportLogs 實(shí)現(xiàn)”。它只是flush ↓ export因此沒(méi)有必要為了它再創(chuàng)建object LogExportCoordinator也沒(méi)有必要class LogExportService更沒(méi)有必要interface LogExportService class DefaultLogExportService一個(gè)普通頂層函數(shù)已經(jīng)可以準(zhǔn)確表達(dá)它的職責(zé)。這也是一個(gè)很實(shí)用的設(shè)計(jì)判斷如果一段邏輯只是協(xié)調(diào)已有能力而且自身沒(méi)有狀態(tài)、生命周期和新的變化點(diǎn)普通函數(shù)往往就是最簡(jiǎn)單、最準(zhǔn)確的設(shè)計(jì)。六、Android / iOS 平臺(tái)入口還存在嗎存在。刪除AppLogger.exportLogs()并不意味著平臺(tái)差異消失了。Android 仍然可以提供suspend fun exportLogs( context: Context, config: LogExportConfig LogExportConfig(), ): ExportedLogFile { return exportLogs( createLogExporter( context context, config config, ) ) }iOSsuspend fun exportLogs( config: LogExportConfig LogExportConfig(), ): ExportedLogFile { return exportLogs( createLogExporter(config) ) }于是業(yè)務(wù)調(diào)用變成AndroidexportLogs(context)iOSexportLogs()注意這里平臺(tái)差異的處理方式和以前沒(méi)有任何本質(zhì)變化。依然是Android 編譯 androidMain iOS 編譯 iosMain變化的只是以前 把 exportLogs 掛到 AppLogger 上 現(xiàn)在 exportLogs 作為獨(dú)立流程入口也就是說(shuō)Source Set 解決平臺(tái)代碼放在哪里。頂層函數(shù)還是擴(kuò)展函數(shù)解決 API 怎么表達(dá)。兩者完全不是一件事。七、真正的公共業(yè)務(wù)邏輯在哪里平臺(tái)入口最終都會(huì)創(chuàng)建LogExporterLogExporter定義在commonMain核心結(jié)構(gòu)類似class LogExporter internal constructor( private val storage: LogExportStorage, private val config: LogExportConfig, )注意最關(guān)鍵的一行private val storage: LogExportStorageLogExporter并不依賴IosLogExportStorage也不依賴AndroidLogExportStorage它依賴的是LogExportStorage這個(gè)公共接口。然后exporter.export()開(kāi)始執(zhí)行公共日志導(dǎo)出流程。例如val sourceFiles storage.listLogFiles() .filter { it.name.endsWith(LOG_EXTENSION) } .sortedBy(ExportSourceFile::name)然后創(chuàng)建 ZIPval output storage.openExport(fileName) val zip ZipArchiveWriter(output, timeZone)讀取日志sourceFiles.forEach { file - zip.add(file) { consume - storage.readLogFile(file, consume) } }最終返回ExportedLogFile( path storage.exportPath(fileName), fileName fileName, sizeBytes storage.exportSize(fileName), logFileCount sourceFiles.size, )這里有個(gè)非常漂亮的地方。LogExporter知道我要找日志 我要篩選日志 我要讀取日志 我要生成 ZIP 我要清理舊 ZIP 我要返回導(dǎo)出結(jié)果但它完全不知道Android 到底怎么讀文件 iOS 到底怎么讀文件這就是公共業(yè)務(wù)邏輯和平臺(tái)能力真正分開(kāi)的地方。八、interface 到底在哪里發(fā)揮作用很多人第一次看這種設(shè)計(jì)時(shí)容易繞進(jìn)去。調(diào)用鏈大概是exportLogs() ↓ LogExporter.export() ↓ storage.listLogFiles()然后就會(huì)疑惑LogExportStorage到底在哪里被調(diào)用了其實(shí)LogExportStorage不是一個(gè)需要“調(diào)用”的對(duì)象工廠。它是LogExporter持有的依賴。也就是說(shuō)interface 在對(duì)象創(chuàng)建階段就已經(jīng)被注入進(jìn)去了。比如 iOSLogExporter( IosLogExportStorage(iosLogDirectory()), config, )把代碼展開(kāi)val iosStorage IosLogExportStorage(iosLogDirectory()) val storage: LogExportStorage iosStorage val exporter LogExporter( storage storage, config config, )這時(shí)LogExporter只知道storage 是 LogExportStorage它并不知道 storage 實(shí)際上是IosLogExportStorage九、平臺(tái)差異其實(shí)是在 createLogExporter() 完成注入這就是整個(gè)設(shè)計(jì)非常關(guān)鍵的位置。iOSLogExporter( IosLogExportStorage(...), config, )AndroidLogExporter( AndroidLogExportStorage(...), config, )而LogExporter要求的只是LogExportStorage因此形成LogExporter │ │ 依賴 ▼ LogExportStorage interface / \ / \ ▼ ▼ AndroidLogExportStorage IosLogExportStorage也就是說(shuō)LogExporter這個(gè)公共業(yè)務(wù)組件不依賴任何具體平臺(tái)實(shí)現(xiàn)。平臺(tái)實(shí)現(xiàn)反過(guò)來(lái)實(shí)現(xiàn)它要求的抽象。這就是非常典型的依賴倒置。十、為什么調(diào)用 interface 最終會(huì)進(jìn)入 iOS 實(shí)現(xiàn)假設(shè)當(dāng)前運(yùn)行的是 iOS。創(chuàng)建對(duì)象時(shí)val storage: LogExportStorage IosLogExportStorage(...)變量類型是LogExportStorage但真正保存的對(duì)象是IosLogExportStorage所以storage.listLogFiles()最終執(zhí)行IosLogExportStorage.listLogFiles()同理storage.readLogFile(...)最終進(jìn)入IosLogExportStorage.readLogFile(...)iOS 里面可能真正使用NSFileManager fopen fread fwriteAndroid 里面則可能使用File FileInputStream FileOutputStream BufferedInputStream BufferedOutputStream這一點(diǎn)其實(shí)并不屬于 KMP 特有機(jī)制。本質(zhì)上就是普通的interface 多態(tài)。十一、完整調(diào)用鏈終于可以串起來(lái)了現(xiàn)在以 iOS 為例。最終結(jié)構(gòu)業(yè)務(wù)層 │ ▼ exportLogs() │ │ iosMain 平臺(tái)便捷入口 ▼ createLogExporter(config) │ ├──────────── 創(chuàng)建 ────────────? IosLogExportStorage │ │ │ │ implements │ ▼ │ LogExportStorage │ ▼ LogExporter(storage, config) │ ▼ commonMain exportLogs(exporter) │ ├── AppLogger.flush() │ ▼ exporter.export() │ ├── storage.listLogFiles() ├── storage.openExport() ├── storage.readLogFile() ├── storage.listExportFiles() ├── storage.deleteExport() ├── storage.exportPath() └── storage.exportSize() │ ▼ 實(shí)際進(jìn)入 IosLogExportStorage │ ▼ NSFileManager / fopen / fread / fwriteAndroid 完全一樣exportLogs(context) ↓ createLogExporter(context) ↓ AndroidLogExportStorage ↓ LogExporter ↓ commonMain exportLogs(exporter) ↓ AppLogger.flush() ↓ exporter.export() ↓ storage.xxx() ↓ AndroidLogExportStorage.xxx() ↓ File / InputStream / OutputStream到這里整個(gè)調(diào)用鏈就非常清楚了。十二、現(xiàn)在整個(gè)日志導(dǎo)出實(shí)際上可以看成四層把前面的代碼壓縮以后可以分成四層。第一層平臺(tái)便捷入口 / 裝配層AndroidexportLogs(context)iOSexportLogs()職責(zé)給調(diào)用方提供簡(jiǎn)單入口 創(chuàng)建當(dāng)前平臺(tái) LogExporter這部分放在androidMain iosMain第二層流程協(xié)調(diào)層exportLogs(exporter)職責(zé)非常簡(jiǎn)單AppLogger.flush() ↓ LogExporter.export()它只是協(xié)調(diào)已有能力。因此使用頂層函數(shù)就夠了。第三層公共業(yè)務(wù)層LogExporter職責(zé)篩選日志 生成文件名 壓縮 ZIP 異常處理 清理舊文件 生成 ExportedLogFile這些邏輯 Android 和 iOS 基本一致。所以放commonMain第四層平臺(tái)能力層公共接口LogExportStorage它定義我要能夠 列日志 讀日志 創(chuàng)建導(dǎo)出文件 刪除導(dǎo)出文件 獲取文件路徑 獲取文件大小至于怎么實(shí)現(xiàn)由AndroidLogExportStorage IosLogExportStorage負(fù)責(zé)。十三、那什么時(shí)候應(yīng)該用 expect / actual理解完interface后再來(lái)看expect/actual就簡(jiǎn)單很多。假設(shè) commonMain 需要platformProcessName()但Android 獲取進(jìn)程名 和 iOS 獲取進(jìn)程名實(shí)現(xiàn)完全不同?？梢詫?/ commonMain expect fun platformProcessName(): StringAndroidactual fun platformProcessName(): String { ... }iOSactual fun platformProcessName(): String { ... }形成commonMain │ ▼ platformProcessName() │ expect / \ ▼ ▼ Android iOS actual actual這種方案比較適合平臺(tái)名稱 系統(tǒng)版本 進(jìn)程名 線程信息 簡(jiǎn)單系統(tǒng)信息 簡(jiǎn)單目錄查詢特點(diǎn)是commonMain 直接需要一個(gè)平臺(tái)能力而且能力本身比較簡(jiǎn)單、固定。十四、為什么 LogExportStorage 更適合 interface日志存儲(chǔ)就不一樣了。它已經(jīng)包含很多能力listLogFiles readLogFile openExport exportPath exportSize listExportFiles deleteExport它本質(zhì)上已經(jīng)是一個(gè)完整組件。這種情況下interface LogExportStorage會(huì)比把所有方法做成expect/actual更合適。第一可以測(cè)試?yán)鏲lass FakeLogExportStorage : LogExportStorage { ... }然后LogExporter( FakeLogExportStorage(), config, )Common Test 不需要真的訪問(wèn) Android 或 iOS 文件系統(tǒng)。第二可以替換以后甚至可以MemoryLogExportStorage DesktopLogExportStorage TestLogExportStorage而LogExporter完全不需要修改。第三符合依賴倒置LogExporter 不依賴 AndroidLogExportStorage IosLogExportStorage 而是依賴 LogExportStorage公共業(yè)務(wù)層只認(rèn)識(shí)抽象。十五、為什么 uploadLogs() 也不應(yīng)該掛在 AppLogger 上日志上傳的情況其實(shí)更加明顯。如果寫AppLogger.uploadLogs(...)看起來(lái)會(huì)像AppLogger 自己具有日志上傳能力。但真正流程其實(shí)是AppLogger.flush() ↓ LogExporter.export() ↓ LogUploader.upload()它至少涉及三個(gè)角色AppLogger LogExporter LogUploader所以這里更不應(yīng)該強(qiáng)行選擇AppLogger作為 receiver。最終 Common 層可以直接寫suspend fun uploadLogs( exporter: LogExporter, uploader: LogUploader, metadata: LogUploadMetadata LogUploadMetadata(), ): LogUploadResult它表達(dá)得非常明確uploadLogs 是一個(gè)流程協(xié)調(diào)入口。它會(huì)協(xié)調(diào)Logger Exporter Uploader完成整個(gè)日志上傳流程。十六、為什么不再造一個(gè) LogService看到這里可能還會(huì)產(chǎn)生一個(gè)想法既然已經(jīng)有exportLogs(...) uploadLogs(...)是不是可以再封一層interface LogService { suspend fun exportLogs(): ExportedLogFile suspend fun uploadLogs(): LogUploadResult }然后class DefaultLogService( private val exporter: LogExporter, private val uploader: LogUploader, ) : LogService看起來(lái)似乎更加“架構(gòu)化”。但目前沒(méi)有這個(gè)必要。因?yàn)轫?xiàng)目已經(jīng)有兩個(gè)真正穩(wěn)定的能力抽象LogExporter → 怎么導(dǎo)出日志 LogUploader → 怎么上傳日志而uploadLogs()只是flush ↓ export ↓ upload它本身并沒(méi)有出現(xiàn)一個(gè)新的獨(dú)立變化點(diǎn)。如果現(xiàn)在再創(chuàng)建LogService LogServiceImpl LogCoordinator只是給已有接口再包一層接口層數(shù)增加了職責(zé)卻沒(méi)有增加。接口不是為了“架構(gòu)完整”這是這里非常重要的一個(gè)判斷。我們創(chuàng)建LogExportStorage是因?yàn)锳ndroid 文件系統(tǒng) 和 iOS 文件系統(tǒng)確實(shí)存在不同實(shí)現(xiàn)。我們保留LogUploader是因?yàn)樯蟼鲗?shí)現(xiàn)本身可以替換 Fake 測(cè)試 組合所以這里存在穩(wěn)定能力邊界。但是uploadLogs()只是現(xiàn)有能力的流程編排。因此接口是為了隔離變化、定義穩(wěn)定能力邊界而不是為了給每一段流程都套一個(gè) Service。十七、頂層函數(shù)、擴(kuò)展函數(shù)、interface、expect/actual 到底怎么選現(xiàn)在可以重新整理成兩個(gè)維度。這是整篇文章最重要的地方。第一個(gè)維度平臺(tái)差異怎么處理首先問(wèn)commonMain 是否需要這個(gè)平臺(tái)能力如果不需要比如打開(kāi) Android Activity 調(diào)用 iOS UIViewController Android 分享 Intent 某個(gè)平臺(tái)獨(dú)有 UI直接放androidMain iosMain即可。不一定需要expect / actual也不一定需要interface平臺(tái)層自己實(shí)現(xiàn)就夠了。如果 commonMain 需要繼續(xù)問(wèn)這是一個(gè)簡(jiǎn)單、固定的平臺(tái)能力嗎如果是平臺(tái)名 系統(tǒng)版本 進(jìn)程名 線程名 簡(jiǎn)單目錄可以考慮expect / actual如果已經(jīng)是文件存儲(chǔ) 數(shù)據(jù)庫(kù) KeyValue Storage Logger Sink LogExportStorage Crash 能力 設(shè)備通信而且要求可測(cè)試 可替換 可注入優(yōu)先考慮interface 平臺(tái)實(shí)現(xiàn)因此平臺(tái)抽象可以先這樣判斷出現(xiàn)平臺(tái)差異 │ ▼ commonMain 是否需要 │ ┌──┴──┐ │ │ 否 是 │ │ ▼ ▼ 平臺(tái)層 是否簡(jiǎn)單、固定 直接寫 │ ┌──┴──┐ │ │ 是 否 │ │ ▼ ▼ expect/actual 是否是完整組件 │ ▼ interface 平臺(tái)實(shí)現(xiàn)第二個(gè)維度API 最終怎么表達(dá)完成平臺(tái)抽象以后再問(wèn)另外一個(gè)問(wèn)題這個(gè)操作真正屬于某個(gè)對(duì)象本身嗎如果屬于可以考慮成員函數(shù) 或者 擴(kuò)展函數(shù)例如throwable.toAppError()非常自然。如果這個(gè)操作不屬于任何一個(gè)參與者而是在協(xié)調(diào)多個(gè)能力例如AppLogger.flush() LogExporter.export() LogUploader.upload()那么更加適合普通函數(shù) 或者 頂層函數(shù)所以第二個(gè)判斷圖可以寫成這個(gè)操作屬于某個(gè)對(duì)象本身嗎 │ ┌──┴──┐ │ │ 是 否 │ │ ▼ ▼ 成員函數(shù) / 是否協(xié)調(diào)多個(gè)能力 擴(kuò)展函數(shù) │ ▼ 頂層函數(shù) 普通函數(shù)十八、擴(kuò)展函數(shù)和 interface、expect/actual 根本不是三選一這是整篇文章最重要的認(rèn)知之一。不要再思考擴(kuò)展函數(shù) VS expect / actual VS interface因?yàn)樗鼈兏静皇峭粚印Ｕ_的問(wèn)題應(yīng)該是第一步平臺(tái)差異是否需要暴露給 commonMain第二步如果需要 它是簡(jiǎn)單平臺(tái)能力 還是完整可替換組件決定expect / actual 還是 interface第三步最終 API 應(yīng)該怎么表達(dá)再?zèng)Q定成員函數(shù) 擴(kuò)展函數(shù) 頂層函數(shù) 普通類方法所以一個(gè)成熟的 KMP 模塊完全可能同時(shí)存在interface 平臺(tái)實(shí)現(xiàn)類 expect / actual 擴(kuò)展函數(shù) 頂層函數(shù)它們各自解決不同的問(wèn)題。十九、回到 Logger最終這套設(shè)計(jì)到底做了什么現(xiàn)在再看整個(gè) Logger 日志導(dǎo)出exportLogs() │ 平臺(tái)便捷調(diào)用入口 │ ▼ createLogExporter() │ ┌─────────┴─────────┐ │ │ ▼ ▼ AndroidLogExportStorage IosLogExportStorage │ │ └─────────┬─────────┘ │ ▼ LogExportStorage interface │ ▼ LogExporter │ ▼ commonMain exportLogs() │ ┌──────────┴──────────┐ │ │ ▼ ▼ AppLogger.flush() exporter.export() │ ▼ 公共日志導(dǎo)出流程每一層的職責(zé)都非常明確。exportLogs(context) / exportLogs()負(fù)責(zé)好不好調(diào)用 當(dāng)前平臺(tái)對(duì)象怎么創(chuàng)建createLogExporter()負(fù)責(zé)當(dāng)前平臺(tái)到底裝配 AndroidLogExportStorage 還是 IosLogExportStorageLogExportStorage負(fù)責(zé)公共業(yè)務(wù)層需要什么平臺(tái)能力Android / iOS Storage負(fù)責(zé)平臺(tái)到底怎么實(shí)現(xiàn)文件讀寫LogExporter負(fù)責(zé)公共日志導(dǎo)出業(yè)務(wù)流程怎么執(zhí)行commonMain exportLogs(exporter)負(fù)責(zé)協(xié)調(diào) AppLogger.flush() LogExporter.export()它沒(méi)有額外狀態(tài)因此頂層函數(shù)就夠了二十、這次重構(gòu)真正改的不是語(yǔ)法表面上看這次只是AppLogger.exportLogs()改成exportLogs()以及AppLogger.uploadLogs(...)改成uploadLogs(...)似乎只是少了一個(gè) receiver。但實(shí)際上真正調(diào)整的是API 的調(diào)用形式是否準(zhǔn)確表達(dá)了真實(shí)職責(zé)。以前AppLogger.exportLogs()很容易理解成AppLogger 自己負(fù)責(zé)日志導(dǎo)出現(xiàn)在exportLogs()表達(dá)的是這是一個(gè)日志導(dǎo)出流程而真正參與流程的是AppLogger LogExporter LogExportStorage同理uploadLogs()是AppLogger LogExporter LogUploader之間的協(xié)調(diào)過(guò)程。這也是為什么最終沒(méi)有繼續(xù)使用擴(kuò)展函數(shù)?？偨Y(jié)這次從最開(kāi)始的AppLogger.exportLogs()一路向下追最后實(shí)際上可以看到 KMP 架構(gòu)設(shè)計(jì)中非常核心的一套思想。可以壓縮成五句話。第一Source Set 決定平臺(tái)代碼在哪里參與編譯擴(kuò)展函數(shù)本身不是跨平臺(tái)機(jī)制。第二擴(kuò)展函數(shù)解決的是 API 表達(dá)問(wèn)題但只有當(dāng)操作真正屬于 receiver 時(shí)才自然。第三跨多個(gè)組件的無(wú)狀態(tài)流程協(xié)調(diào)更適合普通函數(shù)或頂層函數(shù)。第四expect/actual 更適合 commonMain 直接需要的簡(jiǎn)單、固定平臺(tái)能力。第五interface 平臺(tái)實(shí)現(xiàn)更適合完整、可替換、可測(cè)試的平臺(tái)組件。在這個(gè) Logger 中exportLogs()負(fù)責(zé)平臺(tái)便捷入口和流程協(xié)調(diào)LogExporter負(fù)責(zé)平臺(tái)無(wú)關(guān)的日志導(dǎo)出業(yè)務(wù)LogExportStorage負(fù)責(zé)定義公共業(yè)務(wù)層需要的平臺(tái)能力AndroidLogExportStorage IosLogExportStorage負(fù)責(zé)真正的平臺(tái)文件實(shí)現(xiàn)而AppLogger最終重新回到了它真正應(yīng)該負(fù)責(zé)的事情記錄日志 管理日志隊(duì)列 flush另外還有最后一個(gè)非常重要的經(jīng)驗(yàn)不要為了“看起來(lái)架構(gòu)完整”而給每一個(gè)流程都創(chuàng)建 Service、Coordinator 和 Impl。只有當(dāng)一個(gè)地方真正出現(xiàn)獨(dú)立變化 可替換實(shí)現(xiàn) 穩(wěn)定能力邊界 生命周期或狀態(tài)才值得繼續(xù)抽象。如果只是A ↓ B ↓ C這樣簡(jiǎn)單地協(xié)調(diào)已有能力一個(gè)清晰的函數(shù)可能就是最好的設(shè)計(jì)。當(dāng)這些職責(zé)真正分清以后再遇到 KMP 項(xiàng)目里的commonMain androidMain iosMain expect / actual interface 平臺(tái)實(shí)現(xiàn) 擴(kuò)展函數(shù) 頂層函數(shù)就不會(huì)再把它們混成一團(tuán)了。 KMP 平臺(tái)差異到底怎么設(shè)計(jì)？從日志導(dǎo)出重構(gòu)看擴(kuò)展函數(shù)、interface 與 expect/actual
在 KMP 項(xiàng)目里做到一定階段后很容易遇到一個(gè)問(wèn)題同一個(gè)功能Android 和 iOS 的底層實(shí)現(xiàn)完全不同到底應(yīng)該怎么處理常見(jiàn)方案似乎有很多。比如expect / actual或者commonMain 定義 interface androidMain / iosMain 提供實(shí)現(xiàn)類又或者直接在平臺(tái)層寫fun AppLogger.exportLogs(...)這種擴(kuò)展函數(shù)。它們看起來(lái)都在解決“跨平臺(tái)差異”所以非常容易混在一起。但實(shí)際上這幾種設(shè)計(jì)根本不是一個(gè)維度的問(wèn)題。而且在實(shí)際項(xiàng)目繼續(xù)重構(gòu)以后我還發(fā)現(xiàn)另外一個(gè)很容易忽略的問(wèn)題即使擴(kuò)展函數(shù)本身沒(méi)有問(wèn)題也不代表這個(gè)函數(shù)就應(yīng)該擴(kuò)展在某個(gè)對(duì)象上。這篇文章就以一個(gè)真實(shí)的 KMP Logger 日志導(dǎo)出功能為例從最開(kāi)始的AppLogger.exportLogs()一路講到最終的exportLogs(...)把Source Set 擴(kuò)展函數(shù) 頂層函數(shù) interface 多態(tài) expect / actual這些設(shè)計(jì)徹底串起來(lái)。一、先看第一版設(shè)計(jì)最開(kāi)始我們希望業(yè)務(wù)層導(dǎo)出日志時(shí)足夠簡(jiǎn)單。iOSAppLogger.exportLogs()AndroidAppLogger.exportLogs(context)看起來(lái)好像AppLogger自己知道當(dāng)前運(yùn)行的是 Android 還是 iOS。其實(shí)完全不是。這里沒(méi)有if (isAndroid) { ... } else if (isIos) { ... }真正決定平臺(tái)的是 KMP Source Set。例如commonMain androidMain iosMain編譯 Android Target 時(shí)commonMain androidMain編譯 iOS Target 時(shí)commonMain iosMain因此Android 看不到 iosMain iOS 看不到 androidMain所以 Android 可以擁有AppLogger.exportLogs(context)iOS 可以擁有AppLogger.exportLogs()兩套代碼互不沖突。這也是理解后面所有設(shè)計(jì)的基礎(chǔ)。但是這里需要特別注意Source Set 只能說(shuō)明這種代碼“可以正確工作”并不能說(shuō)明AppLogger.exportLogs()就一定是最合理的 API 設(shè)計(jì)。這兩個(gè)問(wèn)題要分開(kāi)看。二、第一版為什么會(huì)寫成 AppLogger.exportLogs()先看 iOS 第一版suspend fun AppLogger.exportLogs( config: LogExportConfig LogExportConfig(), ): ExportedLogFile exportLogs(createLogExporter(config))這段代碼定義在iosMain真正創(chuàng)建導(dǎo)出器的是fun createLogExporter( config: LogExportConfig LogExportConfig(), ): LogExporter LogExporter( IosLogExportStorage(iosLogDirectory()), config, )也就是說(shuō)AppLogger.exportLogs()本身并沒(méi)有實(shí)現(xiàn)讀取日志文件 寫 ZIP 刪除舊 ZIP 獲取文件大小這些底層能力。它主要承擔(dān)的是提供一個(gè)方便調(diào)用的入口 創(chuàng)建當(dāng)前平臺(tái)需要的對(duì)象Android 也是一樣fun createLogExporter( context: Context, config: LogExportConfig LogExportConfig(), ): LogExporter { val logDirectory File(androidLogDirectory(context.applicationContext)) return LogExporter( AndroidLogExportStorage(logDirectory), config, ) }因此第一版可以理解為iOS AppLogger.exportLogs() ↓ createLogExporter() ↓ IosLogExportStorage Android AppLogger.exportLogs(context) ↓ createLogExporter(context) ↓ AndroidLogExportStorage從“平臺(tái)差異怎么隔離”的角度來(lái)說(shuō)這個(gè)設(shè)計(jì)是成立的。真正的問(wèn)題出現(xiàn)在另外一個(gè)維度exportLogs()真的是AppLogger自己的職責(zé)嗎三、擴(kuò)展函數(shù)不是一種跨平臺(tái)機(jī)制這一點(diǎn)非常重要。很多人看到fun AppLogger.exportLogs()會(huì)下意識(shí)覺(jué)得這是 KMP 處理平臺(tái)差異的一種方式。其實(shí)不是。Kotlin 擴(kuò)展函數(shù)本質(zhì)上只是fun exportLogs(logger: AppLogger)換了一種調(diào)用形式AppLogger.exportLogs()所以擴(kuò)展函數(shù) ≠ 平臺(tái)抽象機(jī)制真正讓 Android 和 iOS 使用不同實(shí)現(xiàn)的是androidMain iosMain而不是擴(kuò)展函數(shù)。擴(kuò)展函數(shù)解決的是API 最終以什么形式暴露給調(diào)用者。例如Throwable.toAppError()和toAppError(throwable)能力上沒(méi)有本質(zhì)區(qū)別。前一種只是表達(dá)得更加自然。但擴(kuò)展函數(shù)還有第二個(gè)問(wèn)題以前我們只問(wèn)用擴(kuò)展函數(shù)調(diào)用是不是更方便繼續(xù)重構(gòu)以后發(fā)現(xiàn)這還不夠。還應(yīng)該繼續(xù)問(wèn)這個(gè)操作真的屬于 receiver 嗎例如Throwable.toAppError()非常合理。因?yàn)檎麄€(gè)操作圍繞Throwable展開(kāi)Throwable ↓ 轉(zhuǎn)換 ↓ AppError所以把它寫成throwable.toAppError()語(yǔ)義很自然。但是AppLogger.exportLogs()就不太一樣了。日志導(dǎo)出真正的流程其實(shí)是AppLogger.flush() ↓ LogExporter.export() ↓ LogExportStorageAppLogger在這里僅僅負(fù)責(zé)flush它只是整個(gè)日志導(dǎo)出流程中的一個(gè)參與者。真正負(fù)責(zé)日志篩選 ZIP 壓縮 日志文件讀取 舊文件清理 導(dǎo)出結(jié)果生成的是LogExporter。因此AppLogger.exportLogs()雖然寫起來(lái)方便卻容易給人一種錯(cuò)覺(jué)日志導(dǎo)出是 AppLogger 自己的能力。這就是第一版 API 最終被調(diào)整的原因。四、最終為什么改成頂層 exportLogs()最終 Common 層的日志導(dǎo)出入口改成suspend fun exportLogs( exporter: LogExporter, ): ExportedLogFile { AppLogger.flush() return exporter.export() }這段代碼非常簡(jiǎn)單。先AppLogger.flush()確保 Logger 當(dāng)前隊(duì)列中的日志已經(jīng)完成寫入。然后exporter.export()正式執(zhí)行導(dǎo)出流程。這里和之前最大的變化不是代碼量。而是調(diào)用形式終于和真實(shí)職責(zé)對(duì)齊了。以前AppLogger.exportLogs(exporter)看起來(lái)像AppLogger ↓ 擁有 exportLogs 能力現(xiàn)在exportLogs(exporter)表達(dá)的是這是一個(gè)“日志導(dǎo)出流程” 它會(huì)協(xié)調(diào) AppLogger LogExporter所以它更像一個(gè)流程協(xié)調(diào)函數(shù)。五、為什么流程協(xié)調(diào)適合頂層函數(shù)繼續(xù)看suspend fun exportLogs( exporter: LogExporter, ): ExportedLogFile { AppLogger.flush() return exporter.export() }它沒(méi)有自己的狀態(tài)。也沒(méi)有復(fù)雜生命周期。更沒(méi)有一個(gè)需要替換的“ExportLogs 實(shí)現(xiàn)”。它只是flush ↓ export因此沒(méi)有必要為了它再創(chuàng)建object LogExportCoordinator也沒(méi)有必要class LogExportService更沒(méi)有必要interface LogExportService class DefaultLogExportService一個(gè)普通頂層函數(shù)已經(jīng)可以準(zhǔn)確表達(dá)它的職責(zé)。這也是一個(gè)很實(shí)用的設(shè)計(jì)判斷如果一段邏輯只是協(xié)調(diào)已有能力而且自身沒(méi)有狀態(tài)、生命周期和新的變化點(diǎn)普通函數(shù)往往就是最簡(jiǎn)單、最準(zhǔn)確的設(shè)計(jì)。六、Android / iOS 平臺(tái)入口還存在嗎存在。刪除AppLogger.exportLogs()并不意味著平臺(tái)差異消失了。Android 仍然可以提供suspend fun exportLogs( context: Context, config: LogExportConfig LogExportConfig(), ): ExportedLogFile { return exportLogs( createLogExporter( context context, config config, ) ) }iOSsuspend fun exportLogs( config: LogExportConfig LogExportConfig(), ): ExportedLogFile { return exportLogs( createLogExporter(config) ) }于是業(yè)務(wù)調(diào)用變成AndroidexportLogs(context)iOSexportLogs()注意這里平臺(tái)差異的處理方式和以前沒(méi)有任何本質(zhì)變化。依然是Android 編譯 androidMain iOS 編譯 iosMain變化的只是以前 把 exportLogs 掛到 AppLogger 上 現(xiàn)在 exportLogs 作為獨(dú)立流程入口也就是說(shuō)Source Set 解決平臺(tái)代碼放在哪里。頂層函數(shù)還是擴(kuò)展函數(shù)解決 API 怎么表達(dá)。兩者完全不是一件事。七、真正的公共業(yè)務(wù)邏輯在哪里平臺(tái)入口最終都會(huì)創(chuàng)建LogExporterLogExporter定義在commonMain核心結(jié)構(gòu)類似class LogExporter internal constructor( private val storage: LogExportStorage, private val config: LogExportConfig, )注意最關(guān)鍵的一行private val storage: LogExportStorageLogExporter并不依賴IosLogExportStorage也不依賴AndroidLogExportStorage它依賴的是LogExportStorage這個(gè)公共接口。然后exporter.export()開(kāi)始執(zhí)行公共日志導(dǎo)出流程。例如val sourceFiles storage.listLogFiles() .filter { it.name.endsWith(LOG_EXTENSION) } .sortedBy(ExportSourceFile::name)然后創(chuàng)建 ZIPval output storage.openExport(fileName) val zip ZipArchiveWriter(output, timeZone)讀取日志sourceFiles.forEach { file - zip.add(file) { consume - storage.readLogFile(file, consume) } }最終返回ExportedLogFile( path storage.exportPath(fileName), fileName fileName, sizeBytes storage.exportSize(fileName), logFileCount sourceFiles.size, )這里有個(gè)非常漂亮的地方。LogExporter知道我要找日志 我要篩選日志 我要讀取日志 我要生成 ZIP 我要清理舊 ZIP 我要返回導(dǎo)出結(jié)果但它完全不知道Android 到底怎么讀文件 iOS 到底怎么讀文件這就是公共業(yè)務(wù)邏輯和平臺(tái)能力真正分開(kāi)的地方。八、interface 到底在哪里發(fā)揮作用很多人第一次看這種設(shè)計(jì)時(shí)容易繞進(jìn)去。調(diào)用鏈大概是exportLogs() ↓ LogExporter.export() ↓ storage.listLogFiles()然后就會(huì)疑惑LogExportStorage到底在哪里被調(diào)用了其實(shí)LogExportStorage不是一個(gè)需要“調(diào)用”的對(duì)象工廠。它是LogExporter持有的依賴。也就是說(shuō)interface 在對(duì)象創(chuàng)建階段就已經(jīng)被注入進(jìn)去了。比如 iOSLogExporter( IosLogExportStorage(iosLogDirectory()), config, )把代碼展開(kāi)val iosStorage IosLogExportStorage(iosLogDirectory()) val storage: LogExportStorage iosStorage val exporter LogExporter( storage storage, config config, )這時(shí)LogExporter只知道storage 是 LogExportStorage它并不知道 storage 實(shí)際上是IosLogExportStorage九、平臺(tái)差異其實(shí)是在 createLogExporter() 完成注入這就是整個(gè)設(shè)計(jì)非常關(guān)鍵的位置。iOSLogExporter( IosLogExportStorage(...), config, )AndroidLogExporter( AndroidLogExportStorage(...), config, )而LogExporter要求的只是LogExportStorage因此形成LogExporter │ │ 依賴 ▼ LogExportStorage interface / \ / \ ▼ ▼ AndroidLogExportStorage IosLogExportStorage也就是說(shuō)LogExporter這個(gè)公共業(yè)務(wù)組件不依賴任何具體平臺(tái)實(shí)現(xiàn)。平臺(tái)實(shí)現(xiàn)反過(guò)來(lái)實(shí)現(xiàn)它要求的抽象。這就是非常典型的依賴倒置。十、為什么調(diào)用 interface 最終會(huì)進(jìn)入 iOS 實(shí)現(xiàn)假設(shè)當(dāng)前運(yùn)行的是 iOS。創(chuàng)建對(duì)象時(shí)val storage: LogExportStorage IosLogExportStorage(...)變量類型是LogExportStorage但真正保存的對(duì)象是IosLogExportStorage所以storage.listLogFiles()最終執(zhí)行IosLogExportStorage.listLogFiles()同理storage.readLogFile(...)最終進(jìn)入IosLogExportStorage.readLogFile(...)iOS 里面可能真正使用NSFileManager fopen fread fwriteAndroid 里面則可能使用File FileInputStream FileOutputStream BufferedInputStream BufferedOutputStream這一點(diǎn)其實(shí)并不屬于 KMP 特有機(jī)制。本質(zhì)上就是普通的interface 多態(tài)。十一、完整調(diào)用鏈終于可以串起來(lái)了現(xiàn)在以 iOS 為例。最終結(jié)構(gòu)業(yè)務(wù)層 │ ▼ exportLogs() │ │ iosMain 平臺(tái)便捷入口 ▼ createLogExporter(config) │ ├──────────── 創(chuàng)建 ────────────? IosLogExportStorage │ │ │ │ implements │ ▼ │ LogExportStorage │ ▼ LogExporter(storage, config) │ ▼ commonMain exportLogs(exporter) │ ├── AppLogger.flush() │ ▼ exporter.export() │ ├── storage.listLogFiles() ├── storage.openExport() ├── storage.readLogFile() ├── storage.listExportFiles() ├── storage.deleteExport() ├── storage.exportPath() └── storage.exportSize() │ ▼ 實(shí)際進(jìn)入 IosLogExportStorage │ ▼ NSFileManager / fopen / fread / fwriteAndroid 完全一樣exportLogs(context) ↓ createLogExporter(context) ↓ AndroidLogExportStorage ↓ LogExporter ↓ commonMain exportLogs(exporter) ↓ AppLogger.flush() ↓ exporter.export() ↓ storage.xxx() ↓ AndroidLogExportStorage.xxx() ↓ File / InputStream / OutputStream到這里整個(gè)調(diào)用鏈就非常清楚了。十二、現(xiàn)在整個(gè)日志導(dǎo)出實(shí)際上可以看成四層把前面的代碼壓縮以后可以分成四層。第一層平臺(tái)便捷入口 / 裝配層AndroidexportLogs(context)iOSexportLogs()職責(zé)給調(diào)用方提供簡(jiǎn)單入口 創(chuàng)建當(dāng)前平臺(tái) LogExporter這部分放在androidMain iosMain第二層流程協(xié)調(diào)層exportLogs(exporter)職責(zé)非常簡(jiǎn)單AppLogger.flush() ↓ LogExporter.export()它只是協(xié)調(diào)已有能力。因此使用頂層函數(shù)就夠了。第三層公共業(yè)務(wù)層LogExporter職責(zé)篩選日志 生成文件名 壓縮 ZIP 異常處理 清理舊文件 生成 ExportedLogFile這些邏輯 Android 和 iOS 基本一致。所以放commonMain第四層平臺(tái)能力層公共接口LogExportStorage它定義我要能夠 列日志 讀日志 創(chuàng)建導(dǎo)出文件 刪除導(dǎo)出文件 獲取文件路徑 獲取文件大小至于怎么實(shí)現(xiàn)由AndroidLogExportStorage IosLogExportStorage負(fù)責(zé)。十三、那什么時(shí)候應(yīng)該用 expect / actual理解完interface后再來(lái)看expect/actual就簡(jiǎn)單很多。假設(shè) commonMain 需要platformProcessName()但Android 獲取進(jìn)程名 和 iOS 獲取進(jìn)程名實(shí)現(xiàn)完全不同?？梢詫?/ commonMain expect fun platformProcessName(): StringAndroidactual fun platformProcessName(): String { ... }iOSactual fun platformProcessName(): String { ... }形成commonMain │ ▼ platformProcessName() │ expect / \ ▼ ▼ Android iOS actual actual這種方案比較適合平臺(tái)名稱 系統(tǒng)版本 進(jìn)程名 線程信息 簡(jiǎn)單系統(tǒng)信息 簡(jiǎn)單目錄查詢特點(diǎn)是commonMain 直接需要一個(gè)平臺(tái)能力而且能力本身比較簡(jiǎn)單、固定。十四、為什么 LogExportStorage 更適合 interface日志存儲(chǔ)就不一樣了。它已經(jīng)包含很多能力listLogFiles readLogFile openExport exportPath exportSize listExportFiles deleteExport它本質(zhì)上已經(jīng)是一個(gè)完整組件。這種情況下interface LogExportStorage會(huì)比把所有方法做成expect/actual更合適。第一可以測(cè)試?yán)鏲lass FakeLogExportStorage : LogExportStorage { ... }然后LogExporter( FakeLogExportStorage(), config, )Common Test 不需要真的訪問(wèn) Android 或 iOS 文件系統(tǒng)。第二可以替換以后甚至可以MemoryLogExportStorage DesktopLogExportStorage TestLogExportStorage而LogExporter完全不需要修改。第三符合依賴倒置LogExporter 不依賴 AndroidLogExportStorage IosLogExportStorage 而是依賴 LogExportStorage公共業(yè)務(wù)層只認(rèn)識(shí)抽象。十五、為什么 uploadLogs() 也不應(yīng)該掛在 AppLogger 上日志上傳的情況其實(shí)更加明顯。如果寫AppLogger.uploadLogs(...)看起來(lái)會(huì)像AppLogger 自己具有日志上傳能力。但真正流程其實(shí)是AppLogger.flush() ↓ LogExporter.export() ↓ LogUploader.upload()它至少涉及三個(gè)角色AppLogger LogExporter LogUploader所以這里更不應(yīng)該強(qiáng)行選擇AppLogger作為 receiver。最終 Common 層可以直接寫suspend fun uploadLogs( exporter: LogExporter, uploader: LogUploader, metadata: LogUploadMetadata LogUploadMetadata(), ): LogUploadResult它表達(dá)得非常明確uploadLogs 是一個(gè)流程協(xié)調(diào)入口。它會(huì)協(xié)調(diào)Logger Exporter Uploader完成整個(gè)日志上傳流程。十六、為什么不再造一個(gè) LogService看到這里可能還會(huì)產(chǎn)生一個(gè)想法既然已經(jīng)有exportLogs(...) uploadLogs(...)是不是可以再封一層interface LogService { suspend fun exportLogs(): ExportedLogFile suspend fun uploadLogs(): LogUploadResult }然后class DefaultLogService( private val exporter: LogExporter, private val uploader: LogUploader, ) : LogService看起來(lái)似乎更加“架構(gòu)化”。但目前沒(méi)有這個(gè)必要。因?yàn)轫?xiàng)目已經(jīng)有兩個(gè)真正穩(wěn)定的能力抽象LogExporter → 怎么導(dǎo)出日志 LogUploader → 怎么上傳日志而uploadLogs()只是flush ↓ export ↓ upload它本身并沒(méi)有出現(xiàn)一個(gè)新的獨(dú)立變化點(diǎn)。如果現(xiàn)在再創(chuàng)建LogService LogServiceImpl LogCoordinator只是給已有接口再包一層接口層數(shù)增加了職責(zé)卻沒(méi)有增加。接口不是為了“架構(gòu)完整”這是這里非常重要的一個(gè)判斷。我們創(chuàng)建LogExportStorage是因?yàn)锳ndroid 文件系統(tǒng) 和 iOS 文件系統(tǒng)確實(shí)存在不同實(shí)現(xiàn)。我們保留LogUploader是因?yàn)樯蟼鲗?shí)現(xiàn)本身可以替換 Fake 測(cè)試 組合所以這里存在穩(wěn)定能力邊界。但是uploadLogs()只是現(xiàn)有能力的流程編排。因此接口是為了隔離變化、定義穩(wěn)定能力邊界而不是為了給每一段流程都套一個(gè) Service。十七、頂層函數(shù)、擴(kuò)展函數(shù)、interface、expect/actual 到底怎么選現(xiàn)在可以重新整理成兩個(gè)維度。這是整篇文章最重要的地方。第一個(gè)維度平臺(tái)差異怎么處理首先問(wèn)commonMain 是否需要這個(gè)平臺(tái)能力如果不需要比如打開(kāi) Android Activity 調(diào)用 iOS UIViewController Android 分享 Intent 某個(gè)平臺(tái)獨(dú)有 UI直接放androidMain iosMain即可。不一定需要expect / actual也不一定需要interface平臺(tái)層自己實(shí)現(xiàn)就夠了。如果 commonMain 需要繼續(xù)問(wèn)這是一個(gè)簡(jiǎn)單、固定的平臺(tái)能力嗎如果是平臺(tái)名 系統(tǒng)版本 進(jìn)程名 線程名 簡(jiǎn)單目錄可以考慮expect / actual如果已經(jīng)是文件存儲(chǔ) 數(shù)據(jù)庫(kù) KeyValue Storage Logger Sink LogExportStorage Crash 能力 設(shè)備通信而且要求可測(cè)試 可替換 可注入優(yōu)先考慮interface 平臺(tái)實(shí)現(xiàn)因此平臺(tái)抽象可以先這樣判斷出現(xiàn)平臺(tái)差異 │ ▼ commonMain 是否需要 │ ┌──┴──┐ │ │ 否 是 │ │ ▼ ▼ 平臺(tái)層 是否簡(jiǎn)單、固定 直接寫 │ ┌──┴──┐ │ │ 是 否 │ │ ▼ ▼ expect/actual 是否是完整組件 │ ▼ interface 平臺(tái)實(shí)現(xiàn)第二個(gè)維度API 最終怎么表達(dá)完成平臺(tái)抽象以后再問(wèn)另外一個(gè)問(wèn)題這個(gè)操作真正屬于某個(gè)對(duì)象本身嗎如果屬于可以考慮成員函數(shù) 或者 擴(kuò)展函數(shù)例如throwable.toAppError()非常自然。如果這個(gè)操作不屬于任何一個(gè)參與者而是在協(xié)調(diào)多個(gè)能力例如AppLogger.flush() LogExporter.export() LogUploader.upload()那么更加適合普通函數(shù) 或者 頂層函數(shù)所以第二個(gè)判斷圖可以寫成這個(gè)操作屬于某個(gè)對(duì)象本身嗎 │ ┌──┴──┐ │ │ 是 否 │ │ ▼ ▼ 成員函數(shù) / 是否協(xié)調(diào)多個(gè)能力 擴(kuò)展函數(shù) │ ▼ 頂層函數(shù) 普通函數(shù)十八、擴(kuò)展函數(shù)和 interface、expect/actual 根本不是三選一這是整篇文章最重要的認(rèn)知之一。不要再思考擴(kuò)展函數(shù) VS expect / actual VS interface因?yàn)樗鼈兏静皇峭粚印Ｕ_的問(wèn)題應(yīng)該是第一步平臺(tái)差異是否需要暴露給 commonMain第二步如果需要 它是簡(jiǎn)單平臺(tái)能力 還是完整可替換組件決定expect / actual 還是 interface第三步最終 API 應(yīng)該怎么表達(dá)再?zèng)Q定成員函數(shù) 擴(kuò)展函數(shù) 頂層函數(shù) 普通類方法所以一個(gè)成熟的 KMP 模塊完全可能同時(shí)存在interface 平臺(tái)實(shí)現(xiàn)類 expect / actual 擴(kuò)展函數(shù) 頂層函數(shù)它們各自解決不同的問(wèn)題。十九、回到 Logger最終這套設(shè)計(jì)到底做了什么現(xiàn)在再看整個(gè) Logger 日志導(dǎo)出exportLogs() │ 平臺(tái)便捷調(diào)用入口 │ ▼ createLogExporter() │ ┌─────────┴─────────┐ │ │ ▼ ▼ AndroidLogExportStorage IosLogExportStorage │ │ └─────────┬─────────┘ │ ▼ LogExportStorage interface │ ▼ LogExporter │ ▼ commonMain exportLogs() │ ┌──────────┴──────────┐ │ │ ▼ ▼ AppLogger.flush() exporter.export() │ ▼ 公共日志導(dǎo)出流程每一層的職責(zé)都非常明確。exportLogs(context) / exportLogs()負(fù)責(zé)好不好調(diào)用 當(dāng)前平臺(tái)對(duì)象怎么創(chuàng)建createLogExporter()負(fù)責(zé)當(dāng)前平臺(tái)到底裝配 AndroidLogExportStorage 還是 IosLogExportStorageLogExportStorage負(fù)責(zé)公共業(yè)務(wù)層需要什么平臺(tái)能力Android / iOS Storage負(fù)責(zé)平臺(tái)到底怎么實(shí)現(xiàn)文件讀寫LogExporter負(fù)責(zé)公共日志導(dǎo)出業(yè)務(wù)流程怎么執(zhí)行commonMain exportLogs(exporter)負(fù)責(zé)協(xié)調(diào) AppLogger.flush() LogExporter.export()它沒(méi)有額外狀態(tài)因此頂層函數(shù)就夠了二十、這次重構(gòu)真正改的不是語(yǔ)法表面上看這次只是AppLogger.exportLogs()改成exportLogs()以及AppLogger.uploadLogs(...)改成uploadLogs(...)似乎只是少了一個(gè) receiver。但實(shí)際上真正調(diào)整的是API 的調(diào)用形式是否準(zhǔn)確表達(dá)了真實(shí)職責(zé)。以前AppLogger.exportLogs()很容易理解成AppLogger 自己負(fù)責(zé)日志導(dǎo)出現(xiàn)在exportLogs()表達(dá)的是這是一個(gè)日志導(dǎo)出流程而真正參與流程的是AppLogger LogExporter LogExportStorage同理uploadLogs()是AppLogger LogExporter LogUploader之間的協(xié)調(diào)過(guò)程。這也是為什么最終沒(méi)有繼續(xù)使用擴(kuò)展函數(shù)?？偨Y(jié)這次從最開(kāi)始的AppLogger.exportLogs()一路向下追最后實(shí)際上可以看到 KMP 架構(gòu)設(shè)計(jì)中非常核心的一套思想。可以壓縮成五句話。第一Source Set 決定平臺(tái)代碼在哪里參與編譯擴(kuò)展函數(shù)本身不是跨平臺(tái)機(jī)制。第二擴(kuò)展函數(shù)解決的是 API 表達(dá)問(wèn)題但只有當(dāng)操作真正屬于 receiver 時(shí)才自然。第三跨多個(gè)組件的無(wú)狀態(tài)流程協(xié)調(diào)更適合普通函數(shù)或頂層函數(shù)。第四expect/actual 更適合 commonMain 直接需要的簡(jiǎn)單、固定平臺(tái)能力。第五interface 平臺(tái)實(shí)現(xiàn)更適合完整、可替換、可測(cè)試的平臺(tái)組件。在這個(gè) Logger 中exportLogs()負(fù)責(zé)平臺(tái)便捷入口和流程協(xié)調(diào)LogExporter負(fù)責(zé)平臺(tái)無(wú)關(guān)的日志導(dǎo)出業(yè)務(wù)LogExportStorage負(fù)責(zé)定義公共業(yè)務(wù)層需要的平臺(tái)能力AndroidLogExportStorage IosLogExportStorage負(fù)責(zé)真正的平臺(tái)文件實(shí)現(xiàn)而AppLogger最終重新回到了它真正應(yīng)該負(fù)責(zé)的事情記錄日志 管理日志隊(duì)列 flush另外還有最后一個(gè)非常重要的經(jīng)驗(yàn)不要為了“看起來(lái)架構(gòu)完整”而給每一個(gè)流程都創(chuàng)建 Service、Coordinator 和 Impl。只有當(dāng)一個(gè)地方真正出現(xiàn)獨(dú)立變化 可替換實(shí)現(xiàn) 穩(wěn)定能力邊界 生命周期或狀態(tài)才值得繼續(xù)抽象。如果只是A ↓ B ↓ C這樣簡(jiǎn)單地協(xié)調(diào)已有能力一個(gè)清晰的函數(shù)可能就是最好的設(shè)計(jì)。當(dāng)這些職責(zé)真正分清以后再遇到 KMP 項(xiàng)目里的commonMain androidMain iosMain expect / actual interface 平臺(tái)實(shí)現(xiàn) 擴(kuò)展函數(shù) 頂層函數(shù)就不會(huì)再把它們混成一團(tuán)了。