一定會聽見Activity, Service, Receiver, Provider這四大元件
但是在這四者之前，還有一個本體你一定要先知道
叫做Context
進入正題
Context是Android系統中，維持每個Process正常運作的核心
主導整個系統環境的運行，裏頭描述了環境的信息
所以有權限可以去(或者說被用來)
1.獲取資源 2.啟動App 3.發出廣播 4.Intent去其他"場景"
根據上圖所示，Context本身是一個Abstract的Class
被兩個子類繼承
ContextWrapper->用來包裝Context的類別
ContextImpl->用來實現Context行為的類別
所以ContextWrapper會帶有ContextImpl的reference，
以便使用ContextImpl的API來操作Context，調用系統資源。
而ContextWrapper又把這一切包裝成Activity跟Service，
然後才呈現到開發者面前，提供設計應用。
所以一個App，會擁有App(1)+Activity+Service數量的Context，
而Provider跟Reciever則沒有，但是需要依靠別人給它。
Context實際上做甚麼?
我們每每在Activity中，使用this修飾字時
其實是在執行getContext( )，來取得當下的Context
而App的Context，可以透過getApplicationContext( )取得
我們每當使用showDialog(彈跳窗), startActivity(開啟頁面),
LayoutInflation(產生UI), startService(服務), BroadCast(廣播),
LoadResource(載入資源)，都是需要Context的
這也是為什麼Activity不能直接被new起來執行
因為它一定要有Context，Android在應用上的頁面切換、啟動
大體來說還是嚴謹的，而且受到生命週期的管理，
所以如果你要啟動頁面、服務、廣播、調用功能...
請出示身分跟說明 : 你從哪裡來，要往哪裡去，想拿什麼、幹什麼
所以Context類別也提供許多flag，來調用系統的服務
(可參考官方文件)
(提醒:context因為可以佔用資源，所以要小心生命週期的控管，
不要輕易指定給命比自己長，或static的reference)
小結
Context就是Activity, Service在Android環境中
最原始裸露的靈魂，Activity就像給了肉體(UI)的人，
Service就像不滅的精神、默默耕耘的無名氏。
Service就像不滅的精神、默默耕耘的無名氏。
但是Context翻譯過來的原意 : "上下文"概念太過於籠統
所以又分別依功能被包裝成Activity, Service。
但我們回過頭來看，它的確用於"承先啟後"
更可以循著它來對系統資源做存取。
所以Context實際上就是一個文"本"，"上下文"
彼此有著不同權限與前後關係，我們的應用App
只是把它包裝成舉辦活動(Activity)、提供服務(Service)
Context觀念上大致就是如此
實際的操作跟使用，還請參考官方的文件說明~
實際的操作跟使用，還請參考官方的文件說明~
