iOS 2019 最新面試題集錦

一、 js 與 原生OC交互方式:

       1.JS發起一個假請求,然後用UIwebView的代理方法攔截這起請求,再做相應的處理

       2.在iOS 7 之後Apple添加了一個新的庫JavaScriptCore,用來做js交互。

       首先導入JavaScriptCore 庫,然後在OC 中獲取上下文對象。在定義好JS需要調用的方法。JSContext對象context[@”share”] 等於一個返回值爲空的block。這個block 在子線程中調用,因此執行UI 操作需要回到主線程

二、 OC調用JS

       1、webView stringByEvaluatingJavaScriptFromString:jsStr];

       2、繼續使用JavaScriptCore庫  JSContext 對象調用 evaluateScript:方法

       以上兩個方法都是同步方法,如果JS方法比較耗時會造成界面卡頓。

       所以可以使用wkwebview 的 evaluateJavaScript:代替

      

WKWebView優勢:

運行速度更快,佔用內存低,大概是UIwebView 的四分之一到三分之一

多進程,在APP的主進程之外執行;爲空webView爲多進程組件,他會從APP內存中分離內存到單獨的進程中。當內存超過了系統分配給爲空webView的內存時候,會導致爲空webView瀏覽器崩潰白屏,但是APP不會crash。(APP會收到系統通知,並且嘗試去重新加載頁面)

相反的UIwebView 和APP同一個進程,內存不夠用時就會crash ,從而導致APP crash

wkwebview 使用和手機Safari瀏覽器一樣的nitro JavaScript引擎,相比於UIwebView的javaScript 引擎有非常大的性能提升

wkwebview 是異步處理APP原生代碼與JavaScript之間的通信,因此普遍上執行速度會更快

消除了觸摸延遲

缺點:

不能截屏

不支持記錄webkit 的請求

APP退出會清湖HTML5的本地存儲數據

不支持accept cookies 的設置

需要iOS 9 或更高版本

 

三、線程

       線程安全

       1、互斥鎖     @synchronized(所對象){}

       atomic  原子屬性  爲setter方法加鎖   線程安全需要消耗大量的資源

       nonatomic  非原子屬性

       2、NSLock

3、遞歸鎖 NSRecursivelock

4、NSConditionLock條件鎖

5、GCD 信號量  dispatch_semaphore

6、自選鎖

1、@synchronized 的效率最低,不過它的確用起來最方便,所以如果沒什麼性能瓶頸的話,可以選擇使用 @synchronized。
2、當性能要求較高時候,可以使用 pthread_mutex 或者 dispath_semaphore,由於 OSSpinLock 不能很好的保證線程安全,而在只有在 iOS10 中才有 os_unfair_lock ,所以,前兩個是比較好的選擇。既可以保證速度,又可以保證線程安全。
3、對於 NSLock 及其子類,速度來說 NSLock < NSCondition < NSRecursiveLock < NSConditionLock 。

線程間通信:

兩個線程之間要想互相通信,可以使用:NSMachPort 

//1. 創建主線程的port    // 子線程通過此端口發送消息給主線程    NSPort *myPort = [NSMachPort port];

    //2. 設置port的代理回調對象    myPort.delegate = self;

    //3. 把port加入runloop,接收port消息    [[NSRunLoop currentRunLoop] addPort:myPort forMode:NSDefaultRunLoopMode];

    NSLog(@"---myport %@", myPort);

    //4. 啓動次線程,並傳入主線程的port    MyWorkerClass *work = [[MyWorkerClass alloc] init];

