­　?。ㄔ瓨?biāo)題：感覺在蘋果iOS10中應(yīng)用運行更快更流暢？并非心理作用）

­　　我們即將在iOS10上迎來大量的變化，諸如iMessage這樣蘋果重點提到的內(nèi)容肯定是能贏得最多的關(guān)注了，但還有一些并沒有擺在臺面上的改進(jìn)卻值得注意，尤其是新系統(tǒng)中應(yīng)用運行更加快速流暢這個變化。那么蘋果是如何做到的呢？

­　　如果要用最簡單的語言來說明其中的奧妙所在，可以這么理解：新的API將能夠稍微提前一點點去加載你即將看到的內(nèi)容，而不再是當(dāng)你進(jìn)行滾動操作的時候，內(nèi)容才開始加載。

­　　不少應(yīng)用都有大量所謂的“區(qū)塊”，或者說數(shù)據(jù)集合。以前當(dāng)你快速向下劃動應(yīng)用頁面時，可能會注意到應(yīng)用在試圖跟上你的操作時會有卡頓。這種丟幀現(xiàn)象會讓應(yīng)用的性能表現(xiàn)看上去比它應(yīng)有的水準(zhǔn)更壞。

­　　在WWDC大會的其中一個環(huán)節(jié)中，蘋果特意提到了這些丟幀現(xiàn)象的原因，那就是應(yīng)用得在內(nèi)容進(jìn)入屏幕區(qū)域之后才開始加載，即使加載速度不過是毫秒之間，都會讓你注意到有明顯的卡頓出現(xiàn)。

­　　在iOS10中，蘋果將會讓那些“區(qū)塊”在你進(jìn)行滾動操作時提前加載，確保內(nèi)容進(jìn)入屏幕時已經(jīng)被加載完畢，滾動時的性能影響和加載時間是不會被注意到的。蘋果表示60幀每秒是最理想的，但是應(yīng)用達(dá)不到這個目標(biāo)也是常事。

­　　至于加載時間要提前多少的問題，蘋果稱它的測試已經(jīng)表明應(yīng)用的滾動性能是能夠停留在60幀的安全區(qū)的。

­　　這種理念被稱為“數(shù)據(jù)預(yù)提取”，而且能夠進(jìn)行反向工作。那些滑出你的屏幕的“區(qū)塊”較之以前會被保留更長的時間，以免你突然想要再回頭看看剛才漏掉的內(nèi)容。這樣一來，再往上滾動仍然能有流暢的體驗。

­　　另外蘋果還改變了應(yīng)用訪問數(shù)據(jù)的方式。新的API仍舊采用異步的方式訪問數(shù)據(jù)，但調(diào)用更快了。盡管蘋果希望將這個新設(shè)計用于Core Data，它也適用于開發(fā)者采用的任何解決方案。

­　　在這方面上，諸如Realm這樣的數(shù)據(jù)庫方案對于移動應(yīng)用來說更好一些，速度上比Core Data或SQLite更快。蘋果自家的載入方案終于趕上來了。

­　　新API在后臺隊列中載入數(shù)據(jù)，因此這并不影響主線程。它也能夠自適應(yīng)基于滾動操作的性能表現(xiàn)，因此數(shù)據(jù)載入能夠跟得上你讓“區(qū)塊”加載的操作。

­　　如果你更想知道的是那些有著多排內(nèi)容的應(yīng)用，不用擔(dān)心，蘋果在加載這一類的“區(qū)塊”上也做出了重大的改進(jìn)。

­　　目前應(yīng)用會一次性加載整排的內(nèi)容。比如采用單排設(shè)計的應(yīng)用，當(dāng)你快速滾動內(nèi)容時會出現(xiàn)卡頓。如果是擁有多排內(nèi)容的應(yīng)用，它就會像多米諾骨牌一樣，從左至右來加載那些“區(qū)塊”。

­　　這樣一來，那些內(nèi)容更復(fù)雜的應(yīng)用也能得到和簡單應(yīng)用相當(dāng)?shù)男阅鼙憩F(xiàn)，而且不需要開發(fā)者進(jìn)行額外的更新工作。蘋果指出這種新方案最適用于那些擁有相似尺寸的“區(qū)塊”，不過這種設(shè)計不是必須的。

­　　如果某個應(yīng)用是以頁面或是平板視圖來顯示內(nèi)容的，那就一點問題都沒有了。蘋果全新的渲染API很適合這類應(yīng)用，在你滾動內(nèi)容時根本不會注意到有任何拖慢的載入時間。

­　　最有趣的地方在于，開發(fā)者真的不需要為此做任何事情。所有的變化都在后端已有的API中完成了。只要應(yīng)用兼容iOS10，應(yīng)用就會運行得更加快速和順暢，至少蘋果是這么說的。

­　　如果某個開發(fā)者不喜歡這樣的設(shè)計，盡管不清楚他為什么要拋棄這么好的新方案，但他可以通過一行簡單的代碼回到過去的狀態(tài)。

­　　蘋果的后端小魔術(shù)讓應(yīng)用一下子變得更快了，這能夠讓用戶感到它們變得更好了。開發(fā)者不費勁，用戶們很開心，這還真是一次皆大歡喜的局面。