Basically all Android developers are exposed to onCreate(), onDestory(), onStart(), onStop()and other life-cycle of these methods, but not everyone will go attention to onAttachXXX()such a method groups, Today, I want to explain this with a certain brief article.
Activity in onAttachedToWindow
First, Activitywe can rewrite onAttachedToWindow()and onDetachedFromWindow()this method. As the name suggests, "Attached" is an additional means, so we can determine onAttachedToWindow()that is Viewattached to the windowtime the callback, but onDetachedFromWindow()it is just the opposite.
This method will be in familiar Activitylife cycle onResume()and onPause()middle, but not every once onResume()and onPause()a callback is going to be the next callback them. It should be easier to understand, we certainly do not need to frequent windowthe attach and detach Viewthing.
Here we are naturally prone to a problem at onAttachedToWindow()the time the callback, we can get the Viewwidth and height of it? In other words this time Viewhas elapsed measurement and drawing it?
We write a Demo print a log look.
We can see, and did not. We only have the onWindowFocusChangedtime to truly get a callback Viewwidth and height values.
Therefore, in Activitythe onAttachedToWindow()following pullback, the layout Viewwill be a callback onAttachedToWindow(), and then will go to measure and draw and so on. So we have to get a Viewwider another job is the best View.post()of.
View of onAttachedToWindow usage scenarios
ViewOf onAttachedToWindow()the opportunity when you call occurs in onMeasure()before, then they in the end what is the use of scenario?
When we custom View of some of the more heavyweight resources, but not with other Viewcommon time, you can override these two methods, and onAttachedToWindow()initialized, the onDetachedFromWindow()method was released.
For example Bitmap, although now do not take the initiative to call the recycle()method to recover, but at 8.0 and above systems, manual call will immediately release the memory occupied, so personally I believe it is necessary to manually recover, of course, if the picture is relatively small, memory nothing impact would not have had.
Another example is used to calculate the number of child thread, or with other Viewdisplay-related tasks, in onDetachedFromWindow()can also be stopped, because in most cases, these real-time data for after being separated Viewhas no meaning.
RecyclerView.Adapter 的 onViewAttachedToWindow
Careful small partners will find that RecyclerView.Adapterthere will be such a medium onViewAttachedToWindow()and onViewAttachedToWindow().
Both of these methods in the list when the layout, is very useful as exposure buried, when Adaptercreated Vieware separated when the window (i.e. a sliding window away from the interface of the current), and onViewAttachedToWindow()is directly callback, whereas, in the list of items Viewbeing sliding into the screen, onViewAttachedToWindow()it will be called immediately.
With such attributes, our exposure to Buried, on Shoudaoqinlai, do it directly inside a finished thing.
RecyclerView.Adapter there is a loud noise onAttachedToRecyclerView
Speaking Adapterof onViewAttachedToWindow, why there still has found a onAttachedToRecyclerViewmethod, according to the source we can find, onAttachedToRecyclerView()at setAdapter()the time of the trigger.
Compare, we are able to draw the following usage scenarios:
RecyclerViewEssentially it is aViewGroup, then itItemshould show up, the natural needaddView()to come in, out of time, of course, haveremoveView()to go out, so the corresponding naturallyonViewAttachedToWindow()andonViewAttachedToWindow()the. Therefore, under certain scenarios, you can deal with some Item off the screen by these two callbacks, moved into the work needed to lock the screen. Why does a certain scene, because if you call anotifyDataSetChanged()method, it will trigger all current Item of the screenonViewAttachedToWindow().- While
onAttachedToRecyclerViewandonAttachedToRecyclerView()then it is more appropriate to do some recycling work friends.
My RecyclerView.Adapter of onViewAttachedToWindow Why not working?
There may be a small partner encountered this problem before encountered this problem, first check you this RecyclerViewwhether it is a normal rolling View, if you are rolling nested others, his own set isNestedScrollingEnabledto false, then you are He lost Recyclerviewthe function, that is naturally not enough.
Partners may have little to say, because the demand for historical reasons, I use a NestedScrollViewnested Recyclerview, and ban the Recyclerviewsliding function, but want above exposure Buried function, that what to do?
If this is the case, you will probably only be similar Viewin getGlobalVisibleRect()this way to judge Viewvisibility to deal with. About Viewvisibility analysis, here we go beyond that, we Google it on their own.