(void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg waitUntilDone:(BOOL)wait;

- (void)performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(id)arg waitUntilDone:(BOOL)wait;

進程間通信;

共享存儲系統消息傳遞系統管道:以文件系統爲基礎

URL scheme

Keychain

Uipasteboard

UIDocumentInteractionController

Local socket

Airdrop

UiactivityViewController

APPgroups

 

 

線程保活:

循環

runloop

1.獲取RunLoop只能使用 [NSRunLoop currentRunLoop] 或 [NSRunLoop mainRunLoop];

2.即使RunLoop開始運行,如果RunLoop 中的 modes 爲空,或者要執行的mode裏沒有item,那麼RunLoop會直接在當前loop中返回,並進入睡眠狀態。

3.自己創建的Thread中的任務是在kCFRunLoopDefaultMode這個mode中執行的。

4.在子線程創建好後,最好所有的任務都放在AutoreleasePool中。

如果不執行下列語句:

[runLoop addPort:[NSMachPort port] forMode:NSRunLoopCommonModes];

 

 

Runloop

就是運行循環。保持程序的持續運行、處理APP中的各種事件(手勢定時器等)

節省CPU資源提高程序的性能,在有任務的時候做任務 ,在沒任務的時候休息 空轉

runloop 和線程是一對一的

系統默認五個mode

NSDefaultRunloopMode

UITrackingRunloopMode  爲了保證滑動ScrollView滑動不受影響,在滑動的時候就主動切換到這個mode運行

UITInitializationRunLoopMode  在剛啓動APP的時候第一次進入的mode

GSEventReceive  接收系統內部事件

Common    包含default 和UItrackingMode  

應用:

1、延遲顯示UIimageView 用runloop   performSelector:withObject:afterDelay:inmodes:

2、NSTimer  需要加入mode

3、常駐線程  線程保活

4、在創建場主線程的時候加入 @autoreleasepool,在runloop睡眠的時候釋放

 

定時器:

  1. NSTimer 通過runloop來是實現,一般情況下較爲準確,但噹噹前循環耗時操作較多時會出現延時的問題。同事也受所加入的runloopmode 的影響,commonmode(包含default、UItracking)
  2. CADisplayLink是基於屏幕刷新的週期,所以其一般很準時,每秒60次。其本質也是通過runloop,所以存在和NSTimer相同的問題
  3. GCD定時器是dispatch_source_t類型的變量,其可以實現更加精準的定時效果。GCD定時器實際上是使用了dispatch源(dispatch source),dispatch源監聽系統內核對象並處理。通過系統級調用更加精準   (dispatch類似生產者消費者模式,通過監聽系統內核對象,在生產者生產數據後自動通知相應的dispatch隊列執行,後者充當消費者)。GCD通過dispatch_suspend()釋放定時器

 

ViewDidload 什麼時候調用:(界面初始話操作,加載數據等)在view創建完畢後,不管是通過xib、Storyboard還是loadview自定義view

  1. view被加載的時候
  2. view Controller 用代碼創建的時候
  3. view Controller通過nib解析的時候

在UIViewController 的初始化方法中訪問實例變量view,會導致延遲加載機制失效,會受到內存警告

當訪問UIViewController中的self.view時,如果view爲nil 就會調用loadview

 

 

iOS 程序在main 函數之前:

  1. 首先加載可執行文件
  2. 然後加載蘋果的動態鏈接器dyld,(dyld是一個專門用來加載動態鏈接庫的庫)
  3. 執行從dyld開始,dyld從可執行的文件開始,遞歸加載所有的依賴動態鏈接庫
  4. 動態鏈接庫包括:iOS中用到的所以系統的framework,加載OC runtime方法的libobjec,系統級別的libSystem
  5. 所有動態鏈接庫和我們APP的靜態庫.a和所有類文件編譯後的.o文件,最終都由dyld 加載到內存中

整個事件由蘋果的動態鏈接器主導,完成運行環境的初始化後,配合imageLoader將二進制文件按格式加載到內存。

 

OC 方法調用的過程原理:

OC中的所有方法調用,最終都是轉換成runtime中的一個C語言消息分發函數:objc_msgSend(消息接收者,方法名 ,參數。。。)

這條消息發送之後,系統會在receiver的類對象的方法了吧中找這個方法,如果沒找到,再到receiver的父類的方法列表中找,如此直到根類至找到爲止,如果還沒有找到會報出錯誤。(緩存:方法第一次被調用之後,方法會被存入一張緩存表,之後如果再被調用時就直接從緩存表中取出,以提高效率)。

Runtime中對調用過程做了緩存,在拋出錯誤之前會進行動態決議和消息轉發過程。

若對象無法響應某個選擇子,則進入消息轉發流程:

1、動態方法解析:+bool) resolveInstanceMethod:(SEL)selector

                           +(bool)resolvelassMethod:(SEL)selector

2、備用接受者:

  • (id)forwardingargetForSelector(SEL)slector  (把這條消息轉發給其他對象處理)
  1. 獲取方法簽名進行消息轉發

- (NSMethodSignature*)methodSignatureForSelector:

  1. 完整的消息轉發

- (void)forwardingInvocation(NSInvocation*)invocateion

 1、通過運行期的動態方法解析功能,我們可以在需要某個方法是在將其加入類中

2、對象可以把其無法解讀的某些消息轉交給其他對象來處理

3、經過上述兩步後,如果還是沒有辦法處理消息,那就啓動完整的消息轉發機制

 

 

