refactor(page): 删除旧版页面文件

.agents/skills/kotlin-tooling-native-build-performance/references/artifacts-and-targets.md

@@ -0,0 +1,44 @@
+# Build the Right Artifact for the Feedback Loop
+
+A release binary takes roughly an order of magnitude longer to build than a
+debug binary, and umbrella tasks such as `build` and `assemble` compile the
+same code several times. Map each feedback loop to one specific task.
+
+## Task table
+
+| Feedback loop | Correct task |
+|---|---|
+| Xcode builds and runs the app (direct integration) | `:shared:embedAndSignAppleFrameworkForXcode` |
+| Gradle-only check of the Apple Silicon simulator framework | `:shared:linkDebugFrameworkIosSimulatorArm64` |
+| CocoaPods integration | `:shared:linkPodDebugFrameworkIosSimulatorArm64` |
+| Distribution or App Store validation | `assemble<Name>ReleaseXCFramework` — in CI, not in the local loop |
+| Debug XCFramework genuinely required | `assemble<Name>DebugXCFramework` |
+
+Per-target link tasks follow the pattern
+`link<BuildType>Framework<Target>`; find the exact names with
+`./gradlew :shared:tasks` or in the build log.
+
+## Rules
+
+- `embedAndSignAppleFrameworkForXcode` builds only the slice Xcode asked for
+  and must run from an Xcode build phase, not standalone. Direct integration
+  uses the documented run-script phase; keep its
+  `OVERRIDE_KOTLIN_BUILD_IDE_SUPPORTED` guard so the IDE does not trigger a
+  second Gradle invocation.
+- Do not mix integration methods: a project either uses direct integration or
+  the CocoaPods integration, and the local task must match the one in use.
+- Do not replace CI release artifacts with debug artifacts. If CI release
+  builds are slow, fix caching, the target matrix, and exports instead.
+
+## Target matrix
+
+`*XCFramework` tasks build every declared target. Remove a target only when
+project policy confirms it is unused — the common case is dropping
+`iosX64()` when the team no longer supports Intel-based simulators. State the
+policy assumption in your report; if policy is unclear, ask instead of
+deleting.
+
+Docs:
+https://kotlinlang.org/docs/multiplatform-ios-integration-overview.html,
+https://kotlinlang.org/docs/multiplatform/multiplatform-direct-integration.html,
+https://kotlinlang.org/docs/multiplatform/multiplatform-build-native-binaries.html

.agents/skills/kotlin-tooling-native-build-performance/references/caching-and-gradle.md

