从一次白屏 1.8 秒开始系列写到第五篇绕了一圈最后还是要回到一个最朴素的问题WebView 慢慢在哪儿怎么办说实话前几篇我们聊的内核、白屏、代理、JSBridge都是骨架。但生产线上真正决定用户体验的是骨架之外那层肉——首屏多少秒、崩溃率多少、内存泄漏多少、ANR 多少。这些数字是冷的但你的用户每打开一次页面都在投票。去年我接手过一个 H5 容器列表页平均首屏 1.8 秒崩溃率峰值 0.42%活动促销时 OOM 率会涨到日常的 3 倍。一个季度后我们把首屏压到 480ms崩溃率压到 0.06%。这中间没有一个银弹只有一堆细碎的、每个都能讲半小时的工程动作。这一篇我把这些动作分成四类讲清楚预热让 WebView “已经准备好”、复用让 WebView “不重复造轮子”、内存治理让 WebView “用完能干净走”、崩溃防护让 WebView “炸了不连累我们”。每一类我都会给出我们生产环境真实在用的策略和踩过的坑。一、预热把冷启动提前到用户感知不到的地方1.1 WebView 启动到底慢在哪第一次创建WebView到底花了多少时间我用 Systrace 在中端机上量过大致是这样阶段耗时中端机是否可优化WebView 类加载 内核初始化220 ~ 350ms可前置Provider 实例化GpuChild 进程拉起90 ~ 180ms可前置第一次 loadUrlDNSTCPTLSHTML 下载200 ~ 800ms可前置预请求JS/CSS 解析与渲染100 ~ 400ms受页面影响这张表里有一个非常有意思的事实真正页面相关的只有最后一行前面三个阶段不管你打开什么页面都要花掉。也就是说理论上我们能把整页首屏的 50% 时间提前到用户根本没点击之前。1.2 三级预热策略不是说启动 App 时 new 一个 WebView 就行了。我最早就是这么干的被组里 leader 喷了一顿——你这相当于把所有用户的启动 RAM 都吃掉一份得不偿失。后来我们改成三级渐进式App 启动完成onIdle↓L1 内核预热 触发 WebView 类加载与 Provider无实例↓用户进入可能跳 H5的页面是 L2 实例预热异步创建一个 WebView 放进对象池↓用户点击进入 H5 页L3 数据预热 拦截真实 URL 之前预请求 HTML/关键资源L1 是给整个 App 共享的成本最低。代码就一行但放在哪个时机非常讲究// L1: 仅触发类加载与 Provider // 不创建实例几乎不占内存 object Warmer { fun warmUp() { Looper.getMainLooper() .queue .addIdleHandler { try { // 调 getCurrentWebView- // Package() 拉 Provider triggerProvider() CookieManager .getInstance() } catch (e: Throwable) { Log.w(WV, e) } false } } }注意addIdleHandler这个时机选得很有讲究。如果直接放Application.onCreate会拖慢冷启动 200ms放postDelayed不准只有 IdleHandler 才是主线程真的闲下来的可靠信号。1.3 一个我踩过的大坑Application 里 new WebViewL2 阶段创建实例千万不要用 Application 当 Context。Android 9 之后会直接抛RuntimeExceptionAndroid 10 部分机型还会触发 WebView 多进程目录冲突整个 WebView 子进程拉不起来。正确做法用一个空的、没有 Activity 主题的MutableContextWrapper包住 ApplicationContext 创建 WebView。等真正用的时候把内部 Context 替换成宿主 Activity。这是腾讯 X5、字节 Lynx 都在用的成熟做法。二、复用WebView 对象池的设计与陷阱2.1 为什么必须做复用第一次 WebView 创建慢第二次也慢吗答案是会快一些内核已经在内存里但仍然有 60~120ms 的实例创建开销。更要命的是关闭一个 WebView 后立刻打开另一个还会触发 GC 抖动和子进程通信抖动。所以用完即销毁对中度以上的 H5 场景就是个错误的设计。我们最终选了对象池——但对象池本身也有一堆坑。2.2 对象池的最小骨架class WebViewPool( private val max: Int 2 ) { private val pool ArrayDequeWebView() fun acquire( host: Activity ): WebView { val wv pool.removeFirstOrNull() ?: create(app()) (wv.context as MutableContextWrapper) .baseContext host return wv } fun release(wv: WebView) { reset(wv) if (pool.size max) { (wv.context as MutableContextWrapper) .baseContext app() pool.addLast(wv) } else { wv.destroy() } } }看着简单但reset()这个函数才是真正的难点——你能想到的所有上一次留下的东西都得清干净。2.3 reset 必须做的清理血泪清单我列一下我们生产环境的 reset 清单每一条都对应一个曾经线上出过的事故•loadUrl(“about:blank”)先把当前页打掉否则历史 cookie/storage 会被下一个使用者读到•clearHistory()上一个用户的回退栈不能传染下一个•removeAllViews()避免上一个 Activity 注入的自定义 View 残留•removeJavascriptInterface()上一篇讲过的必须按业务名清理掉所有 JS 接口•WebChromeClient/WebViewClient 重置为空实现这两个 Client 持有 Activity 引用不重置就是内存泄漏•setOnTouchListener(null)触摸监听经常被业务方注册了忘记摘•cancel pending request通过stopLoading()webViewClient.shouldInterceptRequest标记位双保险我特别想强调那个about:blank的步骤。我们曾经为了省一次加载跳过这一步结果发生了一起非常诡异的故障用户 A 在金融页面登录后退出了用户 B 进入活动页时对象池给了同一个 WebView 实例前端代码读到了用户 A 残留的 sessionStorage导致页面错乱**。对象池是性能优化但绝对不能让它跨过用户态的隔离边界**。2.4 池子大小怎么选这是个工程取舍问题没有标准答案。我们的经验值业务形态推荐池大小App 内 H5 占比 20%轻量场景1仅预热一份中等占比常见多层跳转2 ~ 3超级 App / H5 重度场景3 ~ 4 多进程隔离千万别贪多。我曾经把池子调到 5结果低端机内存压力上来反而触发了系统 LowMemoryKiller把 App 整个杀了。后来改到 2 内存紧张时主动 trim整体反而更稳。三、内存治理WebView 是吃内存的大户3.1 一个 WebView 大概要吃多少内存这个数字让我自己一开始也很惊讶在 Android 7 多进程模式下一个空的 WebView常驻物理内存大约 25~50MB加载一个中度复杂页面带视频、图表、若干 SDK可以涨到 80~150MB。注意这是物理内存不是堆内存。Android Studio 的 Profiler 默认只看堆会严重低估。用adb shell dumpsys meminfo pkg才能看到完整的画像包含 GpuChild、SandboxedProcess 等子进程的占用。3.2 三类常见的 WebView 内存泄漏在 LeakCanary 报上来的 WebView 类泄漏里9 成都属于下面三类泄漏 1JsBridge 持有 Activity 注解修饰的 JS 接口对象隐式持有 Activity 引用泄漏 2WebChromeClient 闭包 Kotlin 匿名内部类隐式持有外部类外部类是 Fragment/Activity泄漏 3长生命周期单例缓存了 WebView 全局 Manager 直接 putWebViewActivity 生命周期结束后仍被引用第二类最阴险。Kotlin 写起来很优雅// 看似无害实则泄漏 webView.webChromeClient object : WebChromeClient() { override fun onProgressChanged( v: WebView, p: Int ) { // 这里访问了 Activity 的 // 成员比如 progressBar progressBar.progress p } }这个匿名 object 隐式持有了外部 Activity 的引用。一旦 WebView 进了对象池Activity 就再也回收不掉。修复办法不只是WeakReference——更彻底的做法是把 Client 设计成无状态的所有需要访问 Activity 的逻辑通过 EventBus / Flow 这种事件通道转出去class PoolableChromeClient( private val events: MutableSharedFlow WvEvent ) : WebChromeClient() { override fun onProgressChanged( v: WebView, p: Int ) { events.tryEmit( WvEvent.Progress(p) ) } }Activity 在 onCreate 里订阅 Flow在 onDestroy 里取消订阅。这样无论 WebView 在不在池子里Client 本身都不持有 Activity。3.3 主动内存治理分级响应系统压力不是所有内存都你说了算系统会通过onTrimMemory给信号。WebView 容器应该分级响应level动作UI_HIDDEN暂停媒体、停止动画、freeMemory()RUNNING_LOW清空对象池仅保留最近一个CRITICAL销毁全部空闲 WebView仅留前台实例这套机制让我们在系统压力高峰期 OOM 率下降了 70%。秘诀就一句性能优化要占地盘但要在系统紧张时迅速让出来。四、崩溃防护让 WebView 炸不掉宿主进程4.1 RenderProcessGoneDetail 的正确用法Android 8 以后WebView 默认是多进程的。这意味着 WebView 渲染进程崩了宿主进程不会自动崩溃但你的 WebView 会变成黑屏所有 JS 都失效。如果不处理用户看到的就是一个永远白屏/黑屏的页面。关键回调是onRenderProcessGone。返回 true 才能阻止系统把宿主拖进 ANR。override fun onRenderProcessGone( v: WebView, detail: RenderProcessGoneDetail ): Boolean { val oom detail.didCrash().not() Reporter.log( render_gone, oom oom ) // 1. 立即从父布局摘除 (v.parent as? ViewGroup) ?.removeView(v) // 2. 释放原 WebView v.destroy() // 3. 重建并恢复 URL rebuildAndRetry(currentUrl) return true }关键是立即把 view 从父布局摘掉。如果你只return true不做 destroy 和移除下一帧绘制时系统会因为渲染进程不存在再次抛异常然后就 ANR 了。这个细节官方文档没强调是我们从 Crash 平台堆栈一点点反推出来的。4.2 重建策略不能无脑 retry简单的崩了就重建会导致无限重建死循环——比如某个页面就是会 OOM重建一次再 OOM无穷无尽。我们的策略是renderProcessGone 触发↓同 URL 5 分钟内崩溃次数 ≥ 2 是 → 降级跳到原生兜底页 上报危险页面否 → 重建 WebView恢复 URL记录指数退避计数这条策略上线一周内把渲染进程反复崩溃导致用户卡死的反馈量从日均 50 降到了个位数。4.3 兜底容器当一切都失败时我有一个略偏执的观点WebView 容器必须有一个永不依赖 WebView 的兜底页。一个纯原生写的、能展示当前业务核心信息订单号、商品名、客服入口的 ErrorActivity。因为现实情况是端上 WebView 偶尔会因为某些设备厂商魔改、某次 OTA 出大问题。你不可能保证 100% 可用但你可以保证 100% “不至于让用户被卡死”。这是工程稳定性的底线。五、可观测性没有指标就谈不上治理说了这么多策略最关键的一句留到最后所有不能被度量的优化都是耍流氓。我们最终建立了一个 WebView 性能稳定性看板核心指标只有 5 个但全都是端到端的指标采集点告警阈值首屏耗时FMP点击触发到 onPageFinishedP95 2.0s白屏率见上一篇白屏检测方案 0.5%渲染进程崩溃率onRenderProcessGone 0.1%WebView OOM 率UncaughtExceptionHandler 0.05%对象池命中率acquire() 内部计数 60%很多团队会做一堆细粒度指标比如 DNS 时间、SSL 握手时间。我的看法是第一阶段抓 5 个北极星指标第二阶段才做下钻。指标多了反而没人看。系列收束从内核到治理我们到底在做什么这是 WebView 系列的最后一篇。从第一篇内核架构、第二篇白屏检测、第三篇代理与离线包、第四篇 JSBridge、到今天的性能与稳定性写下来一共五万多字。说实话整个系列写完我自己最大的体会是——WebView 这个东西从技术上看是一个嵌入到 App 里的浏览器内核但从工程上看它是一个介于原生应用和远端服务之间的复杂系统。它不像纯原生那样能完全控制也不像服务端那样能随时回滚。它本质上是一种妥协——为了让前后端复用、让动态运营成为可能、让 H5 跨端体验抹平差异我们在端上养了一只半驯化的怪兽。处理这只怪兽的所有努力——预热、复用、治理、防护——本质都是在把不可控的部分变成可观测、可降级、可恢复。工程稳定性的最高境界不是没有故障而是任何故障发生时系统都能被观测到、被降级、被快速恢复。WebView 容器的所有工程动作都是这条原则的具体实践。下一阶段我可能会写 Compose / Compose Multiplatform 这条线。Compose 在 2026 这个时间点已经从新东西变成了主线KotlinConf 26 上 Koog、Quail 这些工具链的整合让这条线变得更值得深入。如果你有特别想看的方向欢迎留言告诉我。系列结束。下次见。
WebView性能优化与稳定性治理：预热、复用池与崩溃防护
发布时间：2026/6/3 3:06:29
从一次白屏 1.8 秒开始系列写到第五篇绕了一圈最后还是要回到一个最朴素的问题WebView 慢慢在哪儿怎么办说实话前几篇我们聊的内核、白屏、代理、JSBridge都是骨架。但生产线上真正决定用户体验的是骨架之外那层肉——首屏多少秒、崩溃率多少、内存泄漏多少、ANR 多少。这些数字是冷的但你的用户每打开一次页面都在投票。去年我接手过一个 H5 容器列表页平均首屏 1.8 秒崩溃率峰值 0.42%活动促销时 OOM 率会涨到日常的 3 倍。一个季度后我们把首屏压到 480ms崩溃率压到 0.06%。这中间没有一个银弹只有一堆细碎的、每个都能讲半小时的工程动作。这一篇我把这些动作分成四类讲清楚预热让 WebView “已经准备好”、复用让 WebView “不重复造轮子”、内存治理让 WebView “用完能干净走”、崩溃防护让 WebView “炸了不连累我们”。每一类我都会给出我们生产环境真实在用的策略和踩过的坑。一、预热把冷启动提前到用户感知不到的地方1.1 WebView 启动到底慢在哪第一次创建WebView到底花了多少时间我用 Systrace 在中端机上量过大致是这样阶段耗时中端机是否可优化WebView 类加载 内核初始化220 ~ 350ms可前置Provider 实例化GpuChild 进程拉起90 ~ 180ms可前置第一次 loadUrlDNSTCPTLSHTML 下载200 ~ 800ms可前置预请求JS/CSS 解析与渲染100 ~ 400ms受页面影响这张表里有一个非常有意思的事实真正页面相关的只有最后一行前面三个阶段不管你打开什么页面都要花掉。也就是说理论上我们能把整页首屏的 50% 时间提前到用户根本没点击之前。1.2 三级预热策略不是说启动 App 时 new 一个 WebView 就行了。我最早就是这么干的被组里 leader 喷了一顿——你这相当于把所有用户的启动 RAM 都吃掉一份得不偿失。后来我们改成三级渐进式App 启动完成onIdle↓L1 内核预热 触发 WebView 类加载与 Provider无实例↓用户进入可能跳 H5的页面是 L2 实例预热异步创建一个 WebView 放进对象池↓用户点击进入 H5 页L3 数据预热 拦截真实 URL 之前预请求 HTML/关键资源L1 是给整个 App 共享的成本最低。代码就一行但放在哪个时机非常讲究// L1: 仅触发类加载与 Provider // 不创建实例几乎不占内存 object Warmer { fun warmUp() { Looper.getMainLooper() .queue .addIdleHandler { try { // 调 getCurrentWebView- // Package() 拉 Provider triggerProvider() CookieManager .getInstance() } catch (e: Throwable) { Log.w(WV, e) } false } } }注意addIdleHandler这个时机选得很有讲究。如果直接放Application.onCreate会拖慢冷启动 200ms放postDelayed不准只有 IdleHandler 才是主线程真的闲下来的可靠信号。1.3 一个我踩过的大坑Application 里 new WebViewL2 阶段创建实例千万不要用 Application 当 Context。Android 9 之后会直接抛RuntimeExceptionAndroid 10 部分机型还会触发 WebView 多进程目录冲突整个 WebView 子进程拉不起来。正确做法用一个空的、没有 Activity 主题的MutableContextWrapper包住 ApplicationContext 创建 WebView。等真正用的时候把内部 Context 替换成宿主 Activity。这是腾讯 X5、字节 Lynx 都在用的成熟做法。二、复用WebView 对象池的设计与陷阱2.1 为什么必须做复用第一次 WebView 创建慢第二次也慢吗答案是会快一些内核已经在内存里但仍然有 60~120ms 的实例创建开销。更要命的是关闭一个 WebView 后立刻打开另一个还会触发 GC 抖动和子进程通信抖动。所以用完即销毁对中度以上的 H5 场景就是个错误的设计。我们最终选了对象池——但对象池本身也有一堆坑。2.2 对象池的最小骨架class WebViewPool( private val max: Int 2 ) { private val pool ArrayDequeWebView() fun acquire( host: Activity ): WebView { val wv pool.removeFirstOrNull() ?: create(app()) (wv.context as MutableContextWrapper) .baseContext host return wv } fun release(wv: WebView) { reset(wv) if (pool.size max) { (wv.context as MutableContextWrapper) .baseContext app() pool.addLast(wv) } else { wv.destroy() } } }看着简单但reset()这个函数才是真正的难点——你能想到的所有上一次留下的东西都得清干净。2.3 reset 必须做的清理血泪清单我列一下我们生产环境的 reset 清单每一条都对应一个曾经线上出过的事故•loadUrl(“about:blank”)先把当前页打掉否则历史 cookie/storage 会被下一个使用者读到•clearHistory()上一个用户的回退栈不能传染下一个•removeAllViews()避免上一个 Activity 注入的自定义 View 残留•removeJavascriptInterface()上一篇讲过的必须按业务名清理掉所有 JS 接口•WebChromeClient/WebViewClient 重置为空实现这两个 Client 持有 Activity 引用不重置就是内存泄漏•setOnTouchListener(null)触摸监听经常被业务方注册了忘记摘•cancel pending request通过stopLoading()webViewClient.shouldInterceptRequest标记位双保险我特别想强调那个about:blank的步骤。我们曾经为了省一次加载跳过这一步结果发生了一起非常诡异的故障用户 A 在金融页面登录后退出了用户 B 进入活动页时对象池给了同一个 WebView 实例前端代码读到了用户 A 残留的 sessionStorage导致页面错乱**。对象池是性能优化但绝对不能让它跨过用户态的隔离边界**。2.4 池子大小怎么选这是个工程取舍问题没有标准答案。我们的经验值业务形态推荐池大小App 内 H5 占比 20%轻量场景1仅预热一份中等占比常见多层跳转2 ~ 3超级 App / H5 重度场景3 ~ 4 多进程隔离千万别贪多。我曾经把池子调到 5结果低端机内存压力上来反而触发了系统 LowMemoryKiller把 App 整个杀了。后来改到 2 内存紧张时主动 trim整体反而更稳。三、内存治理WebView 是吃内存的大户3.1 一个 WebView 大概要吃多少内存这个数字让我自己一开始也很惊讶在 Android 7 多进程模式下一个空的 WebView常驻物理内存大约 25~50MB加载一个中度复杂页面带视频、图表、若干 SDK可以涨到 80~150MB。注意这是物理内存不是堆内存。Android Studio 的 Profiler 默认只看堆会严重低估。用adb shell dumpsys meminfo pkg才能看到完整的画像包含 GpuChild、SandboxedProcess 等子进程的占用。3.2 三类常见的 WebView 内存泄漏在 LeakCanary 报上来的 WebView 类泄漏里9 成都属于下面三类泄漏 1JsBridge 持有 Activity 注解修饰的 JS 接口对象隐式持有 Activity 引用泄漏 2WebChromeClient 闭包 Kotlin 匿名内部类隐式持有外部类外部类是 Fragment/Activity泄漏 3长生命周期单例缓存了 WebView 全局 Manager 直接 putWebViewActivity 生命周期结束后仍被引用第二类最阴险。Kotlin 写起来很优雅// 看似无害实则泄漏 webView.webChromeClient object : WebChromeClient() { override fun onProgressChanged( v: WebView, p: Int ) { // 这里访问了 Activity 的 // 成员比如 progressBar progressBar.progress p } }这个匿名 object 隐式持有了外部 Activity 的引用。一旦 WebView 进了对象池Activity 就再也回收不掉。修复办法不只是WeakReference——更彻底的做法是把 Client 设计成无状态的所有需要访问 Activity 的逻辑通过 EventBus / Flow 这种事件通道转出去class PoolableChromeClient( private val events: MutableSharedFlow WvEvent ) : WebChromeClient() { override fun onProgressChanged( v: WebView, p: Int ) { events.tryEmit( WvEvent.Progress(p) ) } }Activity 在 onCreate 里订阅 Flow在 onDestroy 里取消订阅。这样无论 WebView 在不在池子里Client 本身都不持有 Activity。3.3 主动内存治理分级响应系统压力不是所有内存都你说了算系统会通过onTrimMemory给信号。WebView 容器应该分级响应level动作UI_HIDDEN暂停媒体、停止动画、freeMemory()RUNNING_LOW清空对象池仅保留最近一个CRITICAL销毁全部空闲 WebView仅留前台实例这套机制让我们在系统压力高峰期 OOM 率下降了 70%。秘诀就一句性能优化要占地盘但要在系统紧张时迅速让出来。四、崩溃防护让 WebView 炸不掉宿主进程4.1 RenderProcessGoneDetail 的正确用法Android 8 以后WebView 默认是多进程的。这意味着 WebView 渲染进程崩了宿主进程不会自动崩溃但你的 WebView 会变成黑屏所有 JS 都失效。如果不处理用户看到的就是一个永远白屏/黑屏的页面。关键回调是onRenderProcessGone。返回 true 才能阻止系统把宿主拖进 ANR。override fun onRenderProcessGone( v: WebView, detail: RenderProcessGoneDetail ): Boolean { val oom detail.didCrash().not() Reporter.log( render_gone, oom oom ) // 1. 立即从父布局摘除 (v.parent as? ViewGroup) ?.removeView(v) // 2. 释放原 WebView v.destroy() // 3. 重建并恢复 URL rebuildAndRetry(currentUrl) return true }关键是立即把 view 从父布局摘掉。如果你只return true不做 destroy 和移除下一帧绘制时系统会因为渲染进程不存在再次抛异常然后就 ANR 了。这个细节官方文档没强调是我们从 Crash 平台堆栈一点点反推出来的。4.2 重建策略不能无脑 retry简单的崩了就重建会导致无限重建死循环——比如某个页面就是会 OOM重建一次再 OOM无穷无尽。我们的策略是renderProcessGone 触发↓同 URL 5 分钟内崩溃次数 ≥ 2 是 → 降级跳到原生兜底页 上报危险页面否 → 重建 WebView恢复 URL记录指数退避计数这条策略上线一周内把渲染进程反复崩溃导致用户卡死的反馈量从日均 50 降到了个位数。4.3 兜底容器当一切都失败时我有一个略偏执的观点WebView 容器必须有一个永不依赖 WebView 的兜底页。一个纯原生写的、能展示当前业务核心信息订单号、商品名、客服入口的 ErrorActivity。因为现实情况是端上 WebView 偶尔会因为某些设备厂商魔改、某次 OTA 出大问题。你不可能保证 100% 可用但你可以保证 100% “不至于让用户被卡死”。这是工程稳定性的底线。五、可观测性没有指标就谈不上治理说了这么多策略最关键的一句留到最后所有不能被度量的优化都是耍流氓。我们最终建立了一个 WebView 性能稳定性看板核心指标只有 5 个但全都是端到端的指标采集点告警阈值首屏耗时FMP点击触发到 onPageFinishedP95 2.0s白屏率见上一篇白屏检测方案 0.5%渲染进程崩溃率onRenderProcessGone 0.1%WebView OOM 率UncaughtExceptionHandler 0.05%对象池命中率acquire() 内部计数 60%很多团队会做一堆细粒度指标比如 DNS 时间、SSL 握手时间。我的看法是第一阶段抓 5 个北极星指标第二阶段才做下钻。指标多了反而没人看。系列收束从内核到治理我们到底在做什么这是 WebView 系列的最后一篇。从第一篇内核架构、第二篇白屏检测、第三篇代理与离线包、第四篇 JSBridge、到今天的性能与稳定性写下来一共五万多字。说实话整个系列写完我自己最大的体会是——WebView 这个东西从技术上看是一个嵌入到 App 里的浏览器内核但从工程上看它是一个介于原生应用和远端服务之间的复杂系统。它不像纯原生那样能完全控制也不像服务端那样能随时回滚。它本质上是一种妥协——为了让前后端复用、让动态运营成为可能、让 H5 跨端体验抹平差异我们在端上养了一只半驯化的怪兽。处理这只怪兽的所有努力——预热、复用、治理、防护——本质都是在把不可控的部分变成可观测、可降级、可恢复。工程稳定性的最高境界不是没有故障而是任何故障发生时系统都能被观测到、被降级、被快速恢复。WebView 容器的所有工程动作都是这条原则的具体实践。下一阶段我可能会写 Compose / Compose Multiplatform 这条线。Compose 在 2026 这个时间点已经从新东西变成了主线KotlinConf 26 上 Koog、Quail 这些工具链的整合让这条线变得更值得深入。如果你有特别想看的方向欢迎留言告诉我。系列结束。下次见。
