James Hsueh

Kotlin Coroutines Bootcamp

共 10 篇文章

Day 1: 為什麼我們需要 Coroutines？— 從 Thread 到 協程的演進

在第一天，我們先不急著寫複雜的程式碼，而是先釐清「Coroutine 解決了什麼問題」。我們會比較傳統 Java Thread 的代價、Callback 的維護困難，以及 RxJava 的學習曲線。我們將通過一個簡單的性能測試

Day 2: 關鍵字大解密 — suspend, runBlocking, coroutineScope, launch

今天我們不談深奧的理論，而是專注於掃除新手最常見的誤區。你是否曾經困惑：為什麼加了 suspend 程式碼還是卡住？runBlocking 到底該不該用？它跟 coroutineScope 又有什麼差別？在這一天，我們將深入拆解 suspend、launch、runBlocking 與 coroutineScope。透過程式碼實戰，你將徹底釐清 「阻塞 (Blocking)」 與 「暫停 (Suspending)」 的本質區別，學會如何正確地啟動協程，建立連接「同步世界」與「非同步世界」的橋樑。

Day 3: 啟動協程的三種姿勢 — launch, async 與 Job 的掌控權

在 Java/Android 的世界裡，要從一個背景執行緒拿到結果通常很麻煩（需要 Callback 或是 Future.get() 阻塞）。Kotlin 協程提供了兩個最強大的武器：launch 和 async。"

Day 4: 協程的運行環境 — CoroutineContext 與 Dispatchers 詳解

如果你的 App 畫面卡住（ANR），通常是因為你在 Main Thread 做了太重的工作。如果你的 App 崩潰報錯 NetworkOnMainThreadException，是因為你在 Main Thread 連網路。如果你的 App 崩潰報錯 CalledFromWrongThreadException，是因為你在 Background Thread 更新 UI。今天我們要學習如何用 Dispatchers 來指揮協程去正確的地方工作。

Day 5: 結構化併發 (Structured Concurrency) — 馴服野生協程的韁繩

無論是在實際開發中（特別是 Android/Backend）或是 現實生活中，我們最怕的是 「僵屍」的出現。在開發上的殭屍是指那些使用者已經離開頁面，卻還在背景默默下載大檔案、消耗電量、甚至導致記憶體洩漏 (Memory Leak) 的任務。今天我們要學習 Kotlin 協程最引以為傲的設計哲學：結構化併發 (Structured Concurrency)。

Day 6: 協程中的異常處理 — 誰該負責這個 Bug？

在實際開發中，如果我同時發送 3 個 API 請求，其中一個失敗了（比如 404），我不希望另外兩個請求也被強制取消，甚至導致 App 閃退。今天我們要學習如何控制 **異常傳播 (Exception Propagation)**，以及如何正確地捕捉協程中的錯誤。

Day 7: 協程間的溝通— 深入 channel 的生產與消費模式

在複雜的系統中，協程之間往往需要交換資訊。例如：一個協程負責讀取網路資訊，另一個協程負責將資訊轉換寫入資料庫。比較傳統做法是使用「共享變數」（Shared Mutable State），例如一個 List，但這需要加鎖（Lock/Synchronized），容易導致死鎖或效能低落。

Day 8: 響應式開發 — Kotlin Flow 基礎與操作

Flow 是 Kotlin 為了對標 RxJava 而設計的工具，它基於 Coroutines 構建，具備 結構化併發特色

Day 9: 讓非同步程式碼可測試化 — 使用 runTest 與 TestDispatcher 進行單元測試.md

在傳統的單元測試（Unit Test）中，測試跑完就結束了，不會等你背景的 Thread 跑完。而且，如果你的程式碼裡有 delay(5000)，難道測試真的要等 5 秒嗎？這樣測試速度會慢到令人髮指。今天我們要介紹 kotlinx-coroutines-test，它是官方提供的測試框架，能讓你像「奇異博士」一樣控制時間。

Day 10: 深入底層 — 協程是如何被編譯成狀態機 (State Machine) 的？

為什麼 suspend 函數可以暫停？為什麼局部變數在暫停後還能恢復？為什麼協程切換比 Thread 快這麼多？答案就在於：狀態機 (State Machine) 與 CPS (Continuation-Passing Style)。