今天介紹四大元件中的另外兩個，直接開始：
BroadcastReceiver：官方解釋網址
這個元件的用途是Android 預設的溝通模式，溝通的方式就好像以前的無線電，Broadcast透過Intent 廣播到某個彼此溝通好的 Action頻道上，Receiver則是向收音機一樣，將對應的資訊從頻道上擷取下來，再去執行自己需要的動作，Android所有的開放的服務如打電話、連絡人、檔案總管等等，都是可以透過Broadcast 與Intent去呼叫對應的行為。
筆者認為這個元件的優點是實作方便，但缺點就是沒有AIDL 的IBinder穩定跟效率，所以如果有跨App或Process(之後的多執行緒篇章再解釋)且穩定及效率上的考量，可以考慮直接實作AIDL，筆者選了幾篇值得一看的文章如下：
ContentProvider：官方解釋網址
寫到這個原件，筆者覺得很值得一提的一個回憶，大約筆者在第一年(4.x)開發的時候就知道了這個元件，但當時使用這個元件的人極少，為甚麼？舉例：
那個時候的軟硬整合的Source code，大多都是一些直接從Linux層去讀對應位置的值，
然後直接實作功能的程式碼，這也不能怪開發者，因為有一些這樣實作的功能，
還比透過Android官方建議的ContentProvider還穩定
(因為做手機的廠商根本沒照規定實作，就好比Nexus 5x的鏡頭是反的….)
時過境遷，現在Android因為使用的人多了，資安跟權限的考量提升，
因此Android 6以後的版本幾乎都要求需要透過官方文件上所示的方式去讀值，
因此這個元件的使用率就大幅提升了xD(教學文件大多是2017年出現的)，
可以說是鹹魚翻身的一個元件？
此元件的用途大多是給予不同的App或是使用者讀取自身App產生的檔案的讀寫權限，
因此這個才是比較正式的檔案資訊傳遞管道，當然開發者圖方便或是為了解決某些限制，
筆者自己的認知，多是直接用讀取外部資料這個權限…
p.s. 現在很多以前版本的Source Code、Simple Code其實都Build不起來或是Build起來會直接噴Crash了…
最後介紹筆者認為值得一提的Context：官方解釋網址
先列出拜讀過的文章：
依筆者的說法來說，Context就是一個Application的靈魂！
一個App不會有兩個靈魂，所有的功能接口都是透過這個Context去跟別的App溝通，
當然你需要的功能也可以從Context上去取得，在App Context上宣的變數，
也可以視為這個App scope裡的全域變數，Activity跟Service都是繼承他實作出來的。
筆者也遇過開發者使用過Activity、Service，也常用到Context，
但就是沒有特別去了解Context是什麼，也因此會有很多不太正確的用法。
因此介紹四大元件的最後，呼籲大家一定要順便了解Context是什麼～
希望讀者看完這兩天的文章後，對於Android可以更熟悉一些！
本文同步刊登在Medium上，連結在此。
iThome鐵人賽
看影片追技術