始终使用它，闻起来很好。
让我在模块中详细说明。
1。错误查询
基本上，它可以反映大多数在线迷你计划的问题。
但是，仍然有很多问题：
例如，在早期，我使用官方的bar自定义组件报告屏幕扫除时的错误，并且未定义该功能。我仔细检查了代码以确保WX。呼叫之前使用功能。但是，仍然有很多错误，我无法弄清楚。由于不同的基本库和模型，错误报告列表还充满了许多兼容性错误。这些很难知道模型和环境，因此很难处理。
评分：4分
建议：
1。在错误结果中添加更多过滤器，例如模型（可以给出iOS版本吗？可以给出版本吗？）
2。可以优化列表吗？如果您想折叠或简单地提供详细信息以查看？该列表不一定需要直接显示每个错误的详细信息，我需要的是一目了然的清单。
2。实时日志
实时日志可以将问题的“通过”上传到后台并将其全部存储。它不仅可以搜索，而且可以导出日志，这对于开发人员来说非常方便地更加仔细地查看以前的问题并找出问题的原因。
从功能上讲，实时记录是错误警报的有机补充。
错误警报实际上包含两个方面： Mini程序自己的问题和错误，例如上面提到的客户端或基本库在某些情况下存在错误； b。自己的业务法规和业务逻辑中的异常错误。
从这两个方面，实时记录更适合业务端问题。然后问题来了。对于业务方面的问题，仅打印一个实时日志是不够的。对于业务端日志和统计数据，我们以前选择的方式是埋葬这些要点并自行计算它们，我们对代码有自己的控制权，我们可以进行一些更详细的统计分析和处理，这些分析和处理更接近我们自己的业务。从这个角度来看，与自我建立点相比，实时记录的优势在哪里？除了简单的访问外，似乎没有更多。
评分：3
建议：提供开放的API，用于阅读和统计分析其自己的业务系统。
3。性能监控
这不是要说的。每个版本后的一周，基本上是一个经常审查的模块。
评分：5
建议：还没有
4。警报设置
总比没有好，但是这意味着很难理解为什么通过扫描代码添加此功能将其添加到独家组中。
评分：4
建议：可以将其作为功能模块合并到Mini计划助理或迷你程序数据工具中吗？这不是通过发送迷你程序的消息来响应警报提醒的更自然的方法吗？
5。迷你程序速度测量
在迷你计划中，几乎有几种方法可以执行“速度测试”：
1-在Mini计划后端中的“开发” ---“操作和维护中心” ---“绩效监控”。您可以在此处看到一些数据，包括首次打开，下载，渲染等，但不能自定义。如果您想看到其他一些“速度”，则无能为力。
2-迷你程序背景中的“统计信息” ---在“自定义分析”中创建事件，改进事件字段，并通过API接口报告和分析数据。但是，可以使用此方法，但是，自定义分析通常用于执行用户行为分析或进行业务数据分析（包括随后的漏斗分析）。进行基本的软件分析似乎不是合理和专业的，并且在查询时非常麻烦。此外，对于“速度测试”，缺乏许多专业指标（例如操作员网络环境元素，等等，当然可以通过报告的自定义字段来处理这些指标，但会为小型程序添加很多额外的工作）。例如
3-制作自己的“速度测试”统计信息后端...我不会谈论这个，这很麻烦，没有必要。
小型计划的速度测试应被认为是“绩效监控”和“自定义报告”的有力补充，并真正实现了“专业知识”。首先，尺寸比性能监控要丰富得多。区域，操作员，操作系统，网络类型，模型等包括关键维度，允许更细粒度的交叉分析。其次，使用上述内容比“自定义分析”要容易得多。您唯一需要做的是：1。定义监视指标并获得监视ID； 2。在迷你程序中报告接口电话的时间； 3。在后台查看数据。
评分：4
建议：
1-自定义尺寸功能。指南中的示例很简单。您能解释一下场景并详细使用更多以及一些常见的自定义维度吗？
2-净速度测量和速度测量中的默认维度，您可以考虑连接“模型”分组（该模型中的“中和高低齿轮”不在速度测量中）。由于可以在用户的肖像（6、7、8，Max，，等）中分析用户的模型，因此是否可以根据此维度分配模型？即使我访问了我的迷你程序的十大型号，我也不要求所有东西（这个“高”命中了我的笑声，高有多高？低得多？这个标准并不严格。幸运的是，我没有在上面放一个“老人”）。
3-可以将区域维度添加到净速度测量的默认维度中吗？计算机室与不同地区人民的速度之间的关系可以直观地看到，这很方便进行优化。
4-最后，只有7天的数据吗？最大粒子可长达60分钟吗？那么，如何直观地优化在每周/每月平均之前和之后的比较呢？在Mini计划数据统计和性能监控中，有一些尺寸，例如“最后7天，最后30天以及自定义时间”。很方便查看，可以看见。
以上就是关于开发运维中心：提升小程序质量的利器与错误查询优化建议全部的内容，关注我们，带您了解更多相关内容。
