2015年，是移動領域新技術取得極大豐收的一年。

iOS篇

2015年，iOS有太多的事情發生，每一次事件都促進了iOS技術的一次飛躍。

---

首先是蘋果宣佈從2015年2月1日開始，全部上傳至App Store官方商店的新iOS應用都必須支持64位。爲此，全部的App在打包時要兼容32位和64位，雖然某些機型上速度快了很多，可是App的體積卻大了很多。 
2015年應該是iOS的「瘦身年」。各大公司在發現本身的iOS App超過了50M以後，紛紛開始組織iOS團隊對App進行減肥，而後咱們就會發現，體積變大，不光是兼容64位致使的，兼容64位只會致使.a文件的增長，而資源文件是致使體積變大的另外一個因素。 
先說資源文件，包括如下幾點：

• 減小圖片和音頻文件的大小（這一點攜程的App作的不錯，每一個圖片都不超過100k，甚至50-100k之間的圖片都不多，而不少App之因此體積大，是由於其中有不少1M以上的圖片）。
• 對於PNG圖片，因爲它內部保存了額外的分層和透明通道信息，統稱爲EXIF，因此它會比JPG圖片大一些。App開發推薦使用PNG圖片是由於XCode會在打包時壓縮PNG圖片的大小。咱們能夠寫一個腳本，在打包前，把PNG圖片中這些多餘的信息，刪除掉。
• 單色圖片使用使用字體文件。關於字體文件的技術，也就是IconFont，網上有不少例子，同時適用於Andorid和iOS，我這裏就很少說了。
• 使用.9圖。之所周知.9圖是Android的技術，能極大減少圖片的體積，卻不知，iOS也有相似的實現方式。
• 動態下載表情包。把聊天時用到的表情圖片，作成從服務器下載zip包的方式，而不是打包在App中。
• 清除再也不使用的圖片。每次迭代作新需求，都會致使一些舊圖片再也不使用了。XCode不提供檢查未使用圖片的功能，那咱們就須要本身寫一個腳本，每次發版前，對整個工程檢查一次。

再說.a文件。.a文件是編譯文件，這個文件大，說明代碼多。因而咱們檢查項目中的代碼，真的要寫那麼多行嗎？其實有不少優化的空間。

• 冗餘的類和方法。這些冗餘仍然是由於作新需求致使的，忘記刪除不用的類和方法，須要寫腳本查找，按期刪除。
• 類似度極高的代碼片斷。初級程序員在寫代碼時，喜歡把一段代碼從A類粘貼到B類中，而後修改其中的幾個變量名稱，這個功能就算作完了。因而兩段類似度極高的代碼就產生了。 
  稍微懂得些面向對象思想的人，都知道這時候須要把這樣的代碼抽象出來，好比說在Utils類中新建一個方法，而後要用到這段邏輯的人調用Utils類的這個方法便可。 
  但並非全部的程序員都有這樣的境界，即便是有幾年經驗的人，也會由於急着下班二人世界或者給孩子換尿布而採用複製粘貼大法敷衍了事。長此以往，冗餘代碼就多了，包的體積天然就大了。爲此，咱們須要有一個檢查代碼類似度的工具。在iOS領域，我推薦Simian這個工具。有興趣的讀者能夠嘗試一下，對大家的項目使用一下這個工具，看能找出來多少類似的代碼來
• 使用代碼生成UI，而不是使用Xib或Storyboard。通過測試，對於同一個頁面，使用代碼而致使的.a文件增長的體積，大於Xib的體積。是時候該返璞歸真，考慮使用Xib來佈局了。Xib之因此廣受詬病，是由於XCode這個IDE工具很爛，另外一個緣由是咱們使用的少，人老是會抵觸陌生的事物，在使用Xib的過程當中遇到障礙了，就又轉到寫代碼的路線了。
• 使用Hybird方案來代替iOS原生代碼。我作過嘗試，一個功能模塊，致使.a文件增長3M，但使用Hybird卻只有1-2M的樣子，並且這1-2M中有一部分打包放在App中，另外一部分則作成增量下載，從而從總體上減小App包的大小。其中Hybird的增量包技術是關鍵。
• 編譯選項的優化。好比說Strip Link Product設爲Yes啊，Make Strings Read-Only設爲Yes啊，去掉異常支持啊，都能減小包的大小。此外，常常檢查LinkMap文件，也是控制瘦身的一個辦法。

