iOS進階--UIView的繪制

如果要研究OpenGL ES相關(guān)和 GPU 相關(guān)，這篇文章很具有參考的入門價值.

十余年的平鄉(xiāng)網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。網(wǎng)絡(luò)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整平鄉(xiāng)建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)公司從事“平鄉(xiāng)網(wǎng)站設(shè)計”,“平鄉(xiāng)網(wǎng)站推廣”以來，每個客戶項目都認(rèn)真落實執(zhí)行。

首先要從 Runloop 開始說,iOS 的 MainRunloop 是一個60fps 的回調(diào),也就是說16.7ms(毫秒)會繪制一次屏幕,這個時間段內(nèi)要完成:

這些 CPU 的工作.

然后將這個緩沖區(qū)交給 GPU 渲染, 這個過程又包含:

最終現(xiàn)實在屏幕上.因此,如果在16.7ms 內(nèi)完不成這些操作, eg: CPU做了太多的工作, 或者 view 層次過于多,圖片過于大,導(dǎo)致 GPU 壓力太大,就會導(dǎo)致"卡"的現(xiàn)象,也就是 丟幀 , 掉幀 .

蘋果官方給出的最佳幀率是: 60fps (60Hz),也就是一幀不丟, 當(dāng)然這是理想中的絕佳體驗.

