​       又到一年結束時，回顧這一年，我在幾個新的技術領域取得了一些小小的收穫，這其中，有App相關的，也有App領域之外的。接下來，我來談談自己的一些實踐和心得體會。

 1）《Android外掛化開發指南》的英文版出版

​      在社群一眾朋友的幫助下，我把這本書翻譯成英文，並經過幾番修改，終於由CPC Press在國外出版了，在中文版的基礎上加上了對Android O和P的外掛化支援。書的英文名是《Android App-Hook and Plug-In technology》。我不知道老外對這個技術的接受程度有多少，但總算是了卻了一樁心願，讓全世界知道Android技術在中國做的有多深入。

​      接下來，我會在微信公眾號連載這本書的中文版本。        

 2）Appium自動化測試框架

​      9月份在成都培訓Appium的時候，順手寫了一個Appium自動化測試框架。

​      自動化測試框架的宗旨在於讓測試人員通過編寫配置檔案的方式來大規模、快速產出自動化測試用例，而不需要太多的程式設計知識。

​      Appium傳統的程式設計方式是的面向過程的，為此要實現一個自動化測試用例，需要寫很多行程式碼。這對於測試人員尤其是不擅長程式設計的測試人員，是很難推行這門技術的。

​      由此而衍生出一種Page Object的設計模式。為每個頁面建立一個類，把操作預先封裝到各個頁面類中。再往前走一步，就是把操作定義在配置檔案yml中，由這個自動化測試框架來解析配置檔案。這樣的好處是，即使是不擅長編碼的測試人員，也可以遵循一些簡單的規則，通過配置檔案，迅速組織出自動化測試用例。

​      另一方面，Appium同時支援Android和iOS，但並不意味著寫一套程式碼，同時適用於Android和iOS。為此，需要在框架中做相容，消除這些不一致的地方，封裝出同一套介面，從而達到一臺程式碼，同時適用於Android和iOS。

​      Appium是一門很有趣的技術，涉及大量的App技術知識，各位從事Android或iOS的技術同學，可以考慮入手這個領域。Appium的難點在於開發環境的搭建，90%的初學者卡在了這裡，所以沒有繼續前行。對於Android和iOS開發人員而言，這都是小兒科。

​      在做Appium自動化框架的時候，陪伴我多年的Android手機掛了，不能真機測試。這時夜神模擬器進入我的視線。可以在一臺電腦上啟動多個夜神模擬器，通過埠來進行區分，也就是雙開技術。最關鍵是模擬器的速度，非常的流暢。缺點是目前只支援Android4.4、5.1和7.1這三個版本，以及只支援Windows和Mac兩個版本。         

3）聊天機器人

​      在寫完Appium自動化測試框架後，我順手寫了一個聊天機器人，仍然是藉助於Appium技術，捕獲到對方說的話，然後自動回覆訊息。

​      當時有一個難點就是，在App中捕獲到的聊天內容是圖片，如何把圖片轉換成文字？

​      再有就是這個程式的穩定性。因為要一直監聽App中的新訊息，所以程式就放在那裡。如何確保程式的穩定性，而不是一個小時後程式就崩潰了。比如說Appium會有一個timeout，超過這個值，Appium就會丟擲一個異常然後終止程式。如何避免半小時沒有收到新訊息，Appium不會因為超過了這個timeout值而掛掉。

​      另一個難點就是人工智慧。目前我寫的這個機器人還只能做到你有來言、我有去語，但是答非所問，風馬牛不相及。於是我最近又開始進入“深入學習”和“知識圖譜”這兩個領域，去尋找成熟的解決方案。希望2020年能早日解決這個問題。

4）搭建一套測試環境

​      隨著記憶體降價到白菜價，我把自己的PC本升級到32G記憶體。接下來通過VMWare，建立了十幾臺虛擬機器，分別搭建Jenkins、Nginx、Maven、Redis、MySQL、SpringMVC、Node環境，這其中大部分軟體是通過Docker來搭建的。

​      在安裝這些軟體的時候，我發現使用Docker要比直接安裝更容易一些。

​      另一方面，就是網路配置。為每臺虛擬機器同時開啟兩塊網絡卡，一個是橋接模式，動態分配IP，用於虛擬機器上外網；一塊網絡卡是NAT模式，從而和主機形成一個小型區域網，固定IP，這樣就不會因為重啟虛擬機器而導致IP改變。虛擬機器之間通過NAT模式下的固定IP相關訪問。

​      下載一個花生殼軟體。可以免費領取到兩個域名，其中一個是80埠，另一個是隨機埠。把域名指向一臺安裝了Nginx的虛擬機器的ip，由Nginx負責分發到其他虛擬機器處理外界的請求。這樣外界就可以通過這兩個域名來訪問我這個小型區域網提供的服務了。