@@ -0,0 +1,68 @@
+# Caching and Gradle Configuration
+
+Safe for every scenario; apply these before anything else.
+
+## Update Kotlin
+
+The latest Kotlin version is the first official recommendation for
+Kotlin/Native compilation time — each release improves compiler performance.
+Check `gradle/libs.versions.toml` or the plugin block and propose an upgrade
+if the project is behind. Read the compatibility guide for the target release
+before upgrading; for example, use the
+[Kotlin 2.4 compatibility guide](https://kotlinlang.org/docs/compatibility-guide-24.html)
+when moving to Kotlin 2.4.x. Each target release has a corresponding
+compatibility guide. See the
+[Kotlin 2.3.20 release notes](https://kotlinlang.org/docs/whatsnew2320.html#new-dsl-for-disabling-compilation-cache)
+for the related cache change.
+
+## Remove stale workarounds
+
+Projects accumulate workarounds for long-fixed compiler issues. Upgrade Kotlin
+first, then inspect:
+
+- `kotlin.native.disableCompilerDaemon=true`
+- `org.gradle.daemon=false`
+
+Each disables a performance feature. Remove stale workarounds and check
+whether the build completes successfully.
+
+## Enable Gradle caching
+
+```properties
+# gradle.properties
+org.gradle.caching=true
+org.gradle.configuration-cache=true
+```
+
+- Trial the configuration cache with the user's real task before committing
+  it. If Gradle reports configuration-cache problems, fix the blockers listed
+  in the HTML report instead of abandoning the cache.
+- The configuration cache implicitly enables parallel task execution, which
+  can run several `link*` tasks at once and overload the machine (KT-70915).
+  If that happens, bound it with `org.gradle.workers.max` in
+  `gradle.properties` or `--max-workers` on the command line — do not turn
+  the cache off for this reason alone.
+- Delete `org.gradle.configureondemand=true`. Kotlin Multiplatform does not
+  support Configuration on Demand, and it is not the same feature as the
+  configuration cache.
+- For CI, a remote Gradle build cache extends `org.gradle.caching` across
+  machines.
+
+## Keep `~/.konan` warm in CI
+
+Kotlin/Native stores its compiler distribution and caches in `$HOME/.konan`.
+Ephemeral CI machines and containers that lose it pay the cold-start cost on
+every build. On GitHub Actions:
+
+```yaml
+- uses: actions/cache@v4
+  with:
+    path: ~/.konan
+    key: konan-${{ runner.os }}-${{ hashFiles('**/libs.versions.toml') }}
+```
+
+Use the `konan.data.dir` Gradle property only when the project intentionally
+relocates that directory (for example, to a cacheable path on a CI runner).
+
+Docs: https://kotlinlang.org/docs/native-improving-compilation-time.html and
+https://kotlinlang.org/docs/gradle-compilation-and-caches.html

.agents/skills/kotlin-tooling-native-build-performance/references/experimental.md

@@ -0,0 +1,32 @@
+# Experimental Switches
+
+Offer these last, label them experimental in the report, and keep them out of
+the default recommendation set. Get the user's agreement before enabling any
+of them.
+
+## Incremental compilation of klib artifacts
+
+```properties
+# gradle.properties
+kotlin.incremental.native=true
+```
+
+Recompiles only the changed part of a klib into the final binary, which helps
+warm rebuilds after small edits. If it causes broken or inconsistent builds,
+revert it and file a YouTrack issue with a minimized reproducer.
+
+## smallBinary
+
+The `smallBinary` binary option sets `-Oz` as the default LLVM optimization
+level to shrink release binaries and their link time. It can cost runtime
+performance, so verify hot paths before keeping it. It applies to release
+binaries — it is not a fix for slow debug loops.
+
+## LLVM backend customization
+
+Customizing the LLVM backend is a last resort when nothing else helps, and is
+out of scope for a routine performance pass — point the user at the official
+documentation instead of improvising compiler flags.
+
+Docs: https://kotlinlang.org/docs/native-binary-options.html and
+https://kotlinlang.org/docs/native-improving-compilation-time.html

.agents/skills/kotlin-tooling-native-build-performance/references/exports-and-generated-code.md

@@ -0,0 +1,50 @@
+# Framework Exports and Generated Code
+
+## Framework exports
+
+Every exported module grows the API surface the compiler and linker must
+keep.
+
+- Remove `transitiveExport = true`. It exports the entire transitive closure
+  and disables dead code elimination in many cases — it is almost never what
+  the project actually needs.
+- Keep an explicit `export(...)` only for modules whose API Swift or
+  Objective-C code calls directly.
+
+```kotlin
+// Before: exports everything analytics depends on, defeats DCE
+binaries.framework {
+    export(project(":analytics"))
+    transitiveExport = true
+}
+
+// After: exports exactly the Swift-facing API
+binaries.framework {
+    export(project(":analytics"))
+}
+```
+
+If Swift code stops compiling after narrowing exports, add back only the
+specific modules it references — that is the export list the project really
+needs.
+
+## Generated code
+
+If `ksp*` tasks dominate the measured time, report the bottleneck as
+generated-code work — do not present a Kotlin/Native tweak as the fix.
+
+- Scope KSP to the targets or source sets that need generated code instead of
+  a broad `ksp(...)` dependency:
+
+  ```kotlin
+  dependencies {
+      add("kspCommonMainMetadata", libs.myprocessor)
+      add("kspIosSimulatorArm64", libs.myprocessor)
+  }
+  ```
+
+- Confirm the generated sources are consumed by the corresponding native
+  compilation before adding another target-specific KSP configuration.
+
+Docs: https://kotlinlang.org/docs/ksp-multiplatform.html and
+https://kotlinlang.org/docs/native-improving-compilation-time.html