Im wondering how I can avoid the little white 'flashing' of the views in a recyclerview when the user scrolls a little faster.
The flashing can be avoided of course by preloading more views outside of the visible screen
I could not find anything yet how this can be done, although this must be a pretty common task??
I tried this code from a blog:
public class PreCachingLayoutManager extends LinearLayoutManager {
private static final int DEFAULT_EXTRA_LAYOUT_SPACE = 600;
private int extraLayoutSpace = -1;
private Context context;
public PreCachingLayoutManager(Context context) {
super(context);
this.context = context;
}
public PreCachingLayoutManager(Context context, int extraLayoutSpace) {
super(context);
this.context = context;
this.extraLayoutSpace = extraLayoutSpace;
}
public PreCachingLayoutManager(Context context, int orientation, boolean reverseLayout) {
super(context, orientation, reverseLayout);
this.context = context;
}
public void setExtraLayoutSpace(int extraLayoutSpace) {
this.extraLayoutSpace = extraLayoutSpace;
}
#Override
protected int getExtraLayoutSpace(RecyclerView.State state) {
if (extraLayoutSpace > 0) {
return extraLayoutSpace;
}
return DEFAULT_EXTRA_LAYOUT_SPACE;
}
}
Then I assigned the LayoutManager to my custom Recyclerview in the constructor by using setLayoutManager()
It is "custom", but I only wanted to set the LayoutManager in the costructor, thats why I overwrote the RecyclerView
Unfortunately, this did not have any effect
The RecyclerView is a very efficient API already and usually if you have frames dropping, you can optimize your item layout to be lighter and also make sure you free resources when views are recycled. There is really no need to pre-load anything.
Here is a blog post that gives some ideas of how to do those things
https://blog.workable.com/recyclerview-achieved-60-fps-workables-android-app-tips/
They don't mention it in this post, but also if your items have images, make sure those images are not too big.
The main point is to make the drawing of your views as fast as possible because everything is constantly redrawn as you scroll.
Related
I'm using shared element transition between activities. The first activity contains a LinearLayout and a RecyclerView:
The second activity:
And here's my code, seems very simple:
ActivityOptionsCompat options = ActivityOptionsCompat.makeSceneTransitionAnimation((Activity) getContext(), pairs);
ActivityCompat.startActivity(getContext(), new Intent(Intent.ACTION_VIEW, scheme), options.toBundle());
In common cases, everything seems ok, the transition animation works perfectly. But if I start the next activity while the RecyclerView in the first activity is scrolling, then go back to the first activity, something terrible happens:
I also tested ListView and ViewPager, ListView has same problem while ViewPager not. If I stop the scroll before startActivity, everything will be fine.
However in my product environment, views are complicated and it is ugly to find all ListViews and RecyclerViews and stop their scrolls. Is there anyway to prevent it from happening other than stop scrolling before startActivity?
RecyclerView class don't have such method to disable scrolling. Create CustomRecyclerView yourself like one below.
public class FooRecyclerView extends RecyclerView {
private boolean verticleScrollingEnabled = true;
public void enableVersticleScroll (boolean enabled) {
verticleScrollingEnabled = enabled;
}
public boolean isVerticleScrollingEnabled() {
return verticleScrollingEnabled;
}
#Override
public int computeVerticalScrollRange() {
if (isVerticleScrollingEnabled())
return super.computeVerticalScrollRange();
return 0;
}
#Override
public boolean onInterceptTouchEvent(MotionEvent e) {
if(isVerticleScrollingEnabled())
return super.onInterceptTouchEvent(e);
return false;
}
public FooRecyclerView(Context context) {
super(context);
}
public FooRecyclerView(Context context, #Nullable AttributeSet attrs) {
super(context, attrs);
}
public FooRecyclerView(Context context, #Nullable AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
}
}
replace RecyclerView to above created customview,
<com.customGoogleViews.FooRecyclerView
android:id="#+id/task_sub_list"
android:layout_width="match_parent"
android:layout_height="match_parent" />
disable scrolling before starting new activity,
recyclerview.enableVersticleScroll(false);
ActivityOptionsCompat options = ActivityOptionsCompat.makeSceneTransitionAnimation((Activity) getContext(), pairs);
ActivityCompat.startActivity(getContext(), new Intent(Intent.ACTION_VIEW, scheme), options.toBundle());
Hope it helps :)
I have a ViewPager that utilizes a RecyclerView for each page and shares ViewItem rows across pages. Accordingly I share a single RecyclerViewPool between them. However, the ViewPager loads each RecyclerView whether or not it is the page on screen. Is there a way to indicate to the RecyclerView that all of its items are offscreen and force its views to be returned to the Recycler?
My sense is that subclassing LinearLayoutManager and overriding its onLayoutChildren method is the way to go, but I don't have much experience with LayoutManager and would like some guidance.
So here is a subclass of LinearLayoutManager that operates the way I described:
public class PageVisibleLinearLayoutManager extends LinearLayoutManager {
public PageVisibleLinearLayoutManager(Context context) {
super(context);
}
public PageVisibleLinearLayoutManager(Context context, int orientation, boolean reverseLayout) {
super(context, orientation, reverseLayout);
}
public PageVisibleLinearLayoutManager(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) {
super(context, attrs, defStyleAttr, defStyleRes);
}
private boolean pageVisible = true;
void setPageVisible(boolean pageVisible) {
boolean change = (this.pageVisible != pageVisible);
this.pageVisible = pageVisible;
if(change) requestLayout();
}
#Override
public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) {
if(pageVisible) {
super.onLayoutChildren(recycler, state);
} else {
removeAndRecycleAllViews(recycler);
}
}
}
It works nicely and gives up its views if requested. As dsh mentioned, it is important to mark adjacent pages as being on screen (and I really don't know why setOffscreenPageLimit doesn't limit the number of pages loaded as expected). My previous solution was to use ViewStub and inflate a page only when it was on screen or adjacent. The layout manager method is slightly faster upon initial turning to an unloaded page, but ViewStub has the advantage of pages staying in memory once loaded (making subsequent scrolling more smooth), so I decided to stick with that.
Thank you all. Next question...
I am using StickyHeaderListview in my project to display contents and for refreshing the list, I am using SwipeRefreshLayout.
The problem here is, when I try to scroll up the list, it starts refreshing the list and not allowing to view the previous items of list.
I want the behavior should be such as the list get refresh only when I've reached to the first item and I try to scroll up , not everytime when i scroll up the list.
Can anyone help on this?
P.s. For implementing SwipeRefreshLayout, I am refering this example
I faced the same problem when using StickyHeaderListview as a direct child of SwipeRefreshLayout. StickyHeaderListview is in fact a FrameLayout wrapping a ListView inside. As nitesh goel explained, this would lead to problems with canChildScrollUp(). Based on nitesh goel's example, this is a full version of CustomSwipeRefreshLayout that works well for me:
public class CustomSwipeRefreshLayout extends SwipeRefreshLayout {
/**
* A StickyListHeadersListView whose parent view is this SwipeRefreshLayout
*/
private StickyListHeadersListView mStickyListHeadersListView;
public CustomSwipeRefreshLayout(Context context) {
super(context);
}
public CustomSwipeRefreshLayout(Context context, AttributeSet attrs) {
super(context, attrs);
}
public void setStickyListHeadersListView(StickyListHeadersListView stickyListHeadersListView) {
mStickyListHeadersListView = stickyListHeadersListView;
}
#Override
public boolean canChildScrollUp() {
if (mStickyListHeadersListView != null) {
// In order to scroll a StickyListHeadersListView up:
// Firstly, the wrapped ListView must have at least one item
return (mStickyListHeadersListView.getListChildCount() > 0) &&
// And then, the first visible item must not be the first item
((mStickyListHeadersListView.getFirstVisiblePosition() > 0) ||
// If the first visible item is the first item,
// (we've reached the first item)
// make sure that its top must not cross over the padding top of the wrapped ListView
(mStickyListHeadersListView.getListChildAt(0).getTop() < 0));
// If the wrapped ListView is empty or,
// the first item is located below the padding top of the wrapped ListView,
// we can allow performing refreshing now
} else {
// Fall back to default implementation
return super.canChildScrollUp();
}
}
}
Ok I have got it working. If the SwipeRefreshLayout is the root of the layout and the ListView resides deep into the hierarchy (I had put the ListView inside a RelativeLayout along with the empty TextView) and not the direct child of the SwipeRefreshLayout, it won’t detect a swipe up on the list view properly.
You should create a custom class that extends SwipeRefreshLayout and override canChildScrollUp() method in SwipRefreshLayout
Here is a example :
public class CustomSwipeRefreshLayout extends SwipeRefreshLayout{
private AbsListView view;
public CustomSwipeRefreshLayout(Context context) {
super(context);
}
public CustomSwipeRefreshLayout(Context context, AttributeSet attrs) {
super(context, attrs);
}
public void setView(AbsListView view){
this.view=view;
}
#Override
public boolean canChildScrollUp() {
return view.getFirstVisiblePosition()!=0;
}
}
I have had a similar problem, the direct child should be an instance of ScrollView (or ListView). The SwipeRefreshLayout will only take in account the direct child's scroll and not the child's of that direct child. I managed to solve this by using two SwipeRefreshLayouts.
I posted the code on github.
Hi i think i made something for a generally use :
public class CustomSwipeRefreshLayout extends SwipeRefreshLayout {
private View v;
public CustomSwipeRefreshLayout(Context context) {
super(context);
}
public CustomSwipeRefreshLayout(Context context, AttributeSet attrs) {
super(context, attrs);
}
public void setView(View v) {
this.v = v;
}
#Override
public boolean canChildScrollUp() {
return this.v.canScrollVertically(-1);
}
}
With that solution, only set the view you want to scroll inside the SwipeRefreshLayout, after call canChildScrollUp(). like this :
this.refreshLayout.setView(aView);
this.refreshLayout.canChildScrollUp();
I don't test it a lot, but if i'm right it will work for every view at every place (direct child or not) in the SwipeRefreshLayout.
(for me it was SwipeRefreshLayout => RelativeLayout => SrcollView => linearLayout)
This is very simple solution:
list.setOnScrollListener(new AbsListView.OnScrollListener() {
#Override
public void onScrollStateChanged(AbsListView view, int scrollState) {
}
#Override
public void onScroll(AbsListView view, int firstVisibleItem, int visibleItemCount, int totalItemCount) {
int topRowVerticalPosition = (list == null || list.getChildCount() == 0) ?
0 : list.getChildAt(0).getTop();
swipeRefreshLayout.setEnabled((topRowVerticalPosition >= 0));
}
});
So, if you're on the top of the listview you will be enabled to do refresh.
long time reader, first time asker so please be gently ;)
I have an Android code that displays around 10 pictures in second on ImageView.
(calling setImageBitmap on ImageView to set new bitmap)
This causes display lags so I'm trying to speed it as much as I can.
I found that (with traceview) that app spend a lot of time on methods:
ViewRoot.performTraversals
View.measure
FrameLayout.onmeasure
ViewGrou.measureChildWithMargins
I suspecting on ImageView measuring so i have create CustomImageView and overide onMeasure just to call super method and write sysout.
It seems that after every setImageBitmap onmeasure is called 3 times.
Bitmaps are allways of the same size so there is no change. Actually it can be change from time to time when image source is changed but that should be remeasured only then.
What can I change, overide, do to eliminite this measurement impact on application speed?
If you need further information tell me and I will provide it.
Sample code
final Bitmap bitmapScaled = Bitmap.createScaledBitmap(bitmap2, width, height, false);
imageView2.setScaleType(ScaleType.CENTER_INSIDE);
if (setSize) {
setSize(imageView2, width, height);
}
imageView2.setImageBitmap(bitmapScaled);
Method that I change to make it work faster (possibly not safe?!)
boolean layout=true;
int noL=1;
#Override
public void requestLayout() {
if (layout){
super.requestLayout();
if (noL>10){
layout=false;
}else{
noL++;
}
}
}
When I had a similar problem I did the following:
public class ImageViewEx extends ImageView{
private boolean makeRequest;
public ImageViewEx(Context context){
super(context);makeRequest=true;
}
public ImageViewEx(Context context, AttributeSet attrs) {
this(context, attrs, 0);
}
public ImageViewEx(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
makeRequest=true;
}
public void setImageBitmapNoRequestLayout(Bitmap bitmap) {
makeRequest = false;
setImageBitmap(bitmap);
makeRequest = true;
}
#Override public void requestLayout(){
if(makeRequest)super.requestLayout();
}
}
Now changing the bitmap with setImageBitmapNoRequestLayout(...) does not call requestLayout().
public class SynchronisedScrollView extends ListView {
private ScrollViewListener scrollViewListener = null;
public SynchronisedScrollView(Context context) {
super(context);
}
public SynchronisedScrollView(Context context, AttributeSet attrs,
int defStyle) {
super(context, attrs, defStyle);
}
public SynchronisedScrollView(Context context, AttributeSet attrs) {
super(context, attrs);
}
#Override
protected void onScrollChanged(int x, int y, int oldx, int oldy) {
Log.d("Hello", "I am scrolled");
// super.onScrollChanged(x, y, oldx, oldy);
}
}
I want to catch how much the listView is scrolled, so I extend ListView. I am able to scroll the list. But OnScrollChanged is not called. For ScrollView and HorizontalScrollView OnScrollChanged is called whenever it scrolls. Which function is triggered when we scroll a ListView.
In ListView you must explicitly register an onScrollListener to receive onScroll() events.
I think that the method you are looking for is:
public void offsetChildrenTopAndBottom(int offset) {
// ...
}
from ViewGroup. What you can do is extend ListView to gather the offset given to one of the ListViews and pass it though to the other ListView. Make sure that you call super.offsetChildrenTopAndBottom on the recieven end or you could easily end up with a stackoverflow.
I would create a private method and have the new Observable views.
public class ObservableListView extends ListView {
private ObservableListView peer;
// [Constructors] make sure you override all the super constructors.
// Can have trouble with layouts otherwise
public void setPeer(ObservableListView peer) {
this.peer = peer;
}
#Override
public void offsetTopAndBottom(int offset) {
super.offsetTopAndBottom(offset);
if (peer != null) {
peer.internalVerticalOffset(offset);
}
}
private void internalVerticalOffset(int offset) {
super.offsetTopAndBottom(offset);
}
}
If you feel brave you can also define an xml property to give one of the ListViews id and let that one set up the peer relation. (I can expand if you are interested)
My bad, this is non working code. I'm trying to figure out how to do this with the hidden method. In this code I'm overriding the wrong method. Will update shortly.
Update:
Ok, after some research I think that the best option is to combine the extension of ListView with a TouchDelegate.