一般來說如果幀率達到 60+fps (fps = 60幀以上,如果幀率fps 50,人眼就基本感覺不到卡頓了,因此,如果你能讓你的 iOS 程序 穩(wěn)定 保持在 60fps 已經(jīng)很不錯了, 注釋,是"穩(wěn)定"在60fps,而不是, 10fps , 40fps , 20fps 這樣的跳動,如果幀頻不穩(wěn)就會有卡的感覺, 60fps 真的很難達到, 尤其是在 iPhone 4/4s等 32bit 位機上,不過現(xiàn)在蘋果已經(jīng)全面放棄32位,支持最低64位會好很多.

總的來說, UIView從繪制到Render的過程有如下幾步：

UIView 的繪制和渲染是兩個過程:

上面提到的從 CPU 到 GPU 的過程可用下圖表示:

下面具體來討論下這個過程

假設(shè)我們創(chuàng)建一個 UILabel

這個時候不會發(fā)生任何操作, 由于 UILabel 重寫了 drawRect 方法,因此,這個 View 會被 marked as "dirty" :

類似這個樣子:

然后一個新的 Runloop 到來，上面說道在這個 Runloop 中需要將界面渲染上去，對于 UIKit 的渲染，Apple用的是它的 Core Animation 。 做法是在Runloop開始的時候調(diào)用：

在 Runloop 結(jié)束的時候調(diào)用

在 begin 和 commit 之間做的事情是將 view 增加到 view hierarchy 中，這個時候也不會發(fā)生任何繪制的操作。 當(dāng) [CATransaction commit] 執(zhí)行完后， CPU 開始繪制這個 view :

首先 CPU 會為 layer 分配一塊內(nèi)存用來繪制 bitmap ，叫做 backing store

創(chuàng)建指向這塊 bitmap 緩沖區(qū)的指針，叫做 CGContextRef

通過 Core Graphic 的 api ，也叫 Quartz2D ，繪制 bitmap

將 layer 的 content 指向生成的 bitmap

清空 dirty flag 標(biāo)記

這樣 CPU 的繪制基本上就完成了.

通過 time profiler 可以完整的看到個過程：

假如某個時刻修改了 label 的 text :

由于內(nèi)容變了, layer 的 content 的 bitmap 的尺寸也要變化，因此這個時候當(dāng)新的 Runloop 到來時， CPU 要為 layer 重新創(chuàng)建一個 backing store ，重新繪制 bitmap .

CPU 這一塊最耗時的地方往往在 Core Graphic 的繪制上，關(guān)于 Core Graphic 的性能優(yōu)化是另一個話題了，又會牽扯到很多東西，就不在這里討論了.

GPU bound：

CPU 完成了它的任務(wù)：將 view 變成了 bitmap ，然后就是 GPU 的工作了， GPU 處理的單位是 Texture .

基本上我們控制 GPU 都是通過 OpenGL 來完成的，但是從 bitmap 到 Texture 之間需要一座橋梁， Core Animation 正好充當(dāng)了這個角色：

Core Animation 對 OpenGL 的 api 有一層封裝，當(dāng)我們要渲染的 layer 已經(jīng)有了 bitmap content 的時候，這個 content 一般來說是一個 CGImageRef ， CoreAnimation 會創(chuàng)建一個 OpenGL 的 Texture 并將 CGImageRef（bitmap） 和這個 Texture 綁定，通過 TextureID 來標(biāo)識。

這個對應(yīng)關(guān)系建立起來之后，剩下的任務(wù)就是 GPU 如何將 Texture 渲染到屏幕上了。 GPU 大致的工作模式如下：

整個過程也就是一件事：

CPU 將準(zhǔn)備好的 bitmap 放到 RAM 里， GPU 去搬這快內(nèi)存到 VRAM 中處理。 而這個過程 GPU 所能承受的極限大概在16.7ms完成一幀的處理，所以最開始提到的60fps其實就是GPU能處理的最高頻率.

因此， GPU 的挑戰(zhàn)有兩個：

這兩個中瓶頸基本在第二點上。渲染 Texture 基本要處理這么幾個問題：

Compositing 是指將多個紋理拼到一起的過程，對應(yīng) UIKit ，是指處理多個 view 合到一起的情況，如:

如果 view 之間沒有疊加，那么 GPU 只需要做普通渲染即可.

如果多個 view 之間有疊加部分， GPU 需要做 blending .

加入兩個 view 大小相同，一個疊加在另一個上面，那么計算公式如下：

R = S + D *( 1 - Sa )

其中 S , D 都已經(jīng) pre-multiplied 各自的 alpha 值。

Sa 代表 Texture 的 alpha 值。

假如 Top Texture （上層 view ）的 alpha 值為 1 ，即不透明。那么它會遮住下層的 Texture .

即, R = S 。是合理的。

假如 Top Texture （上層 view ）的 alpha 值為 0.5 ，

S 為 (1,0,0) ，乘以 alpha 后為 (0.5,0,0） 。

D 為 (0，0，1) 。

得到的 R 為 （0.5，0，0.5） 。

基本上每個像素點都需要這么計算一次。

因此， view 的層級很復(fù)雜，或者 view 都是半透明的（ alpha 值不為 1 ）都會帶來 GPU 額外的計算工作。

這個問題，主要是處理 image 帶來的，假如內(nèi)存里有一張 400x400 的圖片，要放到 100x100 的 imageview 里，如果不做任何處理，直接丟進去，問題就大了，這意味著， GPU 需要對大圖進行縮放到小的區(qū)域顯示，需要做像素點的 sampling ，這種 smapling 的代價很高，又需要兼顧 pixel alignment 。 計算量會飆升。

如果我們對 layer 做這樣的操作：

會產(chǎn)生 offscreen rendering ,它帶來的最大的問題是，當(dāng)渲染這樣的 layer 的時候，需要額外開辟內(nèi)存，繪制好 radius，mask ，然后再將繪制好的 bitmap 重新賦值給 layer 。

因此繼續(xù)性能的考慮， Quartz 提供了優(yōu)化的 api ：

簡單的說，這是一種 cache 機制。

同樣 GPU 的性能也可以通過 instrument 去衡量：

紅色代表 GPU 需要做額外的工作來渲染 View ，綠色代表 GPU 無需做額外的工作來處理 bitmap 。

全文完

收錄： 原文地址

零基礎(chǔ)如何學(xué)習(xí)ios開發(fā)？

oc已全部翻譯完成視頻總4個視頻免費下載

鏈接:

提取碼:64s9

oc已全部翻譯完成視頻 總4個視頻|OC教程04：速建+講解.mp4|OC教程03：如何給機器人添加紋理與著色.mp4|OC教程02：場景管理.mp4|OC教程01：涂鴉的投射原理與應(yīng)用.mp4

如何快速學(xué)會ios開發(fā)

篇一：分享簡單學(xué)習(xí)iOS開發(fā)的方法

隨著3G技術(shù)的普及與智能終端的快速發(fā)展，逐漸的移動開發(fā)者最受企業(yè)的歡迎，特別是iOS軟件開發(fā)人才更是得到了企業(yè)的青睞，從現(xiàn)在情況來看，iOS培訓(xùn)和iOS軟件開發(fā)人才有些嚴(yán)重供不應(yīng)求。

容易上手的，學(xué)習(xí)iOS要注意到每個細節(jié)，因為每個細小的知識都有可能改變這個程序，如果有一點的錯誤都會導(dǎo)致整個程序無法運行，其實學(xué)習(xí)iOS和上學(xué)學(xué)習(xí)一樣，都是從最基礎(chǔ)的開始學(xué)起，慢慢的積累知識。如果想學(xué)好iOS，現(xiàn)在單單在網(wǎng)上學(xué)習(xí)是有點out了，可以選擇零學(xué)費，就能夠入學(xué)的培訓(xùn)學(xué)校學(xué)習(xí)一下，如果沒有合適的話，可以了解一下培訓(xùn)機構(gòu)，找一個口碑不錯的，這樣結(jié)合理論和實際才能夠?qū)W好iOS。

在課前一定要做好準(zhǔn)備資料及準(zhǔn)備內(nèi)容，要知道老師要講什么？先做好預(yù)習(xí)，這樣有準(zhǔn)備的上戰(zhàn)場才會學(xué)得更好，在課堂上認(rèn)真聽老師講課，在電腦上操作老師所講的內(nèi)容，如果有不懂的一定要及時向講師問清是怎么回事，課后多做幾次練習(xí)，那么就不是問題了。3

如果聽不懂怎么辦？

這些現(xiàn)象很正常，誰也不敢保證講師所講的知識都能夠無一不漏的聽明白，能夠在電腦上操作出來，那么如果遇到不懂得就要直接問，還可以先預(yù)習(xí)今后再去學(xué)習(xí)理論課的時分就能夠有對于性的去聽了，教師講到你現(xiàn)已把握的內(nèi)容時，你能夠注意聽一下講師是不是有了新的見解及創(chuàng)新的認(rèn)識、講的和你了解到的是不是一樣，如果不太一樣的話，那么就要做下記號，課下與老師溝通，承認(rèn)這個

常識點的真實意義；若是講到你預(yù)習(xí)時不會的常識點的話，你更大概仔細的去聽了，認(rèn)真的去了解一下到底是怎么個意思？

篇二：如何快速學(xué)會ios開發(fā)

針對學(xué)習(xí)iOS開發(fā)怎么樣?想學(xué)iOS開發(fā)如何才能快速學(xué)習(xí)?沒有基礎(chǔ)怎么快速學(xué)習(xí)iOS開發(fā)等問題，藍鷗iOS培訓(xùn)專業(yè)老師指點明燈!看著身邊學(xué)iOS開發(fā)的人拿了高工資，很多人按捺不住了。但菜鳥真的也可以成為iOS開發(fā)軟件工程師嗎?只要有恰當(dāng)?shù)膶W(xué)習(xí)方法，學(xué)習(xí)軟件開發(fā)并不難。對于軟件初學(xué)者來說，主要做到以下幾點：

