[图片] 有开发者提过该问题，但至今尚未修复： 今年1月份：https://developers.weixin.qq.com/community/develop/doc/000a0a189f47c0ff266d753bb5bc00?highLine=sourcemap%2520%25E4%25B8%25BB%25E5%258C%2585%25E8%25A7%25A3%25E6%259E%2590%2520null去年9月份：https://developers.weixin.qq.com/community/develop/doc/000288fd5e0608d49dcc2476a5b400?highLine=sourcemap%2520%25E4%25B8%25BB%25E5%258C%2585%25E8%25A7%25A3%25E6%259E%2590%2520null 问下，在该Bug修复前，作为开发者的我们，有退一步的解决方案吗？

[图片] 还需要提供哪些额外信息吗？

测试手机：4个机型——2苹果、2安卓 测试步骤： 页面 index/index 为小程序启动页，在 onLoad 生命周期中 redirectTo 到 ob/index 页面查看 wx.getPerformance().getEntries() 数据4个机型中，红米 Note 8 Pro 有以下两个问题： route 的 path 出错route 的 navigationStart < startTime[图片] ———————————— 诉求： 请帮忙确认影响范围当前，对于开发而言，是否有兼容方案来处理这类问题

测试步骤： 冷启动小程序。同时，在一旁用秒表，记录冷启动的点击时间，记为A。（备注：冷启动是，在小程序列表，下拉删除该小程序，然后再次点击启动该小程序）小程序启动后，通过 wx.getPerformance().getEntries() 方法查看 appLaunch 条目的 startTime，记为 B。比较 A 和 B在测试中，用两台安卓和两台苹果手机分别测试。测试结果： 安卓手机中，B - A ≈ ±100ms苹果手机中，B - A ≈ 2s，估计是某个步骤的耗时未统计（两台苹果手机是 iPhone 8 Plus 和 iPhone 11）部分操作过程截图： [图片]

查看代码片段 https://developers.weixin.qq.com/s/xrwuOMmM7Ux1 代码片段中，仅有一个页面，该页面打开时，会有至少两条的 fcp 性能条目。这是 BUG 吗？如果是，方便分享下产生该 BUG 的底层原因吗？ [图片]

Q1：我确认下，这个结论对吗？ 在微信首页下拉，这里的「最近使用的小程序」或「我的小程序」，拖动删除后，小程序会被销毁。但代码包，不会在此时被清理。 Q2：那么，代码包的清理机制是？ ——————以下是参考的官方文档—————— 1、小程序运行机制 从用户认知的角度看，广义的小程序启动可以分为两种情况，一种是冷启动，一种是热启动。 冷启动：如果用户首次打开，或小程序销毁后被用户再次打开，此时小程序需要重新加载启动，即冷启动。热启动：如果用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时小程序并未被销毁，只是从后台状态进入前台状态，这个过程就是热启动。2、小程序更新机制 含未启动时更新和启动时更新 3、文件系统 清理策略 本地临时文件只保证在小程序当前生命周期内，一旦小程序被关闭就可能被清理，即下次冷启动不保证可用。本地缓存文件和本地用户文件的清理时机跟代码包一样，只有在代码包被清理的时会被清理。

之前问的一个问题：https://developers.weixin.qq.com/community/develop/doc/000c2c83f9cee8212b8d061ad57800 得到的答复是：“PerformanceObserver 的监听会有延迟，不保证和生命周期有时序关系”。 想确认下：PerformanceObserver 的监听有可能延迟，但不会提前，对吧？ 举两个例子： 例子1： PerformanceObserver 的 route（记为A）page#onReady（记为B）理论上：A < B实际上，可能：A >= B（该场景是因为 PerformanceObserver 的延迟）例子2： PerformanceObserver 的 firstRender / firstPaint / firstContentfulPaint（记为A）page#onLoad / page#onShow（记为B）理论上：A > B实际上：A > B（只会延迟，因此该顺序不变）

PerformanceEntry：https://developers.weixin.qq.com/miniprogram/dev/api/base/performance/PerformanceEntry.html 在 PerformanceEntry 中的 evaluateScript（逻辑层 JS 代码注入耗时），在打开主包和分包时，都有可能出现多个条目。那么，计算某个包（主包或分包）的逻辑代码注入总耗时，应该怎么计算？ 它们是串行的，把各条目的 duration 求和它们是并行的，且时间起点一样，取 duration 最大值它们是并行的，且时间起点不一样，无法统计

是因为终点不是这样计算，还是它们就是有差值的？ [图片]

通过打日志查看，在打开一个页面，并且页面首次渲染完成时：页面生命周期钩子(onLoad, onShow, onReady)都触发完后，通过 PerformanceObserver 监听方式的回调才触发。即，数据可采集的顺序为： page.onLoadpage.onShowpage.onReadyperformance 的 routeperformance 的 evaluateScriptperformance 的 firstRender疑问： performance 的evaluateScript 代码注入阶段（记为A）、page.onReady 首次渲染完成（记为B），实际发生顺序是 A ➜ B，但真实数据获可采集顺序却是 B ➜ A，这个是什么原因？两者可采集顺序是固定的吗？