Comparison between Android Activity and Fragment

reference source
reference source
reference source

state method comparison

insert image description here

  • The role of onAttach()
    : the fragment has been associated with the activity. At this time, the activity has been passed in. The value passed by the activity can be used to communicate with the activity. Of course, getActivity() can also be used, provided that the fragment has been connected to the host. The activity is associated and not separated, and there is only one call.
  • When the onCreate()
    system creates a fragment, it calls back and instantiates some variables in it. These variables are mainly: when you pause or stop, the data you want to keep is called only once.
  • When onCreateView()
    is used for the first time, the fragment will draw a layout on it. In order to draw the control, it needs to return a layout view, or it can return null to display nothing.
    When the system uses the fragment, the fragment will return its view, the sooner the better, so try not to do time-consuming operations here, such as loading a large amount of data from the database
  • onActivityCreated()
    is called when the onCreate method in the Activity is executed. The onCreate of the activity has just been completed when onActivityCreated() is executed. Therefore, the onCreate of the activity may not be completed before onActivityCreated() is called, so UI operations that interact with the activity cannot be performed in onCreateView(), and UI interactive operations can be performed in onActivityCreated(). So, this method is mainly to initialize those elements that you need the UI of your parent Activity or Fragment to be fully initialized.
  • onStart()
    is the same as activity, it is called back when Fragement is started, and Fragement is visible at this time.
  • onResume()
    and activity are visible when running in activity. Activated, Fragement enters the foreground and activates when it can get focus.
  • onPause()
    is consistent with the activity. Other activities get the focus. This is still visible. When the first call is made, it means that the user leaves the fragment (not destroyed). It is
    usually used for user submission (maybe the user will not come back after leaving) )
  • onStop()
    is consistent with the activity, the fragment is invisible, the possible situation: the activity is stopped or the fragment is removed but added to the rollback stack, a stopped fragment is still alive and will be removed if it is not used for a long time remove.
  • onDestroyView()
    Called when the layout in the Fragment is removed. Indicates that fragemnt destroys the associated UI layout and clears all view-related resources. Then this knowledge removal view has not been destroyed and has not left the activity
  • onDestroy()
    destroys the fragment object, similar to activity.
  • onDetach()
    Called when Fragment and Activity are disassociated. Leave the activity.

Activity

advantage

As one of the four major components, it is the only component visible to the user. It is easy to use the program entry
, easy to process event logic, and the life cycle is simple and clear. The declaration cycles of different activity instances are independent of each other. There is an activityManager provided by the system to create and maintain instances and the stack

shortcoming

Creation and various states rely on Frameworks manipulation,
which is too large and complex, and
it is difficult to pass parameters

Precautions

If it is not necessary, you must declare configChagnes, at least add orientation, keyboard, and keyboardHidden
to reduce the reference of the activity instance,
try to pass parameters through Intent, use basic data types and ArrayList, etc., and implement the Parcelable interface when objects must be used

Fragment

advantage

Lightweight Activity, with some functions of Activity, life cycle, display UI elements, logic control, etc.
It can dynamically create and control objects, create instances, and control the display mode conveniently

Modularity: We don't have to write all the code in the Activity, but write the code in their own Fragment, so that the UI of different businesses can be separated.
Reusability: Multiple Activities can reuse a Fragment.
Adaptability: According to the screen size and screen orientation of the hardware, different layouts can be easily realized, so that the user experience is better.

shortcoming

Depends on activity, cannot exist independently

Precautions

Fragment is managed by FragmentManager, each Activity has a FragmentManager, which manages a Fragment stack

Fragment instances are identified by ID or TAG

Activity has a Fragment pool, the instance will not necessarily be destroyed, it may be saved in the pool, cached

FragmentManager's scope of action is the entire Activity, so a certain layout ID cannot be replaced by Fragment repeatedly, that is, there cannot be two Fragments with the same ID in the same activity, FM does not recognize the instance, but recognizes the ID

The life cycle of the Fragment reflects the life cycle of the Activity,
that is, when it is being displayed, it is the same as the Activity, the Activity is onPause, and the Fragment inside is onPause

Each Fragment does not know whether it is really visible to the user. For example, it is Fragment A now, and Fragment B is displayed on it. When B is displayed, A does not know that there is another one on it, and it does not know that it is invisible to the user. Similarly, there is another C, and B does not know either
. After C exits, B still does not know that he is on the top of the stack and is visible to the user, and A does not know when B backs off. That is to say, the Fragment is displayed or exited, and other Fragments in the stack cannot perceive it.
This is not as good as Activity. After a is covered by b, a will go to onStop(). Similarly, after c is displayed, b can also be perceived through onStop().
Fragment can monitor the change of BackStackState from FragmentManager, but it only tells you that the Stack has changed, not whether it is more or less, and where you are.
One solution is to record the Path depth of the page and compare it with the Stack depth where the Fragment is located. If they are consistent, the Fragment is on the top of the stack. Because the Path depth of each page is fixed, but the Stack depth does not change, so this can accurately determine whether the Fragment is visible to the user. Of course, this is only valid for the entire page, and it is invalid for an area in the layout.

Fragment event delivery, for stacked Fragments, is actually equivalent to adding a bunch of Views in a FrameLayout, so if the top-level Fragment does not handle the click event, the event will be passed to the lower layer until the event is processed. For example, there are two Fragments A and B, B is on top of A, B has only a simple TextView and does not handle the event, then when you click on B, you will find that the View in A has handled the event. This will not happen to the Activity, because the event cannot be spread across the form, the above Activity does not handle the event, and it will not be passed to the following Activity, even if it is visible.
The solution is to let the root layout of the above Fragment eat the event, and add onClick="true" for each root ViewGroup.
Interact with third-party Activities. To interact with third parties, you still need to use Android's standard startActivityForResult() and onActivityResult() methods.
But there are some things to pay attention to Fragment, Fragment also has these two methods, but in order to allow Fragment to receive onActivityResult() correctly, it is necessary: ​​the host Activity must implement an empty onActivityResult(), which calls super.onActivityResult(), calls Fragment#startActivityForResult() instead of using Activity Of course, you can also use Activity's startActivityForResult() directly. In that case, the returned result can only be processed in the host Activity.

Guess you like

Origin blog.csdn.net/weixin_51109304/article/details/131043383