一、打好基礎(chǔ)，不能一步登天

學(xué)習(xí)iOS,首先要學(xué)習(xí)C語言，很多人跳過C，直接學(xué)Objective-C，這是極不可取的。Objective-C是C的超集，必須有C的基礎(chǔ)，學(xué)習(xí)才能更好更快的進行。不要一開始就盲目崇拜別人的大項目，要從小項目開始，一步一個腳印，遇到困難不要退縮，解決困難也是學(xué)習(xí)的過程。

二、必須如蜜蜂，多方采集花蜜

在學(xué)習(xí)初期對于iOS沒有概念，最好的辦法就是多看別人的代碼，多吸取別人的養(yǎng)分。遇到不懂得問題不要跳過，而是要多問，多向人請教，學(xué)習(xí)別人的思路，吸取有益的知識，并做好學(xué)習(xí)筆記。積少成多，會成為你不小的財富。

三、勤動腦，多動手，有創(chuàng)新精神

軟件開發(fā)者是為了讓軟件實現(xiàn)更豐富更強大的功能，必須有很強的實際操作能力。作為iOS開發(fā)工程師，不但要了解用戶需要哪些功能，有哪些需求，還要多動腦，開發(fā)出符合市場以及時代需求的項目。這都需要軟件開發(fā)者具備很好創(chuàng)新精神。

