content.json

{"meta":{"title":"IFFE-team","subtitle":"互联网金融前端团队","description":null,"author":"IFFE Teammates ヽ(；▽；)ノ＼(^-^ )","url":"https://iffe.js.org/blog"},"pages":[],"posts":[{"title":"Node.js 项目持续集成实践","slug":"项目持续集成实践","date":"2017-01-01T18:15:55.000Z","updated":"2017-05-05T09:59:20.000Z","comments":true,"path":"2017/01/02/项目持续集成实践/","link":"","permalink":"https://iffe.js.org/blog/2017/01/02/项目持续集成实践/","excerpt":"前端开发流程（ 语法检查、编译、重载）的自动化我们在工作中已经用得比较溜了，这篇文章主要介绍 Node.js 应用部署到服务端过程（编译、测试）的自动化。 这里以开源的 API Mock 系统 AMP 的部署为例（ https://iffe.leanapp.cn ），通过这套系统提供的 mock 服务，前端可以在接口定义完毕后就着手开发，与后端接口开发并行以提升项目整体效率。接口支持 CORS 跨域访问、支持 HTTPS 访问，为前端开发，尤其是移动端开发带来便利。","text":"前端开发流程（ 语法检查、编译、重载）的自动化我们在工作中已经用得比较溜了，这篇文章主要介绍 Node.js 应用部署到服务端过程（编译、测试）的自动化。 这里以开源的 API Mock 系统 AMP 的部署为例（ https://iffe.leanapp.cn ），通过这套系统提供的 mock 服务，前端可以在接口定义完毕后就着手开发，与后端接口开发并行以提升项目整体效率。接口支持 CORS 跨域访问、支持 HTTPS 访问，为前端开发，尤其是移动端开发带来便利。 实现的效果 本地开发代码，提交到 gitlab 的 master 分支后自动测试和编译，并将编译结果提交到可部署生产的 built 分支，需要的时候一键发布生产。 实现细节 这里用到 gitlab.com 提供的私有代码托管和 git-ci 服务，以及 leancloud 的云引擎。gitlab.com 提供的服务可以使用自己搭建的 gitlab 替换。提供与 leancloud 类似云引擎功能的网站，市面上也不少，这里因为其免费策略合理所以采用，拿它们举例适用性较广。 首先我们要在项目根目录添加 gitlab-ci.yml 文件，用于描述持续集成的过程，分三个阶段： 测试 只需要执行 Node.js 应用的测试命令: npm test 123test: script: - npm test 构建 执行 Node.js 应用的构建命令: npm run build 123build: script: - npm run build 部署 1234deploy: stage: deploy script: - . deploy.sh # 为了方便脚本执行上下文控制，我们将命令写到 deploy.sh 中 deploy.sh 脚本完成两件事： 执行编译命令 push 编译代码到 built 分支 完整配置如下： 123456789101112131415161718192021222324252627282930313233343536# .gitlab-ci.ymlimage: node:6# 缓存安装后的 node_modules ，以加速下次构建cache: paths: - node_modules/before_script: - npm i -D # 所有任务执行前都会执行该脚本，用于安装所有依赖包 # 添加 ‘build' 任务，描述构建任务的执行build: stage: build # 定义所属阶段 script: - npm run build # 需要运行的脚本 only: - build # 'build' 任务仅影响 'build' 分支# 添加 'test' 任务， 描述测试任务的执行test: stage: test # 定义所属阶段 script: - npm run test # 需要运行的脚本 except: - master # 'test' 任务影响除 'master' 分支之外的所有分支# 添加 'deploy' 任务， 完成构建和部署deploy: stage: deploy script: - . deploy.sh # 需要运行的脚本 only: - master # 'deploy' 任务仅影响 'master' 分支 由于测试任务由除 master 之外的分支的 push 触发，而部署任务完成后，将编译结果 push 到 built 分支。所以我们 push 到 master 后，会先执行部署任务，部署任务完成后，执行测试任务（如下图） 任务执行结果： 有了构建好的代码，就可以部署到 leancloud 了，部署前我们需要告诉 leancloud 代码库地址，并将 deploy key 信息保存到 gitlab 的项目配置中。这样以后 leancloud 就可以凭 deploy key 向 gitlab 库拉取代码。 两边信息配置完毕，就可以开始部署，在“部署”面版填写“分支或版本号“为 built 即可。 如果一切顺利，部署成功后就可以访问应用了。 （请注意：演示系统虽然功能 ok，但是运行环境为 leancloud 免费版云引擎，配额受限，请 不要 在实际项目中使用， 请使用大师在内网环境部署的。） 解决工作中场景中哪些痛点 无缝版本切换，实现“为跑道上飞驰的赛车更换零件”——在 leancloud 部署应用到生产环境的过程中发现一个有意思的细节，就是新版本构建出问题并不影响线上服务。大致过程类似于在一台新服务器上运行好版本代码，然后把流量从上运行上一版本代码的服务器切过来，在此之前会检测配置的端口是否正常相应请求，如果不是就终止切换，并提示发版失败，发版成功则把“旧版服务器”做存档，以供后续版本回退。有了这一机制，发版本就可以选择最适合业务的时机，而不是非要等到用户量最低的时候，“他好我也好” 😝 提前暴露编译配置的问题，实际项目中更改生产构建配置，往往改完当时验证没问题后就不太会留意，而等到真正发版前的一段时间项目文件变动可能产生预料外的问题，这时发现再解决就占用了本已紧张的发版时间，而且需要定位产生问题的代码，这问题在多人协作以及长周期的版本尤其突出。而引入持续集成后，每次 push 将会触发测试环节，在这里加上构建测试，通过测试结果即可及时发现问题并处理。 提升开发体验，将一部分消耗资源、重复的、机械性的任务如全量编译，交由持续集成服务器完成，以节约开发机资源，让开发者专注于开发而不受打断。能有空伸个懒腰，发发呆不再是奢求。 思考 探索“云计算”、”微服务”这些新热技术在前端开发领域的应用场景，对理解“小而美”产品（快速迭代、小步快跑的同时保持新集成特性的稳定输出）存在的基础（支撑点），有推导和借鉴意义。 短期内切换应用部署方案显然并不现实，但这并不构成拒绝拥抱变化的充分条件，毕竟技术的发展不因主观意愿而转移，而去中心化和原子化（把功能和服务内聚为模块）显然是日益突显的两个特征。实际上下半年组内在一些项目中切换 git 做版本管理，并将暴露的问题解决得七七八八已是一个不错的开端。 “ 我觉得套路和扯皮救不了中（cheng）国（xu）人（yuan），但技术储备可以 ” 。","categories":[{"name":"建站❤编程","slug":"建站❤编程","permalink":"https://iffe.js.org/blog/categories/建站❤编程/"}],"tags":[{"name":"持续集成","slug":"持续集成","permalink":"https://iffe.js.org/blog/tags/持续集成/"},{"name":"实践","slug":"实践","permalink":"https://iffe.js.org/blog/tags/实践/"},{"name":"Node.js","slug":"Node-js","permalink":"https://iffe.js.org/blog/tags/Node-js/"}]},{"title":"ATS ( App Transport Security )是什么，以及如何支持 ATS","slug":"ATS ( App Transport Security )是什么，以及如何支持 ATS","date":"2016-12-13T12:21:12.000Z","updated":"2017-05-05T09:59:20.000Z","comments":true,"path":"2016/12/13/ATS ( App Transport Security )是什么，以及如何支持 ATS/","link":"","permalink":"https://iffe.js.org/blog/2016/12/13/ATS ( App Transport Security )是什么，以及如何支持 ATS/","excerpt":"今天明秋童鞋在需求文档中看到接入任意门需要满足 ATS 标准，我们就来了解了下什么是 ATS ；该标准对 web 开发的影响，及应对措施。 什么是 ATSApp Transport Security，简称 ATS，是苹果为了提高 App 与服务器之间数据安全，而在 iOS 9 当中首次推出的一项安全特性。在苹果全球开发者大会（WWDC）的一场演示中，该公司公布了一个最后期限——2017 年 1 月 1 日——即 App Store 当中的所有应用必须在这个日期之前启用这一重要安全功能。","text":"今天明秋童鞋在需求文档中看到接入任意门需要满足 ATS 标准，我们就来了解了下什么是 ATS ；该标准对 web 开发的影响，及应对措施。 什么是 ATSApp Transport Security，简称 ATS，是苹果为了提高 App 与服务器之间数据安全，而在 iOS 9 当中首次推出的一项安全特性。在苹果全球开发者大会（WWDC）的一场演示中，该公司公布了一个最后期限——2017 年 1 月 1 日——即 App Store 当中的所有应用必须在这个日期之前启用这一重要安全功能。 距离最后期限越来越近，于是开发者们又将收到一波升级需求,不升级的后果图片里面说得比较清楚了。对应工作中的场景，就是版本因达不到接入标准而延期，这时候就不是走个特批就能解决的问题了，因为后面还有一道 App Store 上架的外部审核，要是卡在这里后果就是 App 无法如期上架，全员落水，运营和 iOS 开发哥哥提前表示 “这锅咱不背不背不背啊😭…” 所以今后如果不幸因 ATS 被“不达标”了，表觉得是 someone 有意怼你，应该明白这背后是一家伟大公司为了保护用户数据安全而做的充满情怀和正义感的事情，嗯 (认真脸)。 ATS 的硬性指标： 强制使用 https 证书域名和链接地址域名匹配 根证书受苹果信任 证书在有效期内 必须支持 TLS1.2 至少 RSA 2048位或者是 ECC 256位密钥加密 SHA256 算法证书 加密套件要求，必须使用 AES-128 或者 AES-256 支持，并且支持完整前向加密： RSA 算法要求使用以下加密套件： TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA DSA 算法要求使用以下加密套件： TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHATLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 总结下就是：必须使用 https 协议；证书有效且强度足够。 如何支持 ATS 标准 强度足够的证书好解决，购买苹果信任CA所颁发的证书即可，一般知名的商业证书颁发机构如 GoDaddy 、 VeriSign … 然后就是部署 https 的 web 服务，这里以常见的 Nginx、Apache 以及 Tomcat 为参考： 2.1 Apache：（Apache，Nginx 要求关联的 openssl 版本在 1.0.1+ ，这样网站才支持 TLS1.2） 12SSLProtocol all -SSLv2 -SSLv3SSLCipherSuite ECDH:AESGCM:HIGH:!RC4:!DH:!MD5:!aNULL:!eNULL; 2.2 Nginx 12ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDH:AESGCM:HIGH:!RC4:!DH:!MD5:!aNULL:!eNULL; 2.3 Tomcat 要求环境 tomcat7+ 和 JDK1.7+ ，配置参考如下： 123456789101112<Connector port=\"443\" protocol=\"org.apache.coyote.http11.Http11Protocol\" maxThreads=\"150\" SSLEnabled=\"true\" scheme=\"https\" secure=\"true\" keystoreFile=\"keystore/domain.jks\" keystorePass=\"证书密码\" clientAuth=\"false\" sslProtocol=\"TLS\" ciphers=\"TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA\" /> 看到这里，你是不是该撸起袖子做些什么，或把本文转给需要它的运维童鞋们 ヽ(；▽；)ノ＼(^-^ ) 。 参考：苹果ATS检测iOS 9 中可用的受信任根证书列表","categories":[{"name":"科普小知识","slug":"科普小知识","permalink":"https://iffe.js.org/blog/categories/科普小知识/"}],"tags":[]},{"title":"全栈工程师培训笔记","slug":"全栈工程师培训笔记","date":"2016-11-20T22:06:46.000Z","updated":"2017-05-05T09:59:20.000Z","comments":true,"path":"2016/11/21/全栈工程师培训笔记/","link":"","permalink":"https://iffe.js.org/blog/2016/11/21/全栈工程师培训笔记/","excerpt":"有幸参加阮一峰老师为期两天的《全栈工程师培训》，获益良多，将训练营四讲内容分享如下： 纲要第一讲：前端开发的历史和趋势 前端开发的历史演变 前端 MVC 框架的兴起 前后端分离 全栈工程师 前端开发的未来","text":"有幸参加阮一峰老师为期两天的《全栈工程师培训》，获益良多，将训练营四讲内容分享如下： 纲要第一讲：前端开发的历史和趋势 前端开发的历史演变 前端 MVC 框架的兴起 前后端分离 全栈工程师 前端开发的未来 第二讲：React 技术栈 React 的基本用法 React 应用的架构 第三讲：Node 应用开发 Node 的基本用法 Restful API Express 框架搭建 Web 应用 第四讲：前端工程简介 持续集成 静态代码检查 单元测试 功能测试 持续集成服务 Travis CI 收获就我个人而言，收获比较大的是第三讲和第四讲内容，因为实际开发工作中涉及服务端开发和测试、集成方面较少，阮老师的讲解还是让自己开了眼界。 周末就花了些时间，使用 CircleCI 实践了一把持续集成，结合 remarkjs 实现将阮老师的培训讲义（MarkDown格式），自动转为网页屁屁踢(见上文中的链接)，这样在讲义不断完善的过程中，文中的 PPT 内容也能保持更新，下一步的计划是把团队博客也这么整整，完了小伙伴们直接提交 md 即可，编译和发布过程都将自动集成 ( •̀ ω •́ )y 。 感谢感谢公司提供这么好的机会，能与技术大牛面对面学习交流。","categories":[{"name":"建站❤编程","slug":"建站❤编程","permalink":"https://iffe.js.org/blog/categories/建站❤编程/"}],"tags":[{"name":"培训","slug":"培训","permalink":"https://iffe.js.org/blog/tags/培训/"},{"name":"框架","slug":"框架","permalink":"https://iffe.js.org/blog/tags/框架/"},{"name":"React","slug":"React","permalink":"https://iffe.js.org/blog/tags/React/"},{"name":"Node","slug":"Node","permalink":"https://iffe.js.org/blog/tags/Node/"},{"name":"持续集成","slug":"持续集成","permalink":"https://iffe.js.org/blog/tags/持续集成/"},{"name":"测试","slug":"测试","permalink":"https://iffe.js.org/blog/tags/测试/"}]},{"title":"Android WebView 前端开发调试","slug":"Android WebView 前端开发调试","date":"2016-06-20T22:06:46.000Z","updated":"2017-05-05T09:59:20.000Z","comments":true,"path":"2016/06/21/Android WebView 前端开发调试/","link":"","permalink":"https://iffe.js.org/blog/2016/06/21/Android WebView 前端开发调试/","excerpt":"这篇是之前写的东东，因为iffe博客出问题，所以一直存着，今天借大师开的Github页发出来，PPT是上次应小龙邀请做移动端调试方法分享时准备的，一起放上来😄 在这次的参数RSA+AES加密需求(160310版本)中，由于涉及的接口众多，测试回归时需要在微信中到相关页面进行验证，工作量巨大，所以需要一个更高效率的移动端调测方式。 这篇文章要里介绍了连接和抓包，其中出现远程调试安卓Webview的截图，很多同事尝试时在列表中只能看到chrome中打开的页面，通过 这篇文章可以知道，原因是其他app可能没有开启webContentsDebuggingEnabled，chrome的安全策略限制了这些网址的展示，要突破这一限制，需要用到一款叫Xposed的APP 。 Xposed的原理是利用动态劫持，通过替换/system/bin/app_process程序控制zygote进程，使得app_process在启动过程中会加载XposedBridge.jar这个jar包，从而完成对Zygote进程及其创建的Dalvik虚拟机的劫持。","text":"这篇是之前写的东东，因为iffe博客出问题，所以一直存着，今天借大师开的Github页发出来，PPT是上次应小龙邀请做移动端调试方法分享时准备的，一起放上来😄 在这次的参数RSA+AES加密需求(160310版本)中，由于涉及的接口众多，测试回归时需要在微信中到相关页面进行验证，工作量巨大，所以需要一个更高效率的移动端调测方式。 这篇文章要里介绍了连接和抓包，其中出现远程调试安卓Webview的截图，很多同事尝试时在列表中只能看到chrome中打开的页面，通过 这篇文章可以知道，原因是其他app可能没有开启webContentsDebuggingEnabled，chrome的安全策略限制了这些网址的展示，要突破这一限制，需要用到一款叫Xposed的APP 。 Xposed的原理是利用动态劫持，通过替换/system/bin/app_process程序控制zygote进程，使得app_process在启动过程中会加载XposedBridge.jar这个jar包，从而完成对Zygote进程及其创建的Dalvik虚拟机的劫持。 Xposed的安装在这篇文章中已经介绍了很清楚，这里不赘述。下面截几个过程中的图 IMWeb团队袁飞翔这篇文章中介绍了开启QQ客户端debug模式的方法，参考其中代码： 把里面的 packageName 的判断去掉，重新编译成apk 就可以啦。也许有童鞋会说“我是前端开发怎么知道如何编译安卓app呢？” 身为前端，如果说web开发对于我们是陆地，客户端和服务端开发可能就是海洋和天空。离开了陆地我们无法生存，但这不应该成为我们放弃追求上天和入水的理由。 跳出舒适圈，才能走向更广阔的海洋和天空；正所谓“技多不压身”，了解其他领域的开发技能，有助于让我们从不同维度来思考工作中遇到的问题，虽然过程中可能需要投入额外的时间，但有的时候放适当放慢解决问题的速度，反而是对个人能力的提升——如果一开始看到那堆java代码感觉和平时写的js语法差异很大，看不懂就放弃了，可能就不会开始APP开发的第一步，更不会去思考如何编译打包的问题。而是直接采用QQ浏览器微信调试工具，这样既省时又省事的方式，但后续如果需调试微信之外的APP就卡壳了，一味追寻捷径也可能让人迷失，尤其对于开发新人。 需要指出的是，Xposed需要root权限（这个对开发应该不是啥问题吧），另外新版本的QQ和微信安卓客户端已经使用X5内核而不调系统Webview了，新版可以尝试在存储卡根目录下放置文件：debug.conf，或者使用老版本的客户端。 参考文章： 使用Xposed强制androidwebView开启debug模式 安卓教程：Xposed 框架安装及使用 Xposed 入门与模块示例 – 电量伪装 QQ浏览器开启网页调试教程。","categories":[],"tags":[]},{"title":"Mac下Chrome浏览器设置跨域","slug":"Mac下Chrome浏览器设置跨域","date":"2016-01-20T22:06:46.000Z","updated":"2017-05-08T05:33:46.000Z","comments":true,"path":"2016/01/21/Mac下Chrome浏览器设置跨域/","link":"","permalink":"https://iffe.js.org/blog/2016/01/21/Mac下Chrome浏览器设置跨域/","excerpt":"","text":"前端开发经常会遇到跨域的问题，尤其是本地开发，经常需要调后端同事电脑或测试环境的地址，这就对本地开发阶段造成了一些困扰。好在一些浏览器对开发者提供了“禁用安全模式”，前端ER们在本地开发的时候就不用考虑跨域的问题了，各终端的命令如下： Mac下的Chrome：1234# 49以前的版本open -a \"Google Chrome\" --args --disable-web-security# 49以后的版本open -a /Applications/Google\\ Chrome.app --args --disable-web-security --user-data-dir Windows下的Chrome：1chrome.exe --disable-web-security Mac下的Safari：1open -a '/Applications/Safari.app' --args --disable-web-security Windows下的Safari：1C:\\Program Files\\Safari\\Safari.exe --disable-web-security","categories":[],"tags":[]},{"title":"平安内网标装机远程调试安卓webview的方法","slug":"平安内网标装机远程调试安卓webview的方法","date":"2016-01-02T22:06:46.000Z","updated":"2017-05-05T09:59:20.000Z","comments":true,"path":"2016/01/03/平安内网标装机远程调试安卓webview的方法/","link":"","permalink":"https://iffe.js.org/blog/2016/01/03/平安内网标装机远程调试安卓webview的方法/","excerpt":"由于安全策略限制，我们的开发机只能连入内网，且需要经过标装。 平安内部主要用到两张网，一张是办公开发用的PA_WLAN，另一张是移动设备接入的MA网，开发机与测试机由于不在同一网段，也就只能上演人鬼情未了了（用Mac开发的土豪例外）； 另一方面，标装过的机器木有管理员权限，无法通过共享wifi给手机来创建局域网环境，于是另一条路被宣告堵死。 以往的方法都不灵，只能另辟蹊径咯~ 最终希望寄托在连通二者的USB线。","text":"由于安全策略限制，我们的开发机只能连入内网，且需要经过标装。 平安内部主要用到两张网，一张是办公开发用的PA_WLAN，另一张是移动设备接入的MA网，开发机与测试机由于不在同一网段，也就只能上演人鬼情未了了（用Mac开发的土豪例外）； 另一方面，标装过的机器木有管理员权限，无法通过共享wifi给手机来创建局域网环境，于是另一条路被宣告堵死。 以往的方法都不灵，只能另辟蹊径咯~ 最终希望寄托在连通二者的USB线。 于是问题转化为：如何通过USB线实现开发机与测试手机通信，让手机的流量通过USB线走开发机网络。 先介绍解题思路 通过Chrome的远程调试工具连通手机和开发机，实现通信； 将手机流量通过代理指向开发机端口； 开发机监听端口，接收代理流量 具体操作步骤针对第一点，标装机需要安装ADB驱动（没有管理员权限的话到idesk搜索“Android”安装第一个搜索结果） [caption id=”” align=”alignnone” width=”507”] 安装之后，勾选“Extras”下的“Google USB Driver package”，然后安装。[/caption] 安装之后的操作； 开启当前Android设备的USB调试模式 开发机上安装Chrome浏览器（版本>=32） 用USB线连接Android设备，在PC或MAC上的Chrome地址栏输入chrome://inspect 然后回车，或通过菜单图标→工具→检查设备，进入调试界面 勾选界面中的 Discover USB devices ，直到搜索到你的Android设备 在移动设备上弹出的是否允许远程调试上，选择“允许” 在下面的页面列表（将展示已在Android上的Chrome中打开的页面），点击对应的 inspect 开始调试 此时将在桌面版Chrome上弹出一个新的标签页，即为调试界面；[caption id=”” align=”alignnone” width=”507”] 连通后的效果是这样的~[/caption] 这样以后，开发机的Chrome开发者工具就可以远程调试手机上的Chrome页面，但仅限于Chrome。接下来解决手机APP联网和流量抓包的问题。 第二点的实现，得借助一款叫做“Transparent Proxy”的软件实现（需root权限），配置全局代理后，所有APP的流量就都指向Chrome的8888端口了； 需要注意的是：开发机与手机之间网络连接需要靠大小Chrome通奸来维持，所以即使不是调试手机版Chrome网页，也要保持手机Chrome后台运行状态（即 保持上图中的小绿点常亮） [caption id=”” align=”alignnone” width=”267”] 需要如图配置三个地方[/caption] 第三点，到目前为止，手机上的流量已经全部转向台式机的Chrome，接下来要做的，是将台式机Chrome接收到的流量转到我们熟悉的抓包工具——Fiddler上 [caption id=”” align=”alignnone” width=”274”] Chrome的配置[/caption] Fiddler的配置方法就不介绍了，不懂的百度一下，记得勾选“Allow remote computers to connect”哦。 [caption id=”” align=”alignnone” width=”508”] 财富宝APP的抓包，从User-Agent值可以看到系统和内核信息[/caption] 目前我们用较多的是console.re 和blog.qqbrowser.cc的方案； 方案一本质是模拟console，依赖第三方服务器且存在网络延迟问题，功能也远不及Chrome开发者工具强大； 方案二需要安装鹅厂产品，不过相比带来的调试便利，这点推广还算良心。另外这个方案只能调试内核使用x5的APP，如微信、QQ空间等，且对APP版本有要求，如微信6.1以后才支持x5内核。相比之下，咱们这套方法有三个优势： 不需要专门去安装个QQ浏览器用于调试（对于办公机内存吃紧如我的同学而言还是蛮赞的）； 不仅限于X5内核，可调试所有安卓应用中的webview； 手机使用开发机网络，无需MA账号，妈妈再也不用担心你的手机流量~ 最终实现的效果[caption id=”” align=”alignnone” width=”508”] 手机上打开页面的列表，点击“inspect”开始调试[/caption] [caption id=”” align=”alignnone” width=”507”] 远程调试Chrome中打开的页面[/caption] [caption id=”” align=”alignnone” width=”507”] 远程调试APP webview中的页面[/caption] [caption id=”” align=”alignnone” width=”506”] 远程调试微信webview中的页面[/caption] 不将就于console.re模拟调试、不局限于仅满足特定场景的调试方案，要就用最直接的开发工具，做有追求的开发者（追求高效、追求简单、追求纯粹、追求XX… ）。 迂回妥协的方案如：设置全局开关 然后判断页面运行环境切换开关 虽然也是经验的结晶，但终究影响开发效率和体验。 面对外部条件和环境给开发带来的不便，我们还是要保持有开发者的初心，而不是以此为理由降低对开发过程和自己的要求，相信有光，于是光就在前方不远处。","categories":[{"name":"建站❤编程","slug":"建站❤编程","permalink":"https://iffe.js.org/blog/categories/建站❤编程/"}],"tags":[{"name":"android","slug":"android","permalink":"https://iffe.js.org/blog/tags/android/"},{"name":"webview","slug":"webview","permalink":"https://iffe.js.org/blog/tags/webview/"},{"name":"调试","slug":"调试","permalink":"https://iffe.js.org/blog/tags/调试/"}]}]}