如何編寫穩定流暢的iOS移動端應用

原文連接：http://www.jianshu.com/p/f4adce56166f

不忘初心

在過去幾年間，移動應用以雷霆之勢席捲全球。咱們在工做和休閒時間中使用互聯網的方式，已經隨着移動應用的前進腳步發生了變革。在開發應用的時候，人們也開始考慮「移動優先」的作法。咱們正在面對全新一代的移動設備，諸如可穿戴設備或衆多移動配件——正是它們構成了「萬物互聯」的世界。咱們將面對全新的用戶界面，經過它們數據展現及指令接收處理。同時，咱們還將看到，愈來愈多的公司將真正地踐行「移動優先」的思路。而在將來數年中，這一切都將影響咱們設計、開發和測試軟件的方式。

把一個客戶端作得穩定、無奔潰、流暢，是寫客戶端朋友的夢想，可是，咱們面臨的結果每每是不如人意的。天下武功，惟快不破。不少公司都信奉這個教條。巴不得把app開發週期壓縮到最低,這就致使了開發中隱藏了不少問題。有點經驗的工程師草率的優化一下,更糟的狀況是那些沒有經驗的工程師甚至不會對app進行任何優化，這將會使狀況變的更糟。

十年前,移動設備的硬件資源是很是有限的.甚至連浮點數都是被禁止的.由於浮點數能致使計算的速度變慢。科技發展如此迅速的今天,硬件很大程度上能夠彌補軟件的短板。可是硬件的進步終究沒法掩飾軟件的不足，這也是寫這篇文章的初心。

移動端關注要點

在程序開發中，測試是必不可少的。移動端測試按大的類型劃分能夠分爲白盒測試和黑盒測試。

白盒測試通常是由開發人員使用編碼的方式進行。測試者須要接觸程序的內部代碼；而黑盒測試能夠在不知道程序內部結構和代碼的狀況下進行。

下面是主要的測試流程了：
冒煙測試：在軟件測試中，冒煙測試是指快速驗證APP的主要功能（例如：微信的登錄、退出、發消息等功能） 。若是沒有發現問題，再進行更加深刻的測試工做；若是發現有問題，就說明APP有重大缺陷。

功能測試：功能測試也叫行爲測試，須要根據測試用例來驗證應用預期的功能有沒有實現。

自由探索式測試：嘗試邊界條件、輸入特殊符號、異常網絡環境、忽然中斷程序等操做 。功能測試的目的是驗證正常的功能有沒有實現，而自由探索測試的目的就是爲了試試應用在極端的操做下會不會出現問題。探索式測試就是要找到能讓應用出錯的操做。

迴歸測試：對以前使用咱們的服務測試過的應用，將案例複測一遍。

移動端關注的一些指標
運行多少小時不崩潰；
屢次打開頁面，控制崩潰率；
界面優化，如何才能讓用戶不急躁、不煩躁；
服務器沒有返回數據，是否會致使奔潰；
網絡很差，數據來的太慢，界面是否不流暢；
從數據庫讀的數據太慢如何解決等。

移動端界面應該有本身的邏輯，須要網絡數據的地方，應該有默認值，這樣在網絡數據沒有返回的狀況下，讓用戶有數據能夠看到。收到的網絡數據應該是經過某種方式刷新到界面，而不是等到數據返回才刷新頁面。當沒有網絡數據的時候，界面應該能夠自成一體，走的通流程，不強依賴網絡數據。

在弱網模式下調試是咱們必備的功力，由於咱們要考慮用戶的實施環境一般都不會很好。把常用的數據，存到緩存，提升APP的運行效率、界面流程度。同時，咱們須要具有收集奔潰日誌的功能，這樣才能更好的減小崩潰，提升用戶體驗。

界面卡頓產生的緣由和解決方案