由此可見，學(xué)習(xí)iOS開發(fā)，只要肯吃苦，有恒心，菜鳥也可以有很藍，很廣闊的天空。iOS培訓(xùn)很注重基礎(chǔ)教學(xué)，教學(xué)方式與大學(xué)不同，在教授理論知識的同時，更注重實踐技能的培養(yǎng)。擺正心態(tài)，切勿操之過急，囫圇吞棗，將每天所學(xué)定義為就是今后工作要用的，這樣你便會認(rèn)真對待每一次學(xué)習(xí)、每一行代碼和遇到的每一個難題。

參加iOS開發(fā)培訓(xùn)也可以，現(xiàn)在iOS開發(fā)培訓(xùn)大概也就4個月時間，花一兩萬系統(tǒng)學(xué)4個月也是一個不錯的選擇，雖然要一兩萬，但是效果跟自己學(xué)肯定是不一樣的，要是自己學(xué)跟有老師帶著學(xué)一樣，那這個世界上將沒有學(xué)校存在了。對于參加iOS開發(fā)培訓(xùn)的一定

要選對機構(gòu)，有句話說得好，選對比選好有時候重要太多。你考30分的'成績讓你去北大清華也不一定能夠成就了呢，所以選擇口碑好的機構(gòu)，專注iOS開發(fā)的機構(gòu)比較好，畢竟咱基礎(chǔ)不好，那些機構(gòu)做雜很難做精。不管是快速學(xué)還是慢慢自學(xué)還是選擇iOS培訓(xùn)機構(gòu)系統(tǒng)培訓(xùn)，只要你投入進去就好，堅持下去一定會有大收獲。不管做什么或者學(xué)什么一定要避免三天打魚兩天曬網(wǎng)，這樣效果不會明顯。

篇三：零基礎(chǔ)學(xué)iOS開發(fā)的方法

怎么學(xué)習(xí)iOS開發(fā)，尤其是對于沒有基礎(chǔ)的，甚至是0基礎(chǔ)的朋友而言，要學(xué)習(xí)iOS開發(fā)就需要注重方法了。由于iphone手機帶來的手機應(yīng)用狂潮，現(xiàn)在很多人都希望從事這塊的開發(fā)。很多初學(xué)者可能會問，沒有基礎(chǔ)怎么樣才能學(xué)好iOS開發(fā)，我們要看什么書呢，還是什么視頻，其實這些都不是重要的，重要的是，你認(rèn)為自己可以學(xué)好iOS開發(fā)，認(rèn)為自己可以堅持下來，這是關(guān)鍵啦。

其實學(xué)很多語言都是通的，即使0基礎(chǔ)學(xué)習(xí)也不怕，從C語言入門，因為iOS開發(fā)用的是OC語言，是在C基礎(chǔ)上的，不過也跟C不是很搭界，你可以直接學(xué)習(xí)OC語言也可以，還有開發(fā)工具是用Xcode，是在Mac系統(tǒng)的，你多摸索一下就可以開發(fā)簡單的應(yīng)用了，建議你買一本iphone開發(fā)秘籍第二版看看。學(xué)語言，無非就是要學(xué)好基礎(chǔ)，弄清楚概念，然后做個簡單的例子，慢慢的體會，基礎(chǔ)打好了，到后面你會覺得突然自己提高了很多，很多東西都自然而然地明白了，在黑暗中的努力是為了迎接光明。