OC類結構

OC類是objc_class結構體

它裏面有isa指針、指向父類的super_class 指針、類名、類的版本信息、該類的實例變量大小、類信息供運行期使用的一些標識符、類的成員變量鏈表、方法定義的鏈表、方法緩存、協議鏈表

 

 

UIView 和 CALayer

所有的view都是由一個底層的Layer來驅動。Layer側重於圖形的顯示,而view相當於layer的管理者。

UIView 繼承與UIResponder 而 CALayer 繼承於NSObject。所以UIView 可以響應事件,而CALayer 則不能。

每個UIView內部都有一個CALayer在背後提供內容的繪製和顯示。兩者都有樹狀層級結構,layer 內部有sublayers,view 內部有subviews

layer 內部維護着三份layer tree ,分別是動畫樹、模型樹、渲染樹,在iOS 做動畫的時候,我們修改動畫的屬性,在動畫的其實是動畫樹,而最終展示在界面上的其實是提供view的modelayer

 

設計模式

  1. 單例模式: 確保程序運行期某個類只有一個實例對象,用於資源共享控制
  2. 代理模式:一對一反向傳值。當一個類的某些功能需要別的類來實現,但是又不確定具體會是哪個類實現
  3. 觀察者模式:

通知:  notification通知中心,註冊通知中心,任何位置可以發送消息,註冊觀察者的對象可以接收。

KVO 鍵值對改變  通知觀察者

       4、工廠模式:工廠方式創建類的實例

5、MVC 模式 :model 、view 、control  模型、視圖、控制器對應用程序進行數據處理、業務邏輯和視圖展示解耦

6、MVVM模式: model、view、viewModel  將MVC中controller的業務邏輯提取到viewModel層,進行解耦合

設計模式:並不是一種新技術,而是一種編碼經驗。 mvc設計模式 :模型,視圖,控制器,可以將整個應用程序在思想上分成三大塊,對應是的數據的存儲或處理,前臺的顯示,業務邏輯的控制。  代理模式:代理模式給某一個對象提供一個代理對象,並由代理對象控制對源對象的引用單例模式:說白了就是一個類不通過alloc方式創建對象,而是用一個靜態方法返回這個類的對象。系統只需要擁有一個的全局對象,這樣有利於我們協調系統整體的行爲,比如想獲得[UIApplication sharedApplication];任何地方調用都可以得到 UIApplication的對象,這個對象是全局唯一的。  觀察者模式: 當一個物體發生變化時,會通知所有觀察這個物體的觀察者讓其做出反應。實現起來無非就是把所有觀察者的對象給這個物體,當這個物體的發生改變,就會調用遍歷所有觀察者的對象調用觀察者的方法從而達到通知觀察者的目的。  工廠模式:可以簡單概括爲同類型不同型號的產品有各自對應的工廠進行生產。

 

 

@autoreleasepool

  1. 是自動釋放池,讓我們更自由的管理內存
  2. 當我們手動創建了一個@autoreleasepool,裏面創建了很多臨時變量,當@autoreleasepool結束的時候,裏面的內存就回回收
  3. ARC 系統自動管理自己的autoreleasepool,runloop就開始iOS 中的消息循環機制,當一個runloop結束時系統纔會一次性清理掉唄autoreleasepool 處理過的對象,其實本質上說是在本次runloop迭代結束時清理掉本次迭代期間被放到autoreleasepool中的對象。至於何時runloop結束並沒有固定的duration。

 

會產生大量臨時變量的時候使用@autoreleasepool

循環中創建了很多的臨時對象,使用@autoreleasepool

你生成了一個輔助數據線程,使用 @autoreleasepool

長期在後臺運行的任務

 

 

 

Static

Static 修飾局部變量 ,只會初始化一次,並且在程序中只有一份內存,可以延長局部變量的生命週期,改變了知道整個項目結束時纔會被銷燬

Static修飾全局變量時,作用域僅限於當前文件

1).函數體內 static 變量的作用範圍爲該函數體,不同於 auto 變量,該變量的內存只被分配一次,因此其值在下次調用時仍維持上次的值; 2).在模塊內的 static 全局變量可以被模塊內所用函數訪問,但不能被模塊外其它函數訪問; 3).在模塊內的 static 函數只可被這一模塊內的其它函數調用,這個函數的使用範圍被限制在聲明它的模塊內; 4).在類中的 static 成員變量屬於整個類所擁有,對類的所有對象只有一份拷貝; 5).在類中的 static 成員函數屬於整個類所擁有,這個函數不接收 this 指針,因而只能訪問類的static 成員變量。

 

 

 

