Question

我有一个可能会收到两个连续更新请求的AppWidget。要显示它必须以编程方式绘制五个50x50位图，设置一些PendingIntent并获得一些配置（只是为了让您对工作负载有所了解）。两次通话之间大约需要60毫秒。

到目前为止我发现的避免不必要更新的选项是有一个静态字段，如：

public class myWidget extends AppWidgetProvider {

    private static long lastUpdate;

    @Override
    public void onReceive(Context context, Intent intent) {

        if((System.currentTimeMillis()-lastUpdate) > 200) {
            doUpdates(context);
        }
        lastUpdate = System.currentTimeMillis();

    }
}

考虑到表现和“最佳实践”......

在这种情况下，您认为哪种解决方案最好？

1）使用静态字段（如示例中所示）

2）让小部件更新两次

3）其他

换句话说，使用静态字段比让窗口小部件更新两次更有害吗？

Answer 1

要显示它必须以编程方式绘制五个50x50位图，设置一些PendingIntent并获得一些配置（只是为了让您对工作负载有所了解）。两次通话之间大约需要60毫秒。

请注意，如果在更新请求进入时碰巧让您的UI处于前台，这将导致您的UI丢帧。

在这种情况下，您认为哪种解决方案最好？

＃1和＃2。

无法保证您的流程仍然在两个后续更新请求之间。可能它将会出现，因为您似乎正在针对200ms内的两次更新进行优化。但它不能保证。因此，请使用静态数据成员进行优化，但要确保您的代码能够在两者之间终止的过程中继续存在。

我建议使用SystemClock.elapsedRealtime()代替System.currentTimeMillis()。 System.currentTimeMillis()基于实时时钟，可以在运行中进行调整（例如，NITZ信号，SNTP更新，用户手动更改时钟）。 SystemClock.elapsedRealtime()保证单调递增，因此对于这种情况来说它是更好的选择。只有在需要将某些内容与“真实世界”时间绑定时才使用SystemClock.elapsedRealtime()（例如，作为使用Calendar个对象的一部分），而不是间隔时间。

AppWidget双重更新还是静态字段？

1 个答案: