54 lines
3.1 KiB
Markdown
54 lines
3.1 KiB
Markdown
# Repository Guidelines
|
|
|
|
## Project Structure & Module Organization
|
|
|
|
This repository is an Obsidian-friendly documentation project for HarmonyOS APM analysis.
|
|
|
|
- `HarmonyOS APM分析报告_20260731.md` is 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:
|
|
|
|
```sh
|
|
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:
|
|
|
|
1. Preview the full report and check headings, tables, code blocks, and image captions.
|
|
2. Recalculate totals and confirm date ranges, versions, and event classifications against the source screenshots.
|
|
3. 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.
|
|
|
|
```text
|
|
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.
|