测试上遇到的困扰
测试一直是软件开发中重要的一环，在“软件测试杂谈”中，提到了一些测试相关的概念，更多深入的文章请参阅简书。Android 的开发里，AVD 则是测试不可或缺的一部份。透过 AVD 可以不用准备大量的实体设备，就可以让所开发的 App 在不同的环境中检视其运作的情况。
使用 Notebook 进行 Android 开发的人，通常都会遇到一个困扰是：Notebook 的磁盘空间大多不是很充裕。在开发 Android App 时，常常要使用多个 AVD，来测试 App 在不同的环境下都可以正常地运作，毕竟 Android 的平台碎片化已经是一种特色了。
然而在空间有限的情况下，建一个 AVD 就要上 Giga 的空间，这还不包含不同版本的 Image 文件。每一个版本还有分 32bit、64 bit，有 Google API、没有 Google API，再加上 TV 和 Wear 这二种设备种类。林林总总的 Image 加起来，配上 AVD 可能要产生出不同画面尺寸的组合，对于有限的磁盘空间来说更是捉襟见肘。
如果要扩充 Notebook 的存储空间，除了价格上的因素以外，往往还会受限于 Notebook 硬体架构上的局限性。就这个缺点来说，PC 相对是一个比较好的选项。但是改为使用 PC 开发，就会失去了原本 Notebook 具备的机动性。想要二者优点兼具，替代性的选项是在二台机器间进行 Source Code 同步，需要机动性就在 Notebook 上开发，需要空间时就转移到 PC 上开发。
这个选项对大型公司而言，是一个再直接不过的选项，因为公司内通常都会有一定程度的版本控管系统在协助，文件移转的负担比较小，甚至更豪华的有专用 Lab 环境。反过来说，不在这样体制内的人，只能苦命地手动将 Source Code 反覆传来传去，费工又容易出错。
对于这样的族群来说，需要将选项的内容再进化，也就是开发仍在 Notebook 上保持机动性，同时选择关键的环境来建立 AVD，做基本的确认。而 PC 上则是可以广泛地建立不同选项的 AVD，要进行测试时就将二个环境结合起来，将 Notebook 建置好的结果传送到 PC 上执行测试。
所以现在的问题是，这样的要求做得到吗？要怎么做？
可行的方案
首先，先来了解负责管理受测装置的工具 - ADB 的运作原理，这个工具包含了三个部份 Client、Daemon、Server：
- Client: 负责接收我们输入的指令，并且传送给所连接的 Server，一般就是我们在 Command-line 使用的
adb指令。 - Daemon: 驻扎在移动装置上，可以是实体设备或是 AVD，负责在装置上执行由 Server 传来的指令。
- Server: 在计算机上执行，负责管理 Client 与 Daemon 之间的讯息传递。
从上图来看，可行的方案有三个：第一个是透过 Server 转送讯息给 Daemon，第二个是让 Client 连接到远程的 Server，第三个方案则是让 Server 连到远程的 Daemon。
第一个方案是使用 adb forward 的指令，让 Daemon 可以收到所处 PC 向 127.0.0.1 发出的讯息，并转给 AVD 指定的 Port。这个动作最直接的效果，是让所在的 PC 可以不用透过 Console，直接与 AVD 中的 Service 进行沟通。但似乎与跨机器无关，所以先略过。
第二个方案要达成不难，在 adb 的指令中有参数分别是 -H 及 -P 可以指定 Server 的 Address 及 Port。例如以下的指令可以列出 192.168.1.1 计算机上，ADB Server 所管理的装置清单。
adb devices -H 192.168.1.1 -P 5038
但有一个很关键的问题是，如何设定让 Android Studio 使用远程的 ADB Server 来进行部署及测试？IDE 和 Gradle 我都没有找到答案，也许是这样的选项还不存在吧！会有这个结果，最主要的问题应该是卡在如何让远程的 ADB Server 拿到生成好的结果，以传送进 AVD 内。
不过，倒是可以使用以下演示的指令来启动远程ADB Server 的测试，只不过连部署的工作都要在生成完成后，用 adb 自己动手。
adb shell am instrument -w <test_package_name>/<runner_class> -H 192.168.1.1 -P 5038
方案三，也是可以用 adb 的指令来达成，以下的指令可以让 ABD Server 连接到 192.168.1.1 计算机上的 AVD。
adb connect 192.168.1.1:3333
连上之后，就可以在 IDE 的 “Select Deployment Target” 的窗口中，看到远程的 AVD 被列在 “Connected Devices” 清单中。接下来的动作就跟过往一样，选择远程 AVD 的项目后，按下【OK】，等生成完成就可以看到 App 出现在远程 AVD 的画面里。
这个方案比第二个更具优势的是，可以直接在 IDE 或是 Gradle 中就完成部署及测试，维持原本的开发经验一气呵成，不用再另外做设定。
需注意的技术细节
在方案二或方案三的指令中，如果直接进行连接，应该会遇到问题、无法完成连接。主要的原因可以看一下图示：
ADB Server 聆听的 Address 是 127.0.0.1，而外部传入的 Port 是在真实的 IP 上，也就是说讯息并没有传到 ADB Server 所在的 Port 上。为了要解决这样的情况就必须要把真实 IP 接到的讯息 Forward 到 127.0.0.1 所在的 Port。
以 Windows 为例，内建有 netsh 指令来进行这项工作。以下的指令就是把真实 IP 在 5038 上收到的讯息，转送到 ADB 默认的 5037 Port 上：
netsh interface port proxy add v4tov4 listenport=5038 connectaddress=127.0.0.1 connectport=5037
这里有个小细节要注意，在设定 ADB Server 的聆听 Port 转送时，不能使用同一个 5037，会导致 ADB Server 无法启动。
同时，AVD 的 Port 是成对配置的，ADB 管理的范围是由 5554 到 5585，每二个号码分配给一个 AVD，偶数的号码是给 Console 连接用，奇数才是保留给 ADB。第一个 AVD 分配到的会是 5554，而 ADB 使用的则为 5555。以下图的 AVD 为例，显示的是 5558，但要进行远程连接的 Port 应该加一号为 5559。
AVD 的 Port 也不要占用到 5554 到 5585 的范围，否则 ADB 会认为 Port 被分配走，而跳过改取下一组。
这个设定是有持绩性的，不会因为重新开机而消失。而执行这个指令需要有 Administrator 的权限，所以可以一次就设定好清单，毕竟范围也就只有从 5555 到 5585。如此一来，不论 AVD 被分配到哪一个 Port 上，都可以被远程连接上。
所能达到的效果
最后总结一下以这种方式进行开发的好处：
- 节省开发环境的磁盘空间，并且可以更弹性地选择测试设备的规格，不用被开发的机器所限制。
- 有效利用闲置资源、增加工作效率。用 Notebook 开发的人，另外拥有 PC 是很常见的情况，只是很有可能在开发时是闲置的。而开发时最耗资源的都是测试，所以如果可以把耗资源的部份转移到效能相对较好的 PC 上，可以有效地提高效率。
- 减少空转与等待的情况。延续上一点，耗资源的工作被转出去，开发的机器就可以接续进行开发的工作，或是放松休闲一下，上上网、看个影片，等待测试完成。
另外，这次还有汇整其他在尝试过程中所遭遇问题的解决方法，有需要的朋友，可以连到 wznote.blogspot.com 看一下。更多深入的文章请参阅简书 //www.greatytc.com/u/fea63707e07f 或 wznote.blogspot.com
