Weex调试神器——Weex Devtools使用手册

伴随着weex的正式开源,对一款针对weex框架的简单易用的调试工具的呼声也日趋强烈。weex devtools就是为weex前端和native开发工程师服务的一款调试工具,可同时检查weex里DOM属性和Javascript 代码断点调试,支持IOS和Android两个平台。

Chrome devtools对于前端开发者来说最熟悉不过,有广泛的用户基础.weex devtools实现了Chrome Debugging Protocol,其使用体验和普通的web开发一致,对于前端开发者是零学习成本,其主要功能分为两大部分——Debugger和Inspector,第一个版本已经随weex0.6.1 发布, 手淘也已接入。

以下是Devtools的使用介绍,欢迎大家试用。有任何问题建议,请提交这里,会很快得到解答。

Devtools 主要功能一览

连接设备

devtools可以动态检测客户端的连接绑定请求,同时连接/调试多个device(或者模拟器)是很容易的事情。连接的客户端显示在“Device List"界面,如下图所示。点击对应device的Debugger按钮即开始调试流程,并弹出JS断点调试的页面;随后点击Inspector按钮可弹出调试DOM的页面。

Debugger

这个是用来调试weex中的js前端代码的页面,“Sources” tab能够显示所有JS源码,包括jsFramework和bundle代码。可以设置断点、查看调用栈,功能和普通的chrome浏览器调试一样。"Console" 控制台显示前端的Log信息,并能根据级别(info/warn/error等)和关键字过滤。

Breakpoint and CallStack

Inspector

Inspector 功能丰富,能够用来查看 Element \ Network \ Console log \ ScreenCast \ BoxModel \ Native View 等。

Element

这里展示的是在Android/iOS上的native DOM树,及其style属性,和layout图。鼠标在DOM 树移动时,在device(或模拟器)上对应节点会高亮显示,有助于native开发者定位和发现节点。screencast只是对屏幕图像拷贝,在远程调试时能看到远程设备界面,数据网络下screencast也将有较大流量花销,,如果设备就在手头儿则建议关掉。

Network

这里展示的是bundle资源加载网络访问的性能。所以如果bundle资源在device本地,Network是没有数据的。

查看网络请求的总耗时和延时

查看网络请求的header和response

控制台

这里显示的是Android/iOS上的native log,并不是前端log(显示在Debugger页面)。同样native log也有对应级别--warn/error等,和关键字过滤,native开发查询很方便。

资源

这里和Network一样,远端访问的资源文件会显示在这里,没有实际作用。因为在Debugger页面,"Sources"里已经有源码并可以断点调试。不过假如你的应用里有数据库文件,在这里可以方便的查看而无需root,这是非常有用的。

如何安装和启动devtools

无论是跑在IOS或者Android端,weex-devtool都是必需的,用来启动服务器和chrome页面。

安装

$ npm install  -g  weex-toolkit

用法

weex debug [options] [we_file|bundles_dir]

选项:

-h, --help           显示帮助
-V, --verbose        显示debug服务器运行时的各种log
-v, --version        显示版本
-p, --port [port]    设置debug服务器端口号 默认为8088
-e, --entry [entry]  debug一个目录时,这个参数指定整个目录的入口bundle文件,这个bundle文件的地址会显示在debug主页上(作为二维码)
-m, --mode [mode]    设置构建we文件的方式,transformer 最基础的风格适合单文件,loader:wepack风格 适合模块化的多文件.默认为transformer

如何在设备或者模拟器上调试

weex调试初体验之playground

