「反者道之動，弱者道之用。天下萬物生於有，有生於無。」，摘自《老子·道德經》。
從蘋果「熱修復門」說起近日，有關蘋果揮刀「熱修復」的新聞在iOS圈炸鍋了，一時間眾說紛紜，有人說這是蘋果反制微軟前一天發布Visual Studio 2017自帶React Native for iOS功能，有人說這是蘋果與「移動第一」Facebook巨頭之爭，也有人說當下動態技術已經猖狂地威脅到App Store審核機制云云。
不打算對這件事情本身做過多的論述，蹭蹭這個熱點，今天我們來聊聊移動技術發展歷程所經歷的種種「黑科技」。
始於PC時代2004年，為了鞏固Windows系統和Office的市場佔有率，微軟開發並維護了一套線上修複方案，用於修復漏洞及特定問題，避免延續到發版解決，著名的補丁「黑科技」技術誕生。
隨後，補丁技術在遊戲領域發揚光大。WOW（魔獸世界）作為一款網路遊戲，其Bug是必然存在的，通過補丁技術，客戶端無需頻繁升級，伺服器也無需停機，玩家正在遊戲時，通過補丁技術即可完美修復WOW客戶端存在的Bug。
嶄露頭角時間在遊走，智慧型手機開始逐步增長，移動網際網路開始萌芽。移動技術演進大致可以分成四個階段：網頁階段、Native（原生）階段、Hybrid（混合式）階段、驅動原生階段。
相信早期做過移動APP的同學還記得，App Store剛推出的時候，還是允許APP做個殼，直接連著服務端的一個網頁。後來喬老爺把這種APP給禁止了，不給上App Store，因為這種體驗實在太差了，當然本地能力也是缺失的，比如調用攝像頭。
Native APP的體驗好，缺點也明顯，不僅成本較高，更甚的是應用嚴重依賴於市場和用戶是否主動下載最新版本，推廣難度也較高。
2011年，Hybrid（混合式） 概念橫空而出。這一帶有「黑科技」性質技術思路大概這樣，採用HTML5作為UI，通過內置瀏覽器作為渲染，當需要本地能力時候，採用Native方式編寫，並提供接口給UI端調用。
由於深受Native開發成本之高、迭代周期之痛和Web APP體驗之殤，Hybrid APP 一誕生便廣受歡迎，迅速成名。毫無誇張地說，Hybrid的誕生是整個移動技術發展的裡程碑，推動了大前端技術走進移動網際網路的歷史舞臺。PhoneGap（後來改名Cordova）成為這一技術派系的傑出代表。
一路前行，亂象叢生隨著移動網際網路進入深水區，用戶對APP體驗要求到達了極致，然而Hybrid因其採用內置瀏覽器UI渲染方式，難免會影響到用戶的最佳體驗。Native動態化誠然成為移動開發領域的一大迫切需求。
最早要從Wax項目說起，還記得當年在iPhone上火爆無比的遊戲「憤怒的小鳥」嗎，它就是基於Wax框架編寫的。Wax把Lua腳本語言與原生Objective-C底層Runtime結合起來，使得你可以用Lua語言來開發iPhone應用。當年蘋果對於Lua腳本是持著支持態度的，可蘋果萬萬沒有想到的是Wax在應用開發層面並沒有火起來，反而「助攻」它成為了iOS APP熱修復開山鼻祖。
2013年，iOS 7推出了JSCore，它是原生與JS交互的橋梁，讓開發者在原生與JS之間穿梭自如。蘋果在這方面繼續扮演著「助攻」角色，JSCore推出不久，騰訊iOS開發工程師bang寫了一個熱修復框架JSPatch，通過JavaScript調用Objective-C的原生接口，從而動態植入代碼來替換舊代碼，以實現修複線上Bug。相對於Wax,JSPatch的接入成本較低，對項目影響非常小，不需要額外引入腳本（直接使用JSCore），因此它迅速成為iOS熱修復的熱門選擇。與此同時，國外的Rollout熱修平臺誕生，不同於JSPatch，Rollout提供的是簡易SDK接入方式，擁有後端管理頁面，目前並沒有開源。
移動APP原生動態化的追求遠遠不僅僅是線上Bug熱修復。
2014年，Facebook推出了React Native，大致的思路是，JavaScript開源庫React.js是實現Native的一種DSL，在運行態時候，通過下發的JS文件，Native代碼會解析UI渲染工作，而不是把UI渲染交與內置瀏覽器。它帶來的是Hybrid無法提供的完全的原生APP體驗，而又保留著Web迭代效率。同時，React Native也很好地適合跨平臺開發模式，不管Android還是iOS，各類UI都被統一封裝成可復用JS組件，APP開發會趨於簡單而快速地用JS搭積木，「Learn Once ,Write Anywhere」。
React Native這種實時於原生系統交互技術開啟了驅動原生APP時代，它完全地顛覆了蘋果或Google所引領的APP編程模式。
2015年，阿里巴巴可以說是站在巨人肩膀上，採用了類似設計思路，正式推出了Weex開源框架。不同於React Native，它基於JavaScript另外一個開源庫Vue.js實現實時原生交互。
移動APP動態化繼續深入發展，尤其是阿里巴巴基於對Android Dex分包原理的理解，借鑑了服務端OSGi規範而推出了Atlas容器化框架，更是把原生動態化技術推向高潮。
Altas的使命不再是簡單的熱修復，它是伴隨著阿里越來越多業務而導致客戶端體積快速增長而需要把客戶端化整為零、模塊自由組合等迫切需求前提下誕生的。後端的容器化設計思路被搬到移動平臺大舞臺。
移動「黑科技」遠還沒有停止下來的念頭。2017年1月，騰訊公司推出了微信小程序。筆者也花費了些時間對小程序運行機制進行了些許的剖析，簡而言之，小程序也是一種基於驅動原生表現形態，JS-Bridge作為其中的核心。作為集大成者，小程序野心更大，當然它所面臨的挑戰也更加大，很多非技術性挑戰。
技術規範迫在眉睫任何事物的高速發展，帶來好處的同時也帶來了風險。魚龍混雜的「黑科技」帶來的最大危險是安全的隱患。
蘋果一貫作風是讓所有事情可控，iOS APP生態維護得還不錯，App Store上架審核機制功不可沒。當下很多「黑科技」都或多或少的觸碰到蘋果的原則，相信Google也遇到同樣的問題，整頓移動技術規範迫在眉睫。
事物的矛盾和對立轉化是永恆不變的規律，簡單粗暴的扼殺，帶來的後果就是另外一種對立「黑科技」的誕生。作為移動領域兩大幫主，蘋果和Google需要的是更加超前的布局，引領移動技術走向規範。
規範的很重要一步就是權限分明，蘋果和Google公司需要明確iOS和Android APP本身哪些東西是不能觸碰，哪些是可以任由開發者去驅動。回頭看看移動技術這些「黑科技」，JS-Bridge和Android Dex分包通常作為口子被充分地利用。作為發布者蘋果和Google,在這上面是否可以大有所為。作為開發者，能夠利用iOS或Android自身技術滿足當下需求，何樂不為！
寫在最後移動開發領域正在深水區，當下移動技術「黑科技」比較混亂，我們通常關注的迭代周期與用戶體驗仍然是較活躍兩大話題。
筆者認為，一味地追隨「黑科技」與兩耳不聞窗外事是要不得的兩個極端。只顧自己一畝三分地已經不能成為創新時代的掌控者。盲目崇拜，拿來主義更容易成為「xx門」的受害者，很傻很天真。
擴展思路，了解背後原理，任何方案的接入，都要想好撤出方案。另外，提高代碼質量，重視代碼審計環節，熱修復的需求本不應該那麼迫切。
平和大度 探索追求！
歡迎打賞：