@Demon2004 我从来没说过对第三方库宽容，我只是说就实现这个功能而言，如果第三方库直接有Activity可以用了，岂不是要配合你？例如ZXing的android包，就自带了一个扫码的Activity，我懒得搞直接用还不行？如果我只是做扫码功能，只能作出两个选择，重做一个activity去继承你那个，要么直接改ZXing的源码。
针对Java，OOP是有局限性的，例如C++的静多态，就不依赖继承来实现。而且继承缺点很多，不利于封装，因为你这样做会导致一溜子类依赖父类（特别是android app一大票的activity）行为。更多的就不多说了，毕竟都是说到烂的话题。
android的Activity类，为什么必须继承来使用，如果仅仅占在复用角度上去说，是说不过去的（毕竟显示个hello world是不需要理会你说的什么onCreate之类的，其他GUI系统，能直接new的多了去了，这说明设计者的意图是让你去干一些重要的事情），如果只是代码复用，那么默认的Application类就是做好的例子。所以，我觉得这些恰好是反对你说法的最好的例子。
一般来说，大部分OS都会提供监听器来监听各种组件的生命周期，所以我也给出解决方案，那就是继承Application，通过ActivityLifecycleCallbacks来监听全部Activity的显示和销毁，虽然需要继承实现，但危害相对较轻（毕竟Application就只有一个，功能还简单，而Acivity却有N个），而且问题比较少。那反过来你仔细想想，ActivityLifecycleCallbacks为啥是成员，而不是父类方法，这样做，我还少写代码呢，你说是吧？至于OOP那些乱七八糟的名词，很多书都讨论到烂了，能找到更好的路子，就上更好的，不是非必须的继承（或者错误的继承），通常是灾难的开端。
说说在 Android 中如何实现强制下线功能在应用程序中的一个常见功能是 “强制下线”。比如 QQ 号在别处登录后，就会把当前的 QQ 号挤下线。实现思路是：在界面上弹出一个对话框，让用户无法进行任何其他操作，只能点击...
