為什么我要重寫自己的UIKit？
如今的軟件更像是由不計其數的磚塊堆砌起來的金字塔，沒有一點結構完整性，完全是成千上萬的奴隸依靠蠻力修建起來。 – 艾倫·凱伊(Alan Kay)
這是一個關于（Web）互聯網的故事。根據很多定義，它是這個星球上出現的偉大奇跡之一，它有一個低調的開始，僅僅作為發送超文本文件的一種媒介，但是當它遇上了Javascript 這門腳本語言，它變成了一個可以創造成千上萬應用的卓越平臺。
時光前進二十年如今你已經擁有多家價值數十億美金的公司(從非死book到LinkedIn)，你投入數不清的開發工程師資源想用HTML來打造一款高水準的應用，我的公司(bubbli)也陷入了類似的陷阱。人們總是說“多用CSS transforms”“用Google Closure Tool優化代碼”，可這完全是個傻瓜才會干的差事，這樣做所跨越的抽象層次太深，就好像建一所空中樓閣一樣。
最后我們終于醒悟過來，開始為每一個平臺開發原生應用，因為每個平臺都提供了“最好的工具”，這些開發工具就是被設計用來從零開始來創建應用。而 且，移動平臺的計算能力在過去幾年得到了飛速發展：Apple和Google持續的在對用的平臺上推出各種新技術。我還記得在WWDC 2013的開發者講座中聽過的一次UI Dynamics主題的課程，我對自己說：
WOW，太不可思議了！
緊接著是：
等一下，為什么我們需要Apple這種填鴨式的UI創新？難道我們忘記了計算機是一種圖靈完備的設備，我們可以讓它做任何我們想做的事？
就這樣我掉進了兔子洞里面，開始著手用OpenGL ES重寫我自己的UIKit。
大白兔
如果你從未用過我們的應用，給你一些提示：這些球型的照片叫做氣泡，你可以用你的iPhone想鏡子一樣觀察周圍的世界。
我們可以把它們想象成一種通向自身的一種媒介，延續它們自生的視角。就像你從未看過由幾千張圖片構成的電影，你也不會看到一個氣泡平展成一幅平面圖片。
這里難處繪制氣泡的數據量要比一幅平面照片而言多得多，在60幀下要讓照片生成非線性的樣式還要面對CPU的性能限制。一開始我想用 CoreAnimation來實現，但之前做非死book 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/fdef語句。
別再拖延修補你所依賴的閉源框架
CoreData上下文變量在合并兩個上下文時會觸發數百萬的KVO通知嗎？當然不會。當你從零開始建造整個世界時，你可以僅憑蠻力和堅持不懈來解決任何Bug。對比你在IE11里發現的種種神奇老Bug，耐心等看看明年是不是還是這尿性。
而且我敢打賭，有能力的開發人員重寫自己的框架比使用別人的框架更有效率，因為你非常清楚所有的東西如何工作，只要你能建立比較好的抽象，其實只是幾千行代碼的問題。
壓榨當代硬件的變態性能
事實上每一個與屏幕連接的CPU都配有一個GPU芯片。那我們為何還要在CPU上做如此多的繪畫工作？越來越多的消費者希望得到沉浸式的體 驗，GPU在此方面可以提供高效的計算能力。你可以看看在我們的應用的最下方那個相機按鈕，你會注意到當你滑動屏幕時它會折射屏幕的其他位置.iOS 7極大地敢刪了屏幕截圖的性能，但是和一個用紋理渲染的視圖沒有什么可比性。
統一的代碼庫
不久的未來我們將不用擔心在不同的平臺上實現相同功能的困擾。如果我對Go語言不感冒，我可能會使用于前臺相同的語言，這樣做最顯而易見的好處就是可以有效控制開發隊伍的規模。
平臺大戰之后
這篇文章的觀點其實沒有什么新意可言—游戲開發人員很多年前就認可了這種這種哲學。平臺廠商們刷的小伎倆，試圖讓開發者相信用戶界面和他們所運行于 的操作系統是緊緊關聯的。不過近些年來的趨勢，你已經可以在沒有任何特殊權限的用戶控件運行不可思議的代碼量，僅僅用 POSIX和Kronos接口你就 可以得到相當多的驚喜。此外最令我興奮的是，在emscripten上有潛力能運行各種不同的平臺。如果emscripten能夠持續改善，JS會變得越 來越不重要，在某個時間點瀏覽器廠商可以選擇一個不用編譯JS的后臺置換現有平臺，我們再也不用為我們的應用適配多種瀏覽器而感到煩惱了。如果我是 Apple或者Google，我會非常關心這種哲學是否在進行之中，一個只專注于某個平臺的開發者將會失敗，這也會導致市場份額會變得更加不固定。如果我 的公司不是這樣，我會愿意傾入所有可能的資源來推行這項哲學。Alan Kay經常評論說“我們所感知到的現代軟件系統非常復雜，然而事實并非如此”，如果我們追溯過去所學重寫所有的抽象，你會得到一個大幅縮小的核心代碼。我 更傾向于他的這種看法，也非常激動想要看到由此帶來的創新。
下期再會
后面我希望拓展來講講一些在搭建一個跨平臺的UI框架時是開發更加有趣的一些關鍵抽象，和一些缺點和挑戰。再次之前，請通過@newhouseb在推ter上找到我。
原文鏈接： Ben Newhouse 翻譯： 伯樂在線 - 袁欣
譯文鏈接： http://blog.jobbole.com/61414/