​      Jenkins是唯一沒有通過Docker進行安裝的，因為我要經常修改其中的檔案。究其原因，還是出於對Jenkins的恐懼。這是個非常強大的持續整合工具，裡面有各種配置開關。我只完成了Node專案、Android專案、SpringMVC的持續整合。

​      考慮到每臺虛擬機器安裝的軟體以及配置都差不多，於是就做了一個虛機映象，這其中包括JDK、Docker、jq這些基礎軟體的安裝，還包括設定免密登入、把docker加入管理員組這些基本配置。一開始我只給這個虛機映象分配了10G空間，但越來越不夠用，幾次擴容後，發現15G是一個比較合適的值。

​      再後來我對映象做了優化，刪除了介面元件，這樣映象的體積就減少了很多，同時啟動速度也快了。

​      接著我把一臺虛擬機器設定為maven私服、NPM私服，甚至Docker私服，從而讓我的專案所有的外界依賴都從這臺虛擬機器獲取。

​      其實很多網際網路公司的測試環境和生成環境，都是不能之間訪問的，都需要做一臺跳板機。我們開發人員先登入到跳板機，再通過跳板機訪問測試環境或生成環境的虛機。

​      使用XShell可以同時操作多臺虛擬機器，還可以在主機和虛擬機器之間傳遞檔案。

​      這裡只是粗略總結一下搭建一套環境的步驟。很多細節，以後再詳細介紹，還有很多沒有提及的軟體，比如ELK、Grafana+Zabbix、MySQL、Redis等等。

​      對於一個測試人員而言，搭建一套測試環境是必須具備的機能。不能一直從事功能測試這種體力活兒，久而久之，會被這個行業所淘汰。        

5）Hybrid         

​      從事App研發這七八年的時間，其實有一半時間在做跨平臺和動態化技術。這幾年我一邊做培訓，一邊在系統梳理這方面的知識。         

​      首先是Hybrid。這是最老牌的跨平臺技術。經過這十年來的發展，仍然不能突破手機瀏覽器效能低劣的桎梏，但是，它仍然是絕大多數創業公司的首選。你想啊，Android和iOS只要各招1個開發人員，負責實現原生App和H5的通訊，以及日常的發版，剩下的錢就全都可以招H5開發人員了，只需要開發一套業務邏輯，這是多麼節省人力成本的模式。

​      效能問題是Hybrid永遠的痛，業內有很多首頁秒開的技術方案和框架，比如說VasSonic。

​      原生App和H5之間的互動，以及頁面相互跳轉。可以使用成熟的框架例如Cordova，或者自己寫一套，其實並不難。

​      Hybrid分兩套完全不同的技術方案：

• 方案1是直接訪問線上的H5、JS和CSS、圖片，這會導致訪問的時候比較慢，因為要下載很多資源，一般是Node+Express來提供H5的外殼，裡面的內容，用React還是vue亦或是Angular就無所謂了；

• 方案2是離線包。事先把H5、JS和CSS、圖片都打包到App中，以後有更新，再從伺服器下載新的zip包，可以是全量的zip包，也可以是增量zip包，後者體積會更小一些。 

​      對於流派1，難點主要在於：

• Node，很多前端開發人員並不能熟練掌握Node技術，畢竟這是一門伺服器端技術。涉及到Jenkins持續整合、伺服器查日誌等等。

• 此外，如果前端H5要發起一個網路請求，則需要在Node層寫一個API介面，給前端H5頁面呼叫。 

​      對於流派2，主要問題是麻煩：

• H5端的網路請求，由於跨域的問題，所以要間接使用App端的網路請求框架。順帶著，共享App端的使用者token。

• 配置增量更新，是一個很繁瑣的事情。要逐個版本去驗證，下載增量包後，是否升級成功了。

• 每次除錯程式碼，都要經歷一個漫長的過程：生成壓縮包、打包App、清空App本地快取，解壓H5壓縮包。 

​      

​      對於創業公司而言，更多的選擇方案1，因為能快速迭代試錯而人力成本極低，招人時也不需要太多的培訓成本。

6）React Native        

​      據我所知，國內的很多OTA公司，都已經把原生App改造為用ReactNative來寫的了。

​      RN從2015年誕生至今，雖然還沒有釋出一個1.0的正式版本，但是其在國內網際網路公司的受歡迎程度，已經遠非其他App技術所能企及。究其原因，是iOS jsPatch被Apple禁用，但是RN的熱更新技術卻仍然能通過Apple Store的稽核。迄今為止，也只有這個技術不受Apple的限制。

