2. 程式人生 > >Android_效能優化之ViewPager載入成百上千高清大圖oom解決方案

Android_效能優化之ViewPager載入成百上千高清大圖oom解決方案

阿新 • • 發佈：2019-02-16

歡迎加入技術談論群：714476794

一、背景

最近做專案需要用到選擇圖片上傳，類似於微信、微博那樣的圖片選擇器，ContentResolver讀取本地圖片資源並用RecyclerView+Glide載入圖片顯示就搞定列表的顯示，這個沒什麼大問題，重點是，點選圖片進入大圖瀏覽，比如你相簿有幾百張圖片，也就意味著在ViewPager中需要載入幾百個view，況且手機拍出來的圖片都是1-2千萬左右畫素的高清大圖(筆者手機2千萬畫素 也就是拍照出來的照片3888*5152)，大小也有5-7個兆，ViewPager滑動不了十幾張就oom了，即是對圖片做了壓縮處理，把圖片解析度降低至1366*960，大小壓縮至150k以下，並且在ViewPager的destroyItem方法做了bitmap資源的回收，雖然效果好了點，這也抵擋不了oom的降臨（網上查詢的方案都是壓縮、使用第三方控制元件、回收，其實這都沒用，可能他們沒有真正體驗過ViewPager載入幾百上千張大圖的感受），瀏覽到了第50-70張的時候就oom了 記憶體一直暴漲，根本回收不了的，不信你們試試，壓縮和回收根本不能根治問題，那麼怎麼解決呢？研究了微信和微博，他們怎麼也不會oom，最後我想到了一種解決方案。

二、方案實施

1、以往的普通做法

部分程式碼：

List<SubsamplingScaleImageView> mViews = new ArrayList<>();
        
        int size = mDatas.size();
        for (int i = 0; i < size; i++) {
            SubsamplingScaleImageView view = new SubsamplingScaleImageView(this);
            mViews.add(view);
        }

        mBinding.viewpager.setAdapter(new MyAdapter());
 

class MyAdapter extends PagerAdapter {

        @Override
        public int getCount() {
            return mDatas.size();
        }

        @Override
        public boolean isViewFromObject(View view, Object object) {
            return view == object;
        }

        @Override
        public Object instantiateItem(ViewGroup container, final int position) {

            ViewGroup.LayoutParams params = new ViewGroup.LayoutParams(
                    ViewPager.LayoutParams.MATCH_PARENT,ViewPager.LayoutParams.MATCH_PARENT);
            final SubsamplingScaleImageView imageView = mViews.get(position);
            imageView.setLayoutParams(params);

            final String url = mDatas.get(position);
            String cacheExists = cacheExists(url);
            if(TextUtils.isEmpty(cacheExists)) {//沒快取 需要壓縮(壓縮耗時 非同步)
                new AsyncTask<Void, Void, String>() {
                    @Override
                    protected String doInBackground(Void... voids) {
                        String cacheNoExistsPath = getCacheNoExistsPath(url);
                        BitmapCompressUtils.compressBitmap(url, cacheNoExistsPath);
                        File file = new File(cacheNoExistsPath);
                        if (file.exists()) {//存在表示成功
                            return cacheNoExistsPath;
                        } else {
                            return url;
                        }
                    }

                    @Override
                    protected void onPostExecute(String s) {
                        imageView.setImage(ImageSource.uri(s));
                    }

                }.execute();


            } else {//有快取 直接顯示
                imageView.setImage(ImageSource.uri(cacheExists));
            }

            container.addView(imageView);
            return imageView;

        }

        @Override
        public void destroyItem(ViewGroup container, int position, Object object) {

            SubsamplingScaleImageView imageView = mViews.get(position);
            if(imageView != null) {
                imageView.recycle();
            }

            container.removeView(imageView);

        }
    }
 

