爲何我要編寫本身的UIKit

現在的軟件更像是由不可勝數的磚塊堆砌起來的金字塔，沒有一點結構完整性，徹底是成千上萬的奴隸依靠蠻力修建起來。

-- 艾倫·凱伊(Alan Kay)

這是一個關於（Web）互聯網的故事。根據不少定義，它是這個星球上出現的偉大奇蹟之一，它有一個低調的開始，僅僅做爲發送超文本文件的一種媒介，可是當它趕上了Javascript 這門腳本語言，它變成了一個能夠創形成千上萬應用的卓越平臺。

時光前進二十年現在你已經擁有多家價值數十億美金的公司(從Facebook到LinkedIn)，你投入數不清的開發工程師資源想用HTML來打造一款高水準的應用，個人公司(bubbli)也陷入了相似的陷阱。人們老是說「多用CSS transforms」「用Google Closure Tool優化代碼」，可這徹底是個傻瓜纔會乾的差事，這樣作所跨越的抽象層次太深，就好像建一所空中樓閣同樣。

最後咱們終於醒悟過來，開始爲每個平臺開發原生應用，由於每一個平臺都提供了「最好的工具」，這些開發工具就是被設計用來從零開始來建立應用。並且，移動平臺的計算能力在過去幾年獲得了飛速發展：Apple和Google持續地在對應的平臺上推出各類新技術。我還記得在WWDC 2013的開發者講座中聽過的一次UI Dynamics主題的課程，我對本身說：

WOW，太難以想象了！

緊接着是：

等一下，爲何咱們須要Apple這種填鴨式的UI創新？難道咱們忘記了計算機是一種圖靈完備的設備，咱們可讓它作任何咱們想作的事？

就這樣我掉進了兔子洞裏面，開始着手用OpenGL ES重寫我本身的UIKit。

大白兔

提示：我關閉了文字渲染，由於我在不一樣的平臺使用了不一樣的文字渲染庫，在我錄製這幅GIF時我尚未完成在OS X上的文字測試。不過在iOS上效果看起來還不賴。

若是你從未用過咱們的應用，給你一些提示：這些球型的照片叫作氣泡，你能夠用你的iPhone想鏡子同樣觀察周圍的世界。

咱們能夠把它們想象成一種通向自身的一種媒介，延續它們自生的視角。就像你從未看過由幾千張圖片構成的電影，你也不會看到一個氣泡平展成一幅平面圖片。

這裏的難處在於繪製氣泡的數據量要比一幅平面照片而言多得多，在60幀下要讓照片生成非線性的樣式還要面對CPU的性能限制。一開始我想用CoreAnimation來實現，但以前作Facebook Page的哥們發現這樣的效率不夠，在UIKit下併發加載不少資源很是困難。很快我決定使用OpenGL來繪製氣泡。

掉下兔子洞

此刻最大的挑戰是OpenGL對於CoreAnimation生成的動畫不夠友好。我設法混合了UICollectionViews和一些OpenGL代碼，已經接近咱們預期的效果，但在WWDC上看到了iOS 7的改變後，咱們決定增長照片的數量，而且動畫的變換應該可以承上啓下，圍繞這個精神咱們迅速構思新的交互形式.一件讓咱們很痛苦的事情是如何在持續改變氣泡視圖尺寸的同時不會在氣泡間產生縫隙，這種效果給人感受就像整個界面向左邊收縮

隨着你的手指向左滑動，整個網格視圖就像一條繩索沿着一個竹竿纏繞的愈來愈緊。

這張gif是在個人電腦上錄製，因此這些氣泡是靜態的，在iPhone上每一個氣泡都會隨着陀螺儀變換角度。看起來效果簡直難以想象，這是個免費的應用， 你能夠下載來看看這種效果。

我一直想用純OpenGL來實現，讓我驚訝的是，原來只要對UICollectionView進行高度優化也能夠很容易在屏幕上顯示幾百個氣泡，我看我只能給本身打個20分。

如今已經沒有回頭路了。

改寫所有

在創業公司作僅有的一個程序員的最大好處就是我不須要跟別人解釋個人想法是可行的。不過當咱們要發佈應用，Apple可不會讓一款看起來帶有明顯iOS 6風格的應用上線，無論怎樣咱們還須要作iOS 7適配。因此我一不作二不休，用OpenGL ES從頭開始重寫一切東西。

