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

我有一个AppWidget，它可能会收到两个连续的更新请求。要显示它必须以编程方式绘制五个50x50位图，设置一些pendingent并进行一些配置（只是为了让您对工作负载有一点了解）。两次呼叫之间大约需要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） 其他

换句话说，使用静态字段是否比让小部件更新两次更有害

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

请注意，如果在更新请求发出时您的UI恰好位于前台，这将导致UI掉帧

在这种情况下，你认为哪一个是最好的解决方案

一号和二号

无法保证您的进程仍在两个后续更新请求之间。考虑到您似乎正在为200毫秒内的两次更新进行优化，它可能会出现。但这并不能保证。因此，出于优化目的，请使用静态数据成员，但要确保您的代码能够在中间终止的过程中幸存下来

不过，我建议使用

SystemClock.elapsedRealtime（）

，而不是

System.currentTimeMillis（）

System.currentTimeMillis（）

基于实时时钟，可以动态调整（例如，NITZ信号、SNTP更新、用户手动更改时钟）

SystemClock.elapsedRealtime（）

保证是单调递增的，因此对于这种情况，它是一个更好的选择。仅当您需要将某些内容绑定到“真实世界”时间（例如，作为使用

日历

对象的一部分）时，才使用

SystemClock.elapsedRealtime（）

，而不是间隔计时