Android Widget开发的相关技术点记录

1、Widget的UI需要展示的数据以静态变量的形式存放在了Provider中。

与同事讨论过其它两种方案的可行性：
A、开启Service用来取数据，数据以静态变量形式存放在Service当中。
B、存储在本地。
这三种方案的好坏，其实全在于一个东西就是静态变量的生命周期。按Linux内存管理方式来说，只要内存不满，是不会释放内存中的进程的。也主是说，客户端启动一次之后，只要不是内存满了，静态变量就存在。得到这个结论以后，就可以看出来数据以静态变量形式存放在Provider和Service中结果是一样的（前提是Service没有在Application之外单开进
程）。
但是，理论上来讲，客户端毕竟是有可能被挤出内存的，这时候，Widget的数据就丢失了。这就体现出方案B的优越性来了，数据永远存在。但方案B的唯一缺点就是每次都需要去本地取，速度上有缺陷。


2、在什么地方开启线程获取数据

是开个Service呢，还是直接在Provider的onUpdate里面到了需要更新的时候开启一个线程呢？结论是，只要Service不单开进程，结果是一样的。因为它们的生命周期都是Application在内存中的生命周期，而使用Service的话，与Widget进行数据交换时还存在不方便的问题。

3、使用当前Context生成的AppWidgetManager才能更新UI。不要把Context保存起来，等到联网获取数据后再用它生成AppWidgetManager更新UI，这样是更新不成功的。

4、两次调用new RemoteViews，传入相同viewId的话，第二次得到的RemoteViews里面的View树与第一次相同。暂时没有解决方案，只能先reset一下，这样可以清除上次的UI数据，但不能清除PendingIntent。可以通过设置空的PendingIntent来实现无响应。
Intent intent = new Intent();
return PendingIntent.getBroadcast(context, 0, intent, 0);

5、静态变量存储ID时，一旦客户端异常，进程崩溃后，ID丢失。这样，即使再后台登录，没有ID信息，Widget上的UI数据也不会更新。所以，UI数据可以静态变量存储，进程崩溃后重启时可以重新获取，但ID信息一定得存储到本地。比如，SharedPreference，不要每次更新都去取，这样更新时会很卡，可以每次判断一下当前是否没有ID信息，没有的话再去本地取。另外就是每次系统调用onUpdate和onDeleted时，同步一下本地的ID信息。