本文主要包含：
橋西網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián),橋西網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為橋西1000多家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)公司要多少錢，請找那個售后服務(wù)好的橋西做網(wǎng)站的公司定做！
卡頓產(chǎn)生的主要原因是又CPU、GPU引起的。
CPU(中央處理器): 對象的創(chuàng)建和銷毀、對象屬性的調(diào)整、布局計算、文本的計算和排版、圖片的格式轉(zhuǎn)換和解碼、圖像的繪制(Core Graphics)
GPU(圖形處理器)：紋理的渲染
在OpenGL中，GPU有兩種渲染方式
app中主要的耗電來源于： CPU處理、網(wǎng)絡(luò)、定位、圖像處理
優(yōu)化方案：
入門級（建議）
1. 用ARC管理內(nèi)存
2. 在正確的地方使用reuseIdentifier
3. 盡可能使Views透明
4. 避免龐大的XIB
5. 不要block主線程
6. 在Image Views中調(diào)整圖片大小
7. 選擇正確的Collection
8. 打開gzip壓縮
中級（這些是你可能在一些相對復(fù)雜情況下可能用到的）
9. 重用和延遲加載Views
10. Cache, Cache, 還是Cache！
11. 權(quán)衡渲染方法
12. 處理內(nèi)存警告
13. 重用大開銷的對象
14. 使用Sprite Sheets
15. 避免反復(fù)處理數(shù)據(jù)
16. 選擇正確的數(shù)據(jù)格式
17. 正確地設(shè)定Background Images
18. 減少使用Web特性
19. 設(shè)定Shadow Path
20. 優(yōu)化你的Table View
21. 選擇正確的數(shù)據(jù)存儲選項
進(jìn)階級（這些建議只應(yīng)該在你確信他們可以解決問題和得心應(yīng)手的情況下采用）
22. 加速啟動時間
23. 使用Autorelease Pool
24. 選擇是否緩存圖片
25. 盡量避免日期格式轉(zhuǎn)換
一、優(yōu)先級別不同：iOS最先響應(yīng)屏幕
當(dāng)我們使用iOS或者是Android手機時，第一步就是滑屏解鎖找到相應(yīng)程序點擊進(jìn)入。而這個時候往往是所有操控開始的第一步驟，iOS系統(tǒng)產(chǎn)品就表現(xiàn)出來了流暢的一面，但Android產(chǎn)品卻給人一種卡頓的現(xiàn)象，更別說后續(xù)深入玩游戲或者進(jìn)行其它操控了。這是為什么？
其實這與兩個系統(tǒng)的優(yōu)先級有關(guān)，iOS對屏幕反應(yīng)的優(yōu)先級是最高的，它的響應(yīng)順序依次為Touch--Media--Service--Core架構(gòu)，換句話說當(dāng)用戶只要觸摸接觸了屏幕之后，系統(tǒng)就會最優(yōu)先去處理屏幕顯示也就是Touch這個層級，然后才是媒體（Media），服務(wù)（Service）以及Core架構(gòu)。而Android系統(tǒng)的優(yōu)先級響應(yīng)層級則是Application--Framework--Library--Kernal架構(gòu)，和顯示相關(guān)的圖形圖像處理這一部分屬于Library，你可以看到到第三位才是它，當(dāng)你觸摸屏幕之后Android系統(tǒng)首先會激活應(yīng)用，框架然后才是屏幕最后是核心架構(gòu)。
優(yōu)先級的不同導(dǎo)致了iOS產(chǎn)品以及Android手機在操控過程中的表現(xiàn)差異，當(dāng)你滑動屏幕進(jìn)行操控的時候，iOS系統(tǒng)會優(yōu)先處理Touch層級，而Android系統(tǒng)則是第三個才響應(yīng)Library層級，這是造成它們流暢度不同的因素之一。
二、硬件工作配置不同：iOS基于GPU加速
目前智能手機硬件裝備競賽當(dāng)中，其實處理器等配置已經(jīng)達(dá)到了一個瓶頸期，各大旗艦產(chǎn)品在硬件比拼當(dāng)中基本上沒有太大的區(qū)別，而這時候GPU就成為了一個凸顯差異的重要因素。一些大型軟件像是3D游戲?qū)PU性能要求都會比較高，蘋果iPhone產(chǎn)品采用的Power VR SGX系列GPU在當(dāng)下來說非常的主流，跑分測試數(shù)據(jù)證明了它并不會比一些旗艦級別的Android產(chǎn)品差勁。
而iOS系統(tǒng)對圖形的各種特效處理基本上正好都是基于GPU硬件進(jìn)行加速的，它可以不用完全借助CPU或者程序本身，而是通過GPU進(jìn)行渲染以達(dá)到更流暢的操控表現(xiàn)。但是Android系統(tǒng)產(chǎn)品則并非如此，因為Android需要適應(yīng)不同的手機硬件，需要滿足各種差異配置，所以很多圖形特效大多都要靠程序本身進(jìn)行加速和渲染，并嚴(yán)重依賴CPU運算的操作自然會加大處理器的負(fù)荷，從而出現(xiàn)卡頓的問題。雖然Android 4.0以及4.1等更高版本中進(jìn)行了改進(jìn)將硬件加速設(shè)為默認(rèn)開啟，但依舊無法做到所有特效全部都靠GPU進(jìn)行加速。在很多Android手機里面都自帶有“是否開啟GPU渲染”這個功能選項，不過開啟之后的改善也是微乎其微。
屏幕最先響應(yīng)的優(yōu)先級關(guān)系，再加上iSO本身GPU加速程序的特性，使得大家在操控過程中感覺iOS手機擁有著不錯的流暢性。因為它本身的整個流程都是在為最大化的流暢做服務(wù)，不管是第一印象的滑動接觸屏幕，還是你進(jìn)一步使用程序之后的更深層操作都是如此。而GPU加速這點特性，應(yīng)該是它優(yōu)于Android系統(tǒng)流暢性的又一個因素。
三、開發(fā)機制不同：安卓機制效率低
Android的編程語言是JAVA，而iOS的則為Objective-C，不過要是說Android系統(tǒng)之所以有些卡頓是因為JAVA開發(fā)語言的關(guān)系，或者是拿它和Objective-C對比肯定會有人提出質(zhì)疑。Objective-C的優(yōu)勢是效率高但比較“唯一”，而JAVA的優(yōu)勢則是跨平臺不過運行效率相對偏低，其實這兩個編程語言所帶來的機制不同，就已經(jīng)造成了各自系統(tǒng)之間的流暢性差異化。
iOS的Objective-C，編譯器gcc，而這個gcc編譯出來的代碼又被蘋果專為iOS架構(gòu)優(yōu)化到了極致，運行過程中也不需要虛擬機在中間插手，執(zhí)行效率自然很高。這一段話應(yīng)該是iOS系統(tǒng)本身運行程序的執(zhí)行過程，而Android是通過JAVA虛擬機來執(zhí)行，并且系統(tǒng)需要占用大量內(nèi)存來換取執(zhí)行速度，再加上不定期的內(nèi)存自動回收機制，從而直接導(dǎo)致了卡頓現(xiàn)象的出現(xiàn)。
Android的JAVA編程本身運行效率比Objective-C低一些，而且再加上內(nèi)存自動回收的機制，所以造成了一些卡頓不流暢的現(xiàn)象出現(xiàn)。但根據(jù)技術(shù)人員講解，現(xiàn)代的JAVA虛擬機效率已經(jīng)不再是最大的瓶頸，Android 4.0系統(tǒng)版本之后的卡頓現(xiàn)象明顯得到了改善，所以這也是有用戶并沒有發(fā)現(xiàn)自己新買的Android手機出現(xiàn)太多卡頓現(xiàn)象的原因。看來編程語言和機制已經(jīng)被Android進(jìn)行了改善，這同樣也不是造成它與iOS流暢性偏差的唯一因素，不過影響卻是實實在在存在著。
三、系統(tǒng)設(shè)計不同：安卓APP無法統(tǒng)一
因為iOS產(chǎn)品的封閉性，所以所有的APP運行對象都比較單一，因為每個應(yīng)用程序都是被運行在iPhone，iPad等iOS產(chǎn)品當(dāng)中，它們有著很高的硬件利用效率。因為iOS系統(tǒng)的配件供應(yīng)商只有那么幾家，CPU也是一年換一次，這點不像Android終端年年變月月變，開發(fā)者很難遇見未來終端分辨率會包含多少種，GPU驅(qū)動會包含哪些等等，所以相對來說Android應(yīng)用開發(fā)成本較高且收益較慢。而iOS應(yīng)用開發(fā)則因為軟硬件垂直整合而受益，這樣一來蘋果自然就保證了應(yīng)用本身其與硬件產(chǎn)品之間的完美結(jié)合程度。
其實Android和iOS兩大系統(tǒng)APP開發(fā)情況的不同，也正是它們開發(fā)和不開放的特性所造成的。如果要是拿旗艦Android手機加上一個專為這款旗艦產(chǎn)品設(shè)計的游戲，來和蘋果iPhone運行對比的話，你真的不會遇到Android旗艦機出現(xiàn)卡頓延遲的問題，為什么因為這款游戲針對這款手機設(shè)計，在軟硬等方面都達(dá)到了最大化的兼容和優(yōu)化，自然就不會出現(xiàn)停滯的現(xiàn)象。
而Android系統(tǒng)程序要被安裝在各種符合要求的手機上面，開發(fā)者也不可能針對所有的機器型號進(jìn)行開發(fā)，只能在比較主流的機器上進(jìn)行測試并保證運行效果，所以他們?yōu)榱思骖櫿麄€產(chǎn)品線只能不得不降低游戲體驗以達(dá)到高中低產(chǎn)品可以共用的效果。最后那些占據(jù)了Android終端份額的大量大眾用戶們由于自己的手機不是旗艦產(chǎn)品而得不到流暢的使用體驗，自然而然就會產(chǎn)生Android產(chǎn)品不如iOS流暢的抱怨。
不管是iOS產(chǎn)品感覺比Android流暢還是真的比它流暢，其實說到底原因很簡單。蘋果會花費一年甚至兩年的時間去開發(fā)一個桌面icon，一種字體，并去測試屏幕點位，而Android終端中除了Nexus系列之外似乎沒有太多產(chǎn)品可以做到用這么長的時間去做這么細(xì)致的事情。有網(wǎng)友說得好，Android做的更多的是“讓系統(tǒng)跑起來”，而iOS擁有著蘋果做的更多的則是“讓系統(tǒng)以最高的效率跑起來”，或許這就是iOS產(chǎn)品比Android更流暢的原因吧。但更好的一面的是，隨著谷歌對Android的持續(xù)升級以及各廠商對自家產(chǎn)品的循序改進(jìn)，使得越來越多的Android終端正在擺脫卡頓不流暢的束縛，未來安卓用戶的期待同樣有望得到更好的滿足。
在我們 iOS 開發(fā)的過程中，會遇到 APP 不流暢的情況。在 屏幕圖像顯示的那些事兒中 , 講述了屏幕渲染的流程，當(dāng) GPU 或者 CPU 沒有在屏幕每一次刷新時完成內(nèi)容的提交，而造成渲染流水線耗時過長，就會導(dǎo)致重復(fù)渲染同一幀數(shù)據(jù)造成 圖像掉幀 ，也就是所謂的”卡頓“。
為了保持流程的UI交互，App的刷新拼搏應(yīng)該保持在 60fps 左右，其原因是因為 iOS 設(shè)備默認(rèn)的刷新頻率是60次/秒，而1次刷新（即 VSync 信號發(fā)出）的間隔是 ，所以如果在 16.67ms 內(nèi)沒有準(zhǔn)備好下一幀數(shù)據(jù)，就會產(chǎn)生”卡頓"。 可以在程序中用 CADisplayLink 來測量幀率），然后在屏幕上顯示出來，但應(yīng)用內(nèi)的 FPS 顯示并不能夠完全真實測量出性能，因為它僅僅測出應(yīng)用內(nèi)的幀率。
通過子線程監(jiān)測主線程的 RunLoop ，判斷兩個狀態(tài)（ kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting ）之間的耗時是否達(dá)到一定閾值
UIKit 的單線程天性意味著 UI 要在主線程上更新，這意味著繪制會打斷用戶交互，甚至讓整個 App 看起來處于無響應(yīng)狀態(tài)。但是如果能避免用戶等待繪制完成就好多了。 針對這個問題，有一些方法可以用到：例如 異步渲染 ， Core Animation 提供了 drawsAsynchronously 屬性。
drawsAsynchronously 屬性對傳入 -drawLayer:inContext:的CGContext 進(jìn)行改動，允許 CGContext 延緩繪制命令的執(zhí)行以至于不阻塞用戶交互。它自己的 -drawLayer:inContext: 方法只會在主線程調(diào)用，但是 CGContext 并不等待每個繪制命令的結(jié)束。相反地，它會將命令加入隊列，當(dāng)方法返回時，在后臺線程逐個執(zhí)行真正的繪制。 根據(jù)蘋果的說法。這個特性在需要頻繁重繪的視圖上效果最好（比如我們的繪圖應(yīng)用，或者諸如 UITableViewCell 之類的），對那些只繪制一次或很少重繪的圖層內(nèi)容來說沒什么太大的幫助。
iOS性能優(yōu)化的一個重要方面是視圖渲染，在渲染的過程中避免出現(xiàn)圖層混合，離屏渲染等問題，從而減少CPU和GPU的性能開銷，達(dá)到性能優(yōu)化的目的。
我們在開發(fā)調(diào)試過程中，可通過Xcode中的視圖調(diào)試選項來幫助我們快速查找出渲染過程中的問題。
真機調(diào)試運行App項目，在Xcode的工具欄中選擇，Debug - View Debugging - Rendering，其中有9個選項。
若使用的是模擬器，在Simulator工具欄的Debug選欄中也有視圖調(diào)試的選項。
調(diào)試這幾個選項，我們來具體看看，針對視圖渲染有哪些具體問題需要優(yōu)化。
在多個UI視圖疊加的情況下，如果有透明或者半透明的控件，那么GPU會根據(jù)透明度去計算這些layer疊加在一起最終的顯示的顏色。舉例，如果頂層VeiwA顏色是紅色RGB(255,0,0)，透明度是40%，底層ViewB顏色是綠色RGB(0,255,0)，那么最終疊加顯示出來顏色是RGB(102,153,0)。
計算公式
這個渲染過程會消耗GPU性能，因此要避免出現(xiàn)圖層混合。
順便提一下：UIView的opaque屬性默認(rèn)為Yes。
opaque這個屬性不是決定視圖是否透明，而是決定在視圖渲染過程的處理方式。視圖是否透明跟 alpha 和 hidden 有直接關(guān)系。
如果視圖不透明，就設(shè)置opaque為Yes，表示圖形系統(tǒng)會將視圖視為完全不透明，完全不透明視圖應(yīng)該使用完全不透明的內(nèi)容來填充，該內(nèi)容的alpha值應(yīng)該為1.0（自身的alpha和填充顏色的alpha都應(yīng)該為1.0），這樣圖形系統(tǒng)將不考慮它與其他視圖的混合顏色計算，從而提高性能。若設(shè)置為NO，圖形系統(tǒng)通常會將視圖與其他內(nèi)容合成，消耗性能。如果View是在scrollView中或者在動畫中，對性能的提升更為明顯。
有些View的子類使用drawRect:方法繪制自己的內(nèi)容，那么opaque屬性對其無效。
這個選項用來檢測是否正確使用layer的shouldRasterize屬性，該屬性默認(rèn)是NO，若 shouldRasterize為YES則開啟光柵化。光柵化是將layer預(yù)先渲染成位圖(bitmap)，然后緩存起來，緩存未被復(fù)用則標(biāo)注為紅色，緩存被復(fù)用會標(biāo)注為綠色，紅色越多，性能越差。使用光柵化的視圖清晰度會降低。
蘋果的GPU只解析32bit的顏色格式，32bit的顏色格式由RGBA(紅、綠、藍(lán)、透明度)四個顏色通道組成，每一個顏色通道都占據(jù)8bit，取值范圍是[0, 255]。
如果某圖片是GPU 不支持的顏色格式，那么圖片需要被復(fù)制到CPU進(jìn)行顏色格式轉(zhuǎn)換，這樣的圖片會被標(biāo)注為藍(lán)色。藍(lán)色越多，性能越差。
這個選項用來解析圖層的顏色格式，具體用途暫不清楚。
打開這個選項后，UILabel都會被標(biāo)注，標(biāo)注為銀白色或橙色，UIImageView的圖片內(nèi)容有部分透明時標(biāo)注為紫羅蘭色，全不透明時標(biāo)注為橙色；有趣的是，xib中調(diào)整UILabel的textColor，當(dāng)RGB三個顏色通道的色值一致時（如000000、999999、FFFFFF等），UILabel會被標(biāo)注為銀白色，當(dāng)RGB三個顏色通道的色值不一樣時（如999897等），UILabel會被標(biāo)注為橙色。
這個選項用來調(diào)整顏色刷新頻率。通常情況是以每10毫秒一次的頻率更新圖層調(diào)試顏色，選中這個選項則設(shè)置每幀畫面都會刷新，沒有了10毫秒的延遲。在需要加快顏色刷新頻率的場景下使用，通常情況下用不到。
這個選項用來檢測圖片在展示時是否被放大或縮小，以及像素是否對齊。如果image.size和imageView.size不匹配（例如，image的實際大小是50×50，imageView的尺寸大小25×25，或者為200×200），圖片在展示時會縮放或者放大圖片，會消耗資源，imageView會被標(biāo)注為黃色，黃色越多，性能越差。避免出現(xiàn)黃色標(biāo)注，將imageView.size設(shè)置成與image.size一樣的。
這個選項用來檢測是會把那些離屏渲染的圖層顯示為黃色。黃色越多，性能越差。
屏幕渲染有 當(dāng)前屏幕渲染 和 離屏渲染 兩種方式。
常見的會引起離屏渲染的操作：
這個選項用來檢測是否是直接使用 OpenGL 繪制的， 使用 OpenGL 繪制的圖層會標(biāo)注為藍(lán)色。藍(lán)色越多，性能越好。如果僅僅使用 UIKitAPI，那么不會有任何效果。
這個選項用來檢測是否出現(xiàn)重新繪制，進(jìn)行了重繪的區(qū)域會標(biāo)注成黃色，使用Core Graphics重新繪制會消耗性能，因此重繪區(qū)域越小越少，性能越好。
重慶分公司
重慶分公司
