最近再次更新了weex-toolkit，版本1.3.8，weexpack版本1.1.6。版本号有了小升级，没发现什么变化，文档更是感觉很久都没变化了。记录下自己发现的一些坑，只是处于探索研究阶段，很多实际开发的功能还没涉及，但仅这些皮毛已经有足够的理由放弃了。
Weex宣称是一次开发、多端适配，这点上比ReactNative需要针对不同端使用不同组件开发的方式看起来美好了很多，无论是成本还是效率，肯定都有巨大的益处。一旦你相信了，兴冲冲跑进去，才发现底下是一个多大的陷阱（如果能爬上来，肯定有很大进步?）。开发时，上层组件看起来是统一了，但下面其实是N多的多端适配补丁，只是将ReactNative多端开发的不同下移了，而且这个不同还是各端Native代码。
Weex总体思想是好的，帮开发者封装不同端的差异，只是感觉这个活刚干了表面一层，剩下就烂尾了。。。
页面跳转问题
页面跳转几乎就是web开发的核心，多页还是单页，对用户是体验感官问题，对开发者则是数据流程等基础架构问题。关于页面跳转weex文档并没有提及，严格说也是提及了，前提是读者有native开发经验。
单页内跳转
单页基于vue-router实现跳转，这种方式还是传统的web开发，能减少很多额外的问题。如果不在乎依赖包的版本比较老旧，那么基于weex-hacknews这个demo修改最简单，相对问题也少。
单页最大的问题，在于你的app就真的成了一个浏览器容器，每次打开都是一个全新的浏览器。
如果想基于weex-toolkit创建的项目做单页开发，需要自己调整很多东西，这个脚手架本身是为了多页而存在的。一些不成体系的趟坑经验见
多页跳转
这种方式不止是weex-toolkit脚手架应用，也是weex-ui所推荐的，但内层的机制却需要开发者熟悉native的跳转方式，关键这也是开发时必须熟知的。
针对三端（web端是为了方便开发），跳转方式和路径都是不同的：
- Web端，比较简单，使用document.location，跳转路径使用
/about.html形式。 - Android端，跳转要基于Activity（Android开发的基础概念，后续相关的不再备注），有两种方式，一是使用navigator模块，它使用action+category方式跳转Activity，因该模块中写死了category，不改变SDK的基础上，为了防止多个weex应用在被同样的category呼起时冲突，需使用第二种方式，即使用 event 模块，它会显式调用WXPageActivity(脚手架中的java类)，重新渲染当前Activity。跳转路径是本地资源路径
file://assets/dist/xxxx.js - iOs端，可以正常使用navigator模块（具体的跳转机制与Android不同，这块我不太熟）。跳转路径是本地路径
file://..../bundlejs/xxxx.js或 hot reload的http://.../xxxx.js
weex提供的navigator模块与event模块都是响应跳转路径的，但是event应该是比较老的方式，因为放到了脚手架源码中，反而可以作为自己开发的自定义模块方便控制。但在Android的跳转机制上，是刷新Activity，而不是跳转新的脚手架native部分的源码中，很大一部分是处理HotReload部分的，会导致与实际打包后引用业务js路径不同
统一封装一个跳转方法，实现区分代码如下：
/** * 跳转页面 * 根据传入的跳转相对路径（/about、/views/user等），对三端区别处理，添加前后缀 * 该方法可以通过Vue.mixin()机制全局注入，但src/entry.js中Vue.mixin()无法打包入weexjs，因此需要定义在src/lib/utils.js中 * @param String url 要跳转的地址 */export function jump (url) { let platform = weex.config.env.platform.toLowerCase(); if (url.indexOf('/') === 0) { if (platform === 'web') { url += '.html' } else { url = weex.config.bundleUrl.replace(/\/(views\/.+|[^\/]+)\.js$/, url + '.js') } } if (platform === 'android') { // android中navigator会根据action+category区分， // 为了防止多个weex应用呼起导致冲突，使用event模块方式跳转(显式调用intent) const event = weex.requireModule('event') event.openURL(url) } else { const navigator = weex.requireModule('navigator') navigator.push({url: url, animated: "true"}) }} 有一个需要注意的地方，就是脚手架中Android实现代码有bug，需要修复 WXPageActivity.java中 mUri 赋值问题，否则无论如何跳转，最终都是获取的初始加载页面：
try { // 注意这里添加了if块：如果uri不是hot reload传过来的对象，需要为mUri赋值 if (uri.toString().indexOf('{') != 0) { mUri = uri; } JSONObject initData = new JSONObject(uri.toString()); ...
flex布局问题
weex默认都是使用flex布局，但是这个布局使用，有一定的限制（仅描述我发现的，可能现象总结不准确）。
如果某个元素定义了 align-items:center，其下任意层级中再有flex布局的组件，不指定高度时，Android无法自动扩充（仅紧挨展现内容），iOs看不到渲染的内容。如果整个页面都保持没有这个特别的样式定义，那么Android是可以正常实现flex布局的自动扩充的。
宽高指定才好安排内容。weex宽度上按750px缩放，可能有细微像素差别，问题不大。可视高度随机型不同、虚拟按键和虚拟键盘收缩而不断变更，如果能自动扩展填充，相对会好很多。可能有些问题是native本身就带有的，比如虚拟键盘弹出，Android原生也是要做特别处理的。
weex-ui中很多组件，尤其是容器组件（一般是带有align-items样式定义的）是要求必须指定高度的，其中的wxc-minibar一类的组件还会减去顶部大概64px的大小，用来计算可视高度，但在虚拟按键存在的机型上，明显被遮挡部分内容。虽然有其他方法一直保持动态计算，但这种方案要求对每个容器都进行高度计算，对后期发展会造成很大的干扰。
欢迎尝试保证整个应用都不设定具体的高度，有可能会带来好的体验。
样式兼容问题
weex样式是无法简写的，虽然写起来比较麻烦，倒也没什么可吐槽的地方。只是iOs不支持层级样式，这点就比较奇葩了。
其他一些样式无效的都算小问题，就没有特别记录了，总有其他方式替代（margin、padding增加空白相互替换等）。
登录态保持
没有cookie，无法自动记录，需要用到storage存储来替代。
因为是多页面，要注意每个页面都是同一套逻辑来检查（check storage->check api）。习惯了单页面总觉得很浪费资源。
组件扩展
按文档做就好了，相对比较简单。唯一需要注意的是native编写完毕后，注意前端的js部分，也要把新组件注册上。
这小半年中，小程序的文档更新的都嫌太快，weex却是一直这个样子，更新最快的恐怕是weex的趟坑记录吧。