Http 請求方式:

  1. opions  返回服務器針對特定資源所支持的HTML請求方法 或 允許客戶端查看服務器性能
  2. get 向特定資源發出請求
  3. post 向指定資源提交數據(提交表單、上傳文件)
  4. put 向指定資源位置上上傳其最新內容
  5. head  與get請求類似,返回的響應中沒有具體內容,用於獲取報頭
  6. delete 請求服務器刪除request-URl所表示的資源
  7. trace 回顯服務器收到的請求,用於測試和診斷
  8. connect 能夠將連接改爲管道方式的代理服務器

 

在項目什麼時候選擇使用GCD,什麼時候選擇NSOperation?
答: 項目中使用NSOperation的優點是NSOperation是對線程的高度抽象,在項目中使用它,會使項目的程序結構更好,子類化NSOperation的設計思路,是具有面向對象的優點(複用、封裝),使得實現是多線程支持,而接口簡單,建議在複雜項目中使用。
項目中使用GCD的優點是GCD本身非常簡單、易用,對於不復雜的多線程操作,會節省代碼量,而Block參數的使用,會是代碼更爲易讀,建議在簡單項目中使用


 

線程與進程的區別和聯繫

1). 進程和線程都是由操作系統所體會的程序運行的基本單元,系統利用該基本單元實現系統對應用的併發性 2). 進程和線程的主要差別在於它們是不同的操作系統資源管理方式。 3). 進程有獨立的地址空間,一個進程崩潰後,在保護模式下不會對其它進程產生影響,而線程只是一個進程中的不同執行路徑。 4.)線程有自己的堆棧和局部變量,但線程之間沒有單獨的地址空間,一個線程死掉就等於整個進程死掉。所以多進程的程序要比多線程的程序健壯,但在進程切換時,耗費資源較大,效率要差一些。 5). 但對於一些要求同時進行並且又要共享某些變量的併發操作,只能用線程,不能用進程。

 

一、TCP 是傳輸控制協議  transport control protocol  ,基於字節流傳輸,有連接,可以提供可靠地通信傳輸

       TCP充分實現了數據傳輸時的各種控制功能,可以進行丟包的重發,還可以對次序亂掉的分包進行順序控制。TCP 作爲一種面向連接的傳輸協議,只有在確認通信端存在時纔會發送數據,從而避免數據流量的浪費。TCP 通過檢驗和、序列號、確認應答 和重發控制等機制實現可靠性傳輸。TCP 連接只能是點到點

二、UDP 是用戶數據協議 user data protocol ,基於數據報,無連接,不可靠

      UDP將部分控制轉移到應用程序去處理,自己只提供作爲傳輸層協議的最基本功能。對丟包亂序不做處理,UDP 支持 一對一、一對多、多對一、多對多通信

 

編程步驟: TCP  1、創建一個socket    2、設置socket屬性   3、綁定IP地址 端口信息到socket 上bind()    4、設置要連接的對方的IP地址和端口號   5、連接服務器 connect()   6、收發數據  receive ()  send() 7、關閉網絡連接

         UDP  1、創建一個socket    2、設置socket屬性   3、綁定IP地址 端口信息到socket 上bind()    4、設置要連接的對方的IP地址和端口號   5、發送數據 sendto()    6、關閉網絡連接

 

Viewcontroller 生命週期

當一個視圖控制器被創建,並在屏幕上現實的時候

1、alloc   2、init  3、loadview  4、viewdidload  5、viewwillappear  6、viewdidappear

當一個視圖被移除屏幕並且銷燬的時候的執行順序

1、viewwilldisappear   2、viewdiddisappear   3、dealloc

關於viewdidunload  在發生內存警告的時候如果本視圖不是當前屏幕正在顯示的視圖的話,viewdidunload將會被執行,本視圖的所有子視圖將被銷燬已釋放內存,此時開發者需要手動釋放該控制器中創建的對象。

 

iOS  APP性能測試:

instrument

1、leaks 內存泄漏  ,一般查看內存的使用情況,檢查泄漏的內存,並提供了所有活動的分配和泄漏模塊的類對象分配統計信息以及內存地址歷史記錄

2、time profile 時間探測: 分析代碼的執行時間,找出導致程序變慢的原因

3、allocations 內存分配:檢測內存使用、分配情況。跟蹤工程的匿名虛擬內存和堆的對象提供類名和可選保留釋放歷史

 

