精华内容
下载资源
问答
  • ios手机页面滑动卡顿问题

    千次阅读 2018-07-02 21:39:25
    因为现在移动设备真是贼辣多,手机屏幕的高度,宽度各式各样。所以我们有一些页面高度不够长,在iPhone8x、三星长屏手机等页面显示不全,所以我开发的时候,有时候会给html和body都设置上height:100%,所以在ios...

    说起来真是件悲伤的事情,开发了这么多移动端页面,今天犯了一个低级,而我却不知道的错误。

    因为现在移动设备真是贼辣多,手机屏幕的高度,宽度各式各样。

    所以我们有一些页面高度不够长,在iPhone8x、三星长屏手机等页面显示不全,所以我开发的时候,有时候会给html和body都设置上height:100%,所以在ios手机上这个页面滑动的时候就会卡顿了。

    正确的做法应该是这样的:给html设置一个min-height:100%;给body设置一个

    max-width: 750px;
    margin: 0 auto;

    所以,错误就出在了

    html,body{

      height: 100%;

    }

    删除上述代码即可。

    如果还不行啊,网上有人是这样推荐的

    其他原因:
    *{
      -webkit-overflow-scrolling: touch;
    }
    增加上述代码。

    展开全文
  • 最近做项目的时候需要使用ScrollView嵌套RecyclerView,使用过程中出现了一个问题,在Android6.0以上的手机上面会出现当RecyclerView里面的数据超过屏幕的时候,RecyclerView的高度会被强制设置为不超过屏幕的底部,...

    最近做项目的时候需要使用ScrollView嵌套RecyclerView,使用过程中出现了一个问题,在Android6.0以上的手机上面会出现当RecyclerView里面的数据超过屏幕的时候,RecyclerView的高度会被强制设置为不超过屏幕的底部,也就会导致多出来的数据并不会展示出来,而是需要去滑动RecyclerView展示多出来的数据,注意这里滑动的是RecyclerView,并不是ScrollView。也就是说RecyclerView的滑动事件和ScrollView的滑动事件是互不相关的,会造成滑动冲突从而导致滑动非常卡顿。

    在网上面找到很多方法,其中一种是重写LinearLayoutManager的cancanScrollVertical()方法,试了一下,滑动确实不卡顿了(因为禁止了RecyclerView的滑动事件,不会产生冲突),但是数据却仍然显示不全。

    还有一种方法是设置RecyclerView的nestedScrollingEnabled="false",这种方法跟上面的效果一样,还是不能解决数据显示不全的问题。

    最后说一下本人亲测可用的两种方法:

    方法1:在XML布局文件中给RecyclerView外面包一层RelativeLayout,并给RecyclerView添加属性android:nestedScrollingEnabled="false",代码如下

    <RelativeLayout
         android:layout_width="match_parent"
         android:layout_height="wrap_content">
    
         <android.support.v7.widget.RecyclerView
              android:id="@+id/recyclerView"
              android:layout_width="match_parent"
              android:layout_height="wrap_content"
              android:nestedScrollingEnabled="false" />
    
    </RelativeLayout>

    方法二:使用android.support.v4.widget.NestedScrollView代替ScrollView,并给RecyclerView添加属性android:nestedScrollingEnabled="false"

    最后提醒一下,由于nestedScrollingEnabled属性在api 21以下是不支持的,所以可以在java代码里面重写cancanScrollVertical()方法返回false来代替

    最后运行项目,大功告成!!!

    展开全文
  • 人们常说,无论什么手机品牌,只要搭载了安卓系统,使用一段时间就会出现卡顿的现象。...1、窗口动画缩放如果大家在使用手机过程中出现屏幕滑动卡顿,其实很有可能是窗口动画导致的,我们只需打开...

    人们常说,无论什么手机品牌,只要搭载了安卓系统,使用一段时间就会出现卡顿的现象。但是根据目前市场情况来看,这种现象一般很少出现,毕竟手机厂商在系统优化上下了不少功夫。万一有一天真的出现了卡顿问题怎么办呢?今天小编就以小米手机为例,如果小米手机出现卡顿问题,教你开启这4个功能,让手机流畅飞起再战3年。

    2a022208d93b0ad5d89b7964db82452d.png

    1、窗口动画缩放

    如果大家在使用手机过程中出现屏幕滑动卡顿,其实很有可能是窗口动画导致的,我们只需打开手机设置,找到手机开发者模式,将窗口动画缩放、过渡动画、动画程序时长三个模式调整为0.5X即可。如果没找到开发者模式,可以找到系统版本号连续点击3-4下即可。

    9f69af9eea03fcff27adf6873469c86e.png

    2、后台限制

    有时候手机中很多应用程序虽然表面上看似关闭了,但是很多都在手机后台自启动着,一般很少有人知道,都在偷偷的占用手机运行内存。另外,再加上手机使用时间过长,硬件老化等情况导致手机卡顿。其实这个时候打开设置找到后台进程限制即可轻松解决。

    e919599fd31d2d64a65f2b5c3598e6ee.png

    3、GPU渲染

    GPU渲染可能很多朋友不了解,其实是一种手机上图像处理器的意思,当开启强制GPU渲染时,所有跟图像相关的任务都会交给专门处理图片的GPU来处理。另外,手机CPU也能只负责计算,缓解了CPU的压力,让性能充分发挥到了极致。打开手机设置,在开发者选项中找到GPU渲染开启即可。

    00c6aea9307d3342b0d62119a3fb1954.png

    4、应用通知

    不知道大家有没有这样的烦恼,只要手机联网就会收到很多乱七八糟的消息弹窗,这样不仅消耗手机电量,而且还占用手机内存空间,这也是造成手机卡顿的主要原因,可能很多朋友都没意识到这个问题。那么如何解决呢?其实打开手机设置找到通知状态栏,选择通知管理关闭即可。

    6adb6c1cb5bf97571e86026b5f29c4fa.png

    以上就是解决小米手机卡顿4个方法,是不是感觉非常实用呢?如果你有这种情况可以尝试一下。当然小米手机实用功能不只这一点,比如在小米手机应用市场中找到"智能证件照相机"通过这个相机可以直接拍摄一寸、二寸证件照等。

    0a045255beebc28b2532cc4b88d4c88c.png

    本期话题:手机出现卡顿你一般都是如何解决的?欢迎评论区留言讨论。

    展开全文
  • Fragment大家肯定不会陌生的,几乎每个App里都有它的存在,作为Google在3.0以后引入的一个概念,极大的解决了Activity(或者说手机屏幕)的局限性,让Activity碎片化,正如它的原意 【分段】,【碎片】一样让一个...

    前言

    Fragment大家肯定不会陌生的,几乎每个App里都有它的存在,作为Google在3.0以后引入的一个概念,极大的解决了Activity(或者说手机屏幕)的局限性,让Activity碎片化,正如它的原意 【分段】,【碎片】一样让一个屏幕中的activity展示多个页面成为了现实。

    本篇文章主要讲的是在Viewpager和Fragment一起使用的时候出现的一些问题,如何解决。至于Fragment的使用总结可以参考Android中Fragment知识点终极整理

    先配一张生命周期图,以便下面分析使用
    这里写图片描述

    问题分析

    • 问题一:当Viewpager和Fragment一起使用的时候,假如有四个Fragment,如果不做其它设置,当Fragment的逻辑复杂耗时的时候或者View结构复杂,在页面进行滑动的时候,可以感觉到明显的卡顿

    • 问题二:当Viewpager和Fragment一起使用的时候,假如有四个Fragment,如果不做其它设置,当你从第一个Fragment滑动到第三个Fragment的时候:
      1.如果使用的是FragmentPagerAdapter,那第一个Fragment会执行到onDestroyView,即Fragment的视图被销毁了,实例还存在,当再次滑动到第一个Fragment的时候,会再次从onCreateView回调重建View。
      2.如果使用的是FragmentStatePagerAdapter,那第一个Fragment会一直执行到onDetach,即视图销毁了,如果没有添加到回退栈,Fragment的实例也会被销毁,当再次滑动到第一个Fragment的时候,会再从onAttach开始回调。
      不管是第一种adapter还是第二种adapter,都对导致Fragment实例或者视图的重复加载。

    显然问题一和问题二都不是我们想看到的,有人可能会想通过 ViewPager的 setOffscreenPageLimit 方法预加载四个Fragment,避免第一次 进到页面时候滑动卡顿和重复加载,但是这有一个比较大的问题,如果多个Fragment里有很多的网络请求,耗时操作,那这些操作在同一时间进行操作像View的初始化赋值等还是会出现卡顿问题。

    总结上面所说:我们要解决的是View的重复加载以及当Fragment页面和逻辑复杂时ViewPager滑动卡顿

    解决方案

    我推荐的做法是通过封装一个Fragment使用延迟加载,当Fragment第一次可见时进行数据和View的相关操作以避免滑动卡顿;同时结合FragmentPagerAdapter,取消销毁视图,只创建一次View。如何封装,见如下代码

    /**
     * @Description TODO(所有Fragment基类,延迟加载)
     * @author mango
     * @Date 2018/2/23 17:49
     */
    public abstract class BaseFragment extends Fragment {
    
        private String TAG = BaseFragment.class.getSimpleName();
    
        private View mRoot;
    
        /**
         * 是否执行了lazyLoad方法
         */
        private boolean isLoaded;
        /**
         * 是否创建了View
         */
        private boolean isCreateView;
    
        /**
         * 当从另一个activity回到fragment所在的activity
         * 当fragment回调onResume方法的时候,可以通过这个变量判断fragment是否可见,来决定是否要刷新数据
         */
        public boolean isVisible;
    
        /*
        * 此方法在viewpager嵌套fragment时会回调
        * 查看FragmentPagerAdapter源码中instantiateItem和setPrimaryItem会调用此方法
        * 在所有生命周期方法前调用
        * 这个基类适用于在viewpager嵌套少量的fragment页面
        * 该方法是第一个回调,可以将数据放在这里处理(viewpager默认会预加载一个页面)
        * 只在fragment可见时加载数据,加快响应速度
        * */
        @Override
        public void setUserVisibleHint(boolean isVisibleToUser) {
            super.setUserVisibleHint(isVisibleToUser);
            if (getUserVisibleHint()) {
                onVisible();
            } else {
                onInvisible();
            }
        }
    
    
        /*
        *  因为Fragment是缓存在内存中,所以可以保存mRoot ,防止view的重复加载 
        *  与FragmentPagerAdapter 中destroyItem方法取消调用父类的效果是一样的,可以任选一种做法
        *  推荐第二种
        * */
        @Override
        public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
            if(mRoot == null){
                mRoot = createView(inflater,container,savedInstanceState);
                isCreateView = true;
                initView(mRoot);
                initListener();
                onVisible();
            }
            return mRoot;
        }
    
        protected void onVisible() {
    
            isVisible = true;
    
            if(isLoaded){
                refreshLoad();
            }
            if (!isLoaded && isCreateView && getUserVisibleHint()) {
                isLoaded = true;
                lazyLoad();
            }
        }
    
        protected void onInvisible() {
            isVisible = false;
        }
    
        protected abstract View createView(LayoutInflater inflater,ViewGroup container,Bundle savedInstanceState);
        protected abstract void initView(View root);
        protected abstract void initListener();
    
        /**
         * fragment第一次可见的时候回调此方法
         */
        protected abstract void lazyLoad();
    
        /**
         * 在Fragment第一次可见加载以后,每次Fragment滑动可见的时候会回调这个方法,
         * 子类可以重写这个方法做数据刷新操作
         */
        protected void refreshLoad(){}
    
    }
    

    具体作用已经注释很清楚了,子类继承这个就可以了,例如

    /**
     * @Description TODO()
     * @author mango
     * @Date 2018/2/23 10:16
     */
    public class FirstFragment extends BaseFragment{
    
        public String TAG = FirstFragment.class.getSimpleName();
        public TextView textView;
    
        @Override
        public void onAttach(Context context) {
            super.onAttach(context);
            Log.e(TAG,"onAttach");
        }
    
        @Override
        protected View createView(LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
            Log.e(TAG,"createView");
            View root = inflater.inflate(R.layout.frag_first,container,false);
            return root;
        }
    
        @Override
        protected void initView(View root) {
            textView = (TextView) root.findViewById(R.id.tv);
        }
    
        @Override
        protected void initListener() {
    
        }
    
        @Override
        protected void lazyLoad() {
            Log.e(TAG,"lazyLoad");
            textView.setText("这是第一个fragment");
            /**
             * 第一次加载的时候在这做数据和View的操作
             */
        }
    
        @Override
        protected void refreshLoad() {
            super.refreshLoad();
        }
    }
    

    再看看FragmentPagerAdapter

    public class FragmentAdapter extends FragmentPagerAdapter {
    
        public FragmentAdapter(FragmentManager fm) {
            super(fm);
        }
    
        @Override
        public Fragment getItem(int position) {
            return FragmentFactory.getInstance().getFragment(position);
        }
    
        @Override
        public int getCount() {
            return 4;
        }
    
        /**
         * 重写该方法,取消调用父类该方法
         * 可以避免在viewpager切换,fragment不可见时执行到onDestroyView,可见时又从onCreateView重新加载视图
         * 因为父类的destroyItem方法中会调用detach方法,将fragment与view分离,(detach()->onPause()->onStop()->onDestroyView())
         * 然后在instantiateItem方法中又调用attach方法,此方法里判断如果fragment与view分离了,
         * 那就重新执行onCreateView,再次将view与fragment绑定(attach()->onCreateView()->onActivityCreated()->onStart()->onResume())
         * @param container
         * @param position
         * @param object
         */
        @Override
        public void destroyItem(ViewGroup container, int position, Object object) {
    //        super.destroyItem(container, position, object);
        }
    }
    

    方案总结

    • 通过取消调用FragmentPagerAdapter 的destroyItem方法避免视图的重复创建
    • 通过Fragment的setUserVisibleHint方法在Fragment可见时再加载数据,达到懒加载的效果;当Fragment可见时,该方法被回调,参数是true;不可见时,也会被回调,参数是false
      使用过ViewPager的同学一定知道setOffScreenPageLimit()方法,它默认的limit为1,也就是ViewPager会默认初始化下一个Fragment,也就是预加载;当页面可见时setUserVisibleHint方法值为true,预加载时Fragment中的该方法也会被回调,参数是false,所以需要注意

    FragmentPagerAdapter分析

    使用这种adapter时,滑动viewpager,不可见的fragment最多执行到onDestroyView, 即视图被销毁了,但fragment实例并没有被销毁,缓存在FragmentManager中,还是常驻内存的,即没有执行到onDestroy,并且保存了Fragment状态

    具体表现就是该fragment里所实例化的对象依然还在(包括控件),仅仅只是把视图销毁了,fragment的状态依然由FragmentManager维护
    ;当再次可见时,仅从onCreateView开始回调,重新创建视图,像textview和edittext等的值依然保存并显示,但是像listview滑动的位置,scrollview滑动的位置等状态并没有保存

    接下来从FragmentPagerAdapter源码分析下优化点

    优化1

    当创建某个position的页卡时,instantiateItem方法会被调用

        @Override
        public Object instantiateItem(ViewGroup container, int position) {
            if (mCurTransaction == null) {
                mCurTransaction = mFragmentManager.beginTransaction();
            }
    
            final long itemId = getItemId(position);
    
            String name = makeFragmentName(container.getId(), itemId);
            Fragment fragment = mFragmentManager.findFragmentByTag(name);
            if (fragment != null) {
                mCurTransaction.attach(fragment);
            } else {
                fragment = getItem(position);
                mCurTransaction.add(container.getId(), fragment,
                        makeFragmentName(container.getId(), itemId));
            }
            if (fragment != mCurrentPrimaryItem) {
                fragment.setMenuVisibility(false);
                fragment.setUserVisibleHint(false);
            }
    
            return fragment;
        }
    

    重点看这句话 :Fragment fragment = mFragmentManager.findFragmentByTag(name);

    这意味着FragmentPagerAdapter会先从FragmentManager中的【ArrayList< Fragment> mActive】这个List缓存中去查找,如果没有就会通过getItem方法获取一个Fragment,该方法是需要我们重写的;一旦我们主界面tab的所有Fragment都被缓存到FragmentManager中,就不会再走getItem方法了

    看到平时有很多人的写法是在Activity里维护一个List,然后在adapter里的getItem方法根据position从list获取Fragment;其实这种做法是多余的,会占用多余内存

    优化2

    上面说了重写destroyItem方法并取消调用父类的该方法可以避免重复创建视图,看看源码

        @Override
        public void destroyItem(ViewGroup container, int position, Object object) {
            if (mCurTransaction == null) {
                mCurTransaction = mFragmentManager.beginTransaction();
            }
            mCurTransaction.detach((Fragment)object);
        }
    

    重点看mCurTransaction.detach((Fragment)object)方法,会调用FragmentTransaction的detach方法,将fragment与view分离,此时Fragment会执行到onDestroyView();当再次执行instantiateItem方法时,因为Fragment实例被缓存,会调用attach方法,此方法里判断如果fragment与view分离了,那就重新执行onCreateView,再次将view与fragment绑定

    所以我们只需要取消调用父类方法即可避免重复创建视图

    使用场景

    这种adapter消耗一定的内存,仅适合包含少量的Fragment页面,例如首页的tab,引导页等页面


    大量Fragment问题

    有朋友问到这种问题,我也觉得需要解决

    比如新闻类的APP,页面甚至会有十几个Fragment存在,这种情况下显然是不能使用FragmentPagerAdapter了,它会缓存所有的Fragment实例;这时候就要使用FragmentStatePagerAdapter了

    FragmentStatePagerAdapter

    使用这种adapter,当滑动viewpager时,不可见的fragment会执行到onDestroy和onDetach,即视图被销毁了,被移除的Fragment没有添加到回退栈,那这个Fragment实例将会被销毁,不在由FragmentManager维护,仅保存Fragment状态(包括 View 状态和成员变量数据状态);当再次可见时,会从onAttach方法从新走一遍,再次创建该Fragment实例;FragmentStatePagerAdapter 内存占用较小,所以适合大量动态页面,比如我们常见的新闻列表类应用

    FragmentStatePagerAdapter默认会预加载下一个Fragment,也就是会缓存这个Fragment,默认预加载数量是setOffScreenPageLimit()方法的limit决定的,limit默认是1,这时最多缓存3个Fragment;超过limit值,超出的Fragment会被回收,实例被销毁,也就是与当前可见Fragment间隔limit个Fragment会被销毁;如果Fragment没有被缓存,就会通过getItem()方法获取Fragment

    接下来从源码看看

    @Override
        public Object instantiateItem(ViewGroup container, int position) {
           
            if (mFragments.size() > position) {
                Fragment f = mFragments.get(position);
                if (f != null) {
                    return f;
                }
            }
    
            if (mCurTransaction == null) {
                mCurTransaction = mFragmentManager.beginTransaction();
            }
    
            Fragment fragment = getItem(position);
            if (mSavedState.size() > position) {
                Fragment.SavedState fss = mSavedState.get(position);
                if (fss != null) {
                    fragment.setInitialSavedState(fss);
                }
            }
            while (mFragments.size() <= position) {
                mFragments.add(null);
            }
            fragment.setMenuVisibility(false);
            fragment.setUserVisibleHint(false);
            mFragments.set(position, fragment);
            mCurTransaction.add(container.getId(), fragment);
    
            return fragment;
        }
    
        @Override
        public void destroyItem(ViewGroup container, int position, Object object) {
            Fragment fragment = (Fragment) object;
    
            if (mCurTransaction == null) {
                mCurTransaction = mFragmentManager.beginTransaction();
            }
            while (mSavedState.size() <= position) {
                mSavedState.add(null);
            }
            mSavedState.set(position, fragment.isAdded()
                    ? mFragmentManager.saveFragmentInstanceState(fragment) : null);
            mFragments.set(position, null);
    
            mCurTransaction.remove(fragment);
        }
    
    

    先看instantiateItem方法的

     if (mFragments.size() > position) {
                Fragment f = mFragments.get(position);
                if (f != null) {
                    return f;
                }
            }
    

    比如有ABCDEF五个Fragment,预加载一个(limit=1),当AFragment可见时,预加载BFragment,最后mFragments里缓存AB
    这样你从A划到B时,从mFragments取出B,同时预加载C,最后mFragments里缓存ABC
    当你从B滑到A,从mFragments取出A;同时C与A间隔了一个Fragment,C会被销毁,从mFragments中剔除,这点从destroyItem方法的mFragments.set(position, null)可知

    所以可以通过设置合适的limit值,来达到合适的内存利用;同时为了避免滑动卡顿,仍然要采用上述延迟加载的方法,即Fragment可见时才加载数据(比如网络请求,View数据的初始化等复杂操作)

    注意:这种使用大量Fragment的情况下,千万不要在Activity里使用List保存初始化好的Fragment,然后在getItem方法里通过position获取,很浪费内存;通过上面的分析可以知道,getItem方法只会在没有缓存的Fragment可用时才会被调用,不会每次滑动ViewPager时就调用;这样操作后内存中最多只会缓存(2*limit+1)个Fragment,其它的会被销毁,不会浪费内存,除非需要销毁的Fragment出现了内存泄漏

    public class SecondActivity extends AppCompatActivity {
    
        public static final String[] TITLE = new String[] { "NBA", "欧冠", "西甲", "英超", "世界杯", "CBA", "电竞", "中超", "NBA", "欧冠", "西甲", "英超", "世界杯", "CBA", "电竞", "中超"};
    
    }
    public class FragmentStateAdapter extends FragmentStatePagerAdapter {
    
    
        public FragmentStateAdapter(FragmentManager fm) {
            super(fm);
        }
    
        @Override
        public Fragment getItem(int position) {
            return BatchFragment.newInstance(SecondActivity.TITLE[position&(SecondActivity.TITLE.length-1)]);
        }
    
        @Override
        public int getCount() {
            return SecondActivity.TITLE.length;
        }
    
    }
    
    
    展开全文
  • 自定义View卡顿优化

    千次阅读 2018-06-12 14:52:54
    前段时间在项目中用到折线图,于是自己自定义了View,结果在屏幕滑动时,每当自定义View出现时,手机就表现出不顺畅 卡顿的现象。如图所示:于是通过跟踪判定是该折线图的问题。onDraw中的代码是:在drawValue(canvas...
  • 为啥我要做这个东西了,是因为经常要用投影演示app ,... 1、屏幕获取(因为是截图方式获取的,所以有点卡顿)  2、实现点击功能,并在点击的时候出现一个手势图标,方便用户观看  3、实现简单的滑动功能 ...
  • 由上面屏幕显示的原理,采用了垂直同步机制的手机设备。如果在一个VSync 时间内,CPU 或GPU 没有完成内容提交,则那一帧就会被丢弃,等待下一次机会再显示,而这时显示屏会保留之前的内容不变。例如在主线程里添加了...
  • 背景:我在做一个可以滚动的页面的时候插入一个可以播放gif动画的控件,结果发现,如果这个动画在播放的时候,滑动页面会发现卡顿。开始以为是硬件加速问题......最后通过traceview工具发现真正的原因。  android...
  • 最开始使用的HorizontalScrollView和ListView当数据量上去之后发现有些低性能的手机变得卡顿手机屏幕刷新会黑屏(黑平的时候我都惊呆了) 实现 废话不多说了接下来实现功能,处于考虑我决定使用RecyclerView然后让...
  • 随着android手机的普及,大量的...当用户操作触屏手机时,需要在屏幕滑动,如果手机性能不好,会出现卡顿的情况,这种情况会导致手机给用户留下不好的体验,所以我们需要一种可以量化滑动性能的方式。常见的方式是通
  • 所以,我们优化ListView,监听ListView的滑动,在ListView滑动时,不加载任何数据,只有滑动停止时才加载手机屏幕内可见的数据,其他地方不加载 个人思路: 1.首先NewAdapter实现 onScrollList
  • 如果你在切换应用或滑动屏幕时出现了严重的卡顿,这就说明你的机器是时候退休了。不过随着Android手机的高速发展,近两年来,中高端机型的性能都呈现过剩趋势,四核处理器已经得到普及,更具噱头的八核处理器也已经...
  • 用户角度:APP 操作比较缓慢,响应不及时,列表滑动卡顿,动画刷新不流畅等 系统角度:屏幕刷新帧率不稳定,无法保证每秒60(跟手机有关)帧刷新频率,出现掉帧现象 卡顿原因及常见解决方式 过度绘制 去除不必...
  • 手机滑动界面的时候都会有一定的卡顿问题,不管是打开APP还是我们在主屏幕进行副页的滑动。都会感觉非常明显的振作感,这种顿挫感的缘由我不是特别清楚。 我进行了几个猜测。 第1个猜测是系统的升级,可能会导致...
  • 地图类业务优化方法

    2019-06-16 18:31:19
    想想在手机屏幕上添加100个小的Bitmap和背景的大Bitmap需要多少内存? 这些图片没有复用机制,都是储存在Java堆里,显示的Marker越多占用的内存越多。 滑动地图时可能出现卡顿甚至ANR的现象, 其实就...
  • position:sticky是一个新的css3属性,它的表现类似position:relative和position:...一般方法是用js控制 position为 relative 和 fixed切换,但手机滑动会有些滞后,卡顿,而 sticky属性能平滑过渡。 判断stic...
  • position:sticky是一个新的css3属性,它的表现类似position:relative和position:...一般方法是用js控制 position为 relative 和 fixed切换,但手机滑动会有些滞后,卡顿,而 sticky属性能平滑过渡。 判断stic...
  •  2、按住鼠标左键拖拽,这种设置方式需要在游戏屏幕上任意位置或者指定需要的位置,按住鼠标左键拖拽之后,设置相应按键,达到的效果跟我们用手指在手机屏幕滑动的效果是一样的; 3、按住鼠标右键拖拽,这种设置...
  • 在Android tv应用中,不像手机可以通过触摸自由的滑动屏幕,TV应用需要通过焦点的触发,并且在屏蔽中选中的View需要在屏幕中凸显出来,那么一般的处理效果就是,放大View,添加选中发光圈效果,这边提供两个方案 ...
  • 可以直接在android手机屏幕上显示当前Activity中所有控件(不管是否隐藏)的边界,内外边距大小,每一个控件大小,图片大小,字体颜色,大小,以及自定义信息。同时可以直接在屏幕上取色,另外还提供了直尺(单位为...
  • 1.介绍 Android手机内置工具Profile GPU Rendering(中文名称:GPU显示配置文件、GPU呈现模式分析等),用来分析是什么让你的应用出现卡顿、变慢。2.使用方式 开发者选项--GPU 显示配置文件--以条的形式显示于屏幕,...
  • 卡顿监控:观察主线程执行时间监控,不超过16ms(1s/60,人肉眼识别频率,也是系统屏幕刷新的频率); 代码执行时间测试; 代码执行内存测试; 二 按需加载:快速滑动时,只对目标加载;停止滑动时,增加加载量; ...
  • 我们在工作中遇到最多的视图场景恐怕就是各种样式的列表了,这也是由手机屏幕有限的尺寸决定的,随着需求的日益丰满,我们会发现列表的样式也随之做着各种各样的变更:样式越来越多了,布局越来越复杂了,如果我们...
  • 动态加载了20多条数据后就卡顿得无法滑动。 5.在使用loading方式动态加载内容的时候,如果其中有image的内容,并且image在屏幕中出现的时候,它的图片不会显示。 希望能尽快修复这些bug,...
  • 可以先下载apk运行到手机上看看效果,下载链接地址: apk如下所示 组件化apk的下载地址 02.项目运行 运行环境要求 Android studio 版本需要在3.0之上,compileSdkVersion是28,gradle版本是3.2.1,gradle-...
  • //surface左侧滑动(可改变屏幕亮度) } @Override public void moveRight(double value, int move_type) { //surface右侧滑动(可改变播放器音量) } }); //退出并回收资源 wlMedia.exit(); //获取...

空空如也

空空如也

1 2
收藏数 26
精华内容 10
关键字:

手机屏幕滑动卡顿