iOS App記憶體優化之 解決UIImagePickerController的圖片物件佔用RAM過高問題
這個坑會在特定的情況下特別明顯:
類似朋友圈的新增多張本地選擇\拍照 的圖片 並在介面上做一個預覽功能
由於沒有特別的相機\相簿需求,則直接使用系統自帶的UIImagePickerController
最簡單的方法-> UIImagePickerController 選擇圖片 -> 代理返回圖片物件-> 在array中新增圖片物件 -> 用collectionview顯示-> 提交的時候遞迴上傳array的image內容
然而這裡就發現一個會吃記憶體的坑...
代理返回的UIImage物件 新增到array時,記憶體暴漲
其實也不是新增物件到array裡導致的問題,因為我的collectionview 不reload 的話,圖片不顯示時 記憶體也是正常的,只有把這個image物件放置到UIImageView時 記憶體才會暴漲
因此懷疑是圖片解碼方面的原因:解碼會呼叫到ram快取,以便下次讀取時不用再次解碼
然而為了避免app佔用ram過高而被系統kill掉,這個圖片必須要處理一下
通過圖片重新繪製得到UIImage這個佔用記憶體的情況會消失
因此寫個Category方法來簡單處理一下就可以了
- (UIImage *)redraw{ CGFloat width = CGImageGetWidth(self.CGImage); CGFloat height = CGImageGetHeight(self.CGImage); // 建立一個bitmap的context // 並把它設定成為當前正在使用的contextUIGraphicsBeginImageContext(CGSizeMake(width, height)); // 繪製圖片大小設定 [self drawInRect:CGRectMake(0, 0, width, height)]; // 從當前context中建立一個圖片 UIImage* image = UIGraphicsGetImageFromCurrentImageContext(); // 使當前的context出堆疊 UIGraphicsEndImageContext(); // 返回新的改變大小後的圖片return image; }
結果:
這篇不是乾貨,只是解決了一個小問題.
相關推薦
iOS App記憶體優化之 解決UIImagePickerController的圖片物件佔用RAM過高問題
這個坑會在特定的情況下特別明顯: 類似朋友圈的新增多張本地選擇\拍照 的圖片 並在介面上做一個預覽功能 由於沒有特別的相機\相簿需求,則直接使用系統自帶的UIImagePickerController 最簡單的方法-> UIImagePickerController 選擇圖片 -> 代理返回圖
iOS開發記憶體優化之自動檢測記憶體洩露,檢查是否有迴圈引用,檢查記憶體為何如此大,Block迴圈引用的檢查
手機裝置的記憶體是一個共享資源。應用程式可能會不當的耗盡記憶體、崩潰,或者遭遇大幅度的效能降低。 Facebook iOS客戶端有很多功能,並且它們共享同一塊記憶體空間。如果任何特定的功能消耗過多的記憶體,就會影響到整個應用程式。這是可能發生的,比如,這個功能導致了記
win10 解決 WMI Provider Host 佔用CPU過高問題
真心懶得寫Blog,但是之前遇到這個問題在網上查了一大圈,幾乎一摸一樣都是讓關防火牆等服務的,然而對於我來說,並沒有毛線用。 無奈,直接去微軟社群查,還真有一篇問題解決方案。順手翻譯一下放在這裡,希望能幫到大家。 參考連結:https://answers.m
App效能優化之View優化(2)——UI問題的解決
一.概況 上一篇中App效能優化之View優化(1)——UI問題的檢測主要講的是我們在寫完程式碼之後,如何發現程式碼中的問題。從問題中提取經驗,規範好自己之後的程式碼編寫,本文就是講如何規範的進行UI關聯程式碼的書寫。 二.主要的點 View控制元件
cocos2dx 圖片記憶體優化之從200M到50M
公司專案曾經出過一個非常牛逼的問題,由於我感覺一個手機數百M記憶體,怎麼還能不夠用??以至於後來導致遊戲卡到爆,卡到我內心萬馬奔騰的時候我決定,我要優化記憶體。 不過程式碼都寫了如果要動程式碼那我真心日
iOS性能優化之Leaks動態分析
反向輸出 ges 合並 性能優化 recursion 問題 details auto 14. iOS性能優化之Leaks動態分析 Instruments-Leaks有很多跟蹤模塊可以動態分析和跟蹤內存, CPU 和文件系統(因為是動態分析 所以必須運行才能打開)。 具體
ios-App耗電優化
本文轉自:http://www.cocoachina.com/ios/20171205/21428.html 一款好的App一定要有非常好的使用者體驗,這一點已經是大多數開發者的共識。功耗是使用者體驗中一個重要的組成部分,但這部分因為各種問題,很多時候會被大家忽略。之前公司讓我在內部搞個功耗
iOS app上傳 之TestFlight Beta版本測試
軟體開發中的版本分類alpha內部測試版本,極不穩定,一般也不會出現在公眾視線中,僅供內部測試人員測試用。 beta公共測試版,就是對外發布軟體的測試版,用於收集公眾的意見、建議和問題。 就是正式版了,一般都很穩定。 如何將App安裝到真機裝置上供測試方式一:內部測試(內測)
實踐App記憶體優化:如何有序地做記憶體分析與優化
由於專案裡之前線上版本出現過一定比例的OOM,雖然比例並不大,但是還是暴露了一定的問題,所以打算對我們App分為幾個步驟進行記憶體分析和優化,當然記憶體的優化是個長期的過程,不是一兩個版本的事,每個版本都需要收集線上記憶體資料進行監控以及分析。 版本迭代
資料庫查詢速度優化之解決技巧
1、對查詢進行優化,應儘可能避免全表掃描 首先應考慮在 where 及 order by 涉及的列上建立索引。 下面我們來以一個表中177條資料比較一下,全表掃描與建立索引之後效能的一個比較.
android記憶體優化之三記憶體分析工具的使用
anroid記憶體分析工具的使用 一.Eclipse Heap分析記憶體洩露 Android開發中避免不了碰到記憶體洩露問題,這裡先大概講下記憶體洩露的基本概念:記憶體洩露官方的解釋是是用動態儲存分配函式動態開闢的空間,在使用完畢後未釋放,結果導致一直
Vue腳手架工程優化之原始碼和圖片壓縮--webpack配置
在前端做載入速度優化的方案中,有一個是對原始碼和圖片大小進行壓縮。顧名思義就是將原始碼去掉空格、註釋、換行等生產環境中的無用資訊。圖片在不影響效果的前提下進行壓縮。從而減小圖片大小,頁面在載入的時候由於載入的資源較小,實現更快載入。公司的專案是通過Vue的腳手架工具搭
iOS 網路請求優化之取消請求
頁面返回的時候,將網路請求取消 同一個請求多次請求時,短時間忽略相同的請求 同一個請求多次請求時,取消之前發出的請求 傳送的請求,多次嘗試並確保成功 最近發現很多網路請求都有可以優化的地方,雖然開發和測試都沒有發現問題,但是可以讓程式碼更加的優雅。想到
android記憶體優化之webview
在混合型app中它是主角,一切由它呈現,如58同城,趕集網等;在另一些超級app中亦有它的影子,微信,qq,支付寶,沒有一個超級app能少了它,既能展示最新最潮的實時資訊,又能扮演盤踞一方的全功能型網站,與native結合後又能扮演諸如公眾號之內的應用等等,其能力可想而知。webview在android端的演
記憶體優化的解決方案(最全面的總結!如何合理的使用記憶體)
由於Android應用的開發語言為Java,每個應用最大可使用的堆記憶體收到Android系統的限制,通常分配給每個應用程式的記憶體大小為:16M~48M,而如果試圖申請的記憶體大於當前
專案總結1:微信掃碼自動識別裝置型別並跳轉到相應的應用下載頁面(apk或App Store)之解決方案
問題分析:普通頁面一般無法呼叫微信的掃一掃介面,從而否定通過微信掃一掃功能給我們判斷當前掃碼的裝置型別。 解決方案:通過應用下載頁面自身來獲取當前訪問的客戶端裝置型別(iPhone、Android、iPad),然後分別跳轉到不同的下載連結。 新建一個靜態頁面,如:down
App效能優化之卡頓終極原因研究及總結
熱文導讀 | 點選標題閱讀來源:CoorChicehttps://www.jianshu.com
Android-記憶體優化之OOM
Android的記憶體優化是效能優化中很重要的一部分,而避免OOM又是記憶體優化中比較核心的一點,這是一篇關於記憶體優化中如何避免OOM的總結性概要文章,內容大多都是和OOM有關的實踐總結概要。理解錯誤或是偏差的地方,還請多包涵指正,謝謝! (一)Android的記憶體
攜程移動App架構優化之旅
本文為攜程移動開發總監陳浩然在2015年10月份的ArchSummit全球架構師峰會上的演講總結。由於面向受眾為架構師,因此不會涉及到很多技術細節。通過本文,你可以瞭解攜程通過哪些手段來優化它的App架構的。 『攜程旅行App』作為攜程超級App產品,是
Android App效能優化之UI流暢度優化
一、卡頓的問題本質 UI流暢度的優化主要是解決UI卡頓的現象,而UI卡頓的源頭就是渲染效能的問題。佈局太複雜或者是一個元素重複繪製多次等原因,Android系統無法及時完成那些複雜的介面渲染操作,這樣就發生了丟幀,使用者就會感覺到不流暢,卡頓。 Androi