@Demon2004 我從來沒說過對第三方庫寬容，我只是說就實現(xiàn)這個功能而言，如果第三方庫直接有Activity可以用了，豈不是要配合你？例如ZXing的android包，就自帶了一個掃碼的Activity，我懶得搞直接用還不行？如果我只是做掃碼功能，只能作出兩個選擇，重做一個activity去繼承你那個，要么直接改ZXing的源碼。
針對Java，OOP是有局限性的，例如C++的靜多態(tài)，就不依賴?yán)^承來實現(xiàn)。而且繼承缺點很多，不利于封裝，因為你這樣做會導(dǎo)致一溜子類依賴父類（特別是android app一大票的activity）行為。更多的就不多說了，畢竟都是說到爛的話題。
android的Activity類，為什么必須繼承來使用，如果僅僅占在復(fù)用角度上去說，是說不過去的（畢竟顯示個hello world是不需要理會你說的什么onCreate之類的，其他GUI系統(tǒng)，能直接new的多了去了，這說明設(shè)計者的意圖是讓你去干一些重要的事情），如果只是代碼復(fù)用，那么默認(rèn)的Application類就是做好的例子。所以，我覺得這些恰好是反對你說法的最好的例子。
一般來說，大部分OS都會提供監(jiān)聽器來監(jiān)聽各種組件的生命周期，所以我也給出解決方案，那就是繼承Application，通過ActivityLifecycleCallbacks來監(jiān)聽全部Activity的顯示和銷毀，雖然需要繼承實現(xiàn)，但危害相對較輕（畢竟Application就只有一個，功能還簡單，而Acivity卻有N個），而且問題比較少。那反過來你仔細(xì)想想，ActivityLifecycleCallbacks為啥是成員，而不是父類方法，這樣做，我還少寫代碼呢，你說是吧？至于OOP那些亂七八糟的名詞，很多書都討論到爛了，能找到更好的路子，就上更好的，不是非必須的繼承（或者錯誤的繼承），通常是災(zāi)難的開端。
說說在 Android 中如何實現(xiàn)強制下線功能在應(yīng)用程序中的一個常見功能是 “強制下線”。比如 QQ 號在別處登錄后，就會把當(dāng)前的 QQ 號擠下線。實現(xiàn)思路是：在界面上彈出一個對話框，讓用戶無法進行任何其他操作，只能點擊...
