2019，我在几个新的技术领域的尝试和心得

又到一年结束时，回顾这一年，我在几个新的技术领域取得了一些小小的收获，这其中，有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技术，毕竟这是一门服务器端技术。涉及到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年，请多多关照。