基于Android模擬器的調研

面對02機器上pcdroid異常情況頻發，已經影響到自動化測試的穩定性，因此，花了四天時間對當前的Android模擬器進行調研，試圖去尋找一款性能穩定，支持多系統版本的模擬器，從而解決當前自動化測試多系統、多異常的問題。

      （一）初步思考

       我一直相信，當前我們所面臨的窘境對于一些頂級團隊來說，可能已經有完美的解決方案。起初對于Android模擬器的思考，還僅限于Android官方與SDK一起提供的模擬器，不過根據之前經驗來說，官方的模擬器能解決多版本系統的問題，但是由于Android官方的模擬器使用了仿真技術，在x86系統上模擬ARM指令集，從而導致性能低下，根本無法進行自動化操作。因此，起初基于這個優化的構想，發現了Android官網提供了基于模擬器的x86鏡像，不過由于最近g o o g l e服務器被封，并且android的服務器也在被封范圍之列，因此暫時放棄了這種想法。不過令人興奮的是，隨后發現google團隊的幾名工程師設計了一款基于VirtualBox的x86 Android模擬器，并且聲稱在性能上有質的飛越。

    （二）溝通

       在這里不得不提一下溝通帶來的收益，首先是跟團購的QA溝通，發現團購那邊是使用Supserjs進行前端測試，superjs是基于phantomjs設計的一款前端自動化框架，由于內核為webkit，并且支持在linux部署，因此成為了前端解決自動化測試限制的一種方式，不過對于更精確的webapp測試來說，存在以下兩個問題：首先，無法模擬定位，對于LBS業務來說，與定位相關功能的驗證會受到影響。其次，雖然同基于webkit內核，但是仍然不能解決多系統版本的問題。同時，如果自動化測試改為superjs，勢必會導致自動化框架及用例的調整，投入產出比低。并且，對于superjs的折中方案，是使用ghostDriver，從而利用phantomjs解決因為機器導致的測試瓶頸，但是同樣存在不精確的問題。

      第二個溝通的人是爽姐，在溝通過程中，爽姐提到了之前曾經用過一款g o o g l e的Android模擬器——genymotion。穩定性還ok,執行速度快（后面baidu了下才知道，這款模擬器據說是當前最快的Android模擬器，堪比真機），但是之前只應用在手工測試階段，對于genymotion投入自動化環境，還需要進一步調研。

      第三個溝通的是一位Android地圖客戶端的rd，溝通了下Android-x86的可行性，最后感覺都很“靠譜”，也就帶著一種試一試的態度，進行探索。（參看：http://www.oschina.net/question/12_32695）

     （三）模擬器安裝

      根據當前思考的方案，進行了分析，從當前情況上來看，首要解決的問題是將Android-86和genymotion的環境安裝完成。對于genymotion的環境搭建比較順利，直接http://www.genymotion.com/進入官網，下載個人版，然后注冊賬號，下載模擬器，OK環境搞定。速度的確是相當之快，支持的功能也比較全面，不過由于是個人版，沒有對api的支持，因此對于后續自動化持續集成工作，帶來了很大的難度。

        接下來是Android-x86的安裝，第一個遇到的問題是Android-x86官網(http://www.android-x86.org/)無法訪問了，google被墻后帶來資源的匱乏。無奈，先看看能不能通過其他途徑找到鏡像文件，不行也只能購買×××服務翻 墻了！~

        功夫不負有心人，下到了Android-x86-4.4 和 Android-x86-4.3的兩個鏡像。搜了一篇安裝x86虛擬機的帖子（參考:http://www.cnblogs.com/gao241/archive/2013/03/11/2953669.html）,按照這個步驟一步一步往下捋，結果在第一步卡住了，每次按照鏡像就會重啟，鏡像無法正確安裝，后來修改了安裝的命令，在命令后面添加了 idle=poll操作，解決了安裝的問題。

      初步測試了下，這兩個環境的性能相當棒，從啟動速度上來說，Android-x86保持在將近120秒，genymotion在160秒遜色于x86，從響應速度來說，genymotion較x86好一些。

     （四）連接到設備

      當虛擬機都安裝ok，下一個解決的問題是怎么將模擬器與adb連接起來。由于虛擬機的特殊性，不能通過usb監測的方式進行連接，只能通過adb connect IP:<Port>的方式進行連接。以這種方式進行連接，首先要保證虛擬機的IP跟當前機器在一個網段，同時要獲取到當前機器的IP。 對于Android-x86來說，最方便的莫過于Alt+F1的控制臺，通過netcfg的方式直接獲取到IP，而genymotion就沒有控制臺了，后來發現通過genymotion的virtualbox虛擬機在啟動階段會顯示當前機器的IP，OK，IP已經獲取到了，接下來就是connect。

      不過沒有這么順利，connect連接不上機器，網上找了N多方法嘗試，仍然無法解決。苦無對策，但是填到酬勤，正如德國化學家凱庫勒夢到一條收尾相接的蛇而突然明白了苯環的結構，eclipse的Device視圖是否能連接上虛擬機呢？

      嘗試了下，正常的方式當然是不能，后來從網上找到了一種設置IP的方式，然后經由device中的reset進行重啟，就可以connect到虛擬設備了。

   （五）腳本化準備

      能夠連接到設備，下面就可以進行自動化測試了。按照webdriver、端口映射、run，自動化case成功在虛擬機上執行。初步評測穩定性還算可以，美中不足是不能模擬定位。由于整個測試操作已經打通，接下來的工作是如何將當前的工作腳本化。

      啟動虛擬機，直接使用VirtualBox提供的命令 startvm即可啟動（參考http://blog.sina.com.cn/s/blog_4c451e0e0100smar.html）。但是connect的時候，之前是使用eclipse連接的，現在需要以腳本的方式connect。為了解決這個問題，在這里了解了下eclipse插件，找到了與android相關的幾個插件。

    Device窗口歸屬于DDMS視圖，因此DDMS插件也成為了主要關注的對象。使用XJar反編譯之，發現了驚喜。

打開文件，順藤摸瓜

。。。。最終找到在ddmlib.jar目錄中存在AndroidDebugBridge.java，存在reset方法可以滿足當前需求。

        于是，簡單驗證之。

     不過通過這種方式只能連接一個虛擬機，后面了解到，可以結合adb tcpip + connect的方式對后續虛擬機進行連接。連接問題基本解決。

      （六）模擬定位

       最后一個難點，如何模擬GPS定位。這個問題困惑了我將近2天的時間。從網上找到的解決方案是先通過telnet命令登錄到虛擬機，然后經由“geo fix 經度 維度”的方式設定。但是在實踐過程中發現，telnet無法登錄到genymotion和x86虛擬機，geo fix也無從下手。

       第二個實施方案同樣想到了DDMS中的EmulatorControl窗口，既然eclipse能支持模擬定位，那么就照葫蘆畫瓢。

     同樣使用了EmulatorControlConsole插件，發現僅有DeviceMonitor的類才能使用模擬定位操作，而虛擬機被Android認定為Device，因此也不具備了模擬定位功能。

      方案三是通過Android自帶的tools目錄下的Emulator -gps 來實現模擬定位操作，后來也是出現了與方案二相同的原因而放棄。（參考：http://api.apkbus.com/guide/developing/tools/emulator.html）

       通過上面三種思考，可以說通過現有工具去解決模擬定位問題很難再有突破，此時開始從Android內核著手，試著去模仿和制造模擬定位功能。通過查資料了解到GPS在Android中實現是基于nmea標準(國家海事電子協會文件)（參考http://android.tgbus.com/Android/tutorial/201204/418964.shtml）并了解到nmea的數據格式(參考：http://blog.csdn.net/highdam/article/details/2646291)。于是開始查Android文件結構相關的文檔，找到了幾個與gps定位相關的文件,不過一直沒有找到所說的nmea目錄，于是想到了pcdroid一直在用的gpstool工具，由于時間比較晚了，就放到上班后去解決。

       Android源碼目錄結構文檔 http://www.cnblogs.com/yyangblog/archive/2011/03/02/1968880.html

       Android操作系統結構文檔 http://skynet86.blog.163.com/blog/static/17958121520111701719908/

       Android目錄結構 http://blog.csdn.net/chizhaolin/article/details/5722598

       Android源碼所有生成目錄 http://www.cnblogs.com/scue/p/3738882.html

      周一上班，與白宇溝通了下pcdroid模擬定位的問題，得到最大的收獲是給了我一個pcdroid的api文檔（參考http://pcdroid.baidu.com/api.php），文檔里面提供了一種新的模擬定位方式 adb shell gps 經度 維度。通過adb shell命令查看了pcdroid內核的system/bin目錄，發現兩個比較特別的文件，gps和agps.sh

pull下來發現是經由gps調用agps.sh,通過查詢sqlite數據庫中的數據，對gps數據進行設置。

稍后查了下Android關于GPS的實現：

      Android GPS分析 http://blog.csdn.net/xnwyd/article/details/7198728

      Android GPS驅動模塊開發 http://blog.csdn.net/vv0_0vv/article/details/7998596 

      Android GPS架構分析 http://www.eefocus.com/chongzi865458/blog/2012-03/232232_50018.html

發現com.android.location.provider.jar包是Framework層實現。不過由于時間問題，現階段已經沒有時間對這個jar包進行深入研究。修改Android系統涉及到的坑可能還有很多，在此暫時放棄了對Android內核修改的調研。

      在準備放棄模擬定位的同時，一個靈感對當前情況產生逆轉。既然genymotion模擬器可以通過自帶的工具進行gps模擬定位，那么我設置完畢之后，經由虛擬機啟動會不會仍然可以定位呢？嘗試了下，答案是可以。整體上的技術難點已經初步解決，接下來就是修改自動化腳本，試水genymotion新框架了。

續：后面發現可以通過setProp設定系統的定位參數來完成模擬定位（上面那個是轉化為python腳本的截圖），從而也完成了多系統模擬器的調研工作，投入生產過程中。由于效率較優，自動化的速度從1小時30分左右提升到1小時20分，同時模擬器導致的穩定性問題也大大降低。