又到一年結束時，回顧這一年，我在幾個新的技術領域取得了一些小小的收獲，這其中，有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年，請多多關照。