​      雖然Apple Store的稽核速度已經縮短至幾天，但是對於那種很嚴重的bug，我們還是希望能在當天修復並上線。再有就是Apple Store聖誕節假期不稽核稽核App，更恐怖的是，就算你修復了bug並提交稽核，還可能因為其他原因而稽核被拒掉。各位iOS程式設計師應該都深有體會，比如說我最長的一次稽核是一個半月。

​      RN的熱更新技術可以自己做，也可以使用外界比較成熟的解決方案。

​      另一方面，ReactNative是建立在React基礎之上的。這使得原本就熟悉React的H5開發人員，只需要學習RN中的那些標籤控制元件，就可以快速上手了。這就比從事Flutter開發還要去學習Dart要簡單的多了。

​      ReactNative還有一個尖端技術，就是拆分成多個模組，各自打包下載。這就有點Android外掛化的意思了。

​      此外，就是效能問題了。主要是白屏，以及列表頁的優化。業內有一種頁面預載入技術，比如說使用者現在A頁面，App預先把B頁面渲染出來，只是不顯示出來，從而從A頁面跳轉到B頁面，可以秒開。         

7）Flutter         

​      這是2019年最火的技術，我也花了仔細的去研究過它的打包流程、模組化、熱更新、網路請求框架等等技術。         

​      Flutter的精髓是外掛、模組和包。         

​      我在學習研究Flutter的時候，嘗試了網路框架封裝的兩種方式，一種是使用Flutter自身的網路框架，另一種是複用App原生的已有網路框架。我的感受是，如果是一款App完全用Flutter，那麼用第一種方式；如果在已有App上嘗試把幾個模組用Flutter來寫，那麼採用第二種方式。         

​      我還嘗試過模組化拆分。按照酒店機票火車票多個模組的方式，把一個Flutter專案拆分成多個Plugin或Package（二者的區別在於要不要與原生App進行互動）。         

​      我也去嘗試過Flutter的熱更新技術。官方並沒有支援這個技術。但是在Android系統上，可以通過暴力替換的方式，把Flutter功能替換成新版本，來實現熱更新技術。對於iOS，則不具備這個能力。別看缺了這麼個小功能，在國內，這可是至關重要的。      

​      看了很多關於Flutter的技術文章，說到Flutter的渲染速度要比原生App快。但這個優點還遠不足以讓各個一二線網際網路公司、軟體公司把App改造為Flutter。App線上出了bug，能快速修復，才是關鍵。所以在國內，不具備熱修復能力，Flutter很難繼續走得更遠。

8）區塊鏈         

​      年底區塊鏈技術又火了起來。恰好我在2018年做過這個技術，基於Fabric，搭建過一個社群買藥的區塊鏈平臺。十二月的時候，我又把這個技術拾了起來。通過前面搭建的14臺虛擬機器，搭建了一套Fabric區塊鏈系統，包括4臺節點伺服器，3臺排序伺服器，3臺ZooKeeper，4臺Kafka。

​      區塊鏈技術大致分為Fabric和以太坊。我做的是Fabric技術。Fabric是一個龐然大物，學習這門技術，需要具備以下的基礎知識：

• Docker，尤其是Docker Compose。

• Shell指令碼編寫能力。

• nodejs或Java，用於使用Fabric SDK。

• 比特幣和區塊鏈的基礎概念和術語。

​      在此基礎上，就可以從搭建區塊鏈環境入手了。Fabric有很多版本，書籍多針對於1.1，網上文章，則從1.0到1.4各種版本都有。建議從1.1入手，版本迭代對搭建環境影響不大。在1.1的基礎上，再看1.2，1.3，1.4甚至2.0都很容易。         

​      Fabric分為兩個大方向：         

​      方向1：在Fabric上做業務，用GO語言寫智慧合約，以及基於Java或Node的SDK，編寫前端業務邏輯。         

​      方向2：研究Fabric底層實現，包括CA，背書，演算法，安全，對其進行功能上的擴充套件，完善對外提供的SDK，包括區塊鏈瀏覽器等等。         

​      以上就是2019年我的一點收穫。對於我而言，很多都是全新的領域，如果文中的某些觀點有錯誤，還請多多包涵多多指正，接下來，我會持續更新我的公眾號，依次介紹本文所涉及的這些技術，包括：

​      1.        DevOps：從零搭建一套測試環境

​      2.       基於Appium搭建自動化測試框架

​      3.       Android外掛化技術

​      4.       Hybrid技術

​      5.       React Native技術

​      6.       Flutter技術

​      7.       Fabric區塊鏈技術 

​      敬請期待。
​      2020年，請多多關照。