我覺得學(xué)iOS開發(fā)，首先心態(tài)要好，不要想著我已經(jīng)學(xué)習(xí)很長時間了，可以找個好工作，可以賺錢了，牛人除外，不過大多都是普通人。

先慢慢培養(yǎng)興趣下定決心，然后開始找資料，找視頻，查百度。等你覺得這些基礎(chǔ)的都差不多理解了，那就別看書，將精力集中于界面開發(fā)、一定的數(shù)據(jù)庫開發(fā)、通訊接口開發(fā)、協(xié)同開發(fā)與聯(lián)調(diào)。然后自己設(shè)計個東西，可以涵蓋他們的，做個自己想做的東西出來，雖然可能很難，但是你會在過程中學(xué)到很多，是別人教不會你的。

在學(xué)習(xí)過程中遇到什么問題，你可以百度一下看看別人的回答，看多了印象就深了，也就慢慢掌握了。遇到什么思路上的問題，可以來藍鷗網(wǎng)站技術(shù)論壇發(fā)帖，論壇肯定會有人來幫忙的，就算不能完全解決，也可以提供點參考。學(xué)習(xí)要會利用資源，論壇上那么好的資源不用可惜的哦，還有資料堆的東西，只要你能掌握70%，不相信你可以試試。

iOS開發(fā)進階- 閱讀時長統(tǒng)計&復(fù)雜頁面架構(gòu)

記錄器

基于不同的場景提供關(guān)于記錄的封裝、適配。一般分為頁面式，流式，自定義式。

記錄管理者

管理統(tǒng)計記錄數(shù)據(jù)，包含記錄緩存，磁盤存儲，上傳器。

如何降低數(shù)據(jù)的丟失率？

兩種解決方案：

記錄上傳的時機

上傳時機的選擇

從三個方面分析架構(gòu)設(shè)計：整體架構(gòu)、數(shù)據(jù)流、反向更新。

View 的功能包含：控件的初始化、設(shè)置數(shù)據(jù)、交互事件代理等。

ViewController 的功能：視圖創(chuàng)建與組合、協(xié)調(diào)邏輯、事件回調(diào)處理等，事件回調(diào)處理指的是視圖層的事件。

業(yè)務(wù)邏輯處理（預(yù)排版）、數(shù)據(jù)增刪改查封裝者、線程安全處理。

網(wǎng)絡(luò)請求、數(shù)據(jù)解析、增刪改查、本地處理邏輯（適配）

數(shù)據(jù)流包含：網(wǎng)絡(luò)數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)、UI數(shù)據(jù)三部分。

網(wǎng)絡(luò)數(shù)據(jù)經(jīng)過 Engine 層處理加工產(chǎn)生業(yè)務(wù)數(shù)據(jù)，業(yè)務(wù)數(shù)據(jù)經(jīng)過 ViewModel 層處理產(chǎn)生UI數(shù)據(jù)，UI數(shù)據(jù)會轉(zhuǎn)交給視圖控制器控制視圖的顯示。

用戶交互網(wǎng)絡(luò)刷新等都會導(dǎo)致視圖層變化，通過代理方式通知視圖控制器。控制器對ViewModel的強引用找到對應(yīng)ViewModel，然后通過UI數(shù)據(jù)對業(yè)務(wù)數(shù)據(jù)的弱引用找到對應(yīng)的業(yè)務(wù)數(shù)據(jù)同時打上臟標(biāo)記。最后ViewModel進行數(shù)據(jù)流的重新驅(qū)動，將臟數(shù)據(jù)重新處理生成新的UI數(shù)據(jù)更新視圖。

