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資訊。