什么是優(yōu)化
首先我們先破題，來談談“優(yōu)化”這個事情。通常情況下，我們說到優(yōu)化的時候，往往會伴隨著對之前系統(tǒng)的吐槽。或是不好用，或是性能低，或是用起來很麻煩。巴拉巴拉。是的，當我們對原先的系統(tǒng)有槽點的時候，我們會談到“優(yōu)化”。而“優(yōu)化”的前提也是，之前已經(jīng)有過一個東西存在，而且真對目前的場景應景不再適合。這個是有需要對原有系統(tǒng)進行調(diào)整，以滿足當前的場景與需求。那么所謂優(yōu)化即是：對原有系統(tǒng)進行有目的的改造。
好吧，這聽起來雖然說了什么，但其實什么都沒說。因為這是一句大實話。
but，我們仔細分析一下，我們要進行優(yōu)化必須能夠：
對原有系統(tǒng)的問題有所了解
了解目前場景和需求
有目的性的改造原有系統(tǒng)
我們來說一個我們通常會遇到的例子，也是在面試的時候會遇到的問題–“UItableView的性能優(yōu)化”。其實每次有人問我這個問題，我內(nèi)心都有千萬只“草泥馬”奔騰而過。沒有具體的問題場景，只單單跑出來這樣一個問題。是可以和他扯什么圖片內(nèi)存緩存了，避免圓角的使用了，預渲染，預加載了之類的東西。但是這些東西，真的對于在解決他們TableView卡頓的問題有效嗎，不見得。套用《安娜卡列尼娜》一句話：
流暢的UItableView都是相似的，不流暢的UItableView各有各的不幸。
好了，吐槽到此為止。吐槽的目的是為了說明一點，你要進行優(yōu)化，必須有一個特定的場景。在一個受限的范圍內(nèi)進行優(yōu)化，因為這樣目的是可控的。漫無邊際的優(yōu)化，和別人基于方法論的建議之類的東西，不一定對當前的問題有幫助。
比如，之前我們在做的一個社交類的App中，首頁使用了UItableView，老板說怎么用著這么卡頓。然后我們就開始了“優(yōu)化”。
首先，我們知道我們要優(yōu)化的是第一個tab的tableview的滑動效率的問題。那總得有個監(jiān)控的指標吧。對于程序猿來說，感覺這個不卡了，或者感覺這個卡，這個東西太模糊了。無法衡量啊。所以一定要量化。對于界面來講就是大家常說的FPS，每秒幀率。于是我們測量了一下幀率，平均下來是25FPS。ou my god！的確是有點卡。
然后我們知道對于ios來說如果能達到60FPS，那界面絕對不會有卡頓的感覺了。而很少有應用能達到這個水準。那么我們給自己設置了一個目標45FPS。btw,這個目標只是個階段性目標。
好了下面的過程，就是朝著這個目標前進了。當然我們知道，造成FPS較低的原因，一般都是主線程做了太多的事情，導致幀率降低。這只是個大方向。而對我們來講，我們需要精準的知道，主線程都做了些什么事情，導致幀率降低。
首先，我們發(fā)現(xiàn)的是，讀取圖片IO的過程發(fā)生在了主線程。IO過程一般是比較耗時的，于是我們像把該過程移到了后臺線程中處理。發(fā)現(xiàn)幀率能夠提高到33FPS，這還不夠啊。革命尚未完成，同志仍需努力。
之后的過程中，我們把布局預處理，還有圓角，數(shù)據(jù)預加載之類的事情做上去之后，終于基本達到45。階段性目標完成。
好了這是一個優(yōu)化的例子：始于發(fā)現(xiàn)問題，止于目標達成。而重要的是其過程，描述問題?。。?！
分析問題 (定性or定量)
其實，我一直比較堅信一句話：當你能夠準確的描述一個問題的時候，你到解決問題就沒剩幾步了。比如剛才說的卡頓的問題，我們當時是這么描述的：圖片讀取發(fā)生了主線程，主線程中有一部分CPU片段用于文件讀取和圖片解碼，造成主線程阻塞，從而導致幀率下降。當描述到這里的時候，解決方案就比較顯而易見了，挪唄。搞到其他線程中之行。把主線程空出來。
而上面的這個描述還只是一個定性的描述分析。只是闡述了現(xiàn)象。雖然能夠解決了一個問題，但是對整體問題的貢獻有多大，也未可知。所以我們可以當時完全可以這樣描述：我們圖片緩存在文件系統(tǒng)的平均大小是1MB，其讀取時間為10.7ms，圖片格式為jpeg，解碼一個1M的圖片耗時是60ms，而我們知道60FPS，每幀給主線程用來處理任務的CPU時間為17.7S，也就說這個地方占用了大量CPU時間片來處理圖片讀與解碼操作，從而造成了CPU阻塞，造成幀率沒有達到60ms。
當我們使用定量的描述的時候，我們能夠比較精確的知道，一個小問題，對于大問題來說到底意味著什么。而定量分析的方案中，當然包含了很多更多的細節(jié)信息，尤其是數(shù)據(jù)信息。這些也正是定量分析的優(yōu)勢所在。BUT，定量分析是一個非常耗時耗力的事情，你要拿到這么多的數(shù)據(jù)，你勢必要付出很多時間，在采集這些數(shù)據(jù)上面。對于app開發(fā)來講，除非公司給了足夠的資源（尤其是時間），你才能像個研究者一樣去采集這些數(shù)據(jù)，一般情況是，大概都會止步到定性分析這一步。其實這也是看具體問題而定了。
不過無論你是使用定性分析的方式還是定量分析的方式。我們的目標是為了找到能夠準確表述問題的方式，并且定位問題，以求找到解決方案。而為了達到這個目的一般情況下我們可以使用兩種方式：
你的編程功底和對iOS的了解程度都很深，那么完全可以從一些原理性的事情上去分析。我們稱之為：邏輯分析法。
或許你的編程功底很深，或許很淺，或許你嘗試分析而沒有結(jié)果。那么可以使用改改代碼試試的方法了。我們稱之為：實驗法。
邏輯分析法， 原理性分析
哈哈，套用馬哲的一句話：事物是普遍聯(lián)系的。既然是普遍聯(lián)系的，不說必然存在因果，那么通過一定的邏輯分析。是可以找到他們之間的一些蛛絲馬跡的關聯(lián)的。這些關聯(lián)或許可以解釋一些什么。比如剛才卡頓的問題：原理就是主線程CPU被消耗過多，無法及時處理UI任務導致的。這只是一個例子。
我們進行邏輯分析的目的，是為了找到我們的某些代碼和問題之間的因果性聯(lián)系。就是說，我們能夠明確知道造成UI卡頓的問題，就是因為IO的問題之類。這個話題說起來，比較深邃了。其中絕大部分實踐的方法可以從《數(shù)理邏輯》這本書中找到。不過這是本講數(shù)學的書，咱們得稍微換下腦子，把其中的定理，在編程中應用一下。因為我也只是意會了其中的某些東西，講出來還沒有那么功底。就只能麻煩各位自己去琢磨了。：）
實驗法,Assume-Action-Response-Test-Assume
我稱這個過稱為AARTA。這是一個一直往復的過程，在分析的過程中，你得一次次的重復這個過程來找到真正問題的所在。其實，這個方法比較常應用在改BUG這個場景上。其實如果從廣義上講，按照上面咱們對技術優(yōu)化的定義，改bug也算是一種優(yōu)化。只不過這個場景比價特殊而已。當無法準確的分析原理，或者當前程序的復雜性過高（低內(nèi)聚高耦合）已經(jīng)超出人腦的計算能力范圍的時候，那么就可以“猜”了。
（1）假設 assume
根據(jù)以往的經(jīng)驗來，設定一個和問題域相關的假設。比如UI卡頓的問題，你懷疑是不是因為圖片的問題呢。那么現(xiàn)在就假設是圖片的問題！
（2） 嘗試進行修改 action
既然假設是圖片的問題，那么就把UIImageView從Cell上刪掉吧。
（3）看程序的反饋 Response
重新運行一遍程序，看一下程序運行的效果。FPS是否有所改善，而且改善的幅度有多大。
（4）Test
根據(jù)，程序的反饋和我們預先設定的目標來判斷一下，當前改動是否滿足了我們設計的目標。如果有，那么你大概就找到了問題的一個原因。如果沒有那么進行下一步。
（5） 重新提出假設 Assume
既然不是圖片的問題，那么會不會是其他事情上耗費了CPU呢。比如布局樣式的計算。那么重新假設是局部樣式的問題。在執(zhí)行（2）過程。
所謂實驗，即是大膽假設，小心取證，如此往復，以求終解。
監(jiān)控
上面只是進行了一些方法論的探討。但是有一件事情，是若要優(yōu)化一定要做的。那就是“監(jiān)控”。
監(jiān)控是個非常重要的東西。
監(jiān)控是個非常重要的東西。
監(jiān)控是個非常重要的東西。
重要的事情說三遍。尤其是對于運行在生產(chǎn)環(huán)境的程序。這就像是一個體檢，你得實時掌控程序的運行情況，知道問題出在了哪里，甚至有些時候知道：哎呀，出問題了。沒有監(jiān)控，程序一旦上線之后，就像脫韁的野馬，跑到哪里，做了什么，你就是一頭忙然了。突然有一天，老板說有人反饋咱們的app經(jīng)常崩潰，當你沒有crash監(jiān)控，這個你都不知道從哪里查起。
而且，監(jiān)控也是優(yōu)化的數(shù)據(jù)來源。他能夠通過數(shù)據(jù)的指標來非常直觀的告訴你，程序哪里有問題，你優(yōu)化之后，效果是怎樣的?，F(xiàn)在網(wǎng)上有很多這方面的服務提供出來，比如bugly之類的，甚至有些是APM（application performance manager)，直接監(jiān)控到程序的運行狀態(tài)和性能。google一下，能搜出不少來。可以酌情，應用在自己開發(fā)的app中。
總結(jié)
說了半天，總結(jié)一下。優(yōu)化是在可控的范圍內(nèi)有目的性的對現(xiàn)有程序的修改。一般可以使用邏輯分析法和實驗法來定位、分析、描述問題。或者定性或者定量。無論哪種，要想優(yōu)化，你得先建立起對自己app運行的監(jiān)控體系。