如果你是一名weex调试的新手,那么推荐你先下载playground体验一下devtools调试js bundle的基础流程.

  • 前提:

    • 安装weex-toolkit, 内含调试命令weex debug
    • android/iOS设备及pc已联网,若位于不同网段请确保防火墙可访问性
  • 调试步骤:

    • 启动debug server.
      执行命令weex debug将启动 debug server.如果启动成功将会在chrome打开一个welcome页面,在网页下方有一个二维码.
    • 启动playground并扫码.
      点击启首页左上角的扫码按钮扫码上一步中网页下方的二维码.此时welcome页面将会出现你的设备信息.playground进入loading页面,等待你的下一步操作.
    • 点击网页上的Debugger按钮.
      app结束loading进入debugging状态.同时chrome将会打开debugger页面.按照页面提示打开该页的JavaScript控制台并进入source tab.
    • 设置断点刷新当前页.
      点击playground首页list中的任意项将打开一个weex bundle,此时在Sources里会出现相应的js 文件,设置断点并刷新playground 即可调试. 
    • 点击网页上的Inspector 按钮.
      chrome会打开inspector页面,可以查看Element, Console, Network状态.

weex调试初体验之应用

如果是接入weex的应用想调试自己的bundle代码,有以下几个方式:

  1. 借助playground扫码调试we文件

    • 先确定playground已经是可调试状态
    • 执行weex-toolkit 命令,"weex debug xxx.we",会自动编译打包we文件,并在chrome的device 列表页面最底下新生成一个二维码。
    • 用playground扫描新二维码,手机上即显示xxx.we的结果。相应在"Debugger"和"Inspector"页面调试。
  2. 借助playground扫码调试js bundle文件
    • 先确定playground已经是可调试状态
    • 用二维码生成器为xxx.js 生成一个二维码。
    • 用playground扫描新二维码,手机上即显示xxx.js的结果。相应在"Debugger"和"Inspector"页面调试。
  3. 直接修改应用,接入devtools接口
  • Android sdk接口

    // host 表示debug server的ip或域名
    WXEnvironment.sRemoteDebugMode = enable;
    WXEnvironment.sRemoteDebugProxyUrl = "ws://" + host + ":8088/debugProxy/native";
    
  • iOS sdk接口
    #import "WXDevTool.h"
    [WXDevTool setDebug:YES];
    [WXDevTool launchDevToolDebugWithUrl:@"ws://host:8088/debugProxy/native"];
    
时间: 2025-01-13 05:51:40

Weex调试神器——Weex Devtools使用手册的相关文章

[Weex Tips] 合理使用 Weex 的生命周期

这是 Weex Tips 系列文章中的一篇,汇总目录在 这里. 首先建议先看一下有关组件定义的官方文档,其中介绍了生命周期. 在 Weex 项目里有个 issue 专门描述了 Weex 的生命周期,里面有几张很清晰的图,我这里只讲一下用法. 如果想了解组件的编译细节可以参考:<详解 Weex JS Framework 的编译过程>. 如果看完了上边的链接,对 Weex 生命周期的理解应该很到位了,可以简单总结成这么一张图: 注:在新版本的 JS Framework(>0.15.6)中才支

移动网页调试神器Erdua使用技巧

做移动端Web开发的一大痛点就是,在真机运行下无法查看console.log日志和其他信息如网络请求.显示本地存储等信息.如果网页是运行在手机浏览器中还算好,可以把网址在电脑上打开查看console信息,但是如果是做APP的内嵌H5页面,那就只能靠开发阶段在浏览器模拟环境中尽量没有Bug,但是,一旦H5上线后报错那就比较麻烦了,而且还依赖APP环境才能跑的网页,更加难以查找问题.如果让移动端也拥有类似Chrome DevTools工具那岂不是很愉快么? vConsole便是这样一款很棒的移动端D

段错误调试神器 - Core Dump详解

一.前言: 有的程序可以通过编译, 但在运行时会出现Segment fault(段错误). 这通常都是指针错误引起的. 但这不像编译错误一样会提示到文件某一行, 而是没有任何信息, 使得我们的调试变得困难起来.  gdb: 有一种办法是, 我们用gdb的step, 一步一步寻找. 这放在短小的代码中是可行的, 但要让你step一个上万行的代码, 我想你会从此厌恶程序员这个名字, 而把他叫做调试员. 我们还有更好的办法, 这就是core file.  ulimit: 如果想让系统在信号中断造成的错