iOS界面處理是在主線程下進行的，系統圖形服務經過 CADisplayLink 等機制通知 App，App 主線程開始在 CPU 中計算顯示內容，好比視圖的建立、佈局計算、圖片解碼、文本繪製等。隨後 CPU 會將計算好的內容提交到 GPU 去，由 GPU 進行變換、合成、渲染。隨後 GPU 會把渲染結果提交到幀緩衝區去，等待下一次刷新信號到來時顯示到屏幕上。顯示器一般以固定頻率進行刷新，若是在一個刷新時間內，CPU 或者 GPU 沒有完成內容提交，則那一幀就會被丟棄，等待下一次機會再顯示，而這時顯示屏會保留以前的內容不變。這就是界面卡頓的緣由。CPU 和 GPU 不論哪一個阻礙了顯示流程，都會形成掉幀現象。

CPU 形成的資源消耗有如下幾種：

• 對象建立
• 對象調整
• 對象銷燬
• 佈局計算
• Autolayout
• 文本計算
• 文本渲染
• 圖片的繪製和解碼

GPU 資源消耗有下面幾種狀況：

• 紋理的渲染
• 視圖的混合 (Composing)
• 圖形的生成等

具體能夠參考這篇文章

用 Instruments 來檢驗你的app

時間事件查看器-Time Profiler
在xcode的菜單中選擇 product->Profile
咱們會看到下面的界面：

Instruments

點擊Time Profiler進入。

Time Profiler

下面咱們來深究以下的控制面板：

控制面板

如下介紹下配置選項：

1. Separate by Thread: 每一個線程應該分開考慮。只有這樣你才能揪出那些大量佔用CPU的"重"線程。
2. Invert Call Tree: 從上倒下跟蹤堆棧,這意味着你看到的表中的方法,將已從第0幀開始取樣,這一般你是想要的,只有這樣你才能看到CPU中話費時間最深的方法.也就是說FuncA{FunB{FunC}} 勾選此項後堆棧以C->B-A 把調用層級最深的C顯示在最外面。
3. Hide System Libraries: 勾選此項你會顯示你app的代碼,這是很是有用的. 由於一般你只關心cpu花在本身代碼上的時間不是系統上的。
4. Flatten Recursion: 遞歸函數, 每一個堆棧跟蹤一個條目。
5. Top Functions: 一個函數花費的時間直接在該函數中的總和，以及在函數調用該函數所花費的時間的總時間。所以，若是函數A調用B，那麼A的時間報告在A花費的時間加上B.花費的時間,這很是真有用，由於它可讓你每次下到調用堆棧時挑最大的時間數字，歸零在你最耗時的方法。

找到Detail面板裏最耗時的進程，點擊進去能夠看到代碼，觀察是否有異，如此即可逐步優化應用的運行效果了。

修改

修改好後,在儀器從新運行該應用程序Product—Profile（或⌘I-記住，這些快捷鍵真的會爲您節省一些時間）。
分配工具

分配工具

點擊進入

這個時候你會發現兩個曲目。一個叫(分配)Allocations，以及一個被稱爲VM Tracker(虛擬機跟蹤)。

內存泄漏有兩種泄漏。第一個是真正的內存泄漏，一個對象還沒有被釋放，可是再也不被引用的了。所以，存儲器不能被從新使用。第二類泄漏是比較麻煩一些。這就是所謂的「無界內存增加」。這發生在內存繼續分配，並永遠不會有機會被釋放。若是永遠這樣下去你的程序佔用的內存會無限大,當超過必定內存的話 會被系統的看門狗給kill掉。

內存警告是ios處理app最好的方式，尤爲是在內存愈來愈吃緊的時候,你須要清除一些內存。內存一直增加其實也不必定是你的代碼出了問題,也有多是UIKit 系統框架自己致使的。

嘗試

本身動手觀察下，一切天然明瞭。

內存泄露
這一類泄漏是前面提到的 - 當一個對象再也不被引用時出現的那種,檢測泄漏能夠理解爲一個很複雜的事情，但泄漏的工具記得已分配的全部對象，經過按期掃描每一個對象以肯定是否有任何不能從任何其餘對象訪問的。

關閉儀器，回到Xcode和選擇Product->Profile

內存泄露

點擊進入，運行：

運行

本身動手嘗試下，找到右邊面板裏，若是有黑色標識的方法，進入看看。學習就是多嘗試。

篇幅有限，更多的內容咱們下次再聊。