本節(jié)梳理時長統(tǒng)計實現(xiàn)原理和復(fù)雜頁面的架構(gòu)實現(xiàn)思路。

iOS 開發(fā)中的 MVVM 模式——實用進階篇（整理）

這篇文章主要介紹了實際應(yīng)用 MVVM 的過程中的一些問題和解決方案

MVVM（Model View ViewModel）是一種 MVC（Model View Controller）的一種變型，來解決 MVC 中龐大復(fù)雜的 Controller 難以維護的問題。大致上講 MVVM 有幾個要求：

MVVM 和 MVC 有很多類似的特點，主要的不同有：

另外一點，MVVM 默認(rèn) View 和 View Controller 有一個一對一的關(guān)系，一般我們把這兩個看做一個整體，會以 .swift 文件 和 Storyboard 的形式出現(xiàn)。

View Model 的工作是處理所有的展示數(shù)據(jù)的邏輯。如果一個 model 中有一個 NSDate 對象， NSDateFormatter 就會在 View Model 中用來設(shè)置日期的展示形式。

View Model 不能接觸任何用戶界面的部分，View Model 文件中不應(yīng)該 import UIKit ，View Controller 會觀察 View Model 去了解什么時候顯示新的數(shù)據(jù)（通過 KVO 或者 FRP（Functional Reactive Programming））

MVVM 和 MVC 有一個共同的弱點：沒有清楚的定義應(yīng)該把網(wǎng)絡(luò)請求部分放在哪里。在實際操作過程中，我會把網(wǎng)絡(luò)請求放在 View Model 文件里面，但之后我打算把網(wǎng)絡(luò)請求放在自己獨立的一個類中，View Model 文件會擁有這個對象。

下面我們主要談一談實際應(yīng)用 MVVM 過程中一些挑戰(zhàn)：

例如你想構(gòu)造這樣一個常用的界面，有一個 segment control 在屏幕頂部，屏幕的其他部分是一個 collection view，選擇不同的 segment，就會展示不同樣式的 collection view，元素的排列順序。我們定義了一個 enum 來枚舉所有的排列樣式：

那么這個 enum 在 MVVM 模式中應(yīng)該放在哪里呢？因為這個 enum 決定了數(shù)據(jù)排列的順序，每個 cell 中的文字和按鈕的 title，這些都屬于展示的邏輯，所以這個 enum 看起來應(yīng)該放在 view model 中。

然而，這些 layout 并不改變要展示的數(shù)據(jù)，只是決定了要呈現(xiàn)的數(shù)據(jù)的排列方式和排列順序，從這個角度上來說 enum 又應(yīng)該放在 view controller 中。

我的解決方法是把 enum 放在 view model 中，然后在 view model 中加一個對外的 Observable 或者 Signal 來表示使用了哪個 layout，基于用戶選擇的 segment，view model 更新這個值，然后在 view controller 中根據(jù)相應(yīng)的 layout 改變 collection view 的樣式，view controller 也可以根據(jù)這個值來決定用哪個 cell reuse identifier

iOS 開發(fā)者在用 MVVM 和 FRP 寫應(yīng)用的時候最常見的問題可能就是 ViewModel 怎么把數(shù)據(jù)展現(xiàn)給 ViewController。當(dāng) Model 層的數(shù)據(jù)發(fā)生變化更新的時候，ViewController 需要得到通知然后做出相應(yīng)的 UI 更新，我們一般會用到兩種機制：

第一個選項很吸引人，因為可以在 View Controller 中決定怎么選擇觀察那些 property。然而，我不推薦在 Swift 中使用第一個選項，因為 Swift 在 KVO 中沒有類型檢查，你需要對 AnyObject 強制轉(zhuǎn)換類型很多次。

第二個選項是比較 Swift 的方式，基于 Swift 的 generics 特性，signals，sequences，observables 可以支持編譯過程中的類型檢查。

