當(dāng)你拿到這本書的時候我默認(rèn)你是一個iOS開發(fā)者或者已經(jīng)開發(fā)應(yīng)用程序很長一段時間了，并且愿意從另外一個開發(fā)聯(lián)盟加入進來。
在這一章中我們主要領(lǐng)略下高性能app中的一些概念。
定義性能
從技術(shù)的角度講，性能是經(jīng)常被提起的一個模糊的話題，經(jīng)常有些人說高性能應(yīng)用程序但是我們確不知道他們真正在說什么，可能是說用了更少的內(nèi)存，節(jié)省了網(wǎng)絡(luò)流量的使用，或者使用流暢等。
對于我來說，當(dāng)談到高性能的時候，我將從多個方面來討論，一部分是性能的定義，另外我們想要衡量和各種的東西，最后是通過搜集數(shù)據(jù)來測量驗證
在這一章中我們將探討性能的定義接下來我們將討論性能的測量，我們將深入的探索測量過程。
性能定義
內(nèi)存
對于內(nèi)存，我將從應(yīng)用程序消耗的最低內(nèi)存，平均和最大內(nèi)存開始討論，最小內(nèi)存對硬件做了一個限制，高的平均內(nèi)存意味著很多后臺程序?qū)粴⑺溃畲髢?nèi)存將增加應(yīng)用后臺內(nèi)存超出的幾率。
也就是說，你一定要確保內(nèi)存不要泄露，如果內(nèi)存隨著時間的推移持續(xù)增加那么意味著程序可能崩潰拋出內(nèi)存不足異常。
電量消耗
這是另外一個實現(xiàn)高性能代碼的因素，不僅你的數(shù)據(jù)結(jié)構(gòu)和算法要高效而且還需要考慮其他因素，如果你的應(yīng)用是耗盡電量，那我確定沒有喜歡用它。
電量消耗不僅僅是關(guān)注CPU計算周期，同時也是高效實用硬件。
因此需要謹(jǐn)慎的構(gòu)造代碼，在減少電量消耗決策之前，同時要確保不要降低用戶體驗。
啟動時間
你平時打開一個app需要多長時間還是你自是安裝從來不打開？
當(dāng)我們自己的app給別人用的時候，你可能需要初始化很多任務(wù)在用戶使用前，但是一直有爭議的 ，延遲初始化是一個很好的策略用戶在執(zhí)行后續(xù)任務(wù)的時候不應(yīng)該每次都等待。
下面是一些你可能在初始化做的事情：
- 檢查app是不是第一次加載；
- 檢查用戶是否登錄；
- 如果用戶已經(jīng)登錄如果可以的話加載之前的狀態(tài)；
- 連接服務(wù)器獲取最新的更改
- 檢查應(yīng)用底層是否加載完成，如果完成加載UI和狀態(tài)
- 檢查上一次是否有掛起的任務(wù)，如果需要的話就恢復(fù)
- 初始化后續(xù)需要用到的對象和線程池
- 初始化關(guān)聯(lián)東西，例如ORM 崩潰報告系統(tǒng)緩存等。
初始化的事情一直在增加，很難決定是應(yīng)該啟動的時候加載還是延遲加載。
執(zhí)行速度
一旦用戶在使用一個app，他希望盡可能流暢的，任何執(zhí)行過程都應(yīng)該很少時間。
例如一個拍照app，我做的任何編輯我都想在很短的時間看到結(jié)果。我不想花時間討論。
對于一些簡單的效果，例如改版亮度或者對比度，如果能在我調(diào)整的時候看到預(yù)覽的效果那最好了，因此他就需要我們在更短的時間內(nèi)處理完成。
建議：對于一個長時間的運行過程總是應(yīng)該用一個進度來顯示這個過程，無論是費時的計算還是下載內(nèi)容
響應(yīng)性
你的應(yīng)用程序應(yīng)該快速的響應(yīng)用戶的操作，響應(yīng)性是所有優(yōu)化的結(jié)果 權(quán)衡你在程序中做的事情。
有如此多的應(yīng)用在爭取用戶的關(guān)注，你通常有少于一分鐘的時間讓你的應(yīng)用進入用戶的首選應(yīng)用列表，時間限制是非常嚴(yán)格的，如果有很多程序提供了同樣的功能，如果你能再第一步加載的時候消耗更少的時間，那進入用戶的首選列表的轉(zhuǎn)換成本就會很小。
例如我在商店搜索2048游戲的時候，我至少搜索到了超過半打的應(yīng)用，因為我不確定用哪個所以我下載了所有的然后刪除他們最后留下一個。有很多原因起到作用，加載時間、用戶體驗、比其他的更好的平滑動畫等待，每個應(yīng)用有15秒讓我留下印象。
本地存儲
任何應(yīng)用都都是存儲數(shù)據(jù)在服務(wù)器或者另外的數(shù)據(jù)源，但是必須要有一個離線的本地存儲計劃。
我希望我的郵件app至少能顯示我已經(jīng)閱讀過的郵件在離線或者沒有網(wǎng)絡(luò)的時候。
同樣一個新聞app也應(yīng)該能夠在離線模式下顯示上次更新的新聞，以及一些提示對每個新聞條目表明什么事新的和我已經(jīng)準(zhǔn)備讀的，如果我不要訂閱我也不需要登錄。
然而，從本地加載數(shù)據(jù)應(yīng)該是快速的，這不僅要求我們選擇本地緩存而且還要考慮數(shù)據(jù)結(jié)構(gòu)，選擇遠程同步頻率等。
任何應(yīng)用一直占用本地存儲但是沒有一個清理功能對我來說是最糟糕的，令人遺憾的是，大多數(shù)在市場上的應(yīng)用都沒有這個功能，更讓我悲哀的是，下面圖表中的應(yīng)用很多都使用本地存儲在幾百兆，所以當(dāng)我耗盡空間的時候，我只是刪除這些應(yīng)用很長一段時間不在下載他們。
圖-1
從圖1中我們可以看出，超過12G的空間已經(jīng)被使用了只留下950M的可使用空間，我是不高興的對于Facebook使用了250M而沒有提供一個清理按鈕。唯一的清理辦法就是刪除app，另外一個Google+是只用了5M到目前為止是挺好的，但是他也沒有提供一個清理按鈕。
出于這個原因，如果我安裝的社交應(yīng)用像WhatsApp或者Viber如果他們存儲多媒體數(shù)據(jù)但是沒有提供清除按鈕，我不會打開攝像頭權(quán)限，如果他占用很多空間，我寧愿不使用app中的多媒體功能或者直接卸載它。
建議：總是應(yīng)該給終端用戶提供一個清除緩存按鈕。
交互性
iOS提供多種交互操作在app之間共享數(shù)據(jù)，UIActivityViewController、deeplinking，MultipeerConnectivity框架都是可以使用的
定義一個類良好的URL結(jié)構(gòu)對于寫好代碼來解析它是非常重要的，同樣也適用于分享數(shù)據(jù)。
如果你的應(yīng)用需要花很長的時間來準(zhǔn)備數(shù)據(jù)共享到附近的設(shè)備上，那將是一個很糟糕的體驗。
網(wǎng)絡(luò)情況
應(yīng)用應(yīng)該工作在所有網(wǎng)絡(luò)情況下：
- 高帶寬穩(wěn)定網(wǎng)絡(luò)
- 低帶寬穩(wěn)定網(wǎng)絡(luò)
- 高帶寬不穩(wěn)定網(wǎng)絡(luò)
- 低帶寬不穩(wěn)定網(wǎng)絡(luò)
- 無網(wǎng)絡(luò)
給用戶一個提示或者錯誤消息是很好的，但是不能讓用戶無限的等待或者程序崩潰。
圖2
圖2顯示了不同的方式來呈現(xiàn)消息給用戶，TuneIn應(yīng)用顯示了多少流媒體內(nèi)容已經(jīng)緩存，它告訴用戶還需要等待多久才能開始播放音樂。另外像MoneyControl或者Bank of America應(yīng)用它提供了一個不確定的進度條，它更適用于沒有流媒體的應(yīng)用。
帶寬
人們使用手機不僅在wifi情況下同時還是用移動網(wǎng)絡(luò)LTE\3G\2G等，根據(jù)維基百科一篇文章統(tǒng)計的各個國家的網(wǎng)絡(luò)情況，全世界平均帶寬3.8M/S，韓國最快21.9M/S,玻利維亞最慢1M/S.
因此優(yōu)化使用帶寬是另外一個衡量產(chǎn)品好壞的因素，還請記住，如果你已經(jīng)在低帶寬下開發(fā)了程序，運行在高帶寬的時候可能產(chǎn)生不同的結(jié)果。
我記得2010年我和一個大部分人員在印度開發(fā)團隊開發(fā)一個應(yīng)用，網(wǎng)絡(luò)帶寬是很糟糕的需要花很長的時間初始化，因此對于這種情況我們改變了程序市場。
然而當(dāng)我們在韓國市場測試的時候出現(xiàn)了完全不同的結(jié)果，我們沒有做任何優(yōu)化和權(quán)衡工作，因此我們需要寫大量的代碼來避免可能發(fā)生的資源和數(shù)據(jù)競爭。
因此打算實現(xiàn)高性能并不總是優(yōu)化的結(jié)果，有時候評估也會導(dǎo)致。
數(shù)據(jù)刷新
即使你沒有任何的離線瀏覽功能，你也需要一直定期的來刷新數(shù)據(jù)，數(shù)據(jù)刷新的頻率和傳輸?shù)淖止?jié)都會影響整個流量的消耗，如果這個傳輸?shù)淖止?jié)足夠大，用戶肯定會耗盡他的流量，如果這個值足夠大，那么你可能已經(jīng)失去了一個用戶。
iOS6.x的應(yīng)用是不能再后臺刷新數(shù)據(jù)的，從iOS7開始，應(yīng)用可以使用后臺程序刷新，對于實時聊天應(yīng)用一個持久的HTTP或者TCP鏈接可能是更有用的。
多賬戶管理
對于一個家庭來說共用一臺手機是很平常的。例如兩個孩子可能用同一個iPad玩游戲，其中一個人可能想要在假期期間配置一臺設(shè)備來查看每個人的郵件來減少個人的漫游費用，特別是真正國際旅行期間。
決定支持多用戶完全是一個產(chǎn)品決定的，但是如果你決定要支持，請確保：
- 用戶加載高效
- 用戶更新高效
- 用戶切換高效
- 用戶邊界應(yīng)該清楚的并且沒有任何bug
圖3
單點登錄
如果有一個或多個應(yīng)用允許或要求登錄，單點登錄總是一個好主意，因此如果我在一個應(yīng)用中已經(jīng)登錄，那么在其他應(yīng)用只需要點擊登錄就可以。
現(xiàn)在，在跨應(yīng)用之間不僅要同步數(shù)據(jù)，還要同步狀態(tài)等等，因此如果我在其他應(yīng)用登出了沒那么之前登錄的也應(yīng)該顯示登出狀態(tài)。
所有的可能執(zhí)行的邏輯都應(yīng)該高效且安全的。
安全性
安全是非常重要的對于幾個一起安裝的移動應(yīng)用，應(yīng)該確保相互通信，本地數(shù)據(jù)保護和所有的表單數(shù)據(jù)安全，他們都是應(yīng)用共享數(shù)據(jù)安全的關(guān)鍵屬性。
加密是一個不錯的選擇，但是他增加了處理數(shù)據(jù)的時間，更不要說內(nèi)存的消耗了。
因此你需要權(quán)衡速度和加密，但是他們兩者的平衡點的一個關(guān)鍵因素是用戶體驗，注意，硬件也扮演一個重要的角色，在iPhone4上面做的優(yōu)化和注意事項可能在iPhone5C 5S上的結(jié)果是完全不同的。
崩潰
應(yīng)用可能會崩潰，一定會崩潰，過度的優(yōu)化可能也會導(dǎo)致崩潰，使用C代碼也可能導(dǎo)致崩潰。
一個高性能的應(yīng)用應(yīng)該能在崩潰的時候保護自己，并且還能優(yōu)雅的恢復(fù)，例如一些在崩潰中發(fā)生的操作。
項目：高性能
例子創(chuàng)建步驟不翻譯
事列：vCircle
vCircle是我們構(gòu)建的一個基礎(chǔ)網(wǎng)絡(luò)社交app，它支持以下功能:
- 登錄Facebook
- 支持多賬戶
- 顯示最新提示
- 顯示一條信息包括圖像或者所有評論
- 檢索用戶的所有帶評論和標(biāo)記的照片
- 允許添加評論到朋友的狀態(tài)或照片
- 支持無線滾動
我們建立vCircle項目重點是關(guān)注性能，功能可能有些沒有完成，但是我們會完成所有有關(guān)性能的代碼。
并且我們不會使用Facebook或者其他功能性的SDK 我們盡量自己寫代碼，用SDK的一些基礎(chǔ)常見功能。
我們將會用到CocoaPods，如果你不熟悉它，你可能要停下來學(xué)習(xí)下它。
我們在本書的后面將開始使用這個程序。
這個代碼你可從github上下載
備注：這章翻譯基于早期的版本 所以內(nèi)容和下載鏈接有區(qū)別，后續(xù)章節(jié)將基于最新版本。