爲之後的狀況做準備，首先我要確保我能用最小的改動能讓我寫的東西運行在任何現在流行的平臺上。我拋棄了CoreData轉用sqlite，改用C++ 11 而不用Objective-C寫代碼。我沖洗了我本身的網絡棧，觸摸處理，滾動視圖，表視圖，高斯模糊，資源加載，動畫等等。

在WWDC和咱們應用上線之間的四個多月我重寫了應用全部代碼，事實上加上我本身寫的UIKit比咱們以前的應用還少了幾千行代碼，上線後，儘管很緊張可是彷佛沒人發現咱們的應用有任何不舒服的地方。

不僅是小把戲

重寫iOS 7的特效是一項有趣的實驗，不太重寫你本身的UIKit的真正回報是它在某種程度上實現了HTML 5 的承諾——一次編寫，全平臺運行，不會犧牲任何的性能和寶貴的開發時間。

遷移到其餘平臺？小Case

在聖誕節的週末我匆匆忙忙編寫了一款Mac應用。事實上上面的截圖都是這款應用所錄製的而不是從iOS模擬器錄製的。我已經成功地將這款應用遷移到其餘平臺上了（好吧，Wondow Phone不在其中），甚至用emscripten遷移到瀏覽器中運行！遷移後會不會損失一些蘋果的滑動特效？固然，不過不用擔憂只是一些if/ifdef語句。

別再等待你所依賴的閉源框架的修復

CoreData上下文在合併兩個上下文時會觸發數百萬的KVO通知嗎？固然不會。當你從零開始建造整個世界時，你能夠僅憑蠻力和堅持不懈來解決任何Bug。對比你在IE11裏發現的種種神奇情況，耐心等看看明年是否是仍是這尿性。

並且我敢打賭，有能力的開發人員編寫本身的框架比使用別人的框架容易地多，由於你很是清楚全部的東西如何工做，只要你能創建比較好的抽象，其實只是幾千行代碼的問題。

壓榨當代硬件的變態性能

事實上每個與屏幕鏈接的CPU都配有一個GPU芯片。那咱們爲什麼還要在CPU上作如此多的繪畫工做？愈來愈多的消費者但願獲得沉浸式的體驗，GPU在此方面能夠提供高效的計算能力。你能夠看看在咱們的應用的最下方那個相機按鈕，你會注意到當你滑動屏幕時它會折射屏幕的其餘位置.iOS 7極大地改善了屏幕截圖的性能，可是和一個用紋理渲染的視圖沒有什麼可比性。

統一的代碼庫

不久的將來咱們將不用擔憂在不一樣的平臺上實現相同功能的困擾。若是我對Go語言不感冒，我可能會使用app中用到的數據庫抽象/代碼來編寫咱們的後端，這樣作最顯而易見的好處就是定製化和有效控制開發隊伍的規模。

平臺大戰走向終結

這篇文章裏其實沒有什麼新東西——遊戲開發人員不少年前就承認了這種這種哲學。平臺廠商們使用小伎倆，試圖讓開發者相信用戶界面和他們所運行的操做系統是牢牢關聯的。不過，這些年來的趨勢改變了，你已經能夠在沒有任何特殊權限的用戶空間運行許多難以想象的代碼，僅僅用POSIX和Kronos標準你就能夠走得很遠。 此外最令我興奮的是，emscripten有潛力運行各類不一樣的平臺。若是emscripten可以持續改善，JS會變得愈來愈不重要，在某個時間點瀏覽器廠商能夠選擇一個不用編譯JS的後臺置換現有平臺，咱們不再用爲咱們的應用適配多種瀏覽器而感到煩惱了。 若是我是Apple或者Google，我會很是關心這樣的理念是否在推動，一個只專一於某個平臺的開發者將會失敗，市場份額會變得愈來愈流動。要不是個人公司不是Apple或Google，我投入全部可能的資源來推行這個理念。 Alan Kay常常評論說：「咱們所感知到的現代軟件系統很是複雜，咱們接受了這個‘事實’，然而其實這並非事實。若是咱們根據這麼多年來的經驗重寫全部的抽象，咱們會獲得一個大幅縮小的核心代碼k庫。」我更傾向於他的這種見解，也很是激動想要看到若是咱們都這麼作能帶來的創新。

---

原文 Why I wrote my own UIKit
翻譯 伯樂在線 - 袁欣
修訂 SegmentFault