blocks|key|2043857|text|我也遇到过类似的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2043858|我显示的是类似教程的页面。每一页都是一个全屏的jpg。|2043859|首先，我把图片放在res/drawables文件夹里。浏览寻呼机在滑动时非常迟钝。|offset|length|style|CODE|2043860|然后，我将这些jpgs文件移到res/drawable-hdpi文件夹中，延迟就消失了。|2043861|2043862|我认为基于文件夹的图片做了不同的优化。因此我们不能将所有内容都放在res/drawable文件夹中|2043863|entityMap^0|0|0|9|D|0|F|H|0|0|X|C|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@$F|T|G|U|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|V|8|@$F|W|G|X|H|I]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@$F|10|G|11|H|I]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|P|$]]

I had similar problem. 

I am showing tutorial-like pages. Each page is a full screen jpg.

At first, I put the pictures in <code>res/drawables</code>folder. The viewpager is very laggy when swiping it.

<blockquote>
 Then I move those jpgs to <code>res/drawable-hdpi</code> folder, the lag is gone.
</blockquote>

I think different optimisations are done on the pictures based on folder. So we cannot put everything in <code>res/drawable</code> folder

blocks|key|2043839|text|您可能想尝试viewPager.setOffScreenLimit(大小)到您的页数。这将一次加载所有的片段，并防止在滑动时重新加载它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2043840|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You may want to try viewPager.setOffScreenLimit(size) to the number of your pages. This will load all the fragments once and keep from reloading them while swiping.

blocks|key|4970055|text|对于删除lag：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4970056|1)将图片放在res/drawable-hdpi中，如果图片是static.If格式的，则从URL下载，然后使用后台线程加载图片。|4970057|2)通过viewPager.setOffScreenLimit(size)方法设置离屏页面限制。在视图分页缓存的帮助下，您在此方法中设置的最小屏幕数量，缺省情况下它的值是1。|offset|length|style|BOLD|4970058|3)为了获得更好的性能，您可以使用FragmentPagerAdapter和FragmentStatePagerAdapter。|4970059|entityMap^0|0|0|4|X|0|H|K|12|P|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@$F|Q|G|R|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@$F|T|G|U|H|I]|$F|V|G|W|H|I]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|M|$]]

For removal of lag:

1)Put the images in res/drawable-hdpi if images are static.If it is downloaded from URL then use background thread for loading of images.

2) set page off screen limit by this method viewPager.setOffScreenLimit(size) . With the help of that view pager cache the minimum number of screen which you set in this method by default its value is 1.

3)You can use FragmentPagerAdapter and FragmentStatePagerAdapter for better performance.

blocks|key|2857345|text|我通过将图像移动到drawable-nodpi中解决了这个问题，因为这会禁用所有DPI的缩放。移动到hdpi/xhdpi只有在用户使用具有该屏幕密度的设备时才会禁用缩放。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2857346|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I solved this by moving the images into drawable-nodpi, as this disables the scaling for all DPIs. Moving into hdpi/xhdpi will only disable scaling if the user is on a device with that screen density.

blocks|key|4970180|text|我遵循Coderek的回答，将其在不同的|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4970181|res/drawable-hdpi文件夹|style|BOLD|4970182|drawable-xxxhdpi是最适合我的项目的。|4970183|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/users/1074622/coderek^0|3|7|0|0|0|K|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@$A|W|B|X|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

I followed the answer of <a href="https://stackoverflow.com/users/1074622/coderek">Coderek</a> and moved it between the different

res/drawable-hdpi folders

drawable-xxxhdpi is what worked best for my project.

