关于chrome-devtools:iOS-WebViewH5调试新姿势

前言

Sonic平台周边生态sib推出新性能webinspector啦！给iOS进行H5测试带来什么不一样的体验呢？往下持续查看吧

sib应用文档

iOS web测试根底原理浅谈

以后的支流H5调试，基本上都是基于浏览器凋谢的debug ws服务来进行的。咱们通过连贯这些ws，而后发送对应的协定过来，即可达到debug的目标，例如iOS获取elements，则须要依照协定通过ws发送getDocument办法到webkit外面，期待ws server返回对应的element信息。iOS的webkit protocol具体可参考：WebKit/Source/JavaScriptCore/inspector/protocol at main · WebKit/WebKit · GitHub ，外面通过划分域的模式，曾经将协定分为次要的20-30个文件。

如何开启iOS web debug服务？

不同于安卓只须要简略的去开发者模式里开启webview的debug模式，iOS因为其封闭性，开启web debug十分麻烦。咱们须要发送相干的DTX协定给iOS内置的com.apple.webinspector（参考:sonic-gidevice/webinspector.go at main · SonicCloudOrg/sonic-gidevice · GitHub 、sonic-ios-bridge/src/webinspector at main · SonicCloudOrg/sonic-ios-bridge · GitHub ）。

大体流程如下：通过gidevice启动相干的webinspector server办法，随后DTX发送对应的connect id到webinspector，

这时候会返回对应的DTX信息，咱们会依据DTX信息的case标记(Selector参数)进行webinspector client的初始化解决。

该过程中会失去以后设施中的webkit利用pid和base page信息（依据一些技术文章，如果iOS的利用有developer证书，则能够开启H5调试，后续开发保护时会进行验证其真实性）。依据这些pid和page信息，当须要对某个webkit利用进行web debug时，创立一个senderid，并将其发送到webinspector中，让webkit开启debug服务，咱们只须要发送相干的协定信息就行。

协定兼容

尽管iOS的webkit inspector是倒退最早的一个网页调试器，然而因为iOS的封闭性和其余的一些因素，后续的其余内核的浏览器调试并没有应用iOS的webkit调试协定，基于易用性思考，sonic参考google/ios-webkit-debug-proxy 、RemoteDebug/remotedebug-ios-webkit-adapter 这两个我的项目，用golang重写了一遍，只须要应用sib的webinspector adapter模式，即可通过chrome devtool简略调试iOS的safari。外围思路是sib将发送协定信息这个关键步骤做成ws服务，采纳双向代理的模式，通过SonicCloudOrg/sonic-ios-webkit-adapter 拦挡iOS webkit调试协定和Chrome DevTools Protocol协定之间的特异办法，将其转换成单方可承受的调试协定和返回后果。

案例

如果咱们须要获取以后页面下导航栏中的历史信息时，Chrome DevTools Protocol的做法是ws里发送Page域中的getNavigationHistory办法到以后调试的利用中，期待返回的后果就行。比拟惋惜的是，这个办法间接发送到iOS webkit中，iOS webkit会返回信息告知并没有这个办法，不过iOS webkit能够通过曲线救国的形式达到相似的成果。首先，咱们先看Chrome DevTools Protocol中getNavigationHistory的返回信息是什么（参考：Chrome Devtools Protocol ）

{
    "id": "TransitionType",
    "description": "Transition type.",
    "type": "string",
    "enum": [
        "link",
        "typed",
        "address_bar",
        "auto_bookmark",
        "auto_subframe",
        "manual_subframe",
        "generated",
        "auto_toplevel",
        "form_submit",
        "reload",
        "keyword",
        "keyword_generated",
        "other"
    ]
}

{
    "name": "getNavigationHistory",
    "description": "Returns navigation history for the current page.",
    "returns": [
        {
            "name": "currentIndex",
            "description": "Index of the current navigation history entry.",
            "type": "integer"
        },
        {
            "name": "entries",
            "description": "Array of navigation history entries.",
            "type": "array",
            "items": {
                "$ref": "NavigationEntry"
            }
        }
    ]
}


