arkanalyzer 1.0.89 → 1.0.91

package/lib/utils/entryMethodUtils.d.ts

@@ -4,6 +4,29 @@ import { Stmt } from '../core/base/Stmt';
 export declare const LIFECYCLE_METHOD_NAME: string[];
 export declare const CALLBACK_METHOD_NAME: string[];
 export declare const COMPONENT_LIFECYCLE_METHOD_NAME: string[];
+/**
+ * 首块方法：创建阶段一次性执行、不可重复触发。
+ * 列表顺序严格遵循系统调度时序。
+ * Ability 创建 → 窗口/会话创建 → Component 创建
+ */
+export declare const LIFECYCLE_START_METHODS: string[];
+/**
+ * 尾块方法：销毁阶段一次性执行、不可重复触发。
+ * 列表顺序严格遵循系统调度时序。
+ * 窗口开始销毁 → 组件清理 → 窗口销毁完成 → Ability 销毁
+ */
+export declare const LIFECYCLE_END_METHODS: string[];
+/**
+ * 成对/成组出现的生命周期方法。
+ * 同一组中的方法在运行时交替循环出现，放入同一 basic block。
+ * 组内顺序严格遵循系统调度时序。
+ * 配对原则：交替循环出现 + 存在数据流依赖。
+ */
+export declare const LIFECYCLE_PAIRED_METHOD_GROUPS: string[][];
+/**
+ * 返回方法名所属的配对组索引，不属于任何配对组则返回 -1。
+ */
+export declare function getPairedMethodGroupIndex(methodName: string): number;
 export interface AbilityMessage {
     srcEntry: string;
     name: string;

package/lib/utils/entryMethodUtils.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"entryMethodUtils.d.ts","sourceRoot":"","sources":["../../src/utils/entryMethodUtils.ts"],"names":[],"mappings":"AAeA,OAAO,EAAE,KAAK,EAAE,MAAM,UAAU,CAAC;AACjC,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AACpD,OAAO,EAAE,IAAI,EAAE,MAAM,mBAAmB,CAAC;AAGzC,eAAO,MAAM,qBAAqB,EAAE,MAAM,EAmCzC,CAAC;AAEF,eAAO,MAAM,oBAAoB,EAAE,MAAM,EAiBxC,CAAC;AAEF,eAAO,MAAM,+BAA+B,EAAE,MAAM,EAmBnD,CAAC;AAEF,MAAM,WAAW,cAAc;IAC3B,QAAQ,EAAE,MAAM,CAAC;IACjB,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,CAAC;CACvB;AAED,wBAAgB,yBAAyB,CAAC,IAAI,EAAE,IAAI,EAAE,KAAK,EAAE,KAAK,GAAG,SAAS,GAAG,IAAI,CAoBpF;AAED,wBAAgB,WAAW,CAAC,MAAM,EAAE,SAAS,GAAG,IAAI,CASnD"}
+{"version":3,"file":"entryMethodUtils.d.ts","sourceRoot":"","sources":["../../src/utils/entryMethodUtils.ts"],"names":[],"mappings":"AAeA,OAAO,EAAE,KAAK,EAAE,MAAM,UAAU,CAAC;AACjC,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AACpD,OAAO,EAAE,IAAI,EAAE,MAAM,mBAAmB,CAAC;AAGzC,eAAO,MAAM,qBAAqB,EAAE,MAAM,EAmCzC,CAAC;AAEF,eAAO,MAAM,oBAAoB,EAAE,MAAM,EAiBxC,CAAC;AAEF,eAAO,MAAM,+BAA+B,EAAE,MAAM,EAmBnD,CAAC;AAEF;;;;GAIG;AACH,eAAO,MAAM,uBAAuB,EAAE,MAAM,EAK3C,CAAC;AAEF;;;;GAIG;AACH,eAAO,MAAM,qBAAqB,EAAE,MAAM,EAOzC,CAAC;AAEF;;;;;GAKG;AACH,eAAO,MAAM,8BAA8B,EAAE,MAAM,EAAE,EASpD,CAAC;AAEF;;GAEG;AACH,wBAAgB,yBAAyB,CAAC,UAAU,EAAE,MAAM,GAAG,MAAM,CAOpE;AAED,MAAM,WAAW,cAAc;IAC3B,QAAQ,EAAE,MAAM,CAAC;IACjB,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,CAAC;CACvB;AAED,wBAAgB,yBAAyB,CAAC,IAAI,EAAE,IAAI,EAAE,KAAK,EAAE,KAAK,GAAG,SAAS,GAAG,IAAI,CAoBpF;AAED,wBAAgB,WAAW,CAAC,MAAM,EAAE,SAAS,GAAG,IAAI,CASnD"}

