using iscroll in android 2.3.2
1.try translateZ(0);
.listview, .listview * {translateZ(0);}
Instead, if, say, your list is made of LIs:
.listview li {translateZ(0);}
2. remove * in css rules
3. remove rounded corner. According to #6, this is maybe wrong.
5. dot use <a>tag in list
In my experience, the problem occurs only with lists whose items are links. That is, the items are clickable/tappable with the content wrapped in an <a> tag. On most mobile touchscreen devices, performance of these types of lists is abysmal. Frankly, it's just unacceptable. I would be embarrassed to release an app or web site with this kind of list performance.
There is no problem with lists whose items are NOT links. They scroll quite nicely, at least on the devices on which I have tested. (Admittedly limited - iPhone 4 and 4S, iPad 1.)
Proposed solutions have often revolved around specific enhancements - typically shadows, box-shadows, and gradients - and have involved removing these from list items.
6. if you have to use <a>tag , use below trick
Depending on how complex the styling, this will slow things down either a little or a lot, as the poor little CPU in the mobile device tries to keep-up with all those events. JQM is busy flipping styles around, and the browser is trying it's best to keep up with it. Unfortunately, most/all of this is going on in the CPU, and so any hardware acceleration goes largely out the window.
Not only does this slow things down, but it's a horrible visual distraction. What useful purpose does all that piano-key nonsense serve? I say "none".
So, here, really is the fundamental issue. It's inappropriate to use up/down/hover states on list items. At least not whilst scrolling. It serves no useful purpose, it's slow and it's visually distracting.
Fortunately, (at least for mobile touchscreen app developers, like myself) there is a quick and simple workaround. Just a bit of CSS to make it go away:
*.ui-listview *.ui-btn-up-c,
*.ui-listview *.ui-btn-down-c,
*.ui-listview *.ui-btn-hover-c
{
/* Copy your .ui-btn-up styles here */
}
/* Repeat for each of your themes */
If you make ALL of the styles the same for up/down/hover you will see near-native performance. Even so much as a different border will impact performance drastically. Make all the styles the same for all of these states, and the visual distraction goes away. The CPU time needed to do all that redrawing goes away. The user is much happier. The developer isn't embarrassed to release the app.
(On most platforms at least) the issue is NOT shadows or gradients. Feel free to use them. The browser is just pushing around a bunch of pixels when you scroll, and in many cases now with hardware acceleration. The complexity of the styling affects only the initial drawing time, not scrolling performance.
Now, my workaround is only good for a pure touchscreen application. That's fine with me, but others are developing websites that target multiple devices. The effects are appropriate when using a mouse. They might even be desirable on a touchsceen - just not while scrolling!
Perhaps my CSS workaround can be combined with media queries, so that it will only apply if a touchscreen is in use?
However, I am concerned that there are still CPU cycles being wasted because JQM is still flipping the styles, though at least now the browser is saved from doing all that updating of the screen. I don't know if that's a lot of CPU cycles or just a few. But perhaps further improvement can be made.
https://forum.jquery.com/topic/a-fix-for-low-android-performance-remove-box-shadow
I've recently discovered a trick that can let you have your cake and eat it too. It's not directly related to the gradient and box-shadow issue, but caching for hardware acceleration on iOS.
It can be useful to apply a null 3D transform translateZ(0) for example, on Safari/Mobile Safari, because that hints the engine to use hardware acceleration. (The hint isn't needed on other browsers.)
The solution I have usually seen is to apply that transform to everything in a listview. I've found (working with iScroll at least, but probably the same without it) is to apply it only to the top-level elements in the listview, and also not the listview itself.
That is, the usual rule you see is:
.listview, .listview * {translateZ(0);}
Instead, if, say, your list is made of LIs:
.listview li {translateZ(0);}
It will give you the same elimination of the annoying "flicker" effect on scrolling down, but with almost no overhead.
It works for me for LIs that have a modest amount of styled content inside the LI. I haven't experimented beyond that.
In my particular scenario, it eliminates the flicker, takes half the time to render as the first rule, and the render time difference from NOT using the rule is not measurable.
I didn't find that using .listview > li offered any further improvement.
ISCROLL
1.did you tested iscroll-lite??? https://github.com/cubiq/iscroll
2. Adding the -webkit-transform:translate3d(
Android 4.1 should support CSS overflow scrolling. Do you really need to use iScroll on such devices? Consider using Modernizr to detect if overflow scrolling is supported so you could setup CSS scrolling instead of iScroll.
1.try translateZ(0);
.listview, .listview * {translateZ(0);}
Instead, if, say, your list is made of LIs:
.listview li {translateZ(0);}
2. remove * in css rules
3. remove rounded corner. According to #6, this is maybe wrong.
- It seems that a list of items is very slow regardless of the amount of list items
So, knowing this, I worked on the assumption that there were some rendering kinks. Firstly, I removed the rounded corners, which didn't do anything for performance. Then I started removing the box-shadow and text-shadow. After applying some overrides, performance is now good. It's not great, but it's at least usable. Everything seems to run more smoothly, even transitions.
I'd say that removing shadows gave me a performance boost of at least 100%. Which to me makes it worth it (even though it looks a little less nice).
4. text-shadow none ??? According to #6, this is maybe wrong.
Copy code
In my experience, the problem occurs only with lists whose items are links. That is, the items are clickable/tappable with the content wrapped in an <a> tag. On most mobile touchscreen devices, performance of these types of lists is abysmal. Frankly, it's just unacceptable. I would be embarrassed to release an app or web site with this kind of list performance.
There is no problem with lists whose items are NOT links. They scroll quite nicely, at least on the devices on which I have tested. (Admittedly limited - iPhone 4 and 4S, iPad 1.)
Proposed solutions have often revolved around specific enhancements - typically shadows, box-shadows, and gradients - and have involved removing these from list items.
6. if you have to use <a>tag , use below trick
Depending on how complex the styling, this will slow things down either a little or a lot, as the poor little CPU in the mobile device tries to keep-up with all those events. JQM is busy flipping styles around, and the browser is trying it's best to keep up with it. Unfortunately, most/all of this is going on in the CPU, and so any hardware acceleration goes largely out the window.
Not only does this slow things down, but it's a horrible visual distraction. What useful purpose does all that piano-key nonsense serve? I say "none".
So, here, really is the fundamental issue. It's inappropriate to use up/down/hover states on list items. At least not whilst scrolling. It serves no useful purpose, it's slow and it's visually distracting.
Fortunately, (at least for mobile touchscreen app developers, like myself) there is a quick and simple workaround. Just a bit of CSS to make it go away:
*.ui-listview *.ui-btn-up-c,
*.ui-listview *.ui-btn-down-c,
*.ui-listview *.ui-btn-hover-c
{
/* Copy your .ui-btn-up styles here */
}
/* Repeat for each of your themes */
If you make ALL of the styles the same for up/down/hover you will see near-native performance. Even so much as a different border will impact performance drastically. Make all the styles the same for all of these states, and the visual distraction goes away. The CPU time needed to do all that redrawing goes away. The user is much happier. The developer isn't embarrassed to release the app.
(On most platforms at least) the issue is NOT shadows or gradients. Feel free to use them. The browser is just pushing around a bunch of pixels when you scroll, and in many cases now with hardware acceleration. The complexity of the styling affects only the initial drawing time, not scrolling performance.
Now, my workaround is only good for a pure touchscreen application. That's fine with me, but others are developing websites that target multiple devices. The effects are appropriate when using a mouse. They might even be desirable on a touchsceen - just not while scrolling!
Perhaps my CSS workaround can be combined with media queries, so that it will only apply if a touchscreen is in use?
However, I am concerned that there are still CPU cycles being wasted because JQM is still flipping the styles, though at least now the browser is saved from doing all that updating of the screen. I don't know if that's a lot of CPU cycles or just a few. But perhaps further improvement can be made.
https://forum.jquery.com/topic/a-fix-for-low-android-performance-remove-box-shadow
Actually, it's using * as the right-most part of the rule that causes the problem.Using * in css rules is generally a bad idea in terms of performance.
I've recently discovered a trick that can let you have your cake and eat it too. It's not directly related to the gradient and box-shadow issue, but caching for hardware acceleration on iOS.
It can be useful to apply a null 3D transform translateZ(0) for example, on Safari/Mobile Safari, because that hints the engine to use hardware acceleration. (The hint isn't needed on other browsers.)
The solution I have usually seen is to apply that transform to everything in a listview. I've found (working with iScroll at least, but probably the same without it) is to apply it only to the top-level elements in the listview, and also not the listview itself.
That is, the usual rule you see is:
.listview, .listview * {translateZ(0);}
Instead, if, say, your list is made of LIs:
.listview li {translateZ(0);}
It will give you the same elimination of the annoying "flicker" effect on scrolling down, but with almost no overhead.
It works for me for LIs that have a modest amount of styled content inside the LI. I haven't experimented beyond that.
In my particular scenario, it eliminates the flicker, takes half the time to render as the first rule, and the render time difference from NOT using the rule is not measurable.
I didn't find that using .listview > li offered any further improvement.
ISCROLL
1.did you tested iscroll-lite??? https://github.com/cubiq/iscroll
2. Adding the -webkit-transform:translate3d(
3. I've noticed that I had to add that CSS item to every element inside what I was scrolling. That seemed to solve it for me.
4. I found that simple changing false to true worked fine, both desktop and on the iPad
5.
shrinkScrollbars: 'clip' //do not shrink, just move it out of the container
useTransition: false, //use rAnimFrame instead of CSS3 - this increases performance
bindToWrapper: true, //bind the scroll event to the wrapper not the whole document
bounce: false, //do not perform a bounce on scrollEnd
fadeScrollbars: false //make it dependend upon the used device - Android is getting choppy on fade`
댓글
댓글 쓰기