/**
     * 判斷當前圖片url對應的壓縮過的快取是否存在 ""表示不存在
     *
     * @param url 圖片路徑
     * @return
     */
    private String cacheExists(String url) {
        try {
            File fileDir = new File(mCacheRootPath);
            if(!fileDir.exists()) {
                fileDir.mkdirs();
            }

            File file = new File(mCacheRootPath,new StringBuffer().append(MD5EncryptorUtils.md5Encryption(url)).toString());
            if(file.exists()) {
                return file.getAbsolutePath();
            }
        } catch (Exception e) {
            e.printStackTrace();
        }

        return "";
    }

    public String getCacheNoExistsPath(String url) {
        File fileDir = new File(mCacheRootPath);
        if(!fileDir.exists()) {
            fileDir.mkdirs();
        }


        return new StringBuffer().append(mCacheRootPath)
                .append(MD5EncryptorUtils.md5Encryption(url)).toString();
    }

可以看到，這裡筆者通過自己的壓縮演算法(上一篇文章Android_NDK圖片壓縮之Libjpeg庫使用 )做了圖片壓縮，並快取，細心的朋友應該有發現mViews集合新增的view個數是mDatas的size大小個數，這樣就會導致一個問題ViewPager一直向下滑動的時候，記憶體一直是增加的，即是做了資源回收，也是不能解決問題（況且筆者這裡展示圖片的控制元件是SubsamplingScaleImageView 很不錯的大圖區域性載入控制元件 能有效防止oom），大家可以試試，大量圖片的時候還是會oom，這得歸根於viewpager載入的圖片數量問題。


2、解決方案：

圖片壓縮也做了，資源回收也做了，但是ViewPager載入越來越多圖片的時候就會oom 你避免不了，不信你試試；

這裡就要用到ViewPager的view的重用機制(自己理解的)，也就是mViews我們固定給定個數量，如4，這樣ViewPager的i實際所需要的item也就只有4個。

修改後的部分程式碼：

 for (int i = 0; i < 4; i++) {
            SubsamplingScaleImageView view = new SubsamplingScaleImageView(this);
            mViews.add(view);
        }

        mBinding.viewpager.setAdapter(new MyAdapter());

class MyAdapter extends PagerAdapter {

        @Override
        public int getCount() {
            return mDatas.size();
        }

        @Override
        public boolean isViewFromObject(View view, Object object) {
            return view == object;
        }

        @Override
        public Object instantiateItem(ViewGroup container, final int position) {

            ViewGroup.LayoutParams params = new ViewGroup.LayoutParams(
                    ViewPager.LayoutParams.MATCH_PARENT,ViewPager.LayoutParams.MATCH_PARENT);

            int i = position % 4;
            final SubsamplingScaleImageView imageView = mViews.get(i);
            imageView.setLayoutParams(params);

            final String url = mDatas.get(position);
            String cacheExists = cacheExists(url);
            if(TextUtils.isEmpty(cacheExists)) {//沒快取 需要壓縮(壓縮耗時 非同步)
                new AsyncTask<Void, Void, String>() {
                    @Override
                    protected String doInBackground(Void... voids) {
                        String cacheNoExistsPath = getCacheNoExistsPath(url);
                        BitmapCompressUtils.compressBitmap(url, cacheNoExistsPath);
                        File file = new File(cacheNoExistsPath);
                        if (file.exists()) {//存在表示成功
                            return cacheNoExistsPath;
                        } else {
                            return url;
                        }
                    }

                    @Override
                    protected void onPostExecute(String s) {
                        imageView.setImage(ImageSource.uri(s));
                    }

                }.execute();


            } else {//有快取 直接顯示
                imageView.setImage(ImageSource.uri(cacheExists));
            }

            container.addView(imageView);
            return imageView;

        }