package/lib/utils/entryMethodUtils.js

@@ -14,7 +14,7 @@
  * limitations under the License.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.addCfg2Stmt = exports.getCallbackMethodFromStmt = exports.COMPONENT_LIFECYCLE_METHOD_NAME = exports.CALLBACK_METHOD_NAME = exports.LIFECYCLE_METHOD_NAME = void 0;
+exports.addCfg2Stmt = exports.getCallbackMethodFromStmt = exports.getPairedMethodGroupIndex = exports.LIFECYCLE_PAIRED_METHOD_GROUPS = exports.LIFECYCLE_END_METHODS = exports.LIFECYCLE_START_METHODS = exports.COMPONENT_LIFECYCLE_METHOD_NAME = exports.CALLBACK_METHOD_NAME = exports.LIFECYCLE_METHOD_NAME = void 0;
 const Type_1 = require("../core/base/Type");
 exports.LIFECYCLE_METHOD_NAME = [
     'onCreate',
@@ -90,6 +90,58 @@ exports.COMPONENT_LIFECYCLE_METHOD_NAME = [
     'onMeasure',
     'onMeasureSize',
 ];
+/**
+ * 首块方法：创建阶段一次性执行、不可重复触发。
+ * 列表顺序严格遵循系统调度时序。
+ * Ability 创建 → 窗口/会话创建 → Component 创建
+ */
+exports.LIFECYCLE_START_METHODS = [
+    'onCreate',
+    'onWindowStageCreate',
+    'onSessionCreate',
+    'aboutToAppear', // Component 实例创建后、build() 前调用
+];
+/**
+ * 尾块方法：销毁阶段一次性执行、不可重复触发。
+ * 列表顺序严格遵循系统调度时序。
+ * 窗口开始销毁 → 组件清理 → 窗口销毁完成 → Ability 销毁
+ */
+exports.LIFECYCLE_END_METHODS = [
+    'onWindowStageWillDestroy',
+    'aboutToDisappear',
+    'onDetached',
+    'onWindowStageDestroy',
+    'onSessionDestory',
+    'onDestroy', // Ability 最终销毁
+];
+/**
+ * 成对/成组出现的生命周期方法。
+ * 同一组中的方法在运行时交替循环出现，放入同一 basic block。
+ * 组内顺序严格遵循系统调度时序。
+ * 配对原则：交替循环出现 + 存在数据流依赖。
+ */
+exports.LIFECYCLE_PAIRED_METHOD_GROUPS = [
+    // 组件复用：recycle（加入复用池）→ reuse（从池取出），交替循环
+    ['aboutToRecycle', 'aboutToReuse'],
+    // 页面显示/隐藏：交替循环
+    ['onPageShow', 'onPageHide'],
+    // 前台/后台切换：前台序列 → 后台序列，交替循环
+    ['onWillForeground', 'onForeground', 'onDidForeground', 'onWillBackground', 'onBackground', 'onDidBackground'],
+    // 卡片回收/恢复：交替循环
+    ['onFormRecycle', 'onFormRecover'],
+];
+/**
+ * 返回方法名所属的配对组索引，不属于任何配对组则返回 -1。
+ */
+function getPairedMethodGroupIndex(methodName) {
+    for (let i = 0; i < exports.LIFECYCLE_PAIRED_METHOD_GROUPS.length; i++) {
+        if (exports.LIFECYCLE_PAIRED_METHOD_GROUPS[i].includes(methodName)) {
+            return i;
+        }
+    }
+    return -1;
+}
+exports.getPairedMethodGroupIndex = getPairedMethodGroupIndex;
 function getCallbackMethodFromStmt(stmt, scene) {
     const invokeExpr = stmt.getInvokeExpr();
     if (invokeExpr === undefined ||

package/package.json

@@ -1,8 +1,7 @@
 {
   "name": "arkanalyzer",
-  "version": "1.0.89",
+  "version": "1.0.91",
   "files": [
-    "docs",
     "lib",
     "config"
   ],
@@ -13,17 +12,19 @@
   "scripts": {
     "prebuild": "node script/npmInstall.js",
     "build": "tsc",
-    "build:cpp": "node script/buildCpp.js",
-    "prepack": "npm run build && tsc -p ./tsconfig.prod.json && node script/vendorOhosTypescript.js && copyfiles -f arkCppAst/* lib/ast",
-    "test": "npm run build && vitest",
-    "testonce": "npm run build && vitest run",
-    "coverage": "npm run build && vitest run --coverage",
+    "build:cpp": "node script/cpp/buildCpp.js",
+    "test:cpp": "node script/cpp/testCpp.js",
+    "prepack": "node script/prepackPack.js",
+    "postpack": "node script/postpackPack.js",
+    "test": "npm run build && node script/cpp/vitestCpp.js && vitest",
+    "testonce": "npm run build && node script/cpp/vitestCpp.js && vitest run",
+    "coverage": "npm run build && node script/cpp/vitestCpp.js && vitest run --coverage",
     "heapdump": "npm run build && node --expose-gc out/tests/HeapDumpTest.js",
     "perf:arkts": "npm run build && node --max-old-space-size=4096 --expose-gc --perf-basic-prof -r ts-node/register tests/samples/perf/main.ts --project=photos",
-    "perf:cpp": "npm run build && node --max-old-space-size=16384 --expose-gc --perf-basic-prof -r ts-node/register tests/samples/perf/main.ts --project=opencv",
+    "perf:cpp": "npm run build && npm run build:cpp && node --max-old-space-size=16384 --expose-gc --perf-basic-prof -r ts-node/register tests/samples/perf/main.ts --project=opencv",
     "gendoc": "npm run build && npx typedoc",
-    "format": "npx prettier --write src/ tests/",
-    "format:check": "npx prettier --check src/ tests/"
+    "format": "npx prettier --write src/ tests/ packages/",
+    "format:check": "npx prettier --check src/ tests/ packages/"
   },
   "dependencies": {
     "commander": "13.1.0",
@@ -32,7 +33,6 @@
   "devDependencies": {
     "@types/node": "^25.5.0",
     "@vitest/coverage-v8": "^1.5.0",
-    "copyfiles": "^2.4.1",
     "node-api-headers": "^1.1.0",
     "ohos-typescript": "^4.9.5-r4",
     "ts-node": "^10.9.1",

package/docs/HowToCreatePR.md

@@ -1,55 +0,0 @@
-# 中文 
-本指导是对[openharmony-sig提交代码规范](https://gitee.com/openharmony-sig/sig-content/blob/master/Infrastructure/docs/manual/gitee%E6%8F%90pr%E5%B8%B8%E8%A7%84%E6%93%8D%E4%BD%9C.md)的扩充
-
-开发者对仓库修改，统一采用向对应仓库提PR的方式来做修改。提PR的方式有两种：
-1. fork工作仓方式：相关的gitee操作请参考此[链接](https://gitee.com/help/articles/4128#article-header0)。
-2. 评审模式：直接向主仓push代码，gitee自动生成PR。相关的操作参考此[链接](https://gitee.com/help/articles/4346)。
-
-以下为一次提交代码的步骤：
-1. **最重要**：提交代码时一定要记得使用git commit -s -m添加signed-off信息，且signed-off中涉及到的邮箱已经在[链接](https://dco.openharmony.io/sign/Z2l0ZWUlMkZvcGVuX2hhcm1vbnk=)中签署DCO
-
-2. 使用`git push origin <分支名>`将指定分支的本地仓库内容推到远端开发者fork仓库（fork工作仓方式）或远端主仓（评审模式）
-
-3. fork工作仓方式：进入远端fork 的仓库，点击新建PR,选择第2步中提交的分支。评审模式：一个PR会自动创建
-
-4. 在主仓新建ISSUE，ISSUE的类型和内容根据提交的代码特性按实际填写
-   
-5. 在PR页面右边栏的“关联ISSUE”选择第4步创建的ISSUE（不关联无法触发门禁）
-   
-6. 在PR页面右边栏选择审查人员
-   
-7. 在评论中输入`start build`，几秒后会触发门禁
-    
-8. 等待门禁后台审核
-
-   * 如果提交的PR显示DCO检查成功，等待管理员审核通过即可，如果DCO检查失败，请确认是否签署DCO。
-
-   * 提交以后，后台会进行自动化的法务合规、cicd的扫描，扫描结果会在提交的PR下以评论的形式展现出来
-
-   * 如果扫描有问题，需要根据反馈进行整改，然后再重新提交，直到审核通过
-  
-9. 门禁全部通过和人员审查通过后，会自动合并代码
-
-***
-# ENGLISH
-This guide is an expansion of the code submission standards of openharmony-sig.
-
-Developers should make modifications to the repository by submitting a PR (Pull Request) to the corresponding repository. There are two ways to submit a PR:
-
-1. Fork repository method: For related Gitee operations, please refer to this [link](https://gitee.com/help/articles/4128#article-header0).
-2. Review mode: Directly push the code to the main repository, and Gitee will automatically generate a PR. For related operations, please refer to this [link](https://gitee.com/help/articles/4346).
-   
-Here are the steps for a code submission:
-
-1. **Most importantly**: When committing code, always remember to use `git commit -s -m` to add signed-off information, and ensure that the email involved in the signed-off has signed the DCO (Developer Certificate of Origin) as [linked](https://dco.openharmony.io/sign/Z2l0ZWUlMkZvcGVuX2hhcm1vbnk=).
-2. Use `git push origin <branch-name>` to push the content of the specified branch in your local repository to the remote developer's forked repository (fork repository method) or to the remote main repository (review mode).
-3. Fork repository method: Enter the remote forked repository and click on "New Pull Request", selecting the branch submitted in step 2. Review mode: A PR will be automatically created.
-4. Create a new ISSUE in the main repository, and fill in the type and content of the ISSUE according to the features of the submitted code.
-5. On the right side of the PR page, under "Associated ISSUE", select the ISSUE created in step 4 (it cannot trigger the gate if not associated).
-6. On the right side of the PR page, select the reviewer.
-7. Enter "start build" in the comments to trigger the gate after a few seconds.
-8. Wait for the gate to be reviewed in the background.
-   * If the submitted PR shows that the DCO check is successful, wait for the administrator to review and pass. If the DCO check fails, please confirm whether you have signed the DCO.
-   * After submission, the background will carry out automated legal compliance and CI/CD scanning, and the results of the scan will be displayed in the form of comments under the submitted PR.
-   * If there are problems with the scan, they need to be rectified according to the feedback and then resubmitted until the review is passed.
-9. After all gates pass and the personnel review is passed, the code will be automatically merged.

package/docs/HowToHandleIssues.md

@@ -1,155 +0,0 @@
-## 1. Issue 分类
-
-所有新提交的 Issue 应该根据其类型进行分类。主要的分类包括：
-
-* Bug
-* 新功能需求
-* 疑问/支持请求
-* 任务
-
-## 2. 初步筛选
-
-当一个新的 Issue 被提交时，项目维护者应执行以下初步筛选步骤：
-
-1. **确认 Issue 描述是否清晰**：确保 Issue 的描述清晰并包含足够的信息。若描述不清晰，向提问者请求更多信息。
-2. **确认 Issue 分类是否正确**：检查 Issue 的分类是否正确，如果不正确，重新分类。
-
-## 3. 处理流程
-
-根据 Issue 的分类，采取不同的处理流程。
-各环节需要补充责任人
-
-### A. Bug
-
-1. **验证 Bug**
-   * 重现问题：尝试重现提到的问题，若为问题，打上标签跟踪。
-   * 收集更多信息：如果需要更多信息（如日志、错误消息、环境配置等），请求提问者提供。
-2. **优先级排序**
-   * 根据 Bug 的严重程度和影响范围，分配优先级。必解问题标为严重，例行跟踪。
-3. **分配处理**
-   * 指派给合适的开发人员进行处理。
-4. **修复 Bug**
-   * 开发人员修复 Bug 并提交 PR。
-5. **测试和关闭**
-   * 测试修复的有效性。
-   * 合并 PR 后关闭 Issue，并通知提问者。
-
-### B. 新功能需求
-
-1. **评估需求**
-   * 讨论需求的可行性和价值，若有价值录入版本需求。
-   * 收集社区和团队的反馈。
-2. **优先级排序**
-   * 根据项目的目标和资源分配优先级。
-3. **分配处理**
-   * 如果决定实施，指派给合适的开发人员进行设计和开发。
-4. **开发新功能**
-   * 开发人员设计、开发并提交 PR。
-5. **测试和发布**
-   * 测试新功能，确保其符合要求。
-   * 合并 PR 并更新文档后关闭 Issue，并通知提问者。
-
-### C. 疑问/支持请求
-
-1. **回应提问**
-   * 及时回应提问，提供解决方案或指导。
-   * 如果问题已在文档中详细说明，提供相关链接。
-2. **解决疑问**
-   * 如果问题复杂，需要进一步讨论和调查，可能需要分配给合适的人员。
-3. **关闭 Issue**
-   * 一旦问题得到解决或指导，关闭 Issue，并通知提问者。
-
-## 4. 通用规范
-
-* **响应时间**：尽量在 48 小时内响应新 Issue。
-* **沟通**：保持透明开放的沟通，确保 Issue 创建者了解 Issue 的处理进展。
-* **文档更新**：根据 Issue 处理过程中的发现和解决方案，及时更新项目文档。
-* **定期检查**：定期检查未关闭的 Issue，确保所有问题都得到适当处理。
-* **审核人**： [xulingyun-red](https://gitee.com/xulingyun-red)、[sfoolish](https://gitee.com/sfoolish)。
-* **标题**：标题可以添加tag方便查看，如[#arkcheckxx]、[#IRRefactorxx]。
-* **标签**：
-  * `Accept`: 审核通过。
-  * `Duplicate`: 重复Issue，注明重复的Issue号，并关闭。
-  * `Reject`: 拒绝Issue，注明拒绝理由（e.g. issue描述不清楚，长期未回复）。
-
-## 5. Milestone管理
-
-* 每月一个里程碑，里程碑名：M-YYYYMM
-* 月度版本需求和必解问题相关Issue标注Milestone和等级
-* 每月10日锁定当月的必交需求和必解问题，10日后的新增问题单独评估是否必解(遇到周末提前锁定)
-* 每月25日初步锁定下个月的必交需求和必解问题，25日后的新增需求单独评估是否必交(遇到周末提前锁定)
-* 加入Milestone的Issue等级：严重(转测前合入) > 主要(转测后可以合入) > 次要(可以遗留) > 不重要(可以遗留)
-
-## 6. 模板和标签
-
-为帮助开发/测试人员提交有效的 Issue，可以使用模板和标签：
-
-### Issue 模板
-
-**1.BUG模版/缺陷**
-
-```
-**【简要描述 / Description】：**
-
-**【测试步骤 / Test procedure】：**
-
-**【预期结果 / Expected result】：**
-
-**【实际结果 / Actual result】：**
-
-**【其它 / Others】：**
-- 1. Log、截图、多媒体文件等，所有和问题有关的信息：
-
-
-e.g.: https://gitee.com/openharmony-sig/arkanalyzer/issues/IAC3AX
-```
-
-**2.需求模版**
-
-```
-**【需求价值 / Value of the Requirement】：**
-
-**【需求描述 / Requirement Description】：**
-
-**【方案描述 / Solution Description】：**
-
-**【配套文档 / Supporting Documentation】：**
-
-**【验收标准 / Acceptance Criteria】：**
-
-e.g.: https://gitee.com/openharmony-sig/arkanalyzer/issues/IACEBC
-```
-
-**3.任务模版**
-
-```
-**【任务描述 / Task Description】：**
-
-**【解决方案 / Solution Description】：**
-
-**【任务来源 / Task Source】：**
-```
-
-## 7. 其它开发过程规范
-
-### A. 分支管理规范
-
-* 所有代码必须先合主干，再合商分。（特性分支除外，特性分支代码开发完后，也需要先回合主干再按需合入商分）
-* gitee与codehub同步创建月度Release分支，Release分支匹配Milestone的需求和必解问题交付。
-* 月度首版本转测后，release分支只合必解问题不合需求，不夹带合入。
-* 底座月度分支合入需要[sfoolish](https://gitee.com/sfoolish)审核，影响对外接口的同时需要[yifei-xue](https://gitee.com/yifei_xue)审核，接口文档需要yanglin审核。
-
-### B. PR提交规范
-
-* 代码合入前先Rebase
-* 代码PR需要刷新，建议通过`git commit --amend` + `git push -f` 刷新，想在主干保留中间状态，建议分多次PR提交
-* 新建的PR提交后都发到review群里
-
-### C. 代码检视 CheckList
-
-1. PR关联的issue已审核且处于open状态。
-2. issue描述、PR描述与代码实际修改保持一致。
-3. 对于一个问题或者需求的提交，不能夹带其它问题或需求的修改。
-4. 门禁问题和检视意见必须全部处理完毕。
-5. 代码保持一定比例的注释，确保在充分理解代码修改的情况下对代码进行检视和合入。
-6. bugfix类PR默认要补充UT用例。