微信團隊2015年9月中旬發佈了iOS微信安裝包的瘦身經驗，其中有不少實際經驗。文章地址以下： 
http://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=207986417&idx=1&sn=77ea7d8e4f8ab7b59111e78c86ccfe66&3rd=MzA3MDU4NTYzMw==&scene=6#rd

---

其次是春節期間，某款知名App的後門泄露事件。所謂後門，就是App開發期間，方便開發人員和測試人員的一些功能，好比說： 
開發人員和測試人員能夠隨意切換到任意服務器（線上環境、測試環境）進行開發測試工做。傳統的作法，這些地址是寫死的，每次打包出來的App只能在固定的一個環境下運行，咱們迫切須要一個後門頁面，可以靈活配置。固然，線上用戶是不能看到這個後門的，必須作一個相似於彩蛋的功能，好比在設置頁的某個位置連續點100次，纔會彈出一個密碼輸入框，只有輸入正確了，才能進入後門頁面配置服務器地址。 
考慮到發佈到線上的App，存在這樣的彩蛋是很是危險的。因而咱們須要一個Flag標記，在發佈App時要把這個值設置爲false，從而關閉後門入口。但人老是會犯錯誤的，即便有測試團隊把關也仍是會有紕漏。因而，國內某款著名的App在春節期間就把這樣的後門漏出來了，也許是開發或測試人員急着回家過年。這是此次無意之失，讓咱們領略了這款App強大的後門裏隱藏的功能。好比說，

• 服務器切換功能（上午已經介紹過）。
• 記錄App的崩潰信息。有這樣一種場景，測試人員在測試過程當中發現的一個崩潰，雖然也記錄在Bug倉庫中了，可是等開發人員去修復的時候，卻難以再現這個崩潰了。若是能把崩潰記錄到App本地，那麼測試同窗提bug的時候，就能夠把崩潰信息一塊兒貼出來。
• 提供一個後門頁面供Html5團隊進行調試，該頁面內置一個WebView，加載Html5團隊正在開發的Html頁面，要支持調試。
• 對App進行流量測試，統計某個頁面所花費的流量，包括調用MobileAPI、下載圖片、上傳文件、XMPP聊天等等。其中，從App啓動到首頁加載完成所花費的流量是咱們關心的一個關鍵點，而手機待機時，App所花費的流量也是咱們所關心的。咱們須要這樣一個後門頁面，看到這些數據統計。
• 對App進行電池電量消耗測試。須要有個後門頁面記錄每次打開App和退出App的時間，以及這段時間內咱們的App所消耗的電量。爲了確保數據的準確性，須要確保手機上只安裝了一個App，並且處於相同的網絡環境下，好比3G。
• 測試某個頁面請求了哪些MobileAPI接口，打印出調用這些接口時輸入的參數和返回JSON數據。這樣就可以在線上App發現某個頁面有問題時，及時在App後門中檢查數據是否正常，而不用App開發人員和MobileAPI開發人員坐在一塊兒逐行聯調代碼，極大的節省了人力。

在窺探到後門中這許多先進技術以後，各家無線團隊紛紛在本身的App中增長相似的功能，只是不知道最初把後門漏出來的那個哥們離職了沒有？

---

