蘋果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性能分析