blocks|key|139377|text|我在切换页面时避免这种延迟的解决方案是:预加载图像|type|unstyled|depth|inlineStyleRanges|entityRanges|data|139378|final+Drawable[]+images+=+new+Drawable[3];
for(int+i=0;+i<3;+i%2B%2B){
++++int+position+=+i%2B1;
++++images[i]+=+getResources().getDrawable(getResources().getIdentifier("image"%2Bposition,+"drawable",+getPackageName()));
+}|code-block|syntax|javascript|139379|然后：|139380|mViewPager.addOnPageChangeListener(new+ViewPager.OnPageChangeListener()+{
++++++++@Override
++++++++public+void+onPageScrolled(int+position,+float+positionOffset,+int+positionOffsetPixels)+{

++++++++}

++++++++@Override
++++++++public+void+onPageSelected(int+position)+{
++++++++++++imageSwitcher.setImageDrawable(images[position]);
++++++++}

++++++++@Override
++++++++public+void+onPageScrollStateChanged(int+state)+{
++++++++}
++++});|139381|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

My solution to avoid this lag when switching pages was: preload images

<pre><code>final Drawable[] images = new Drawable[3];
for(int i=0; i&lt;3; i++){
 int position = i+1;
 images[i] = getResources().getDrawable(getResources().getIdentifier("image"+position, "drawable", getPackageName()));
 }
</code></pre>

and then:

<pre><code>mViewPager.addOnPageChangeListener(new ViewPager.OnPageChangeListener() {
 @Override
 public void onPageScrolled(int position, float positionOffset, int positionOffsetPixels) {

 }

 @Override
 public void onPageSelected(int position) {
 imageSwitcher.setImageDrawable(images[position]);
 }

 @Override
 public void onPageScrollStateChanged(int state) {
 }
 });
</code></pre>

blocks|key|4970036|text|在@coderek答案的基础上，我似乎已经通过获取位图来解决这个问题，而不是针对特定的密度进行缩放：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4970037|BitmapFactory.Options+opts+=+new+BitmapFactory.Options();
opts.inScaled+=+false;
Bitmap+bitmap+=+BitmapFactory.decodeResource(getResources(),+resource,+opts);

((ImageView)+view).setImageBitmap(bitmap);|code-block|syntax|javascript|4970038|在xxhdpi设备中使用drawable文件夹中的图像会导致分配的内存增加8倍！|offset|length|style|CODE|4970039|附言：|4970040|如果分辨率太大，您也可以对可绘制的图像进行下采样：|4970041|opts.inSampleSize+=+2;|4970042|entityMap^0|0|0|1|6|C|8|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@$I|X|J|Y|K|L]|$I|Z|J|10|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

Building up on @coderek answer I seem to have solved this by fetching bitmaps without scaling them for specific densities:

<pre><code>BitmapFactory.Options opts = new BitmapFactory.Options();
opts.inScaled = false;
Bitmap bitmap = BitmapFactory.decodeResource(getResources(), resource, opts);

((ImageView) view).setImageBitmap(bitmap);
</code></pre>

Using an image from <code>drawable</code> folder in an <code>xxhdpi</code> device resulted in up to 8 times more memory being allocated!

P.S.:

You can also down sample the drawable if the resolution is too big:

<pre><code>opts.inSampleSize = 2;
</code></pre>

blocks|key|139445|text|我知道这是一个老问题，但我最近遇到了这个问题，并发现了一个不同的问题。所以就分享一下，以防有人读到这篇文章。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|139446|我的片段基本上都是大的Imageview文件夹，滚动浏览UX/UI团队给我的图像。然而，任何时候下一个或前一个图像是不同的大小，例如(1200+X+1200)转换为(1200+X+1300)，滑动会延迟，但其余的就可以了。|139447|解决方案位于正确的文件夹中。我进行了实验，发现如果我将所有图像裁剪成相同的大小，就不会出现滞后问题。然而，这并不符合我的需要，因为我想要不同大小的图像。|139448|因此，我改用Glide将图像加载到适当的位置，而不是直接设置可绘制的内容，这非常好地清理了它。因此，如果其他人遇到这个问题，您可能只需要切换到使用glide异步加载，而不是直接设置图像。|139449|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I know this is an old question, but I have run into it recently and discovered a different issue. So just sharing in case anyone comes across this post.

