ios app效能分析

標籤：寫代碼   解析失敗   資料庫   dexp   切換頁面   請求   size   安卓   應用   

蘋果app的流暢性一般比安卓的要好的多。應該是和蘋果系統的設計理念同樣，早期的iphone4曾經是絕對單任務，僅僅能做一件事情，儘管添加了後台能夠。音樂播放，定位等有限的服務。可是大多數普通應用程式切換到後台就別掛起，直到被系統殺死（10－－15分鐘）。一個任務當然記憶體利用率和cpu調度管理就要好管理多了，效率也高。app也不作為server。也不存在超多個socket連結的問題。當然app的效能問題和pc的應用效能問題全然不同。
app主要負責的是資料請求與展示，所以app主要是表如今資料請求方面，展示方面的也有，可是不多。
影響app效能的詳細情況分以下幾類情況：
1.server須要查詢資料庫。比較費時間。

通常有這幾種情況：server資料量較大。資料庫的表分類不合理。資料庫中的表索引設定不夠好，資料庫查詢語句不夠最佳化，資料庫中有髒資料。
2.client反覆發送大量反覆的請求，片下載過程中的反覆下載和代碼邏輯有問題。

3.大量並發發送請求，導致部分請求逾時。如有的登入成功後發送上下班狀態請求。訊息數量請求。金額請求等。

4.用百度代理函數批量解析步行距離，經緯度。
5.把大圖片記憶體直接搬入記憶體並顯示。大資料搬入記憶體。

6.程式出現死迴圈和常常重新整理整個表格。
7.把全部的請求發送到一個server地址進行資料請求。導致server的處理效能下降，進而影響client的效能。
8.短期內收到大量push訊息，不斷中斷使用者操作。甚至導致使用者短期內不能操作app。

9.由於發送請求較慢，請求頁面的資料不確定。載入頁面周期長，使用者長時間看不到完整的頁面，在切換頁面前發送請求，發送成功才切換到相應頁面。
以下是對以上效能問題的解決方式。

對於情況1，當然最佳化資料庫中各個表格，對全部表格設定索引（表的索引對資料的查詢影響超大），最佳化查詢語句，抽象出查詢高頻率的表進行最佳化。去除髒資料。

情況2，用charles抓包和列印日誌哪些請求出現了反覆發送，消除這種不合理的邏輯和錯誤。
情況3。盡量或避免並發請求。能合并的請求盡量合并，如登入後須要發送的大量的請求，直接在登入時就把參數寫上，登入的成功響應訊息裡把你須要各種結果都返回就能夠了。
情況4，百度的步行距離計算代理和地址經緯解析代理都不支援瞬時大批量解析，輕者解析非常費時間才得到結果，重者server拒絕解析或僅僅解析一部分。所以要採用解析一個再去解析還有一個的事件方式解析，防止一窩峰的整個表格的有關步行距離和位址解析的請求都一次性交給百度哥。

當然也存在剛開斷網進入應用，網路恢複，收到網路正常通知後立刻自己主動登入成功後立刻去解析步行距離。百度哥告訴你連網成功，授權成功，實際上你會解析失敗，只是你再去解析一次一般都能夠解析成功。
情況5。你能夠用UIImage *image = [AppManager resizeImage:[UIImage imageNamed:@”my_backgroud_up_6.png”] toSize:CGSizeMake(WINDOW_WIDTH, 64) scale:1];這種方式壓縮顯示在記憶體中。

當然也有把大資料搬入記憶體的情況。一般僅僅須要讀取你用到的部分的資料就能夠。僅僅是我沒有這方面的詳細範例。這樣就防止app記憶體暴漲了，當然你用完後不在使用它了把這類大的對象指標置空，讓系統自己去回收預計效果更好些。
情況6，死迴圈要不得。進入死迴圈若沒有能符合的跳出條件。app相當於隔屁了。所以盡量別設計這類的迴圈等待，若是全然的死迴圈，盡量用單元測試發現，解決掉它。

迴圈刷表格要不得。要等全部資料處理完再刷整個表格([self.tableView reloadData])，當然你僅僅是刷一行表格（如一行表格的高度和內容變更）能夠用[self.tableView reloadRowsAtIndexPaths:@[[NSIndexPath indexPathForRow:self.selectedIndex inSection:0]] withRowAnimation:UITableViewRowAnimationNone];這種重新整理一行表格的局部表格重新整理。若你僅僅改變一個頁面的一個內容（映像變換，標籤內容）而且不影響表格。直接把它的指標設定成本面的全域變數。直接改動就能夠了，也不須要重新整理整個表格或儲存格。若死迴圈重新整理表格。整個程式也完了。肯本不能有這種邏輯。發現一個乾死一個。可是必定誰也不想寫這種代碼，這就是寫代碼的目的和實際實現的處理不一致，單元測試測試達到分支覆蓋就非常easy發現這種嚴重的bug。這類問題僅僅所以出現，可能是邏輯設計錯誤，也可能是拼字錯誤。也可能是從其他代碼拷貝來的代碼沒有改動或改動的不全然對。當把每一個函數的循環複雜度減少到15以下，再編寫測試測試用例就非常easy。若一個主函數上千行。談何單元測試。
情況7，每一個請求相應一個請求網頁地址，用AFNetworking發送http請求。把請求的參數拼接到請求中如，http://test.zuixiandao.cn/fhl/phone/psy/startWorkJsonPhone.htm?cmdCode=0003&key=BF233049EC74B822EB5520A6ADA30A76&phoneId=ios_120e438f-9757-451d-b980-0d87824b02eb&visitTime=1437550879&workKey=1。

server一個頁面處理。當大量使用者訪問時easy出現效能問題。而且也不easy區分各個請求。導致內部邏輯超複雜。server的效能受到影響，當然也影響client的請求回應時間必定受到影響。這種每一個請求相應一個子頁面的方式也對各個頁面狀態的同步要求非常高，操作資料庫的並發也要控制好。幸虧有會話資訊能夠放在cookies裡。
情況8。server的push分為不同類型，每次把push訊息的類型發過來。client對高頻發的訊息進行按時間和類型的進行適當捨棄，如3秒內最多才幹彈出一個新訂單訊息。

若你的push錄音播放非常長。不攔截可能出現聲音疊加的問題。還好蘋果對每分鐘向一個app最多推送訊息有限時，導致不非常明顯，可是安卓這類現象是否嚴重。就由於蘋果對每分鐘push訊息個數的限制，所以導致有部分push訊息可能丟失。
情況9，最好先切換頁面後發送請求。除非有特別的需求才須要這樣做，不讓讓人有感覺處理慢的效能問題。

當然跳到一個頁面時要一個資料載入進度的動畫效果，如一個人型圖案的載入過程。進頁面就顯示一個菊花那樣太不友好。

最app影響效能的都和server方面有關，弱網路登入這個最煩人了，所以要有自己主動登入逾時也能進入首頁，無網路也能進首頁彈出黃條就能夠。自己主動登入要依據網路通知事件來觸發登入，沒有網路還向服務發什麼，當然發也是失敗，還存在正在發送中網路正常的情況。這樣也不可控。也不用浪費電量的起個定時器傻傻的等待網路事件的事情，儘管正常網路網路通知在1秒內能夠收到。有的弱網路比較慢，何不由網路通知事件觸發登入呢？所以收到網路通知才發起自己主動登入是最好的選擇。

這樣在自己主動登入方面也提高效能，讓使用者app啟動非常快。

ios app效能分析