移动开发【免费下载链接】mihonFree and open source manga reader for Android项目地址https://gitcode.com/gh_mirrors/mi/mihon点击查看免费下载本篇技术指南以仓库根目录的 CONTRIBUTING.md 为骨架系统讲解 MihonFree and open source manga reader for Android的代码贡献流程、翻译协作机制与 Fork 合规要点并结合仓库内真实源码与构建配置如 app/build.gradle.kts、AppUpdateChecker.kt逐条印证每条规则背后的工程原因。读完你将掌握如何安全参与 Mihon 的 PR 与 Issue 流程、翻译工作在哪完成、以及如何在不违反 LICENSE 与不污染主项目遥测数据的前提下维护一个合规的 Mihon 分支。一、贡献总览先看 README再动手Mihon 官方贡献入口分两层问题反馈与功能请求按 README 文件 中的指引操作Issues / Feature Requests / Contributing 相关章节。贡献者应先在 README 中确认反馈通道与模板要求避免重复提交。代码贡献见本指南后续章节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仓库根目录 LICENSEApache-2.0 协议。创建分支时官方给出三条必须执行的清单下面结合源码逐条解读。4.1 避免与主应用混淆改应用名与应用图标Fork 后首先要让用户能区分你的版本与官方 Mihon改应用名需同步修改应用显示名称相关的资源与元数据改应用图标默认图标资源位于 app/src/main/res/mipmapic_launcher相关文件及 app/src/debug/res/drawable 下的ic_launcher_background/foreground等。替换图标是合规分支的标配操作避免用户混淆官方版本。4.2 避免安装冲突修改 applicationIdAndroid 的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 时同样需要注意避免与官方各变体冲突buildTypeapplicationIdSuffix说明debug.dev开发调试版release无正式版启用 minify 与资源收缩foss.foss无遥测/无更新检查的开源变体nightly.debug夜间预览版更新源指向mihonapp/mihon-previewbenchmark.benchmark基准测试变体以上行为均可在 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/mihonisNightlyBuildType/isFossBuildType等判定来自 app/src/main/java/eu/kanade/tachiyomi/util/system/BuildConfig.kt本质是读取BuildConfig.BUILD_TYPE字符串比对如BUILD_TYPE foss。Fork 的应对方案按官方建议修改将GITHUB_REPO改为自己的仓库如yourname/your-fork并相应调整RELEASE_TAG的生成规则禁用更彻底的做法是移除或禁用AppUpdateChecker的调用入口让更新检查完全不生效例如在 UI 层不注入该依赖。此外官方在build.gradle.kts中提供了UPDATER_ENABLED构建字段Fork 也可借此开关控制更新功能是否编译进应用。五、Fork 合规自查清单实战速查综合以上章节创建合规 Mihon 分支时的完整操作顺序如下确认 License分支必须遵守仓库根目录 LICENSEApache-2.0保留版权与许可声明更换应用名修改应用显示名称相关资源更换应用图标替换mipmap/drawable下的启动图标资源更换applicationId在 app/build.gradle.kts 中改为自己的包名避免与官方及官方各变体.dev、.foss、.debug、.benchmark冲突替换google-services.json如需 Firebase 功能使用自己的项目配置不需要可直接移除修改或禁用更新检查改动 AppUpdateChecker.kt 中的GITHUB_REPO或禁用更新功能防止分支用户被引导至官方 Release 页面。六、给贡献者的流程建议基于仓库的推断结合本指南与仓库现状可以给出以下操作性建议属于合理推断非官方承诺先小后大从good first issue或文档类、i18n 类改动入手熟悉 PR 流程后再触碰核心逻辑跑通构建改动前先在本地用 Android Studio 打开仓库根目录settings.gradle.kts 已声明:app及各核心模块确认能够编译运行遵守模块边界Mihon 分层清晰presentation→domain→dataPR 中尽量保持改动落在对应层内翻译走 Weblate不要对 i18n/src/commonMain/moko-resources 下的字符串文件直接提 PR翻译一律通过外部 Weblate 平台提交避免与自动化同步冲突。结语CONTRIBUTING.md 篇幅不长但信息密度很高它划定了 Mihon 社区的参与规则评论认领、无需指派、硬性技能门槛Android Kotlin、翻译的 Weblate 外部流程以及三条必须落实的 Fork 合规项应用名/图标、applicationId、google-services.json与更新检查。结合源码逐条对照后可以看到每条规则背后都有真实的工程原因——安装冲突、遥测污染、更新串台。遵循这套清单你的 Fork 才能成为独立、合规、不干扰官方的健康分支。赞分享移动开发【免费下载链接】mihonFree and open source manga reader for Android项目地址https://gitcode.com/gh_mirrors/mi/mihon点击查看免费下载相关推荐为 Real-ESRGAN 贡献代码Fork-PR 协作流程、代码规范与微调优化实战指南为 Real ESRGAN 贡献代码Fork PR 协作流程、代码规范与微调优化实战指南 导读 本文基于仓库 docs/CONTRIBUTING.md ht人工智能深度学习计算机视觉图像处理PicoClaw 贡献开发全指南从 Fork 到合入的协作流程与 AI 辅助贡献规范PicoClaw 贡献开发全指南从 Fork 到合入的协作流程与 AI 辅助贡献规范 PicoClaw 是一个社区驱动的开源个人 AI 助手项目目标是构建人工智能AI 应用AI Agent交互助手工具调用MCP ClientsAgent 记忆CANN/asc-devkit内存消毒样例msSanitizer样例说明 概述 msSanitizer用于检测Ascend C样例运行过程中的内存访问、内存泄漏、未使用内存、竞争和未初始化访问等异常。本人工智能深度学习算子库CANNAscend上一篇Windows界面定制终极指南ExplorerPatcher完全配置手册下一篇Bubble Navigation10分钟快速打造精美Android导航栏的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Mihon 贡献指南深度解读：代码贡献、翻译协作与 Fork 规范实战
移动开发【免费下载链接】mihonFree and open source manga reader for Android项目地址https://gitcode.com/gh_mirrors/mi/mihon点击查看免费下载本篇技术指南以仓库根目录的 CONTRIBUTING.md 为骨架系统讲解 MihonFree and open source manga reader for Android的代码贡献流程、翻译协作机制与 Fork 合规要点并结合仓库内真实源码与构建配置如 app/build.gradle.kts、AppUpdateChecker.kt逐条印证每条规则背后的工程原因。读完你将掌握如何安全参与 Mihon 的 PR 与 Issue 流程、翻译工作在哪完成、以及如何在不违反 LICENSE 与不污染主项目遥测数据的前提下维护一个合规的 Mihon 分支。一、贡献总览先看 README再动手Mihon 官方贡献入口分两层问题反馈与功能请求按 README 文件 中的指引操作Issues / Feature Requests / Contributing 相关章节。贡献者应先在 README 中确认反馈通道与模板要求避免重复提交。代码贡献见本指南后续章节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仓库根目录 LICENSEApache-2.0 协议。创建分支时官方给出三条必须执行的清单下面结合源码逐条解读。4.1 避免与主应用混淆改应用名与应用图标Fork 后首先要让用户能区分你的版本与官方 Mihon改应用名需同步修改应用显示名称相关的资源与元数据改应用图标默认图标资源位于 app/src/main/res/mipmapic_launcher相关文件及 app/src/debug/res/drawable 下的ic_launcher_background/foreground等。替换图标是合规分支的标配操作避免用户混淆官方版本。4.2 避免安装冲突修改 applicationIdAndroid 的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 时同样需要注意避免与官方各变体冲突buildTypeapplicationIdSuffix说明debug.dev开发调试版release无正式版启用 minify 与资源收缩foss.foss无遥测/无更新检查的开源变体nightly.debug夜间预览版更新源指向mihonapp/mihon-previewbenchmark.benchmark基准测试变体以上行为均可在 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/mihonisNightlyBuildType/isFossBuildType等判定来自 app/src/main/java/eu/kanade/tachiyomi/util/system/BuildConfig.kt本质是读取BuildConfig.BUILD_TYPE字符串比对如BUILD_TYPE foss。Fork 的应对方案按官方建议修改将GITHUB_REPO改为自己的仓库如yourname/your-fork并相应调整RELEASE_TAG的生成规则禁用更彻底的做法是移除或禁用AppUpdateChecker的调用入口让更新检查完全不生效例如在 UI 层不注入该依赖。此外官方在build.gradle.kts中提供了UPDATER_ENABLED构建字段Fork 也可借此开关控制更新功能是否编译进应用。五、Fork 合规自查清单实战速查综合以上章节创建合规 Mihon 分支时的完整操作顺序如下确认 License分支必须遵守仓库根目录 LICENSEApache-2.0保留版权与许可声明更换应用名修改应用显示名称相关资源更换应用图标替换mipmap/drawable下的启动图标资源更换applicationId在 app/build.gradle.kts 中改为自己的包名避免与官方及官方各变体.dev、.foss、.debug、.benchmark冲突替换google-services.json如需 Firebase 功能使用自己的项目配置不需要可直接移除修改或禁用更新检查改动 AppUpdateChecker.kt 中的GITHUB_REPO或禁用更新功能防止分支用户被引导至官方 Release 页面。六、给贡献者的流程建议基于仓库的推断结合本指南与仓库现状可以给出以下操作性建议属于合理推断非官方承诺先小后大从good first issue或文档类、i18n 类改动入手熟悉 PR 流程后再触碰核心逻辑跑通构建改动前先在本地用 Android Studio 打开仓库根目录settings.gradle.kts 已声明:app及各核心模块确认能够编译运行遵守模块边界Mihon 分层清晰presentation→domain→dataPR 中尽量保持改动落在对应层内翻译走 Weblate不要对 i18n/src/commonMain/moko-resources 下的字符串文件直接提 PR翻译一律通过外部 Weblate 平台提交避免与自动化同步冲突。结语CONTRIBUTING.md 篇幅不长但信息密度很高它划定了 Mihon 社区的参与规则评论认领、无需指派、硬性技能门槛Android Kotlin、翻译的 Weblate 外部流程以及三条必须落实的 Fork 合规项应用名/图标、applicationId、google-services.json与更新检查。结合源码逐条对照后可以看到每条规则背后都有真实的工程原因——安装冲突、遥测污染、更新串台。遵循这套清单你的 Fork 才能成为独立、合规、不干扰官方的健康分支。赞分享移动开发【免费下载链接】mihonFree and open source manga reader for Android项目地址https://gitcode.com/gh_mirrors/mi/mihon点击查看免费下载相关推荐为 Real-ESRGAN 贡献代码Fork-PR 协作流程、代码规范与微调优化实战指南为 Real ESRGAN 贡献代码Fork PR 协作流程、代码规范与微调优化实战指南 导读 本文基于仓库 docs/CONTRIBUTING.md ht人工智能深度学习计算机视觉图像处理PicoClaw 贡献开发全指南从 Fork 到合入的协作流程与 AI 辅助贡献规范PicoClaw 贡献开发全指南从 Fork 到合入的协作流程与 AI 辅助贡献规范 PicoClaw 是一个社区驱动的开源个人 AI 助手项目目标是构建人工智能AI 应用AI Agent交互助手工具调用MCP ClientsAgent 记忆CANN/asc-devkit内存消毒样例msSanitizer样例说明 概述 msSanitizer用于检测Ascend C样例运行过程中的内存访问、内存泄漏、未使用内存、竞争和未初始化访问等异常。本人工智能深度学习算子库CANNAscend上一篇Windows界面定制终极指南ExplorerPatcher完全配置手册下一篇Bubble Navigation10分钟快速打造精美Android导航栏的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考