        @Override
        public void destroyItem(ViewGroup container, int position, Object object) {
            int i = position % 4;
            SubsamplingScaleImageView imageView = mViews.get(i);
            if(imageView != null) {
                imageView.recycle();
            }

            container.removeView(imageView);

        }

很簡單的修改 就能有效防止oom  利用position%4拿到第幾個控制元件從mViews取值,保證了viewpager載入的mViews儲存的圖片為4個

看一直向下滑動的記憶體走勢圖



記憶體基本維持穩定

三、demo演示

因為要讀取相簿就沒再模擬器執行錄製gif ，直接截圖


四、總結

這個只是簡單的演示，實際專案中的相簿比這個複雜多了，簡單說就是要壓縮，要回收，View重用。

有什麼問題可以留言

相關推薦

Android_效能優化之ViewPager載入成百上千高清大圖oom解決方案

歡迎加入技術談論群：714476794一、背景最近做專案需要用到選擇圖片上傳，類似於微信、微博那樣的圖片選擇器，ContentResolver讀取本地圖片資源並用RecyclerView+Glide載入圖片顯示就搞定列表的顯示，這個沒什麼大問題，重點是，點選圖片進入大圖瀏覽，

iOS 效能優化之頁面載入速率

前言 之前蒐羅了網上很多關於iOS效能優化方面的資料 ，本人和我的小夥伴們也用了一些時間針對自己的App進行了App的啟動速率、頁面的載入速率和 頁面的幀率方面進行了優化，所以結合了理論和實踐，把我們在實踐中主要踩過的坑和需要注意的東西 ，總結了一下，希望可以

網頁效能優化之非同步載入js檔案

一個網頁的有很多地方可以進行效能優化，比較常見的一種方式就是非同步載入js指令碼檔案。在談非同步載入之前，先來看看瀏覽器載入js檔案的原理。 瀏覽器載入 JavaScript 指令碼，主要通過<script>元素完成。正常的網頁載入流程是這樣的。 瀏覽器一邊下載 HTML 網頁，一邊開始解析。

安卓效能優化之懶載入（View的懶載入）

1、背景：為什麼需要View的懶載入。           我們在做安卓專案的時候，經常會有一個使用場景：需要在執行時根據資料動態決定顯示或隱藏某個View和佈局。       上述場景，我們通常的解決方案就是：就是把可能用到的View先寫在佈局裡，再初始化其可見性都設為

Android之打造自己載入高清大圖及瀑布流框架.解決錯位等問題.

