Nvue/Weex 使用Uniapp做了一个App，感觉性能不是很好，了解过Uniapp的Nvue，就想做一个纯Nvue项目，其实基本就是做一个Weex项目，不得不说坑是真的多，但是渲染性能真的是没得比 本项目开发环境为 UNIAPP 的 纯NVUE 项目，与WEEX有不同之处 https://github.com/WindrunnerMax/SW 一、 CSS选择器 1. 简单类选择器 /** Weex仅支持简单类选择器，不支持标签选择器以及子选择器 **/ /* 支持 */ .test{
需要注意的是，我这里格式化，会把width,height中间加一个空格，就不生效了
本篇将节操满满的安利Weex(˶‾᷄ ⁻̫ ‾᷅˵)，不一样的角度推荐你入坑，官网有的我们不拖泥，这里将给你补充官方没有的，深入到蹲坑给你排忧解难，总会给你点惊喜，内容越后越干，请紧张的往下看。
这次大会于 2016 年 12 月 17 日在广州的天虹酒店举办。演讲嘉宾有大漠，勾三股四等一些业界大牛们。特邀嘉宾有 Andrey Sitnik（PostCSS 的作者）和 Hax（贺师俊）。
GCanvas 提供了一套类似于 H5 Canvas 标准的 JavaScript API。基于这套 API 可以方便的去做图形绘制、动画渲染等，开发的体验与 H5 Canvas 是完全一样的。
这一篇来自于网易的前端工程师分享的一篇关于使用 Weex 开发网易严选的文章，内容非常的详细，认真，希望对大家能够有所帮助。 自打出生的那一天起，WEEX就免不了被拿来同React Native“一决高下”的命运。React Native宣称「Learn Once, Write Anywhere」，而WEEX宣称「Write Once, Run Everywhere」。在我看来，并没有谁更好，只有谁更合适。下面我将围绕WEEX入门进行讲解。 （如果你尚不了解React Native，并想简单入门，可以阅读【
今天，开源软件托管平台github上的阿里巴巴主页又增加了一个新项目：Atlas。Atlas意指巨人，它是Google闻名遐迩的波士顿机器人的外号，也是手机淘宝团队的移动容器化框架的代号。在去年的云栖
做安卓时间长了，接触到各种各样的框架，前前后后遇到了很多问题，这里顺便记录一下那些年在安卓开发的发展过程中的那些跨平台开发技术框架，大致如下：
做安卓时间长了，接触到各种各样的框架，前前后后遇到了很多问题，这里顺便记录一下那些年在安卓开发的发展过程中的那些跨平台开发技术框架，大致如下： 如有错误，欢迎指正。 （一）适合WebApp的一些框架 1、Cordova 优点： 开源免费，社区生态成熟，插件丰富 支持离线场景应用 开发工具选择空间大 缺点: 只提供基础访问设备的接口，需要自己搭配其他UI框架和JavaScript框架来搭配 2、Ionic 优点： 国外的一款接近原生的Html5移动App开发框架，免费开源。 漂亮的界面，追求性能，专注原生，免费开源 Angular JS MVVM 开发理念，数据双向绑定 基于Cordova，可以使用 Cordova 的插件 缺点： 需要掌握 HTML + CSS + Angular JS ，学习路线陡峭 Ionic 框架相比于原生的 Cordova 有所差异，Cordova 某些官方插件可能不适用于Ionic 3、Dcloud 优点： 国内厂商，中文文档 对HTML5的性能、工具、能力都做了深入扩展，提供 IDE 、云服务等帮助节省时间 MUI 更贴近国内App使用习惯，提供模块的详细例子，如登录，个人中心 缺点： 部分操作需要具备原生开发经验，如离线打包App 新产品仍然有bug，还需改进 4、小程序 2016年9月21日，微信小程序正式开启内测。2017年1月9日0点，微信第一批小程序正式低调上线。 微信小程序，是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或搜一下即可打开应用。 优点： 1.即用即走——这个是从微信小程序上线就开始打的概念。即用即走使得小程序可以代替许多APP，或是做APP的整体嫁接，或是作为阉割版功能的承载体。 2.倚靠微信流量——相比APP，小程序一个突出的优点是完全嵌入了微信的聊天、公众号体系，完美进行微信体系内的流量引导。这一方面令小程序更加容易获客，另一方面也可以借助微信的成熟社交网络达到爆发式传播。 3.连接线上线下——连接线上线下场景也是微信小程序重要的一环，甚至最先开始为了推动线下习惯的养成，小程序在线上场景方面做了较强的限制。由于人们用微信扫描二维码的习惯培养得比较好，小程序相比APP更容易达成线上线下场景的连接与互动。 缺点： 1.留存——虽然有部分小程序已经杀出重围，但是普遍来讲，主打“即用即走”的小程序在用户留存上仍存在很大的提升空间。阿拉丁发布的小程序白皮书中显示，小程序的平均次日留存在13%左右，但是双周留存骤降到仅有1%。轻易拥有的也不在意失去，这大概是小程序目前的一个症结所在。 2.受控于微信——比起APP，尤其是安卓版的高自由度，小程序要面对很多来自微信的限制，从功能接口，甚至到类别内容，都要接受微信的管控，部分敏感内容还很容易遭受封禁威胁。 部分参考链接：https://www.zhihu.com/question/263816362/answer/274417734 5、PWA PWA（Progressive Web App）是 Google 于 2016 年提出的概念，2017 年已被迅速采用。 PWA全称Progressive Web App，即渐进式Web应用。 一个PWA应用首先是一个网页, 可以通过Web技术编写出一个网页应用. 随后添加上App Manifest和Service Worker来实现PWA的安装和离线等功能。 解决了哪些问题？ 可以添加至主屏幕，点击主屏幕图标可以实现启动动画以及隐藏地址栏 实现离线缓存功能，即使用户手机没有网络，依然可以使用一些离线功能 实现了消息推送 它解决了上述提到的问题，这些特性将使得 Web 应用渐进式接近原生 App。 关于PWA更多详情介绍可以看以下博客介绍： https://segmentfault.com/a/1190000012353473 PWA的优势 可以将app的快捷方式放置到桌面上，全屏运行，与原生app无异 能够在各种网络环境下使用，包括网络差和断网条件下，不会显示undefind 推送消息的能力 其本质是一个网页，没有原生app的各种启动条件，快速响应用户指令 PWA存在的问题 支持率不高:现在ios手机端不支持pwa，IE也暂时不支持 Chrome在中国桌面版占有率还是不错的，安卓移动端上的占有率却很低 各大厂商还未明确支持pwa 依赖的GCM服务在国内无法使用 微信小程序的竞争 PWA写的app 比如这个：https://dd.shmy.tech/client （请使用谷歌浏览器打开） 6、Instant App 2016年的Google大会上，Google发布了有关Instant App的最新技术。千呼万唤之下，号称“Googl
还是失败，新出的东西官网还不是很完善，后面应该不会出现，这里花了几分钟找到了原因，项目少了hap-tools库， 这里没看到官网有这个库的介绍，package.json里也没 ap-tools 这个库的引入。
这篇文章是笔者近期关于Weex在iOS端的一些研究和实践心得，和大家一起分享分享，也算是对学习成果的总结。文章里面提到的做法也许不是最佳实践，也许里面的方法称不算是一份标准的指南手册，所以标题就只好叫“伪最佳实践指北”了。有更好的方法欢迎大家一起留言讨论，一起学习。
基于此运行npm run dev，你可以很快的跑起来一个Web项目。那么如果同一个项目，我想同时可以运行在Weex环境中，改如改造它？首先，我建议是把构建的环境区分好，在build目录下创建一个build-weex.js文件和webpack-weex-conf.js，这两个文件就是用专门处理构建weex bundle。
> 在自己的业务环境中使用，并开放给第三方isv，企业开发者使用，这是一篇有内涵有故事的文章。
这是来自Weex Document的介绍。这句话个人感觉还是非常有诱惑力的。为什么？击中移动端开发两个痛点。
weexpack 是 weex 新一代的工程开发套件，是基于weex快速搭建应用原型的利器。它能够帮助开发者通过命令行创建weex工程，添加相应平台的weex app模版，并基于模版从本地、GitHub 或者 weex 应用市场安装插件，快速打包 weex 应用并安装到手机运行，对于具有分享精神的开发者而言还能够创建weex插件模版并发布插件到weex应用市场。
早期H5和Hybrid方案的本质是，利用客户端App的内置浏览器（也就是webview）功能，通过开发前端的H5页面满足跨平台需求。比如PhoneGap cordova ionic ……
消息业务作为有赞移动的共享业务，在微商城、零售、美业等 B 端 App 中承担着多客服的角色，多客服是有赞为商家提供的连接商家和买家的即时消息客服工具；在精选、有赞客 C 端产品中扮演着用户联系商家的角色。在整个有赞产品中，是商家和用户沟通的桥梁，起着非常重要的作用。
大约两年前，为了写一本Weex的入门书籍，我花了几个月的时间学习了下Weex跨平台相关的知识。
近年来，伴随着大前端概念的提出和兴起，移动端和前端的边界变得越来越模糊，一大批移动跨平台开发框架和模式涌现出来。从早期的PhoneGap、Inoic 等Hybrid技术，到现在耳熟能详的React Native、WEEX和Flutter等跨平台技术，无不体现着移动端开发的前端化。 作为阿里巴巴开源的一套移动跨平台技术框架，WEEX框架最初是为了解决移动开发过程中频繁发版和多端研发的问题而开发的。具体来说，使用WEEX提供的跨平台开发技术，开发者可以很方便地使用Web前端技术来构建高性能、可扩展的原生性能体验，并支持在Android、iOS和Web等多平台上进行部署。 作为目前主流的跨平台技术框架之一，WEEX项目使用Vue.js进行编写，对于熟悉Web前端开发的开发者来说，其是一个不错的选择。在性能和项目迭代方面，WEEX与PhoneGap、Inoic等Hybrid技术相比也有一定的优势。 不过由于种种原因，WEEX的社区生态并不是很完善，也没有一本系统介绍WEEX的书籍。基于对跨平台技术的热爱，以及积累的一些WEEX项目实战经验，笔者思量再三决定对WEEX框架进行系统的梳理，并将其整理成书。 “路漫漫其修远兮，吾将上下而求索。”通过对WEEX技术的学习和本书的写作，笔者深刻地意识到“学无止境”的含义。如果本书对你学习WEEX有所帮助和启发，笔者将不胜欣慰。
关于weex的基础集成网上有很多博客，我就不重点介绍，今天主要分享一下weex文档中并没有的，在实际项目集成中的碰到的注意点和坑。满满的经验和干货，希望能对大家有所帮助。
摘要 Weex方案轻量，高性能，可扩展的特性能够提升饿了么一些业务的体验。因而我们做了些尝试和积累，给大家分享饿了么在 Weex方面的开发，文档，缓存，监控相关的经验。 饿了么前端场景 大量的在Web
自Vue.js 3.0爆出，三大主流框架，写法也是越来越相似，越来越贴近 WebComponents 标准，而周边应用层面的封装已经开始指数级增长。小程序是今年最火的技术，接连出现，快应用也想分一杯羹。PWA（Progressive Web App）进入稳定期，尤其是 PWA桌面版，可以让我们更好的看清楚 PC 桌面版开发的全貌。移动端还是以强运营为主，各大公司都开始不再 全力推动 移动端了，开始重视多端并进，到了开始拼细节的阶段了。TypeScript 全面开花，GraphQL 蠢蠢欲动，WebAssembly 更是打开了浏览器上多语言的大门。所有的这一切都在暗示，浏览器即操作系统，你能想象到未来前端的样子么？
Weex是一个移动端的动态化框架，它允许开发者用轻巧的 HTML/JS/CSS 开发多个端的 NativeApp。用 Weex只需写一份代码，便可运行在Android、iOS以及H5中，并且在 Android 和iOS上以Native UI的形式呈现，为用户提供更好的用户体验。
安装结束后你可以直接使用 weex 命令验证是否安装成功，它会显示 weex 命令行工具各参数：
出于对开发效率和动态化的要求，无线端的开发框架也一直在更新，从 Hybrid、结构化 Native View、React Native、Weex，再到现在正在大受关注的 Flutter。什么样的框架才是适合自己的团队？不仅要有技术追求，而且要考虑实际业务需要。最近，有赞移动选择了 weex 作为无线开发框架，搭建了从开发、Debug、构建、发布、数据一个闭环的流程。本文将对此进行分享。
在上一个系列文章中我们说到大前端一定是可以预见到的未来的趋势之一，那么从本篇文章中我将开启一个新的系列，从入门到深入，一步步走近大前端的核心腹地。计划本系列文章包含以下内容：
经过前面几篇Weex源码分析系列文章，相信大家对Weex是什么、Weex能带来什么、Weex是如何工作的等几个问题已经有了自己的答案。
作为一个纯iOS开发者，每次想学习web都是看两小时就放弃。这次希望自己能够坚持下去。关于weex与 react native，暂且不管有多少坑，先尝试踩一踩，毕竟踩坑也是站立在巨人肩上。本文仅仅作为个人学习笔记，欢迎留言沟通。
node是Weex代码构建中的必要依赖，npm是随同Node一起安装的包管理工具，解决nodeJS代码部署的问题。
首先我们来分析写这个界面，列出几个关键词：列表、Header、下拉刷新、上拉加载；如果使用Android原生开发的话我们会使用到列表组件、然后下拉刷新和上拉加载使用自定义控件的方式实现。
最近开始试水Weex开发，使用这么长一段时间，感觉写Weex还是非常方便的。作为一个Android开发，免不了要追查一下weex的sdk源码。今天，就以Weex SDK for Android为例，分析SDK的
摘要总结：本文主要介绍了Weex在跨平台移动应用开发上的实践方案，包括概述、代码结构、运行流程、实现细节、注意事项以及方案总结。通过介绍Weex在跨平台移动应用开发上的实践经验，帮助开发者更好地理解Weex并快速上手。
经过前面十篇文章，我们学习了Weex的使用、源码及架构分析，对Weex的优缺点和核心能力也有了认识。
在iOS工程中集成FrameWork无外乎两种，第一，项目支持cocoaPods，采用cocoaPods 集成 Weex iOS SDK到你的项目；第二，源码集成，优势在于可以修改WeexSDK，打包生成你自己定制的Weex SDK。 两种方式官网都提供了参考，虽然有些乱七八糟。
经过前面五篇文章的源码分析及总结，我们对Weex的整体架构及核心源码都有了清晰的认识。本篇文章主要总结我在Weex SDK源码阅读时觉得可以借鉴的细节。
原文链接：https://wetest.qq.com/lab/view/441.html
weex 集成过程在官网已经有比较详细的介绍（官网链接） 项目在立项初，决定使用 weex 混合开发框架运行在 iPad 端上。按照官网的流程，很顺利的创建了一个新 weex 空白项目 接下来，碰到了第一个坑。在项目工程路径下执行 weex run ios 命令后，发现没有 iPad 相关的模拟器，只有 iPhone 相关机型的。总不能和领导说，weex 不支持 iPad 端模拟器调试？ 想了想，既然 weex 调用的是 Xcode 中的模拟器，那么肯定会获取到 Xcode 中模拟器列表。如果强行给 weex 调用一个不存在的模拟器会发生什么？带着疑问，去尝试调了下，weex 果然报了错，而且给出了下面的 weex 内部文件报错路径
今天在移动端，尤其是像手机淘宝这样的 app 中，动态性问题逐渐成为一个比较棘手的问题。所谓动态性，就是把移动应用本身的灵活性、迭代更新的周期和成本优化到极致。比如手机淘宝的店铺首页，它允许商家实时装修自己的店铺，更新自家的商品、活动等信息；再比如淘宝、天猫每次大促的会场页面，要求我们非常灵活的及时调整界面信息和状态，确保在瞬息万变的活动当天紧跟促销节奏，应对各种突发情况。
我们期望能有一个解决Native与Weex交互的通用解决方案，简化业务方接入工作，也方便同个 Weex页面可以在不同模块或者不同 App进行正常渲染，因此 ZanWeexModuleSDK就孕育而生。下面将带大家逐步解析 ZanWeexModuleSDK设计方案。
好多人说Weex跨平台不错，一直要推荐我玩一下，我就不信了，来安装玩一下试试效果。实践出真知！安装过程各种坑，工具太多了，太麻烦了，差点放弃（还好坚持下来呢）。
安装 Node.js 环境成功后，npm 包管理工具也会自动安装成功 输入下面命令检查一下
weex 踩坑笔记 Write By CS逍遥剑仙 我的主页: www.csxiaoyao.com GitHub: github.com/csxiaoyaojianxian Email: sunjianfeng@csxiaoyao.com QQ: 1724338257 目录导航 weex 踩坑笔记 1. 基本说明 2. weex-toolkit的使用 2.1 配置入口js文件 2.2 基本命令 2.3 开发调试方式 3. 集成SDK 3.1 集成
这是一篇有故事的文章 --- 来自一个weex在生产环境中相爱相杀的小码农 故事一: Build 虽然weex的口号是一次撰写，多端运行, 但其实build环节是有差异的, native端构建需要使用weex-loader, 而web端则是使用vue-loader,除此以外还有不少差异点, 所以webpack需要两套配置。 最佳实践 使用webpack生成两套bundle,一套是基于vue-router的web spa, 另一套是native端的多入口的bundlejs 首先假设我们在src/views下开
关于为什么学习weex,这里不做解释,相信你下载了app目的就是要学会这个跨平台框架,本系列教程着重讲解使用weex开发如何开发项目,关于底层的原理,会在教程最后讲解。
跨平台一直是老生常谈的话题，cordova、ionic、react-native、weex、kotlin-native、flutter等跨平台框架的百花齐放，颇有一股推倒原生开发者的势头。（事实上更多是共存发展）看完本篇，相信你会对于当下跨平台移动开发的现状、实现原理、框架的选择等有更深入的理解。
首先，先解决上一章出现的坑。官网是提供解决方案的有效途径，既然不能用前端的开发模式在sublime编辑，那就选择回归weex官方教程的怀抱吧。在上一章已经搭建了weex的环境，直接开始创建weex工程。
在iOS中，weex可以类似理解为“放大版”的JSBrdige，weex代码的三部分构成：template(模版)、style(样式)、script(脚本)，本章重点了解weex的三要素与通用样式。
<web>组件： <web>组件用于在页面中嵌入一张网页，src用以指定资源地址。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
