企业官网建设流程全解析

• 移动开发

本篇技术指南以仓库根目录的 CONTRIBUTING.md 为骨架，系统讲解 Mihon（Free and open source manga reader for Android）的代码贡献流程、翻译协作机制与 Fork 合规要点，并结合仓库内真实源码与构建配置（如 app/build.gradle.kts、AppUpdateChecker.kt）逐条印证每条规则背后的工程原因。读完你将掌握：如何安全参与 Mihon 的 PR 与 Issue 流程、翻译工作在哪完成、以及如何在不违反 LICENSE 与不污染主项目遥测数据的前提下维护一个合规的 Mihon 分支。

一、贡献总览：先看 README，再动手

Mihon 官方贡献入口分两层：

1. 问题反馈与功能请求：按 README 文件 中的指引操作（Issues / Feature Requests / Contributing 相关章节）。贡献者应先在 README 中确认反馈通道与模板要求，避免重复提交。
2. 代码贡献：见本指南后续章节，Pull Request 一律欢迎。

官方明确了两条协作准则，值得新贡献者记牢：

• 想认领 open issue 上的任务时，直接在对应 issue 下评论即可，让其他贡献者知道有人在做，避免撞车；
• 无需向任何人申请许可或等待指派（You do not need to ask for permission nor an assignment）。这是一个鼓励低门槛、自驱动参与的社区约定，意味着你可以直接 fork、改代码、提 PR。

二、代码贡献：前置技能与工具链

2.1 必需技能（Prerequisites）

官方明确声明，以下两项技能是硬性要求，且现有贡献者不会主动教授它们——也就是说，参与前你必须已经具备独立上手的能力：

• 基础的 Android 开发 知识（Activity / Fragment、资源系统、Gradle 构建等）；
• Kotlin 语言能力。

Mihon 的代码库正是以 Kotlin 为主的现代 Android 工程，可从仓库结构直观印证这一点：全部业务代码位于 app/src/main/java 下（如eu/kanade/tachiyomi、mihon两大包），核心模块分散于 core/common、domain、data、source-api 等模块，且采用 Multiplatform / 模块化设计。没有 Kotlin 基础，阅读@Inject class、withIOContext {}这类代码会寸步难行。

2.2 工具（Tools）

官方推荐两样必备工具：

• Android Studio：官方 IDE，内置 Gradle 集成、模拟器与 lint 支持；
• 模拟器或开启开发者选项的真机：用于验证改动效果。Mihon 是 UI 密集的漫画阅读器应用，涉及阅读器、下载、更新等交互，真机/模拟器验证是 PR 被合入的基本前提。

2.3 获取帮助（Getting help）

开发过程中遇到问题，官方给出的求助渠道是Mihon 的 Discord 服务器（https://discord.gg/mihon），可在开发过程中实时提问。

2.4 从仓库结构看贡献入口

从源码布局可以推断出常见贡献面（仅供参考，不构成官方承诺）：

• UI 与展示层：presentation-core、app内的presentation目录，涉及页面与组件；
• 领域与数据层：domain（业务用例，如GetApplicationRelease）、data（数据库、仓库实现）；
• 扩展源协议：source-api定义了扩展与主程序交互的接口；
• 本地化资源：i18n模块（见下文翻译章节）。

三、翻译协作：外部 Weblate 流程

官方明确规定：翻译不通过 PR 接收，而是在外部 Weblate 平台完成（Translations are done externally via Weblate）。详细说明见官网文档的 Translation 章节。

仓库内的实现佐证位于 i18n/README.md：

英文原字符串托管在src/commonMain/moko-resources/base/，翻译由外部 Weblate 完成。

实际结构也印证了这一点：i18n/src/commonMain/moko-resources 下按语言代码（base、zh-rCN、zh-rTW、ja、es等）组织strings.xml与plurals.xml。贡献翻译的开发者应前往 Weblate 平台操作，而非直接改i18n目录后提 PR——这能避免与自动化同步流程冲突。

四、Fork 规范：合规分支的完整检查清单

这是原文档篇幅最大、实操性最强的章节。Mihon 允许创建 Fork，但前提是遵守项目 LICENSE（仓库根目录 LICENSE，Apache-2.0 协议）。创建分支时官方给出三条必须执行的清单，下面结合源码逐条解读。

4.1 避免与主应用混淆：改应用名与应用图标

Fork 后首先要让用户能区分你的版本与官方 Mihon：

• 改应用名：需同步修改应用显示名称相关的资源与元数据；
• 改应用图标：默认图标资源位于 app/src/main/res/mipmap（ic_launcher相关文件）及 app/src/debug/res/drawable 下的ic_launcher_background/foreground等。替换图标是合规分支的标配操作，避免用户混淆官方版本。

4.2 避免安装冲突：修改 applicationId

Android 的applicationId是应用的唯一标识，若 Fork 沿用app.mihon，会与官方版互相覆盖安装。官方点名要求修改 app/build.gradle.kts 中的applicationId。

从源码看，当前默认值为：