但有時候在 view model 增加這些 Signals 或者 Observables 有些困難。Swift 的初始化方法對于什么時候?qū)?property 賦值有非常明確的規(guī)定。Signals 或者 Observables 需要使用 view model 內(nèi)部的狀態(tài)，所以它們必須在 super.init() 之后才能創(chuàng)建，但是另一方面，我們在調(diào)用 super.init() 之前保證所有 property 已經(jīng)被賦值了，包括那些 Signal/Observable property。

這是個先有雞還是先有蛋的問題。

我采用比較簡單的解決方法：定義成 var 的隱式可選類型，這樣就可以在 super.init() 之后才給 property 賦值。這不是一個完美的解決辦法。我們可以用 lazy var property 的閉包賦值來代替上面的方法。在 Swift 不斷完善和更新的過程中，大家也可以探索其他更好的辦法。

舉一個很常用的例子，用戶點擊 collection view 中的一個 cell，跳轉(zhuǎn)到詳情頁面。用戶點擊的操作應(yīng)該在 view controller 中處理，具體內(nèi)容是展現(xiàn)一個新的詳情頁面。但是 view controller 不能直接接觸 models，我們要如何用 MVVM 模式實現(xiàn)這樣的用戶交互呢？

我的解決方案是利用 Swift 的閉包。首先在 view model 中定義一個閉包：

然后在 view model 中添加一個 property：

接著我需要調(diào)用閉包，在 view model 中定義一個view controller 可以調(diào)用的函數(shù)，這個函數(shù)的參數(shù)是可以決定使用什么數(shù)據(jù)，一般情況下常用 index path：

現(xiàn)在當(dāng)用戶選中一個 cell，會調(diào)用 view model 中的這個函數(shù)，并且傳入 index path 參數(shù)，view model 決定使用哪個數(shù)據(jù)，并調(diào)用在 view controller 中定義的閉包，例如：

最后一個問題是怎么創(chuàng)建這個 view model。我們需要傳遞一個閉包給view model 的初始化函數(shù)，然后用 lazy loading 來調(diào)用 view model 的初始化函數(shù)。

iOS進階——微信開源存儲框架MMKV(一)

MMKV是微信開源的數(shù)據(jù)持久化框架，現(xiàn)在已經(jīng)支持Android/iOS/PC 平臺。該框架是基于mmap映射內(nèi)存的key—value組件，使用protobuf實現(xiàn)數(shù)據(jù)的序列化和反序列化，性能高，穩(wěn)定性強。微信在2015就在微信應(yīng)用上使用了該框架。實驗證明MMKV是數(shù)據(jù)持久化的首選。

ProtoBuf是由google公司用于數(shù)據(jù)交換的序列結(jié)構(gòu)化數(shù)據(jù)格式，具有跨平臺、跨語言、可擴展特性，類型于常用的XML及JSON，但具有更小的傳輸體積、更高的編碼、解碼能力，特別適合于數(shù)據(jù)存儲、網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)葘Υ鎯w積、實時性要求高的領(lǐng)域。

優(yōu)點：空間效率搞，時間效率要高，對于數(shù)據(jù)大小敏感，傳輸效率高的。

缺點：消息結(jié)構(gòu)可讀性不高，目前使用不廣泛。

MMKV維護了一個String,AnyObject的dic,在寫入數(shù)據(jù)時，會在dit和mmap映射區(qū)寫入相同的數(shù)據(jù)，最后由內(nèi)核同步到文件。因為dic和文件數(shù)據(jù)同步，所以讀取時直接去dit中的值。MMKV數(shù)據(jù)持久化的步驟：mmap 內(nèi)存映射 - 寫數(shù)據(jù) - 讀數(shù)據(jù) - crc校驗 - aes加密。

在MMKV的源碼中，是怎么樣內(nèi)存映射的呢？

標(biāo)題名稱：ios開發(fā)如何進階,iOS進階
URL標(biāo)題：http://chinadenli.net/article23/dseeccs.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計、營銷型網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計公司、品牌網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)