1. instantiate

以前， Fragment 的构造函数不允许携带参数，因为某些场景中 Fragment 会由系统自动创建，例如基于 XML 创建 Fragment、Activity 被杀死后的恢复重建等等。此时，系统通过调用 instantiate 来创建 Fragment，instantiate 通过反射调用 Fragment 无参的构造函数。
现在 Fragment 的构造函数允许携带参数了，我们可以通过自定义 FragmentFactory ，调用 Fragment 的任意构造函数，而系统通过调用 FragmentFactory 来创建 Fragment。
我们可以自定义 FragmentFactory，并重写它的 instantiate 方法来创建 Fragment：
class MyFragmentFactory(private val arg: Any) : FragmentFactory() {
    override fun instantiate(classLoader: ClassLoader, className: String): Fragment {
        val clazz = loadFragmentClass(classLoader, className)
        if (clazz == MyFragment::class.java) {
            return MyFragment(arg)
        return super.instantiate(classLoader, className)
我们将 FragmentFactory 设置给 FragmentManger，之后系统就可以在各种场景中使用工厂创建 Fragment 了。 
//Activity
override fun onCreate(savedInstanceState: Bundle?) {
    supportFragmentManager.fragmentFactory = myFragmentFactory
    super.onCreate(savedInstanceState)
注意 FragmentFactory 的设置必须在 super.onCreate 之前，因为当 Activity 进入重建路径时，会在 super.onCreate 中使用到它。 
 关于 FragmentFactory 的更多介绍，请参考 FragmentFactory ：功能详解&使用场景 
2. onActivityCreated
 
Fragment 早期设计中与 Activity 耦合较多，例如在生命周期方面上除了代理了 Activity 标准生命周期回调以外，还增加了 onActivityCreated 用来观察与 Activity 的绑定关系，onActivityCreated 被认为是 onStart 之前最后一个阶段，此时 Fragment 的 View Hierarchy 已经与 Activity 绑定，因此常用来在这里完成一些基于 View 的初始化工作。 
现在，官方正在逐渐去掉 Fragment 与 Activity 之间的耦合，一个更加独立的 Fragment 更利于复用和测试，因此 onActivityCreated 被废除，取而代之的是在 onViewCreated 中处理与 View 相关的初始化逻辑，与 View 无关的初始化可以前置到 onCreate。但要注意 onViewCreated 回调的时间点，Fragment 的 View 还没加入 Activity View 的 Hierarchy。 
如果我们实在需要获得 Activity 的 onCreate 事件通知，可以通过在 onAttach(Context) 中通过 LifecycleObserver 来获取 
override fun onAttach(context: Context) {
    super.onAttach(context)
    requireActivity().lifecycle.addObserver(
        object : DefaultLifecycleObserver {
            override fun onCreate(owner: LifecycleOwner) {
                owner.lifecycle.removeObserver(this)
                //...      
onAttach(Context) 是 API23 之后新增的 API，前身是 onAttach(Activity)，它也是为了去掉与 Activity 的耦合而被废弃和取代。 
3. setRetainInstance
 
当系统发生横竖屏旋转等 ConfigurationChanged 时，伴随 Activity 的重新 onCreate，Fragment 也会重新创建。setRetainInstance(true) 可以保持 ConfigurationChanged 之后的 Fragment 实例不变。因为有这个特性，以前我们经常会借助 setRetainInstance 来保存 Fragment 甚至 Activity 的状态。 
但是使用 setRetainInstance 保存状态存在隐患，如果 Fragment 持有了对 Activity View 的引用则会造成泄露或者异常，所以我们仅保存与 View 无关的状态即可，不应该保存整个 Fragment 实例，所以 setRetainInstance/getRetainInstance 被废弃，取而代之的是推荐使用 ViewModel 保存状态。 
对于 ViewModel 的基操想必大家都很熟悉就不赘述了。这里只提醒一点，既然 ViewModel 可以在 ConfigurationChanged 之后保持状态，那么 ViewModel 的初始化只需进行一次即可。不少人会像下面这样初始化 ViewModel 
class DetailTaskFragment : Fragment(R.layout.fragment_detailed_task){
    private val viewModel : DetailTaskViewModel by viewModels()
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        //订阅 ViewModel
        viewMode.uiState.observe(viewLifecycleOwner) {
           //update ui
        //请求数据
        viewModel.fetchTaskData(requireArguments().getInt(TASK_ID))
在 onViewCreated 中使用 fetchTaskData 请求数据，当横竖屏旋转造成 Fragment 重建时，虽然我们可以从 ViewModel 中获取最新数据，但是仍然会执行一次多余的 fetchTaskData 。因此更合理的 ViewModel 初始化时机应该是在其内部的 init 中进行，代码如下： 
class TasksViewModel: ViewModel() {
    private val _tasks = MutableLiveData<List<Task>>()
    val tasks: LiveData<List<Task>> = _uiState
    init {
        viewModelScope.launch {
            _tasks.value = withContext(Dispatchers.IO){
                TasksRepository.fetchTasks()
 关于 ViewModel 初始化时机的相关内容，可以参考：Jetpack MVVM 七宗罪之三：在onViewCreated中请求数据 
4. setUserVisibleHint
 
Fragment 经常配合 ViewPager 使用以满足多 Tab 页场景的需求。默认情况下屏幕外部的 Fragment 会跟随显示中的 Fragment 一同被加载，这会影响初始页面的显示速度。setUserVisibleHint 是以前我们常用的“懒加载”实现方案：当 ViewPager 中的 Fragment 进/出屏幕时，FragmentPagerAdapter 会对其调用 setUserVisibleHint，传入 true/false，通知其是否可见： 
@Override
public void setUserVisibleHint(boolean isVisibleToUser) {
    super.setUserVisibleHint(isVisibleToUser);
    if (isVisibleToUser) {
        onVisible(); //自定义回调: 进入屏幕
    } else {
        onInVisible();//离开屏幕
如上，通过重写 setUserVisibleHint 我们可以在 onVisible/onInVisible 中获知 Fragment 显示的时机，便于实现懒加载。但是这种做法有缺陷，首先，你需要为 Fragment 增加基类来定义 onVisible/onInvisible，其次，新增的这两个方法跟原生的生命周期回调交织在一起，增加了代码复杂度和出错的概率。幸好现在我们有了新的“懒加载”解决方案： FragmentTransaction#setMaxLifecycle：setMaxLifecycle 可以将屏幕外尚未显示的 Fragment 的最大的生命周期的状态限制在 Started 
当 Fragment 真正进入屏幕后再推进到 Resumed，此时 onResume 才会响应。借助 setMaxLifecycle 我们仅依靠原生回调即可实现懒加载，而且还避免了额外基类的引入。 
如果你使用的是 ViewPager2，其对应的 FragmentStateAdapter 已经默认支持了 setMaxLifecycle 。对于传统的 ViewPager，启动 setMaxLifecycle 的方法也很简单，FragmentPagerAdapter 的构造方法新增了一个 behavior 参数， 只要在此处传值为 FragmentPagerAdapter.BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT 即可，在 instantiateItem 方法中，会根据 behavior 为创建的 Fragment 设置 setMaxLifecycle。 
// FragmentPagerAdpater.java
@Override
public Object instantiateItem(@NonNull ViewGroup container, int position) {
    ...
    if (fragment != mCurrentPrimaryItem) {
        fragment.setMenuVisibility(false);
        // mBehaviour为1的时候走新逻辑if (mBehavior == BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT) {
            // 初始化item时将其生命周期限制为STARTED
            mCurTransaction.setMaxLifecycle(fragment, Lifecycle.State.STARTED);
        } else {
            // 兼容旧版逻辑
            fragment.setUserVisibleHint(false);
    return fragment;
 关于 setMaxLifecycle 背后的工作原理，可以参考：面试题：如何在 ViewPager 中实现懒加载 
5. onActivityResult
 
以前，我们在 Fragment 可以通过 startActivityForResult/onActivityResult 启动 Activity 并获取返回的结果，这本质是调用了 Activity 的同名方法。随着 Activity Result API 的启用，startActivityForResult/onActivityResult 已经在 Activity 以及 Fragment 中被废弃。相对于 onActivityResult 的结果返回方式，Activity Result API 避免了对 requestCode 的依赖，以更加直观的方式获得 Activity 返回结果。 
基本使用步骤如下图： 
首先，我们创建一个 ActivityResultContract，这里定义了跨 Activity 通信的输入输出协议，系统预置了一系列 ActivityResultContracts.XXXX 可直接使用。然后，我们使用 registerForActivityResult 注册我们的 Contract 和对应的 Callback，Callback 中我们可以获取 Activity 的返回结果。代码如上 
val launcher : ActivityResultLauncher =
    registerForActivityResult(




    

        //使用预置的 Contract：StartActivityForResult
        ActivityResultContracts.StartActivityForResult()) {
             activityResult ->
                 // 获取 Activity 返回的 ActivityResult                                                        
                 Log.d("TargetActivity", activityResult.toString())
                 //  D/TargetActivity: ActivityResult{resultCode=RESULT_OK, data=Intent { (has extras) }}
registerForActivityResult 会返回一个 ActivityResultLauncher 句柄，我们使用它启动 Activity，如下： 
val intent = Intent(this, TargetActivity::class.java)
launcher.launch(intent)
最后我们在目标 Activity 中调用 setResult 返回结果即可： 
//TargetActivity.kt
class TargetActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setResult(Activity.RESULT_OK, Intent().putExtra("my-data", "data"))
        finish()
 关于 Activity Result API 的更多底层原理可以参考 ResultAPI：告别onActivityResult，拥抱ActivityResultContract 
6. requestPermissions
 
requestPermissions/onRequestPermissionsResult 底层也是基于 startActivityForResult/onActivityResult 实现的，因此同样被废弃了，升级为 Result API 的方式。 
ActivityResultContracts 预置了申请权限相关的 Contract： 
request_permission.setOnClickListener {
    requestPermission.launch(permission.BLUETOOTH)
request_multiple_permission.setOnClickListener {
    requestMultiplePermissions.launch(
        arrayOf(
            permission.BLUETOOTH,
            permission.NFC,
            permission.ACCESS_FINE_LOCATION
// 申请单一权限
private val requestPermission =
    registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
        // Do something if permission grantedif (isGranted) toast("Permission is granted")
        else toast("Permission is denied")
// 一次申请多权限
private val requestMultiplePermissions =
    registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions : Map<String, Boolean> ->
        // Do something if some permissions granted or denied
        permissions.entries.forEach {
            // Do checking here
7. setTargetFragment
 
setTargetFragment/getTargetFragment 原本用于 Fragment 之间的通信，例如从 FragmentA 跳转到 FragmentB ，在 B 中发送结果返回给 A： 
// 向 FragmentB 设置 targetFragment
FragmentB fragment = new FragmentB();
fragment.setTargetFragment(FragmentA.this, AppConstant.REQ_CODE_SECOND_FRAGMENT);
//切换至 FragmentB
transaction.replace(R.id.fragment_container, fragment).commit();
// FragmentB 中获取 FragmentA 并进行回调
Fragment fragment = getTargetFragment();
fragment.onActivityResult(AppConstant.REQ_CODE_SECOND_FRAGMENT, Activity.RESULT_OK, inte
如上，代码非常简单，但是这样的通信无法感应生命周期，即使 FragmentA 处于后台也会在 onActivityResult 响应回调。目前 TargetFragment 相关 API 已经被废弃，取而代之的是根为合理的 Fragment Result API。 
假设需要在 FragmentA 监听 FragmentB 返回的数据，首先在 FragmentA 设置监听 
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // setFragmentResultListener 是 fragment-ktx 提供的扩展函数
    setFragmentResultListener("requestKey") { requestKey, bundle ->
        // 监听key为“requestKey”的结果， 并通过bundle获取
        val result = bundle.getString("bundleKey")
        // ...
// setFragmentResultListener 是Fragment的扩展函数，内部调用 FragmentManger 的同名方法
public fun Fragment.setFragmentResultListener(
    requestKey: String,
    listener: ((requestKey: String, bundle: Bundle) -> Unit)
    parentFragmentManager.setFragmentResultListener(requestKey, this, listener)
当从 FragmentB 返回结果时： 
val result = "result"
setFragmentResult("requestKey", bundleOf("bundleKey" to result))
//setFragmentResult 也是 Fragment 的扩展函数，其内部调用 FragmentManger 的同名方法
public fun Fragment.setFragmentResult(requestKey: String, result: Bundle) {
    parentFragmentManager.setFragmentResult(requestKey, result)
上面的代码可以用下图表示： 
FragmentA 通过 Key 向 FragmentManager 注册 ResultListener，FragmentB 返回 result 时， FM 通过 Key 将结果回调给FragmentA ，而且最重要的是 Result API 是生命周期可感知的，listener.onFragmentResult 在 Lifecycle.Event.ON_START 的时候才调用，也就是说只有当 FragmentA 返回到前台时，才会收到结果。 
 关于 Fragment Result API 的更多介绍，可以参考：使用 Result API 实现 Fragment 间的通信
  
Fragment 是帮助我们组织和管理 UI 的重要组件，即使在 Compose 时代也具有使用价值，因此谷歌官方一直致力于对它的 API 的优化，希望他更加易用和便于测试。这些已废弃的 API 在未来的版本中将会彻底删除，所以如果你还在使用着他们，应该尽快予以替换。 
官方也提供了工具帮助我们发现对于过期 API 的使用，Fragment-1.4.0 之后，我们可以通过全局设置严格模式策略，发现项目中的问题： 
class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        FragmentStrictMode.defaultPolicy =
            FragmentStrictMode.Policy.Builder()
                .detectFragmentTagUsage() //setTargetFragment的使用
                .detectRetainInstanceUsage()//setRetainInstance的使用
                .detectSetUserVisibleHint()//setUserVisibleHint的使用
                .detectTargetFragmentUsage()//setTargetFragment的使用
                .apply {
                    if (BuildConfig.DEBUG) {
                        // Debug 模式下崩溃
                        penaltyDeath()
                    } else {
                        // Release 模式下上报
                        penaltyListener {
                            FirebaseCrashlytics.getInstance().recordException(it)
                .build()
 关于 FragmentStrictMode 的更多内容，请参考：https://developer.android.com/guide/fragments/debugging#strictmode 
ARTICLES &amp; TUTORIALS
Forcing bytes download in Okio
这是Jake Wharton的文章, 关于Okio的BufferedSink.
okio 是一个java io库, 包装了一套API用来读写和...
                                    高效的加载高分辨率的图片
加载图片尺寸和类型 
针对不同的图片数据来源，BitmapFactory提供了不同的解码方法（decodeResource()、decodeFile()…），这些方法在构造图片的时候会申请相应的内存空间，所以它们经常抛出内存溢出的异常。这些方法都允许传入一个BitmapFactory.Options类型的参数来获取将要构建的图片的属性。如果将inJustDecodeBoun
                                    Fragment 诞生之初就被定义为一个小型 Activity，因此它代理了 Activity 的许多能力（例如 startActivityForResult 等），职责不够单一。随着 Jetpack 各种新组件的出现，Fragment 的很多职责被有效地进行了分担，其本身也可以更好地聚焦在对 UI 的划分和管理上面，早设计的一些 API 也可以退出历史舞台了。本文就盘点一下 Fragment 那些被废弃的 API。以前， Fragment 的构造函数不允许携带参数，因为某些场景中 Fragment 会由系
public MyAdapter(FragmentManager fragmentManager) {
            super(fragmentManager,FragmentPagerAdapter.BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT);
                                    我们都知道 fragment 中的 setRetainInstance 用于控制是否在 activity 保留 fragment 实例，具体内容可参见 WanAndroid 的每日一问：...
                                    Fragment 是帮助我们组织和管理 UI 的重要组件，即使在 Compose 时代也具有使用价值，因此谷歌官方一直致力于对它的 API 的优化，希望它更加易用和便于测试。这些已废弃的 API 在未来的版本中将会彻底删除，所以如果你还在使用着他们，应该尽快予以替换。.detectFragmentTagUsage() //setTargetFragment的使用.detectRetainInstanceUsage()//setRetainInstance的使用。...
                                    kotlin-android-extensions插件可能算得上是我最喜欢的一个Kotlin在Android上的特性了。
这么说并不夸张，因为以前在使用Java开发Android程序时，我们总是要写一大堆的findViewById，枯燥又没什么意义。
虽然也有一些诸如ButterKnife之类的第三方库，专门用于对findViewById的用法进行简化，但是ButterKnife还是要通过注解来让控件与资源id之间进行绑定，并不算是非常方便。
而kotlin-android-extensions插件的
                                    在用fragmenttabhost做页面切换的时候，发现只要一来回切换fragment，fragment页面就会重新初始化，也就是执行onCreateView()方法，导致每次Fragment的布局都重绘，无法保持Fragment原有状态解决方案：在Fragment onCreateView方法中缓存Viewprotected WeakReference&lt;View&gt; mRootView...
                                    AndroidFragment---概要介绍
 一个Fragment代表一个行为或Activity中用户界面的一部分。你能够在一个Activity中组合使用多个Fragment来创建一个多面板的用户界面，并且可以在多个Activity中重用同个一个Fragment。你可以把一个Frament想象成一个Activity的模块，它有自己的生命周期，接受它们自己的输入事件，并且能够在Activity运
                                    很多情况下，fragment 的生命周期上限应该低于 FragmentManager/Activity。例如，ViewPager 屏幕外的界面不应被 resumed理想状态下，可以通过以...