Android Support Library 27.1.0新增requireActivity()/requireContext()方法的技术疑问

嘿，这个问题问到点子上了——我当初刚接触这俩新方法的时候，也纠结过要不要把项目里的getActivity()全换掉，后来结合场景用多了才摸透门道，咱们慢慢说：

一、require系列方法的设计目的 #

说白了，这俩方法是为了强化契约、简化代码、精准排错而生的：

• 明确契约：当你调用requireActivity()时，相当于在说「我现在的业务逻辑必须依赖Activity才能运行，此时Fragment肯定是处于依附状态的」——把“预期有Activity”这个隐性前提变成了显性的代码约定。
• 避免隐性崩溃：getActivity()返回null时，如果没做判空，后续调用getActivity().startActivity(...)这种代码会直接抛出NullPointerException，但栈信息只会指向调用startActivity的那一行，很难快速定位到“Fragment已经detach”这个根源；而requireActivity()会直接抛出IllegalStateException，错误信息明确告诉你「Fragment X not attached to Activity」，调试起来效率高太多。
• 简化模板代码：不用每次都写if (getActivity() != null) { ... }这种重复的判空逻辑，让代码更聚焦于业务本身。

二、抛出异常比返回null更可取吗？ #

得分场景，但绝大多数业务场景下，是的：

• 如果你的逻辑必须有Activity/Context才能执行（比如启动页面、加载资源、初始化需要Context的SDK），那此时没有Activity本身就是异常情况——比如Fragment已经被移除了，还在执行异步回调里的UI更新，这时候抛出异常能让你及时发现代码逻辑的漏洞，而不是让程序在默默处理null的过程中出现更诡异的bug（比如UI不更新但没报错，排查起来要花几倍时间）。
• 当然，如果你的逻辑可以在无Context时优雅降级（比如异步请求完成后，Fragment已经销毁了，就直接放弃更新UI），那还是用getActivity()并判空更合适——这种情况属于正常的生命周期状态，不是异常。

三、要不要把所有getActivity()都换成requireActivity()？ #

绝对不要一刀切！得看具体场景：

适合替换的场景 #

• Fragment生命周期内的常规操作：比如在onCreateView、onViewCreated、onActivityCreated这些方法里调用，此时Fragment肯定是依附于Activity的，用requireActivity()能省去判空，代码更简洁。
• 必须依赖Context的核心逻辑：比如初始化SharedPreferences、启动Activity、访问资源文件，这些操作没有Context就跑不起来，抛出异常比默默失败更合理。

不适合替换的场景 #

• 异步回调中：比如网络请求、数据库操作的回调，这些操作执行时Fragment可能已经被销毁或detach了——这是正常情况，应该用getActivity()并判空，然后决定是否继续执行（比如如果Activity为null，就不更新UI了）。
• 可能处于未依附状态的生命周期阶段：比如onDestroyView之后、onDetach之前，或者Fragment刚创建还没attach到Activity的时候，这时候调用require系列方法会直接抛出异常，反而不符合预期。

内容的提问来源于stack exchange，提问作者Quantum Dot