    首先看效果圖如下:     本框架支援本地圖片和網路圖片的獲取.採用LruCache演算法,最少使用的最先釋放.有效的避免OOM,專案結構圖:          核心載入類在於ImageLoader.採用了TreadPool去做併發請求.UI處理採用Handler

IOS 多個UIImageView 載入高清大圖時記憶體管理

當我們在某一個View  多個UIImageView，且UIImageView都顯示的是高清大圖，就有可能出現記憶體警告的問題。如果第一次進入這個view，沒有發生記憶體警告，當再次進入這個view，如果上一次的記憶體沒有及時釋放，這一次次的累加，便可導致記憶體崩潰。 1，

淺談android中載入高清大圖及圖片壓縮方式(二)

　　這一講就是本系列的第二篇，一起來聊下關於android中載入高清大圖的問題，我們都知道如果我們直接載入原圖的話，一個是非常慢，需要等待一定時間，如果沒有在一定的時間內給使用者響應的話，將會極大影響使用者的體驗。另一個是如果你的手機記憶體小的話，可能會直接崩潰。這也就是直

runloop實戰應用——載入高清大圖

問題描述 在用tableVIew或者scrollView載入多張高清大圖的時候，頁面會卡頓。如下圖 原因 runloop在一次渲染中，需要渲染十幾張高清大圖，所以卡主了 解決思路 每次Runloop迴圈,只渲染一張大圖!! 1.

載入高清大圖長圖

Android 高清載入巨圖方案 拒絕壓縮圖片 一、概述 距離上一篇部落格有段時間沒更新了，主要是最近有些私事導致的，那麼就先來一篇簡單一點的部落格脈動回來。 對於載入圖片，大家都不陌生，一般為了儘可能避免OOM都會按照如下做法： 對於圖片顯示：根據需要顯示圖片控

IOS多個UIImageView載入高清大圖時記憶體管理

當我們在某一個View  多個UIImageView，且UIImageView都顯示的是高清大圖，就有可能出現記憶體警告的問題。如果第一次進入這個view，沒有發生記憶體警告，當再次進入這個view，如果上一次的記憶體沒有及時釋放，這一次次的累加，便可導致記憶體崩潰。

Android效能優化之較精確的獲取影象顯示到螢幕上的時間

轉載自：http://blog.desmondyao.com/android-show-time/ 這兩天我的包工頭歪龍木·靈魂架構師·王半仙·Yrom給我派了一個活：統計App冷啟動時間。這個任務看上去不難，但是要求統計出來的時間要準，要特別準。 意思就是，我必須要按Activity繪製到

效能優化之載入

效能優化之載入 一、預載入 原理：預載入即提前載入，就是為了讓需要載入的內容在觸發載入之前載入好，觸發載入時只是簡單的展示，這樣會使使用者操作起來更加流暢。但缺點是增加了首次請求的請求數； 使用場景：如選單背景圖切換時提前載入背景圖，減少切換時出現短暫空白現象； 使用方法：預

Android系列Viewpager+Fragment 優化之懶載入（預載入）的實現

今天帶來的就是fragment的優化，怎麼去實現懶載入 懶載入（預載入） 懶載入字面意思就是當需要的時候才會去載入，不需要就不要載入 為什麼Fragment需要懶載入呢，一般我們都會在onCreate()或者onCreateView()裡去啟動一些資料載入操作，比如從本

ionic入門教程第十五課-ionic效能優化之圖片延時載入

週五的時候有個朋友讓我寫一個關於圖片延時載入的教程， 直到今天才有空編輯，這階段真的是很忙，公眾號都變成殭屍號了。 實在是對不起大家。 有人喜歡我的教程，可能我總習慣了用比較簡單容易理解的方式去描述這些東西。 別的就不多說了，大家遇到什麼問題。 可以直接聯絡我，不是一句話兩

菜鳥要做架構師——java效能優化之for迴圈

完成同樣的功能，用不同的程式碼來實現，效能上可能會有比較大的差別，所以對於一些效能敏感的模組來說，對程式碼進行一定的優化還是很有必要的。今天就來說一下java程式碼優化的事情，今天主要聊一下對於for（while等同理）迴圈的優化。 作為三大結構之一的迴圈，在我們編寫程式碼的時候會經常用到。

效能優化之記憶體優化

效能優化之記憶體優化 計算 APP 獲得的最大記憶體分配值 Runtime rt=Runtime.getRuntime(); long maxMemory=rt.maxMemory(); Log.i("maxMemory:",Long.toString(max

Sql Sever效能優化之指定索引

背景：生產環境SQL語句查詢過慢（資料總量在350萬左右），日誌中心一直報警 解決過程：分析無果後，求助於公司的DBA，DBA分析後建議在語句中指定索引 解決：在SQL語句中指定索引，效果相當明顯，親測有效 優化前SQL： SELECT ROW_NUMBER() OVER ( ORDER BY

Android——效能優化之SparseArray

相信大家都用過HashMap用來存放鍵值對，最近在專案中使用HashMap的時候發現，有時候 IDE 會提示我這裡的HashMap可以用SparseArray或者SparseIntArray等等來代替。 SparseArray(稀疏陣列).它是Android內部特有的api,標準的jdk是沒有這

KVM總結-KVM效能優化之磁碟IO優化

前面講了KVM CPU(http://blog.csdn.net/dylloveyou/article/details/71169463)、記憶體(http://blog.csdn.net/dylloveyou/article/details/71338378)的優化，下面接著第三塊的內容，KVM磁

MySQL(三) —— MySQL效能優化之 索引優化

MySQL索引優化 如何選擇合適的列建立索引？ 在where從句、group by 從句、order by 從句、on 從句中出現的列 索引欄位越小越好 離散度大的列放在聯合索引的前面 如何判斷列的離散度？ 去重查詢看列的唯一值，唯一值越多則離散度越大。 mysql&