{
    "id": "NavigationEntry",
    "description": "Navigation history entry.",
    "type": "object",
    "properties": [
        {
            "name": "id",
            "description": "Unique id of the navigation history entry.",
            "type": "integer"
        },
        {
            "name": "url",
            "description": "URL of the navigation history entry.",
            "type": "string"
        },
        {
            "name": "userTypedURL",
            "description": "URL that the user typed in the url bar.",
            "type": "string"
        },
        {
            "name": "title",
            "description": "Title of the navigation history entry.",
            "type": "string"
        },
        {
            "name": "transitionType",
            "description": "Transition type.",
            "$ref": "TransitionType"
        }
    ]
}

由返回构造可知，最重要的是url和titile（其余信息可自定义生成），所以思路能够这样：

通过中间层拦挡到这个特异性的办法，而后将这个办法替换成iOS webkit protocol下Runtime域的evaluate办法（evaluate办法的应用阐明参考：iOS webkit protocol Runtime），发送window.location.href，获取全局windows对象下的location.href后果，而后再次应用Runtime域evaluate办法，发送window.title，获取全局windows对象下的title后果，而后依照getNavigationHistory的返回构造组合获取到的这些信息，再返回到devtool中。

大体设计

不同调试协定之间的API差别 概览

在本人我的项目利用API兼容库

go get -u github.com/SonicCloudOrg/sonic-ios-webkit-adapter

利用方向

通过sib的webinspector adapter性能，不只是sonic的H5，任何基于Chrome DevTools Protocol开发的相干框架都能够用于操作iOS的H5。目前sonic继续保护 SonicCloudOrg/sonic-ios-webkit-adapter 我的项目，用作iOS H5自动化的底层框架，如auto touch、性能采集等，以及提供给前端一个开源易用的iOS webdebug tool，而如果不应用adapter，则是裸露原生的iOS webkit ws服务，能够通过iOS webkit debug tool工具进行调试（参考： webkit-webinspector ），在后续版本中，咱们将会对devtool进行二次开发，欠缺sonic的H5自动化前端。

在sib中应用

sib webinspector

启动后开启chrome的debug模式

chrome --remote-debug-port=9999

而后关上chrome的devtools工具，近程连贯webinspector的调试ws就能够啦！

不过该性能以后还在持续欠缺，还有很多能够优化的空间，欢送大家参加建设~

FAQ

• Q：为什么用golang来写？和ios-webkit-debug-proxy、remotedebug-ios-webkit-adapter有什么区别吗？
• F：咱们应用golang的最大一个起因是其多个平台的兼容性，应用起来不须要额定的配置环境，而且以往的iOS相干H5测试大多须要搭配xcode、Mac环境，然而配合sib应用就能够做到脱离Mac跨平台应用，还解脱了nodejs的依赖。尽管ios-webkit-debug-proxy我的项目也是跨平台的，然而其自身应用C语言，我的项目里有大量指针操作，对于没学过C语言的同学来说这个很折磨人。至于remotedebug-ios-webkit-adapter我的项目，除了解脱nodejs以外，其最大问题是作者曾经不再保护了，综合思考之下决定应用golang重写这个我的项目，便于前期的保护和拓展。
• Q：应用过程中某个protocol办法不反对怎么办？
• F：目前我的项目只是初步实现，还有很多性能未实现，欢送提issue或pr，也欢送相熟Chrome DevTools Protocol协定和iOS webkit debug protocol协定的大佬退出一起保护我的项目。
• Q：二次开发chrome devtool的起因是为什么？
• F：因为在两个协定之间兼容时，sonic很被动，无论是Chrome DevTools Protocol协定还是iOS webkit debug protocol协定产生更改，都导致adapter里须要破费大量的工夫进行适配，咱们须要进步本身的主动权。

文章摘自Sonic wiki https://sonic-cloud.wiki/d/17…