事件的分發和傳遞

  1. 當iOS 程序中發生觸摸事件後,系統會將事件加入到UIApplication管理的一個任務隊列中
  2. UIApplication將處於任務隊列最前端的事件向下分發。即UIWindow
  3. UIWindow將事件向下分發,即UIView
  4. UIView 首先看自己是否能處理事件,觸摸點是否在自己身上。如果能,那麼繼續尋找子視圖
  5. 遍歷子控件,重複以上兩步
  6. 如果沒有找到,那麼自己就是事件處理者
  7. 如果自己不能處理,那麼不做任何事情
  8. 該事件被廢棄

其中UIView 不接受事件處理的情況主要有一下三種:alph< 0.01   userinteractionEnable = NO   hidden = yes

 

這個從父控件到子控件尋找處理時間最合適的view過程,如果父視圖不接受事件處理,則子視圖也不能接收事件

 

       響應者鏈:

       響應鏈是從最合適的view開始傳遞,處理事件傳遞給下一個響應者,響應者鏈的傳遞方向是事件傳遞的反方向,如果所有響應者都不處理事件,則事件被丟棄。

 

 

數據持久化

1、屬性列表plist   用於存儲在程序中不經常修改、數據量小的數據,不支持自定義對象存儲

2、nsuserdefautls  同樣適合於存儲輕量級數據,本質上就是一個plist ,也不支持自定義對象存儲

3、歸檔序列化存儲

可以直接將對象存儲爲文件,也可將文件直接解歸檔爲對象,相對於plist文件與nsuserdefault  存儲更加多樣,支持自定義對象存儲,歸檔後的文件是加密的,也更加安全

4、Core data 

5、數據庫  FMDB

 

謂詞 NSPredicate 

通過設置邏輯條件 對數據進行過濾

 

volatile  是一個類型修飾符。該變量可能會被意想不到的改變。優化器在使用個這個變量時必須每次都小心的重新讀取這個變量的值,而不是使用保存在寄存器裏的備份。

  1. 並行設備的硬件寄存器
  2. 一箇中斷服務子程序中會訪問到的非自動變量
  3. 多線程應用中被幾個任務共享的變量

 

一個參數既可以是const 還可以是volatile。一個例子是隻讀的狀態寄存器,他可能會被意想不到的改變,而程序不應該視圖去修改他

一個指針可以使volatile。當一箇中斷服務子程序修改一個指向一個buffer的指針時

 

什麼是push

客戶端程序留下後門端口,客戶端總是監聽針對這個後門的請求,於是 服務器可以主動像這個端口推送消息

 

 

常見第三方庫:afnetworking 、SDWebImageView、Reactive Cocoa、 React Native

 

block 本質: 是帶有函數執行上下文環境的結構體,其中包含被調函數的指針

 

離屏渲染:

離屏渲染指的是GPU在當前屏幕緩衝區意外開闢了一個緩衝區進行渲染操作。對性能的影響主要是因爲:創建了新的緩衝區以及上下文的頻繁切換

導致離屏渲染的原因:

shouldRasterize 光柵化、遮罩masks、shadows 陰影、edgeantialiasing 抗鋸齒、不透明、複雜形狀設置圓角等、漸變

 

 

UIView 的繪製原理

當我們調用[UIView setNeedsDisplay]這個方法時 ,其實並沒有立即進行繪製工作,系統會立即調用CALayer的同名方法,並且會在當前layer上打上一個標記,然後會在當前runloop將要結束的時候調用【CALayer display】這個方法 然後進入視圖的真正繪製過程

在CALayer display 這個方法的內部實現中會判斷這個layer的delegate是否響應displaylayer這個方法,如果不響應這個方法,就回進入到系統會址流程中,如果響應這個方法,那麼就會爲我們提供異步繪製的入口

異步繪製

1假如我們在某一個時機調用了【view setNeedsDisplay】這個方法,系統會在當前runloop將要結束的時候調用【CALayer display】方法,然後如果我們這個layer的代理實現了【view displayerlayer】這個方法

2、然後會通過子線程的切換,我們在子線程中去做一個位圖的繪製,主線程可以去做一些其他的操作

3、 在子線程中創建一個位圖的上下文,然後通過CoregraphIC API 可以做當前UI空間的一些繪製工作,最後再通過CGBitmapContextCreateImage()這個函數來根據當前所繪製的上下文來生成一張cgimage圖片

       4、最後回到主線程來提交這個位圖,設置layer的contents屬性,這樣就完成了一個UI控件的異步繪製

 

 

