3.1 KiB
Repository Guidelines
Project Structure & Module Organization
This repository is an Obsidian-friendly documentation project for HarmonyOS APM analysis.
HarmonyOS APM分析报告_20260731.mdis the main report and source of truth for findings, calculations, and recommendations.report-assets/contains the screenshots referenced by the report. Keep assets close to the section that explains them through relative Markdown links such as..obsidian/stores workspace and appearance settings. Avoid committing personal workspace-state changes unless they are intentionally shared.
When adding a new report, use a descriptive name with a date (YYYYMMDD) and place its images in report-assets/ or a clearly named report-specific subdirectory.
Build, Test, and Development Commands
There is no compilation step or package-managed test suite. Edit and preview the Markdown in Obsidian or another CommonMark-compatible viewer.
Useful repository checks:
git status --short
rg 'report-assets/' '*.md'
find report-assets -type f | sort
Use these to review changed files, inspect asset references, and inventory screenshots before committing. Confirm every image renders and every table remains readable in preview.
Coding Style & Naming Conventions
Use UTF-8 Markdown, ATX headings (#, ##), fenced code blocks with a language tag, and pipe tables with right-aligned numeric columns where appropriate. Keep heading levels sequential and write concise, evidence-based Chinese prose consistent with the existing report. Use backticks for event types, API names, versions, and identifiers.
Name screenshots with a two-digit sequence and a short lowercase description, for example 08-grafana-native-detail.png. Do not replace an existing image with unrelated evidence under the same filename.
Testing Guidelines
Validation is manual. Before submitting changes:
- Preview the full report and check headings, tables, code blocks, and image captions.
- Recalculate totals and confirm date ranges, versions, and event classifications against the source screenshots.
- Verify all referenced files exist and that no local absolute paths or sensitive operational data were introduced.
Commit & Pull Request Guidelines
Use Conventional Commit-style subjects in the form <type>: <summary>, such as docs: clarify OOM crash accounting or feat: 完善启动性能监控流程. For non-trivial changes, add a blank line followed by - list items describing the concrete behavior, implementation, and verification. Keep the subject concise and do not repeat it in the body. Keep related code, documentation, and supporting assets in the same commit.
feat: 完善启动性能监控流程
- 保证每个进程只提交一次首帧完成事件
- 按启动事件唯一键去重上报
- 在真机验证登录与网络异常场景
Pull requests should summarize the conclusion changed, identify the data period and source, list added or replaced assets, and call out any unresolved evidence gaps. Include rendered screenshots when formatting changes are substantial and link the relevant issue when one exists.