2015年最犀利的技術首推JSPatch，使用這門技術，iOS能夠快速修復線上bug而不須要從新提交AppStore審覈。 
這門技術最先起源於大衆點評的屠毅敏的一個開源項目WaxPatch。它是經過重寫runtime的class_replaceMethod方法，從而能夠修改任何一個類的任何一個方法，該項目的GitHub地址爲：https://github.com/mmin18/WaxPatch 
WaxPatch上支持的語言爲Lua，也就是說，創建了一套Objective C和Lua語言之間大部分語法的映射關係，咱們只要熟記這些轉換語法，就能快速把一個Objective C方法翻譯爲Lua方法。而後咱們把須要修改的Lua方法所在的類文件打包成zip，由App在啓動的時候下載zip包並解壓到本地目錄，因而咱們會看到，當運行到舊的Objective C方法時，實際執行的是下載到的Lua方法。這一切都由於Objective是一門動態語言，咱們能夠基於此製造一些「黑魔法」。 
可是WaxPatch從2013年10月起就再也不更新了。當2015年2月蘋果宣佈全部上傳至App Store官方商店的新iOS應用都必須支持64位，這時咱們發現WaxPatch並不支持64位。這就間接致使了不少已經在項目中使用了WaxPatch的App，必須砍掉WaxPatch熱修復功能，後來社區有人給出了WaxPatch的64位解決方案，才讓熱修復技術能繼續向前發展，這個項目的的GitHub地址爲：https://github.com/maxfong/WaxPatch_X64/commits/master 
儘管如此，WaxPatch仍是有不少侷限性。好比說它不支持多線程、不支持Block，不支持結構體和結構體指針這兩個類型，這就致使了當咱們在程序中使用了這些語法時，是沒有機會把這些語法轉換爲Lua代碼的。 
經過上文的分析，咱們知道，只要重寫runtime的class_replaceMethod方法，就能夠熱修復Objective C中的任何類的任何方法，WaxPatch只不過使用了Lua做爲新方法的語言載體，咱們徹底可使用Python、JavaScript這樣的腳本再寫出一個新的Patch。 
這時終於輪到JSPatch登場了，它是由騰訊的陳振焯（英文名Bang）於2015年5月編寫的開源項目，從名字就能猜出來，它使用的是JavaScript語言做爲新方法的語言載體，GitHub地址爲：https://github.com/bang590/JSPatch。這個項目解決了上述WaxPatch所不支持的那些語法。目前這個項目還在每週持續更新中。 
JSPatch還有一個亮眼的功能，就是支持一鍵生成，把一個Objective C方法翻譯爲JavaScript的方法。按照這個思路再往前走一步，就是iOS的「插件化編程」。咱們能夠把一個模塊所涉及的全部頁面都使用Objective C先實現了，而後一鍵生成JavaScript方法代碼，打包成一個zip包，這就是插件化編程。不得不說的是，對大量的代碼執行反射操做，性能是一個問題，究竟能往前走多遠，2016年，咱們拭目以待。

---

2015年註定是iOS領域不平凡的一年，好比說，在9月份大規模爆發的XCodeGhost病毒。IDE也能攜帶病毒，這是我一個.NET出身、用慣了Visual Studio的程序員所不可理解的一件事。只要是非官方下載的XCode，都有可能經過CoreService庫文件進行感染，使用有毒XCode開發的App，都會感染病毒。這就像給病人動手術，結果手術刀沒消毒，病人就會有生命危險。 
關鍵是AppStore還沒法檢測出病毒，傳聞將近800款App感染了這一病毒。 
儘管過後當即有人站出來，聲明本身是XCodeGhost的做者，並宣稱是個「苦X程序員的」、「無害的」、「實驗」，同時認可本身出於私心，在代碼里加入了廣告功能，並說本身在10天前，已主動關閉服務器，並刪除全部數據。 
但不少證據代表，這是一個蓄謀已久的惡性事件。 
當號稱「封閉安全」的AppStore也再也不安全，咱們還能相信誰？

---

接下來介紹React Native。這是Facebook在React.js Conf 2015 大會上推出了基於JavaScript的開源框架。同時支持iOS和Android，Github地址爲： 
http://facebook.github.io/react-native/ 
首先，React Native不是依賴於WebView的，因此它不是Hybird。React Native是把js翻譯爲Objective-C，卻是與JSPatch有些淵源 
我一直在關注着這門技術的發展。但目前看起來，還很不成熟。儘管在2015年的各類技術大會上，React Native出盡了風頭，但據我所示，目前也就BAT這種公司願意燒錢讓團隊去嘗試使用。 
有關React Native的更詳細介紹，推薦你們看下面這兩篇文章：

• 我對 React Native 的理解和見解：http://div.io/topic/851?utm_source=tuicool&utm_medium=referral
• React Native概述：背景、規劃和風險：https://github.com/tmallfe/tmallfe.github.io/issues/18

---

2015年iOS的最後一件「振奮人心」的事情是Swift的開源。 
Swift從面世伊始，就號稱要取代Obejctive C成爲新的iOS開發語言，可是幾年事後卻仍是一個很小衆的語言。沒據說有哪家大公司的代碼全都切換到Swift了。也許是我孤陋寡聞了，至少在App應用領域是這樣。 
從2015年12月初Swift開源，截止到本文寫做期間，這個項目的Watch（郵件提醒）爲148四、Star爲22569，Fork爲2652，火得一塌糊塗。可是熱鬧事後，又會有多少人真正關注？蘋果官方給出了開源後的諸多好處和美妙的前瞻，這不過是官方的PR稿子，這不禁得讓我想起了.NET當初開源，也是叫好聲一片，但實際效果並不理想，參見如下報道：

做爲有着十多年編程經驗的碼農，我不能潑太多冷水。我不想澆滅剛入行的小朋友的社區熱情。究竟Swift開源後能產生什麼驚天地泣鬼神的做用，2016年，請用事實驗證吧。