ohos-design-arkui-api-competitive-analysis

ArkUI API Competitive Analysis

Produce a structurally consistent, evidence-traceable Android/iOS benchmarking report for specified ArkUI public UI APIs. Analyze only public capabilities and migration impact; minimal usage examples are allowed, but do not modify product code or the ace_engine implementation.

Task Boundaries

Input: ArkUI API, component, or capability topic; analysis purpose; default Android+iOS benchmarking platforms; optional scope level, platform versions, and report depth.

Output: Analysis Brief, Capability Checklist, Comparator Map, three-platform facts, capability matrix, impact assessment, graded recommendations, items to be verified, and source audit.

Not applicable: performance measurement, product code implementation, Flutter/Web benchmarking, ace_engine modification, or judging public capabilities solely based on internal implementation and unofficial materials.

Non-violable Rules

Rule responsibilities are governed by the referenced files:workflow.md is the sole source for phase order and gates,analysis-dimensions.md is the sole source for subtype closure,platform-source-routing.md is the sole source for Android/iOS paths and official entry points,report-template.md is the sole source for output order and conditional blocks. This section retains only cross-phase hard constraints; when summary wording is inconsistent with the referenced files, the corresponding responsibility file prevails.

Use interface_sdk-js as the authoritative source for ArkUI public interface definitions; ace_engine internal definitions may only be used for implementation comparison.
For Android and iOS evidence collection, prioritize each platform's official documentation, in the order of official API Reference, Guide, Sample; platform source code serves only as implementation corroboration, and community materials are used only to locate official entry points.
Lock the scope level and platform versions before research; do not lower the user-specified level or mix different versions.
First extract facts for the three platforms separately, then compare; do not pre-write conclusions such as "better, missing, unique" during the evidence collection phase.
Benchmarking relationships may only be marked as direct equivalent, functional equivalent, composite implementation, alternative solution, or no equivalent capability found.
Record official facts and analytical inferences separately; every substantive assertion must be traceable to a Fact ID and Source ID.
Complete bidirectional searches for "missing, unique, superior"; when evidence is insufficient, mark 待核, and do not proceed to definitive conclusions.
Domain facts must be dynamically collected from official sources according to the locked version; do not rely on built-in field quick-reference tables, and do not apply the fields, states, or check items of one domain to other domains.
The Analysis Brief must be the first user-visible phase artifact; before it, do not output conclusion summaries, platform pros and cons, or API recommendations.
When the user requests "names only," "one-page conclusion," or other compressed output, use report-template.md 's quick-scan single table; retain at least the scope, Comparator Map, one defined Fact/Claim, sources, and pending-verification status; similar names cannot replace mapping judgment.
Hit analysis-dimensions.md For the specific subtypes defined, such as raw touch/pointer, keyboard shortcuts, continuous gestures, virtualized collections, Flex-like layouts, or explicit animations, the corresponding closed-loop checklist must be completed; for each item, fill in the Coverage status (confirmed, pending, or not-applicable), and broad "event" triggers must not be used to apply other input subtype rules.
Every Capability, Fact, Claim, and Source ID referenced in the output must be defined in the same deliverable; IDs that exist only in internal processes must not be referenced.
When the user requests skipping the official documentation, clearly state that Android Developers and Apple Developer cannot be skipped, and follow platform-source-routing.md to explain the evidentiary roles of official documentation, platform source code, and community materials.
The required fields, statuses, and closed-loop scope for subtypes are governed solely by analysis-dimensions.md ; this document does not reproduce its checklist.
The Path Check, candidate APIs, exclusions, and official evidence-gathering entry points for keyboard shortcuts are governed solely by platform-source-routing.md ; the Comparator Map can be confirmed only after the specified path facts are completed. Other interactions are evidenced according to their own dispatch, hit-testing, arbitration, or responder facts, and the keyboard Path Check table must not be applied to them.
The condition matrix, Path Check order, and quick/full report structure are governed solely by report-template.md ; condition blocks must not be deleted when they are hit.
When official sources conflict and the input is incomplete, you must request the exact symbol, public definition path, documentation link, version baselines for both sides, and documentation time information; a preset baseline must not be used in place of missing input.
When a public signature references a named constant, enum, or sub-property page, continue tracing the official definition until the specific value, default value, unit, and semantics form a closed loop; available official precise sources must not be left as pending。
Every Comparator Map in the full report and quick scan must use the canonical schema of evidence-ledger.md : for Android/iOS, fill in target, mapping type, and rationale/exclusions respectively, and associate the Fact ID, Source ID, Claim ID, and Claim status that support each platform mapping; ArkUI unilateral evidence must not be used to support competitor mappings, and platform mapping types must not be omitted or merged.

Progressive loading

Stage or condition	Read content	Do not load before this
Start analysis	Read in full `references/workflow.md`	None
Draft the Analysis Brief, select specific subtypes, and break down capabilities	Read in full `references/analysis-dimensions.md`	Do not load when the Target and Scope tier have not yet been identified
Establish the facts and claims ledger	Read in full `references/evidence-ledger.md`	Do not load when the Capability Checklist has not yet been formed
Extract ArkUI public definitions	Read in full `references/authoritative-sources.md`	Do not load when the ArkUI evidence-gathering stage has not yet been entered
Map Android/iOS counterparts	Read in full `references/platform-source-routing.md`	Do not load when ArkUI atomic capabilities have not yet been broken down
Generate the formal report	Read in full `assets/report-template.md`	Do not load when facts, mappings, and claims have not yet been audited

Do not load all resources at once at the beginning; when reaching a stage in the table, you must read the corresponding file in full, not just the beginning or the table of contents.

Execution order

Detailed stage deliverables, gates, and fallback rules are governed by references/workflow.md :

分析契约
  -> 能力拆解
  -> 对标对象映射
  -> 各平台独立取证
  -> 规格归一化
  -> 断言审计
  -> 差异与影响
  -> 分级建议
  -> 报告与质量门禁

Report mode

Mode	Applicable Scenarios	Required Content
Quick Scan	Direction Judgment	Analysis Brief, Comparator Map, Core Matrix, Key Risks, Items to Verify, Sources
Full Report	Design Review, Migration Plan, Formal Materials	All phase outputs, minimal usage, item-by-item assertions, impact assessment, and P0/P1/P2 recommendations

Neither mode may omit the version baseline, authoritative sources, scope, fact/inference distinction, and to-verify markers.

Even if the user requests an extremely short answer, use the Quick Scan single table to define the necessary Analysis Brief, Comparator Map, Fact/Claim, and sources; do not directly return a list of API names.

Completion Criteria

Analysis Brief, Comparator Map, Fact Ledger, and Claim Ledger are completed.
All deterministic conclusions have official sources, and all inferences are explicitly marked.
"Missing, unique, superior" has completed bidirectional retrieval.
Recommendations are linked one-to-one with difference evidence.
Version, scope, sources, Fact/Claim associations, and to-verify items have been checked according to this Skill's completion criteria.