【 不用靜態(tài)變量存儲數據 】

1、靜態(tài)變量等數據由于進程已經被殺死而被初始化。

2、使用其他暑假傳輸方式：文件 / sp / contentProvider。

【 有關sp的安全問題 】

不能跨進程同步；存儲SP的文件過大問題；

盡量不要去做跨進程的東西，這非常會影響數據的安全問題。

【 Context的種類及注意事項 】

Application:Android應用中默認單例類，在Activity或Service中通過getApplication()可以獲取到這個單例，通過context.getApplicationContext()可以獲取到應用全局唯一的Context實例。

Activity/Service：都是ContextWrapper的子類，在這兩個類中可以通過getBaseContext()獲取到它們的Context實例，不同的Activity或Service實例，它們的Context都是獨立的，不會復用。

BroadcastReceiver：本身不是Context的子類，而是在回掉函數onReceive()中由Android框架傳入一個Context的實例。系統(tǒng)傳入的這個Context實例是經過功能裁剪的，它不能調用registerReceiver()以及bindService()這兩個函數。

ContentProvider：也不是Context的子類，但在創(chuàng)建時系統(tǒng)會傳入一個Context實例，這樣在CP中可以通過調用getContext()函數獲取，如果CP和調用者處于相同的應用進程中，那么getContext()將返回應用全局唯一的Context實例。如果是其他進程調用的CP，那么CP將持有自身所在的進程的Context實例。

getApplicationContext()：Application的Context, 生命周期貫穿整個App。 ? ? ? ? ? ? ? ? getContext() / this：組件的Context，與組件生命周期同步。 ? ? ? ? ? ? ? ? ? ? ? ? ? ? getBaseContext()：(Google Android 工程師Dianne Hackborn 不建議使用，具體原因沒詳述)。

【 使用建議 】

?數字1：啟動Activity在這些類中是可以的，但是需要創(chuàng)建一個新的task。一般情況不推薦。

?數字2：在這些類中去layout inflate是合法的，但是會使用系統(tǒng)默認的主題樣式，如果你自定義了某些樣式可能不會被使用。 ?

數字3：在receiver為null時允許，在4.2或以上的版本中，用于獲取黏性廣播的當前值。（可以無視）。

【 注意Context引用的持有，防止內存泄漏 】

建議一：不要長時間持有 組件的Context，(持有的情況可能有 workThread, static 變量，non-static inner Class)。

建議二：對于不受控的非靜態(tài)內部類，建議修改成靜態(tài)內部類，同時采用弱引用的方式 引用 Activity/Service 的Context。

建議三：其他可以使用Application Context 的地方，就用Application Context。

【 java四種引用方式 】