? 又到一年結(jié)束時，回顧這一年，我在幾個新的技術(shù)領(lǐng)域取得了一些小小的收獲，這其中，有App相關(guān)的，也有App領(lǐng)域之外的。接下來，我來談?wù)勛约旱囊恍嵺`和心得體會。

1）《Android插件化開發(fā)指南》的英文版出版
? 在社區(qū)一眾朋友的幫助下，我把這本書翻譯成英文，并經(jīng)過幾番修改，終于由CPC Press在國外出版了，在中文版的基礎(chǔ)上加上了對Android O和P的插件化支持。書的英文名是《Android App-Hook and Plug-In technology》。我不知道老外對這個技術(shù)的接受程度有多少，但總算是了卻了一樁心愿，讓全世界知道Android技術(shù)在中國做的有多深入。
? 接下來，我會在微信公眾號連載這本書的中文版本。

2）Appium自動化測試框架
? 9月份在成都培訓(xùn)Appium的時候，順手寫了一個Appium自動化測試框架。
? 自動化測試框架的宗旨在于讓測試人員通過編寫配置文件的方式來大規(guī)模、快速產(chǎn)出自動化測試用例，而不需要太多的編程知識。
? Appium傳統(tǒng)的編程方式是的面向過程的，為此要實現(xiàn)一個自動化測試用例，需要寫很多行代碼。這對于測試人員尤其是不擅長編程的測試人員，是很難推行這門技術(shù)的。
? 由此而衍生出一種Page Object的設(shè)計模式。為每個頁面建立一個類，把操作預(yù)先封裝到各個頁面類中。再往前走一步，就是把操作定義在配置文件yml中，由這個自動化測試框架來解析配置文件。這樣的好處是，即使是不擅長編碼的測試人員，也可以遵循一些簡單的規(guī)則，通過配置文件，迅速組織出自動化測試用例。
? 另一方面，Appium同時支持Android和iOS，但并不意味著寫一套代碼，同時適用于Android和iOS。為此，需要在框架中做兼容，消除這些不一致的地方，封裝出同一套接口，從而達(dá)到一臺代碼，同時適用于Android和iOS。
? Appium是一門很有趣的技術(shù)，涉及大量的App技術(shù)知識，各位從事Android或iOS的技術(shù)同學(xué)，可以考慮入手這個領(lǐng)域。Appium的難點在于開發(fā)環(huán)境的搭建，90%的初學(xué)者卡在了這里，所以沒有繼續(xù)前行。對于Android和iOS開發(fā)人員而言，這都是小兒科。
? 在做Appium自動化框架的時候，陪伴我多年的Android手機掛了，不能真機測試。這時夜神模擬器進(jìn)入我的視線。可以在一臺電腦上啟動多個夜神模擬器，通過端口來進(jìn)行區(qū)分，也就是雙開技術(shù)。最關(guān)鍵是模擬器的速度，非常的流暢。缺點是目前只支持Android4.4、5.1和7.1這三個版本，以及只支持Windows和Mac兩個版本。

3）聊天機器人
? 在寫完Appium自動化測試框架后，我順手寫了一個聊天機器人，仍然是借助于Appium技術(shù)，捕獲到對方說的話，然后自動回復(fù)消息。
? 當(dāng)時有一個難點就是，在App中捕獲到的聊天內(nèi)容是圖片，如何把圖片轉(zhuǎn)換成文字？
? 再有就是這個程序的穩(wěn)定性。因為要一直監(jiān)聽App中的新消息，所以程序就放在那里。如何確保程序的穩(wěn)定性，而不是一個小時后程序就崩潰了。比如說Appium會有一個timeout，超過這個值，Appium就會拋出一個異常然后終止程序。如何避免半小時沒有收到新消息，Appium不會因為超過了這個timeout值而掛掉。
? 另一個難點就是人工智能。目前我寫的這個機器人還只能做到你有來言、我有去語，但是答非所問，風(fēng)馬牛不相及。于是我最近又開始進(jìn)入“深入學(xué)習(xí)”和“知識圖譜”這兩個領(lǐng)域，去尋找成熟的解決方案。希望2020年能早日解決這個問題。

4）搭建一套測試環(huán)境
? 隨著內(nèi)存降價到白菜價，我把自己的PC本升級到32G內(nèi)存。接下來通過VMWare，創(chuàng)建了十幾臺虛擬機，分別搭建Jenkins、Nginx、Maven、Redis、MySQL、SpringMVC、Node環(huán)境，這其中大部分軟件是通過Docker來搭建的。
? 在安裝這些軟件的時候，我發(fā)現(xiàn)使用Docker要比直接安裝更容易一些。
? 另一方面，就是網(wǎng)絡(luò)配置。為每臺虛擬機同時開啟兩塊網(wǎng)卡，一個是橋接模式，動態(tài)分配IP，用于虛擬機上外網(wǎng)；一塊網(wǎng)卡是NAT模式，從而和主機形成一個小型局域網(wǎng)，固定IP，這樣就不會因為重啟虛擬機而導(dǎo)致IP改變。虛擬機之間通過NAT模式下的固定IP相關(guān)訪問。
? 下載一個花生殼軟件?？梢悦赓M領(lǐng)取到兩個域名，其中一個是80端口，另一個是隨機端口。把域名指向一臺安裝了Nginx的虛擬機的ip，由Nginx負(fù)責(zé)分發(fā)到其他虛擬機處理外界的請求。這樣外界就可以通過這兩個域名來訪問我這個小型局域網(wǎng)提供的服務(wù)了。
? Jenkins是唯一沒有通過Docker進(jìn)行安裝的，因為我要經(jīng)常修改其中的文件。究其原因，還是出于對Jenkins的恐懼。這是個非常強大的持續(xù)集成工具，里面有各種配置開關(guān)。我只完成了Node項目、Android項目、SpringMVC的持續(xù)集成。
? 考慮到每臺虛擬機安裝的軟件以及配置都差不多，于是就做了一個虛機鏡像，這其中包括JDK、Docker、jq這些基礎(chǔ)軟件的安裝，還包括設(shè)置免密登錄、把docker加入管理員組這些基本配置。一開始我只給這個虛機鏡像分配了10G空間，但越來越不夠用，幾次擴容后，發(fā)現(xiàn)15G是一個比較合適的值。
? 再后來我對鏡像做了優(yōu)化，刪除了界面組件，這樣鏡像的體積就減少了很多，同時啟動速度也快了。
? 接著我把一臺虛擬機設(shè)置為maven私服、NPM私服，甚至Docker私服，從而讓我的項目所有的外界依賴都從這臺虛擬機獲取。
? 其實很多互聯(lián)網(wǎng)公司的測試環(huán)境和生成環(huán)境，都是不能之間訪問的，都需要做一臺跳板機。我們開發(fā)人員先登錄到跳板機，再通過跳板機訪問測試環(huán)境或生成環(huán)境的虛機。
? 使用XShell可以同時操作多臺虛擬機，還可以在主機和虛擬機之間傳遞文件。
? 這里只是粗略總結(jié)一下搭建一套環(huán)境的步驟。很多細(xì)節(jié)，以后再詳細(xì)介紹，還有很多沒有提及的軟件，比如ELK、Grafana+Zabbix、MySQL、Redis等等。
? 對于一個測試人員而言，搭建一套測試環(huán)境是必須具備的機能。不能一直從事功能測試這種體力活兒，久而久之，會被這個行業(yè)所淘汰。

5）Hybrid
? 從事App研發(fā)這七八年的時間，其實有一半時間在做跨平臺和動態(tài)化技術(shù)。這幾年我一邊做培訓(xùn)，一邊在系統(tǒng)梳理這方面的知識。
? 首先是Hybrid。這是最老牌的跨平臺技術(shù)。經(jīng)過這十年來的發(fā)展，仍然不能突破手機瀏覽器性能低劣的桎梏，但是，它仍然是絕大多數(shù)創(chuàng)業(yè)公司的首選。你想啊，Android和iOS只要各招1個開發(fā)人員，負(fù)責(zé)實現(xiàn)原生App和H5的通信，以及日常的發(fā)版，剩下的錢就全都可以招H5開發(fā)人員了，只需要開發(fā)一套業(yè)務(wù)邏輯，這是多么節(jié)省人力成本的模式。
? 性能問題是Hybrid永遠(yuǎn)的痛，業(yè)內(nèi)有很多首頁秒開的技術(shù)方案和框架，比如說VasSonic。
? 原生App和H5之間的交互，以及頁面相互跳轉(zhuǎn)?？梢允褂贸墒斓目蚣芾鏑ordova，或者自己寫一套，其實并不難。
? Hybrid分兩套完全不同的技術(shù)方案：
? 方案1是直接訪問線上的H5、JS和CSS、圖片，這會導(dǎo)致訪問的時候比較慢，因為要下載很多資源，一般是Node+Express來提供H5的外殼，里面的內(nèi)容，用React還是vue亦或是Angular就無所謂了；
? 方案2是離線包。事先把H5、JS和CSS、圖片都打包到App中，以后有更新，再從服務(wù)器下載新的zip包，可以是全量的zip包，也可以是增量zip包，后者體積會更小一些。

? 對于流派1，難點主要在于：
很多前端開發(fā)人員并不能熟練掌握Node技術(shù)，畢竟這是一門服務(wù)器端技術(shù)。涉及到Jenkins持續(xù)集成、服務(wù)器查日志等等。
此外，如果前端H5要發(fā)起一個網(wǎng)絡(luò)請求，則需要在Node層寫一個API接口，給前端H5頁面調(diào)用。

? 對于流派2，主要問題是麻煩：
首先， H5端的網(wǎng)絡(luò)請求，由于跨域的問題，所以要間接使用App端的網(wǎng)絡(luò)請求框架。順帶著，共享App端的用戶token。
其次，配置增量更新，是一個很繁瑣的事情。要逐個版本去驗證，下載增量包后，是否升級成功了。
再次，每次調(diào)試代碼，都要經(jīng)歷一個漫長的過程：生成壓縮包、打包App、清空App本地緩存，解壓H5壓縮包。

? 對于創(chuàng)業(yè)公司而言，更多的選擇方案1，因為能快速迭代試錯而人力成本極低，招人時也不需要太多的培訓(xùn)成本。

6）React Native

? 據(jù)我所知，國內(nèi)的很多OTA公司，都已經(jīng)把原生App改造為用ReactNative來寫的了。
? RN從2015年誕生至今，雖然還沒有發(fā)布一個1.0的正式版本，但是其在國內(nèi)互聯(lián)網(wǎng)公司的受歡迎程度，已經(jīng)遠(yuǎn)非其他App技術(shù)所能企及。究其原因，是iOS jsPatch被Apple禁用，但是RN的熱更新技術(shù)卻仍然能通過Apple Store的審核。迄今為止，也只有這個技術(shù)不受Apple的限制。
? 雖然Apple Store的審核速度已經(jīng)縮短至幾天，但是對于那種很嚴(yán)重的bug，我們還是希望能在當(dāng)天修復(fù)并上線。再有就是Apple Store圣誕節(jié)假期不審核審核App，更恐怖的是，就算你修復(fù)了bug并提交審核，還可能因為其他原因而審核被拒掉。各位iOS程序員應(yīng)該都深有體會，比如說我最長的一次審核是一個半月。
? RN的熱更新技術(shù)可以自己做，也可以使用外界比較成熟的解決方案。
? 另一方面，ReactNative是建立在React基礎(chǔ)之上的。這使得原本就熟悉React的H5開發(fā)人員，只需要學(xué)習(xí)RN中的那些標(biāo)簽控件，就可以快速上手了。這就比從事Flutter開發(fā)還要去學(xué)習(xí)Dart要簡單的多了。
? ReactNative還有一個尖端技術(shù)，就是拆分成多個模塊，各自打包下載。這就有點Android插件化的意思了。
? 此外，就是性能問題了。主要是白屏，以及列表頁的優(yōu)化。業(yè)內(nèi)有一種頁面預(yù)加載技術(shù)，比如說用戶現(xiàn)在A頁面，App預(yù)先把B頁面渲染出來，只是不顯示出來，從而從A頁面跳轉(zhuǎn)到B頁面，可以秒開。

7）Flutter
? 這是2019年最火的技術(shù)，我也花了仔細(xì)的去研究過它的打包流程、模塊化、熱更新、網(wǎng)絡(luò)請求框架等等技術(shù)。
? Flutter的精髓是插件、模塊和包。
? 我在學(xué)習(xí)研究Flutter的時候，嘗試了網(wǎng)絡(luò)框架封裝的兩種方式，一種是使用Flutter自身的網(wǎng)絡(luò)框架，另一種是復(fù)用App原生的已有網(wǎng)絡(luò)框架。我的感受是，如果是一款A(yù)pp完全用Flutter，那么用第一種方式；如果在已有App上嘗試把幾個模塊用Flutter來寫，那么采用第二種方式。
? 我還嘗試過模塊化拆分。按照酒店機票火車票多個模塊的方式，把一個Flutter項目拆分成多個Plugin或Package（二者的區(qū)別在于要不要與原生App進(jìn)行交互）。
? 我也去嘗試過Flutter的熱更新技術(shù)。官方并沒有支持這個技術(shù)。但是在Android系統(tǒng)上，可以通過暴力替換的方式，把Flutter功能替換成新版本，來實現(xiàn)熱更新技術(shù)。對于iOS，則不具備這個能力。別看缺了這么個小功能，在國內(nèi)，這可是至關(guān)重要的。
? 看了很多關(guān)于Flutter的技術(shù)文章，說到Flutter的渲染速度要比原生App快。但這個優(yōu)點還遠(yuǎn)不足以讓各個一二線互聯(lián)網(wǎng)公司、軟件公司把App改造為Flutter。App線上出了bug，能快速修復(fù)，才是關(guān)鍵。所以在國內(nèi)，不具備熱修復(fù)能力，F(xiàn)lutter很難繼續(xù)走得更遠(yuǎn)。

8）區(qū)塊鏈
? 年底區(qū)塊鏈技術(shù)又火了起來。恰好我在2018年做過這個技術(shù)，基于Fabric，搭建過一個社區(qū)買藥的區(qū)塊鏈平臺。十二月的時候，我又把這個技術(shù)拾了起來。通過前面搭建的14臺虛擬機，搭建了一套Fabric區(qū)塊鏈系統(tǒng)，包括4臺節(jié)點服務(wù)器，3臺排序服務(wù)器，3臺ZooKeeper，4臺Kafka。
? 區(qū)塊鏈技術(shù)大致分為Fabric和以太坊。我做的是Fabric技術(shù)。Fabric是一個龐然大物，學(xué)習(xí)這門技術(shù)，需要具備以下的基礎(chǔ)知識：
Docker，尤其是Docker Compose。
Shell腳本編寫能力。
nodejs或Java，用于使用Fabric SDK。
比特幣和區(qū)塊鏈的基礎(chǔ)概念和術(shù)語。

? 在此基礎(chǔ)上，就可以從搭建區(qū)塊鏈環(huán)境入手了。Fabric有很多版本，書籍多針對于1.1，網(wǎng)上文章，則從1.0到1.4各種版本都有。建議從1.1入手，版本迭代對搭建環(huán)境影響不大。在1.1的基礎(chǔ)上，再看1.2，1.3，1.4甚至2.0都很容易。
? Fabric分為兩個大方向：
? 方向1：在Fabric上做業(yè)務(wù)，用GO語言寫智能合約，以及基于Java或Node的SDK，編寫前端業(yè)務(wù)邏輯。
? 方向2：研究Fabric底層實現(xiàn)，包括CA，背書，算法，安全，對其進(jìn)行功能上的擴展，完善對外提供的SDK，包括區(qū)塊鏈瀏覽器等等。

? 以上就是2019年我的一點收獲。對于我而言，很多都是全新的領(lǐng)域，如果文中的某些觀點有錯誤，還請多多包涵多多指正，接下來，我會持續(xù)更新我的公眾號，依次介紹本文所涉及的這些技術(shù)，包括：
? 1. DevOps：從零搭建一套測試環(huán)境
? 2. 基于Appium搭建自動化測試框架
? 3. Android插件化技術(shù)
? 4. Hybrid技術(shù)
? 5. React Native技術(shù)
? 6. Flutter技術(shù)
? 7. Fabric區(qū)塊鏈技術(shù)

? 敬請期待。
? 2020年，請多多關(guān)照。