defaultConfig { applicationId = "app.mihon" // 官方唯一标识，Fork 必须更换 versionCode = 32 versionName = "0.20.4" buildConfigField("boolean", "TELEMETRY_INCLUDED", "${Config.includeTelemetry}") buildConfigField("boolean", "UPDATER_ENABLED", "${Config.enableUpdater}") ... }

各 build type 还通过applicationIdSuffix派生变体，Fork 时同样需要注意避免与官方各变体冲突：

（以上行为均可在 app/build.gradle.kts 的buildTypes段落中查证。）

4.3 避免污染官方遥测与崩溃上报：替换 google-services.json

这是最容易踩坑的一条。官方要求：若 Fork 要使用 Firebase 分析，必须把 google-services.json 替换成自己的，否则你的分支用户数据会全部汇入官方 Mihon 的 Firebase 项目。

从仓库文件看，官方 google-services.json 中绑定的包名正是官方标识：

{ "project_info": { "project_id": "mihonapp", ... }, "client": [ { "client_info": { "android_client_info": { "package_name": "app.mihon" }, ...

这意味着：任何仍以app.mihon为包名、且直接复用官方google-services.json的 Fork，其崩溃报告与事件数据都会进入mihonapp这个 Firebase 项目，污染官方统计。合规做法是去 Firebase 控制台新建项目、替换为自己的配置文件。

另外需要说明：文档中给出的官方文件路径为app/src/standard/google-services.json，而本仓库中该文件位于根目录 app/google-services.json（仓库组织方式略有差异），但用途一致——按构建变体注入 Firebase 配置。

4.4 避免自动更新指向官方：处理 AppUpdateChecker

官方点名要求 Fork 修改或禁用应用更新检查器，其源码路径为 app/src/main/java/eu/kanade/tachiyomi/data/updater/AppUpdateChecker.kt。若不处理，你的 Fork 用户会被引导去检查并下载官方 Mihon 的更新，造成混乱。

源码核心逻辑如下：

@Inject class AppUpdateChecker( private val getApplicationRelease: GetApplicationRelease, ) { suspend fun checkForUpdate(forceCheck: Boolean = false): GetApplicationRelease.Result { return withIOContext { val result = getApplicationRelease.await( GetApplicationRelease.Arguments( isFossBuildType, isNightlyBuildType, BuildConfig.COMMIT_COUNT.toInt(), BuildConfig.VERSION_NAME, GITHUB_REPO, forceCheck, ), ) result } } } val GITHUB_REPO: String by lazy { if (isNightlyBuildType) { "mihonapp/mihon-preview" } else { "mihonapp/mihon" } }

解读要点：

• 更新检查通过GetApplicationRelease（定义于 domain 模块）查询 GitHub Release；
• 目标仓库由GITHUB_REPO决定：nightly构建指向mihonapp/mihon-preview，其余指向mihonapp/mihon；
• isNightlyBuildType/isFossBuildType等判定来自 app/src/main/java/eu/kanade/tachiyomi/util/system/BuildConfig.kt，本质是读取BuildConfig.BUILD_TYPE字符串比对（如BUILD_TYPE == "foss"）。

Fork 的应对方案（按官方建议）：

1. 修改：将GITHUB_REPO改为自己的仓库（如yourname/your-fork），并相应调整RELEASE_TAG的生成规则；
2. 禁用：更彻底的做法是移除或禁用AppUpdateChecker的调用入口，让更新检查完全不生效（例如在 UI 层不注入该依赖）。此外官方在build.gradle.kts中提供了UPDATER_ENABLED构建字段，Fork 也可借此开关控制更新功能是否编译进应用。

五、Fork 合规自查清单（实战速查）

综合以上章节，创建合规 Mihon 分支时的完整操作顺序如下：

1. 确认 License：分支必须遵守仓库根目录 LICENSE（Apache-2.0），保留版权与许可声明；
2. 更换应用名：修改应用显示名称相关资源；
3. 更换应用图标：替换mipmap/drawable下的启动图标资源；
4. 更换applicationId：在 app/build.gradle.kts 中改为自己的包名，避免与官方及官方各变体（.dev、.foss、.debug、.benchmark）冲突；
5. 替换google-services.json：如需 Firebase 功能，使用自己的项目配置；不需要可直接移除；
6. 修改或禁用更新检查：改动 AppUpdateChecker.kt 中的GITHUB_REPO，或禁用更新功能，防止分支用户被引导至官方 Release 页面。

六、给贡献者的流程建议（基于仓库的推断）

结合本指南与仓库现状，可以给出以下操作性建议（属于合理推断，非官方承诺）：

• 先小后大：从good first issue或文档类、i18n 类改动入手，熟悉 PR 流程后再触碰核心逻辑；
• 跑通构建：改动前先在本地用 Android Studio 打开仓库根目录（settings.gradle.kts 已声明:app及各核心模块），确认能够编译运行；
• 遵守模块边界：Mihon 分层清晰（presentation→domain→data），PR 中尽量保持改动落在对应层内；
• 翻译走 Weblate：不要对 i18n/src/commonMain/moko-resources 下的字符串文件直接提 PR，翻译一律通过外部 Weblate 平台提交，避免与自动化同步冲突。

结语

CONTRIBUTING.md 篇幅不长，但信息密度很高：它划定了 Mihon 社区的参与规则（评论认领、无需指派）、硬性技能门槛（Android + Kotlin）、翻译的 Weblate 外部流程，以及三条必须落实的 Fork 合规项（应用名/图标、applicationId、google-services.json与更新检查）。结合源码逐条对照后可以看到，每条规则背后都有真实的工程原因——安装冲突、遥测污染、更新串台。遵循这套清单，你的 Fork 才能成为"独立、合规、不干扰官方"的健康分支。

• 移动开发