My fragments were all just big Imageview holders basically and scrolling through Images that the UX/UI team gave me. However, anytime the next or previous image was a different size i.e. (1200 x 1200) transitioning to (1200 x 1300) for example, that swipe would lag, but the rest would be fine.

Resolutions were in the correct folders. I experimented and found that if I cropped all images to the same size, I had no lag issues. However, that didn't fit my need as I wanted different size images.

So I switched to using Glide to load the image into place instead of setting the drawable directly and that cleaned it up very nicely. So if anyone else hits this issue, you may just need to switch to loading with glide asynchronously instead of setting directly the images.

blocks|key|2050928|text|我也有类似的问题，在我的例子中，延迟是由布局的背景图片太大造成的。我刚刚调整了图片的大小，滑动延迟消失了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2050929|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I had a similar problem too and, in my case, the lagging was caused by the background picture of the layouts which was too large. I just resized the picture and the swiping lag was gone

blocks|key|2857331|text|上面的解决方案在我的情况下都不起作用！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2857332|我找到了一个绕过这个问题的库，另外还包含了一些更有趣的功能。Take+a+look+at+it+here!|offset|length|2857333|试试这个：|2857334|gradle中的|2857335|compile+'com.ToxicBakery.viewpager.transforms:view-pager-transforms:1.2.32@aar'|code-block|syntax|javascript|2857336|onCreate|style|BOLD|2857337|viewPager.setPageTransformer(true,+new+DefaultTransformer());|2857338|你可以通过改变第二个参数来得到一些非标准的效果，尽管不是所有的都能正常工作。|2857339|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/ToxicBakery/ViewPagerTransforms^0|0|U|N|0|0|0|0|0|0|8|0|0|0|12|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@$D|16|E|17|1|18]]|A|$]]|$1|F|3|G|5|6|7|19|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1A|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1B|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1C|8|@$D|1D|E|1E|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|L|7|1F|8|@]|9|@]|A|$M|N]]|$1|U|3|V|5|6|7|1G|8|@$D|1H|E|1I|Q|R]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

None of above solutions worked in my case!

I found a library which works around the issue, and additionally incorporates few more interesting features. <a href="https://github.com/ToxicBakery/ViewPagerTransforms" rel="nofollow noreferrer">Take a look at it here!</a>

Try this:

In gradle

<pre><code>compile 'com.ToxicBakery.viewpager.transforms:view-pager-transforms:1.2.32@aar'
</code></pre>

onCreate

<pre><code>viewPager.setPageTransformer(true, new DefaultTransformer());
</code></pre>

You can get some non standard efects by changing second argument, though not all of them work properly.

blocks|key|2857431|text|我将图像移到res/drawable-xxxhdpi，而不是移到res/drawable-hdpi。这立即解决了问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2857432|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Instead of moving to res/drawable-hdpi I moved the images to res/drawable-xxxhdpi.
This instantly solved the problem.

Hello I have a viewpager with several pages(using a fragment state pager), and some pngs as backgrounds to those pages. I already followed the Displaying Bitmaps in the Ui (<a href="http://developer.android.com/training/displaying-bitmaps/display-bitmap.html">http://developer.android.com/training/displaying-bitmaps/display-bitmap.html</a>) so I am already caching and setting the image drawable in a background thread. But I still get some lag when swithcing pages of the pager. On Each fragment, I only inflate the view on the onCreateView() method, so I have no Idea what may be causing this lag. What can I do to remove this lag/choppy effect?

Android ViewPager Lag

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

你好，我有一个带有几个页面的视图寻呼机(使用片段状态寻呼机)，以及一些pngs作为这些页面的背景。我已经遵循了在Ui中显示位图()，所以我已经在后台线程中缓存和设置可绘制的图像。但在切换寻呼机的页面时，我仍然会遇到一些延迟。在每个片段上，我只扩大了onCreateView()方法上的视图，所以我不知道是什么原因造成了这种延迟。我可以做些什么来消除这种滞后/波动效应？

问安卓ViewPager Lag
EN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问安卓ViewPager LagEN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问安卓ViewPager Lag
EN