分類的實現原理:

分類在編譯過程中,會生成  類方法列表、實例方法列表、屬性列表等,但是卻沒有 實例變量列表,分類所屬類是存在實例變量列表的。對比實例方法列表,可以發現 分類的實例方法列表中,並未對分類屬性生成getter /setter方法

分類是在運行時進行加載的。

把分類的餓實例方法、屬性、協議 添加到類的實例對象中原本存儲的實例方法、屬性、協議列表的前面

把分類的類方法和協議添加到類的元類上

 

 

應用多線程的時候會出現什麼問題,應如何避免問題的發生?

多線程容易導致資源爭搶,發生死鎖現象.死鎖通常是一個線程鎖定了一個資源A,而又想去鎖定資源B;在另一個線程中,鎖定了資源B,而又想去鎖定資源A以完成自身的操作,兩個線程都想得到對方的資源,而不願釋放自己的資源,造成兩個線程都在相互等待,造成了無法執行的情況。 

避免死鎖的一個通用的經驗法則是:當幾個線程都要訪問共享資源A、B、C時,保證使每個線程都按照同樣的順序去訪問它們,比如都先訪問A,在訪問B和C

採用GCD中的柵欄方法,用並行隊列去裝載事件並異步去執行

 

構建緩存時選用NSCache而非NSDictionary

當系統資源將要耗盡時,NSCache可以自動刪減緩存。如果採用普通的字典,那麼就要自己編寫掛鉤,在系統發出"低內存"通知時手工刪減緩存,NSCache會先行刪減"最久未使用的"對象。

NSCache並不會"拷貝"鍵,而是會"保留"它。此行爲用NSDictionary也可以實現,但是需要編寫比較複雜的代碼。NSCache對象不拷貝鍵的原因在於:很多時候,鍵都是由不支持拷貝操作的對象來充當的。因此,NSCache對象不會自動拷貝鍵,所以說,在鍵不支持拷貝操作的情況下,該類用起來比字典更方便。

NSCache是線程安全的,NSDictionary不是。在開發者自己不編寫加鎖代碼的前提下,多個線程便可以同時訪問NSCache。對緩存來說,線程安全通常很重要,因爲開發者可能要在某個線程中讀取數據,此時如果發現緩存裏找不到指定的鍵,那麼就要下載該鍵所對應的數據了。

Static

1).函數體內 static 變量的作用範圍爲該函數體,不同於 auto 變量,該變量的內存只被分配一次,因此其值在下次調用時仍維持上次的值; 2).在模塊內的 static 全局變量可以被模塊內所用函數訪問,但不能被模塊外其它函數訪問; 3).在模塊內的 static 函數只可被這一模塊內的其它函數調用,這個函數的使用範圍被限制在聲明它的模塊內; 4).在類中的 static 成員變量屬於整個類所擁有,對類的所有對象只有一份拷貝; 5).在類中的 static 成員函數屬於整個類所擁有,這個函數不接收 this 指針,因而只能訪問類的static 成員變量。

 

AsyncDisplayKit的使用

它是一個UI框架,能在異步線程繪製修改UI,然後統一添加進內存 渲染出來。

造成卡頓的原因:CPU 或 GPU消耗過大,導致再一次同步信號之間沒有準備完成,沒有內容提交,導致掉幀問題。

優化原理:

  1. 佈局:iOS 自帶的autolayout在佈局上存在性能瓶頸,並且只能在主線程進行計算。因此asdk棄用了autolayout自己設計了一套佈局方案
  2. 渲染:對於大量文本、圖片等的渲染,uikit組件只能在主線程並且可能會造成GPU繪製的資源緊張。ASDK 使用了一些方法,如圖層的預混合、並且異步在後臺繪製圖層,不阻塞主線程的運行
  3. 系統對象創建與銷燬:uikit組件封裝了CALayer圖層的對象,在創建、調整銷燬的時候,都會在主線程消耗資源。ASDK設計了一套NODE機制,也能夠調用

ASDK最大特點就是異步。將消耗時間的渲染、佈局、圖片解碼、及其他UI操作全部移出主線程,這樣主線程就可以及時響應用戶的操作,來達到流暢運行的目的

 

iOS 應用加密技術防止反編譯

  1. 本地數據加密
  2. URL編碼加密
  3. 網絡傳輸數據加密
  4. 方法體、方法名高度混淆
  5. 程序結構混排加密
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章