C/C++程序调试神器GDB命令行调试器使用教程

没有调试器的情况下编写程序时最糟糕的状况是什么?编译时跪着祈祷不要出错?用血祭召唤恶魔帮你运行程序?或者在每一行代码间添加printf("test")语句来定位错误点?如你所知,编写程序时不使用调试器的话是不方便的.幸好,linux下调试还是很方便的.大多数人使用的IDE都集成了调试器,但 linux 最著名的调试器是命令行形式的C/C++调试器GDB.然而,与其他命令行工具一致,DGB需要一定的练习才能完全掌握.这里,我会告诉你GDB的基本情况及使用方法. 安装GDB 大多数的发行版

关于Weex,你想了解的一切都在这里

Summary 自从南天在Qcon2016宣布Weex项目开源至今已经快两个月了,Weex也在6月的最后一天迎来了全面的开源.截止7月中旬,Weex在github上收获了4K star,一度成为github上的热门项目.Weex,作为无线研发领域新秀,其影响力正逐步从阿里的内部不断向外部扩散,除了全力支持手淘和手猫的大促活动,Weex在常规的业务中也正在稳步的推进,并开始在电商以外场景落地,证明了Weex在无线研发领域广泛的应用前景. 当然,Weex还"年轻",大家在使用的过程中不断的

【阿里鬼道】Weex在双11会场的大规模应用:业务支撑、稳定性保障和秒开实战

前言 Native 开发的诸多亮点中,流畅体验和系统调用是最多被提及的.流畅体验体现在页面滚动/动画的流畅性,背后是更好的内存管理和更接近原生的性能:同时又是 Web 的痛点:资源首次下载.长页面内存溢出和滚动性能.动画性能.传统 web 性能(如JS执行效率).Native 有丰富的系统调用能力,而 Web 痛点在于:W3C 标准太慢,有限的设备访问能力,API 兼容性问题较严重,如 Geolocation 在 Android Webview 中可用性很差. Web 开发同样有诸多亮点,其中最

【双11背后的技术】Weex 双11会场大规模应用的秒开实战和稳定性保障

选自<不一样的技术创新--阿里巴巴2016双11背后的技术>,全书目录:https://yq.aliyun.com/articles/68637 本文作者:鬼道  前言 Native 开发的诸多亮点中,流畅体验和系统调用是最多被提及的.流畅体验体现在页面滚动/动画的流畅性,背后是更好的内存管理和更接近原生的性能:同时又是 Web 的痛点:资源首次下载.长页面内存溢出和滚动性能.动画性能.传统 web 性能(如JS执行效率).Native 有丰富的系统调用能力,而 Web 痛点在于:W3C 标准

网易严选App感受Weex开发

自打出生的那一天起,WEEX就免不了被拿来同React Native"一决高下"的命运.React Native宣称「Learn Once, Write Anywhere」,而WEEX宣称「Write Once, Run Everywhere」.在我看来,并没有谁更好,只有谁更合适.下面我将围绕WEEX入门进行讲解. (如果你尚不了解React Native,并想简单入门,可以阅读[整理]ReactNative快速入门笔记) 网易严选App感受Weex开发 什么都不说,先给你感受下we

初识weex与rax

背景 weex目前在集团乃至全球发展的如火如荼,最近也正在了解相关的资料,目前只是一些初步的了解,在这里分享一下.weex是跨端渲染框架,就是说一套代码,可以在web.ios和android跑,而且在后两者中,是以native方式跑的,因此在渲染效率和交互流畅度上,均有上乘的表现.weex于2016年开始在淘系双11.双12大促大规模使用,稳定可靠,可以看鬼道的介绍:<Weex 在双十一会场的大规模应用:业务支撑.稳定性保障和秒开实战> 那么为什么要做weex,相信做过web移动端页面的开发非