Gridgoal：启动日志[2]——它是需要最长时间修复的简单问题

 

        在过去的一天中，我一直在努力找出由于使 Gridgoal 更高效而导致的错误。之前，我将大量内存用于存储用户的整个日常进度。对于持续 7 天的 Gridgoal，进度如下所示：

        {第0天：200，第1天：450，第2天：55，第3天：0，第4天：0，第5天：0，第6天：0，}

        如果目标历时365天，则I C [R eated 365键：全部初始化为值对0。这是个问题。会有很多浪费的内存，它只会让一切变得臃肿。但是我使用进度对象来计算页面上的所有内容。

        所以我进行了更改并将进度对象初始化为{}。然后，当有人添加一个活动来让我们说“第 4 天”时，它会将“第 4 天”添加到进度对象中。

        为了说明这个问题，假设您有一辆移动货车，它应该有 365 个空位。当您使用 Gridgoal 进行活动时，您实际上是在移动货车中调用特定位置并将活动量添加到该位置。这就是下面的代码所做的。

     

        原始代码

        如果你还记得上面的话，我提前停止为移动货车分配空间，但我仍然试图在不存在的移动货车上找到一个位置。我没有收到错误消息，但该行为不仅适用于第一个行为。该对象将用 null 填充，然后在第二次使用时，一切都会好起来的。但是一旦发现问题，就跟增加一个检查进度对象是否为空一样简单。请参阅下面的代码。

        固定码

        现在 Gridgoal 工作得非常好，而且内存效率很高。看看七爪网源码交易平台_网站源码_商城源码_小程序源码平台_分销商城-七爪网