一、背景达人有通过视频号带货来进行流量变现的需求，但部分有赞商家由于是个人小程序不支持卖货，所以无法获得微信内的公域流量。   现在微信侧给服务商提供了创建个人升级版小程序的能力，所以有赞紧随微信功能更新的脚步，立即帮商家接入该能力，针对个人认证的商家提供了快速创建个人升级版小程序的功能，实现他们的经营需求。   二、个人升级版小程序、企业认证小程序说明[图片] 备注：个人升级版小程序可卖货，且仅审核通过的商品在小程序上卖货。 附：视频号直播带货开通指南，点击查看详情  三、个人升级版小程序创建指引1、代创建流程路径：有赞微商城店铺后台--店铺--微信小程序--快速注册   1）点击下图中的"立即创建"，会弹出二维码 [图片] 2）打开微信扫码，按流程一步步完成小程序创建   注： 务必用和店铺认证的个人信息一致的微信号扫码，且一个微信号最多能注册5个小程序创建成功后，小程序名称为微信分配的默认的小程序名称，以gh_开头， 请在发布前完成小程序名称的修改[图片][图片][图片][图片][图片][图片][图片][图片][图片][图片][图片][图片][图片][图片] 2、设置小程序支付方式代创建完后需要设置下支付方式，点击"支付设置"，选择"境内"或"境外"，然后到详情页面进行详细的设置。 注：支付方式设置过程中需要先完成"微信支付开户意愿确认"，预计需要2个工作日，请耐心等待。 [图片][图片] 3、完善小程序基本信息，前往发布完善小程序基本信息，前往微信小程序-基本信息页面，可点击立即发布小程序，等待微信审核完后即可试用。   注： 发布前请设置你的小程序名称、小程序类目 若未设置则无法发布小程序类目建议设置为：工具 > 信息查询[图片] 四、个人主体小程序商品管理1、小程序创建成功后，所有的商品会同步至微信审核，仅审核通过的商品才可在小程序售卖。 2、若后续你有新的商品要在小程序上售卖， 请前往 店铺-微信小程序-商品管理管理你要售卖的商品。 [图片] 五、问题说明1、个人升级版小程序有别于个人小程序，个人升级版小程序只能通过服务商进行创建，而且可以支持交易 2、个人升级版小程序的商品必须要送到微信进行审核，审核通过的商品才能够拉起支付弹框 3、试用小程序支持转正为个人升级版小程序 4、个人升级版小程序不支持直播 5、代创建流程中的每一步都会记录，如果中途失败，再开始创建的时候会回到之前失败前的那一步 6、代创建过程中电脑端和手机端的同步主要技术方式是轮循 7、在代创建流程中调用微信接口获取到的状态变化见下图： [图片] 六、总结本文主要介绍了，个人升级版小程序的代创建、发布流程，以及相关问题说明，希望无论是商家还是其他研发者看到，都能够有所帮助。

众所周知，小程序当中有一类特殊的内置组件——原生组件，这类组件有别于 WebView 渲染的内置组件，他们是交由原生客户端渲染的。原生组件作为 Webview 的补充，为小程序带来了更丰富的特性和更高的性能，但同时由于脱离 Webview 渲染也给开发者带来了不小的困扰。在小程序引入「同层渲染」之前，原生组件的层级总是最高，不受 [代码]z-index[代码] 属性的控制，无法与 [代码]view[代码]、[代码]image[代码] 等内置组件相互覆盖， [代码]cover-view[代码] 和 [代码]cover-image[代码] 组件的出现一定程度上缓解了覆盖的问题，同时为了让原生组件能被嵌套在 [代码]swiper[代码]、[代码]scroll-view[代码] 等容器内，小程序在过去也推出了一些临时的解决方案。但随着小程序生态的发展，开发者对原生组件的使用场景不断扩大，原生组件的这些问题也日趋显现，为了彻底解决原生组件带来的种种限制，我们对小程序原生组件进行了一次重构，引入了「同层渲染」。 相信已经有不少开发者已经在日常的小程序开发中使用了「同层渲染」的原生组件，那么究竟什么是「同层渲染」？它背后的实现原理是怎样的？它是解决原生组件限制的银弹吗？本文将会为你一一解答这些问题。 什么是「同层渲染」? 首先我们先来了解一下小程序原生组件的渲染原理。我们知道，小程序的内容大多是渲染在 WebView 上的，如果把 WebView 看成单独的一层，那么由系统自带的这些原生组件则位于另一个更高的层级。两个层级是完全独立的，因此无法简单地通过使用 [代码]z-index[代码] 控制原生组件和非原生组件之间的相对层级。正如下图所示，非原生组件位于 WebView 层，而原生组件及 [代码]cover-view[代码] 与 [代码]cover-image[代码] 则位于另一个较高的层级： [图片] 那么「同层渲染」顾名思义则是指通过一定的技术手段把原生组件直接渲染到 WebView 层级上，此时「原生组件层」已经不存在，原生组件此时已被直接挂载到 WebView 节点上。你几乎可以像使用非原生组件一样去使用「同层渲染」的原生组件，比如使用 [代码]view[代码]、[代码]image[代码] 覆盖原生组件、使用 [代码]z-index[代码] 指定原生组件的层级、把原生组件放置在 [代码]scroll-view[代码]、[代码]swiper[代码]、[代码]movable-view[代码] 等容器内，通过 [代码]WXSS[代码] 设置原生组件的样式等等。启用「同层渲染」之后的界面层级如下图所示： [图片] 「同层渲染」原理 你一定也想知道「同层渲染」背后究竟采用了什么技术。只有真正理解了「同层渲染」背后的机制，才能更高效地使用好这项能力。实际上，小程序的同层渲染在 iOS 和 Android 平台下的实现不同，因此下面分成两部分来分别介绍两个平台的实现方案。 iOS 端 小程序在 iOS 端使用 WKWebView 进行渲染的，WKWebView 在内部采用的是分层的方式进行渲染，它会将 WebKit 内核生成的 Compositing Layer（合成层）渲染成 iOS 上的一个 WKCompositingView，这是一个客户端原生的 View，不过可惜的是，内核一般会将多个 DOM 节点渲染到一个 Compositing Layer 上，因此合成层与 DOM 节点之间不存在一对一的映射关系。不过我们发现，当把一个 DOM 节点的 CSS 属性设置为 [代码]overflow: scroll[代码] （低版本需同时设置 [代码]-webkit-overflow-scrolling: touch[代码]）之后，WKWebView 会为其生成一个 [代码]WKChildScrollView[代码]，与 DOM 节点存在映射关系，这是一个原生的 [代码]UIScrollView[代码] 的子类，也就是说 WebView 里的滚动实际上是由真正的原生滚动组件来承载的。WKWebView 这么做是为了可以让 iOS 上的 WebView 滚动有更流畅的体验。虽说 [代码]WKChildScrollView[代码] 也是原生组件，但 WebKit 内核已经处理了它与其他 DOM 节点之间的层级关系，因此你可以直接使用 WXSS 控制层级而不必担心遮挡的问题。 小程序 iOS 端的「同层渲染」也正是基于 [代码]WKChildScrollView[代码] 实现的，原生组件在 attached 之后会直接挂载到预先创建好的 [代码]WKChildScrollView[代码] 容器下，大致的流程如下： 创建一个 DOM 节点并设置其 CSS 属性为 [代码]overflow: scroll[代码] 且 [代码]-webkit-overflow-scrolling: touch[代码]； 通知客户端查找到该 DOM 节点对应的原生 [代码]WKChildScrollView[代码] 组件； 将原生组件挂载到该 [代码]WKChildScrollView[代码] 节点上作为其子 View。 [图片] 通过上述流程，小程序的原生组件就被插入到 [代码]WKChildScrollView[代码] 了，也即是在 [代码]步骤1[代码] 创建的那个 DOM 节点对应的原生 ScrollView 的子节点。此时，修改这个 DOM 节点的样式属性同样也会应用到原生组件上。因此，「同层渲染」的原生组件与普通的内置组件表现并无二致。 Android 端 小程序在 Android 端采用 chromium 作为 WebView 渲染层，与 iOS 不同的是，Android 端的 WebView 是单独进行渲染而不会在客户端生成类似 iOS 那样的 Compositing View (合成层)，经渲染后的 WebView 是一个完整的视图，因此需要采用其他的方案来实现「同层渲染」。经过我们的调研发现，chromium 支持 WebPlugin 机制，WebPlugin 是浏览器内核的一个插件机制，主要用来解析和描述embed 标签。Android 端的同层渲染就是基于 [代码]embed[代码] 标签结合 chromium 内核扩展来实现的。 [图片] Android 端「同层渲染」的大致流程如下: WebView 侧创建一个 [代码]embed[代码] DOM 节点并指定组件类型； chromium 内核会创建一个 [代码]WebPlugin[代码] 实例，并生成一个 [代码]RenderLayer[代码]； Android 客户端初始化一个对应的原生组件； Android 客户端将原生组件的画面绘制到步骤2创建的 [代码]RenderLayer[代码] 所绑定的 [代码]SurfaceTexture[代码] 上； 通知 chromium 内核渲染该 [代码]RenderLayer[代码]； chromium 渲染该 [代码]embed[代码] 节点并上屏。 [图片] 这样就实现了把一个原生组件渲染到 WebView 上，这个流程相当于给 WebView 添加了一个外置的插件，如果你有留意 Chrome 浏览器上的 pdf 预览，会发现实际上它也是基于 [代码]<embed />[代码] 标签实现的。 这种方式可以用于 map、video、canvas、camera 等原生组件的渲染，对于 input 和 textarea，采用的方案是直接对 chromium 的组件进行扩展，来支持一些 WebView 本身不具备的能力。 对比 iOS 端的实现，Android 端的「同层渲染」真正将原生组件视图加到了 WebView 的渲染流程中且 embed 节点是真正的 DOM 节点，理论上可以将任意 WXSS 属性作用在该节点上。Android 端相对来说是更加彻底的「同层渲染」，但相应的重构成本也会更高一些。 「同层渲染」 Tips 通过上文我们已经了解了「同层渲染」在 iOS 和 Android 端的实现原理。Android 端的「同层渲染」是基于 chromium 内核开发的扩展，可以看成是 webview 的一项能力，而 iOS 端则需要在使用过程中稍加注意。以下列出了若干注意事项，可以帮助你避免踩坑： Tips 1. 不是所有情况均会启用「同层渲染」 需要注意的是，原生组件的「同层渲染」能力可能会在特定情况下失效，一方面你需要在开发时稍加注意，另一方面同层渲染失败会触发 [代码]bindrendererror[代码] 事件，可在必要时根据该回调做好 UI 的 fallback。根据我们的统计，目前同层失败率很低，也不需要太过于担心。 对 Android 端来说，如果用户的设备没有微信自研的 [代码]chromium[代码] 内核，则会无法切换至「同层渲染」，此时会在组件初始化阶段触发 [代码]bindrendererror[代码]。而 iOS 端的情况会稍复杂一些：如果在基础库创建同层节点时，节点发生了 WXSS 变化从而引起 WebKit 内核重排，此时可能会出现同层失败的现象。解决方法：应尽量避免在原生组件上频繁修改节点的 WXSS 属性，尤其要尽量避免修改节点的 [代码]position[代码] 属性。如需对原生组件进行变换，强烈推荐使用 [代码]transform[代码] 而非修改节点的 [代码]position[代码] 属性。 Tips 2. iOS 「同层渲染」与 WebView 渲染稍有区别 上文我们已经了解了 iOS 端同层渲染的原理，实际上，WebKit 内核并不感知原生组件的存在，因此并非所有的 WXSS 属性都可以在原生组件上生效。一般来说，定位 (position / margin / padding) 、尺寸 (width / height) 、transform (scale / rotate / translate) 以及层级 (z-index) 相关的属性均可生效，在原生组件外部的属性 (如 shadow、border) 一般也会生效。但如需对组件做裁剪则可能会失败，例如：[代码]border-radius[代码] 属性应用在父节点不会产生圆角效果。 Tips 3. 「同层渲染」的事件机制 启用了「同层渲染」之后的原生组件相比于之前的区别是原生组件上的事件也会冒泡，意味着，一个原生组件或原生组件的子节点上的事件也会冒泡到其父节点上并触发父节点的事件监听，通常可以使用 [代码]catch[代码] 来阻止原生组件的事件冒泡。 Tips 4. 只有子节点才会进入全屏 有别于非同层渲染的原生组件，像 [代码]video[代码] 和 [代码]live-player[代码] 这类组件进入全屏时，只有其子节点会被显示。 [图片] 总结 阅读本文之后，相信你已经对小程序原生组件的「同层渲染」有了更深入的理解。同层渲染不仅解决了原生组件的层级问题，同时也让原生组件有了更丰富的展示和交互的能力。下表列出的原生组件都已经支持了「同层渲染」，其他组件（ textarea、camera、webgl 及 input）也会在近期逐步上线。现在你就可以试试用「同层渲染」来优化你的小程序了。 支持同层渲染的原生组件 最低版本 video v2.4.0 map v2.7.0 canvas 2d（新接口） v2.9.0 live-player v2.9.1 live-pusher v2.9.1

自定义导航栏的一些常见问题： 1、怎么适配手机状态栏高度，使导航栏与胶囊按钮对齐？ 2、写了导航栏组件但是用了fixed定位，脱离普通文档流，要麻烦的去每个页面加padding-top。 3、怎么让导航栏跟page融合到一起，跟随page滚动，这样就不用在这个页面单独适配状态栏了。 4、怎么自动识别非首页启动的小程序，在自定义导航栏加个返回首页的引导？ 使用案例可导入代码片段【现在导入】查看。 子页面 [图片][图片] [图片] 非首页启动的小程序 [图片] 跟随页面，不置顶。 [图片] 监测滚动切换导航栏的显示或隐藏。 [图片] -----------------------------------------------------------------------------------------------------------------------------------------

是否有方法可以判断当前运行环境是体验版或正式版？

以下整理了常见的真机调试控制台报错，以及建议的解决方法。 1、扫描二维码出现 “-50003” 的错误 出现此错误时，可以尝试在工具上登出开发者账户，切换开发者账号，重开项目再试一次。如果不能解决，可以在此贴评论，我们会后台排查原因。 2、控制台出现报错，第一条报错信息是 “Cannot read 'toLowerCase' of undefined” 这是一个底层模块的导致的问题，部分机器会出现。由于出现频率较低，此问题仍在排查修复中。如果出现此错误，可以尝试退出所有项目、关闭工具，然后重新启动电脑。如果不能解决，可以尝试先将工具手动完全卸载，重新启动，然后再安装最新的版本。 3、控制台出现报错，第一条报错信息是 “define is not defined” 这是微信客户端上的某个新改动引起的。最新的 RC、Nightly 工具已经修复了这个问题，可以尝试下载安装再试一次： Nightly 版本： https://developers.weixin.qq.com/miniprogram/dev/devtools/nightly.html RC 版本： https://developers.weixin.qq.com/miniprogram/dev/devtools/rc.html 4、控制台出现报错，第一条报错信息是 “Cannot assign to readonly property xxx of xxx #.<object>” 这是微信客户端上的某个新改动引起的。最新的 RC、Nightly 工具已经修复了这个问题，可以尝试下载安装再试一次： Nightly 版本： https://developers.weixin.qq.com/miniprogram/dev/devtools/nightly.html RC 版本： https://developers.weixin.qq.com/miniprogram/dev/devtools/rc.html 5、控制台出现报错 “Async stack traces in debugger are not available on 32bit platforms” 如果操作系统是 64 位的，请尝试下载安装 64 位的工具。如果操作系统是 32 位的，可以忽略这个报错。 6、控制台报错 “TimeoutOverflowWarning” 请排查项目代码是否存在 setTimeout 的时间参数存在类似 Infinity 等很大的数字。 7、右侧面板出现警告 “Error sync-0” 的问题 如果不影响小程序的加载，可以忽略此问题。如果小程序无法加载，请确认将微信客户端和工具都升级到了最新的版本。 如果开发者有其他问题，可以在此提出。

不知道大家注意image组件没有，img组件里面有一个binderror属性。 binderror 当错误发生时触发，event.detail = {errMsg} 我们利用这个属性，当图片访问失败时就会访问我们自定义的函数。 好，首先我们在data里面有一个图片数组 [图片] wxml循环输出这个图片数组 同时给图片绑定数据data-index 为循环的序号 {{index}} [图片] 看一下界面（ps：第三个图片我故意写错地址） [图片] 然后我们写图片访问失败函数，很简单，直接替换images中序号为index的图片地址为我们的默认图片地址 [图片] 欧了，看一下效果 [图片]

一、写作背景 接触小程序一年多，真实体验就是小程序开发门槛相对而言确实比较低。不过小程序的开发方式，一直是开发者吐槽的，如习惯了 Vue，React 开发的开发者经常会吐槽小程序一个 Page 必须由多个文件组成，组件化支持不完善或者说不能非常愉快的开发组件。在以前小项目中没太大感觉，从加入有赞，参与有赞微商城小程序的开发，是真切的体会到对于大型小程序项目开发的复杂性。 有赞从微信小程序内测就开始开发小程序，在不支持自定义组件的时代，只能通过 import 的形式拆分模块或实现组件。在业务复杂的页面，可能会 import 非常多的模块，而相应的 wxss 也需要 import 样式，除了操作繁琐，有时候也难免遗漏。 作为开发者，我们当然希望可以让工作更简单，更愉快，也希望改善我们的开发方式。所以希望能够更了解微信小程序框架，减少不必要的试错，于是有了一次对小程序框架的 debug 之旅。(基础库 1.9.93) 通过三周空余时间的 debug，也算对小程序框架有了一些浅显的认识，达到了最初的目的；对小程序启动，实例，运行等有了真切的体会。这篇文章记录了小程序框架的基本代码结构，启动流程，以及程序实例化过程。 本文的目的是希望把我看到的分享给对小程序感兴趣或者正在开发小程序的读者，主要解答“框架对传入的对象等到底做了什么”。 二、从启动流程一窥小程序框架细节 在开发者工具中使用 help() 方法，可以查看一些指令和方法。使用其中的 openVendor 方法可以打开微信开发者工具在小程序框架所在目录。其中以包括以基础库命名的目录和其他帮助文件，如其中有两个工具 wcc，wcsc。wcc 可把 wxml 转换为对应的 JS 函数 —— $gwx(path, global)，wcsc 可将 wxss 转换为 css。而基础库目录包括 WAService.js 和 WAWebview.js 文件。小程序框架在开发者工具中以 WAService.js 命名（WAWebview.js 不知其作用，听说在真机环境使用该文件）。 在开发中工具命令行使用 document.head 可以查看到小程序的启动流程大致如下： [图片] 以小节的方式分别介绍这些流程，小程序是如何处理的（小节编号与图中编号相同）。 1、初始化全局变量 下图是小程序启动是初始化的一些全局的变量： [图片] 那些使用“__”开头，未在文档中提及可使用变量是不建议使用的，wxAppCode 在开发者工具中分为两类值，json 类型和 wxml 类型。以 .json 结尾的，其 key 值为开发者代码中对应的 json 文件的内容，.wxml 结尾的，其 key 值为通过调用 $gwx(’./pages/example/index.wxml’) 将得到一个可执行函数，通过调用这个函数可得到一个标识节点关系的 JSON 树。 [图片] 2、加载框架（WAService.js） 使用工具对 WAService.js 进行格式化后进行 debug。可以发现小程序框架大致由： WeixinJSBridge、 NativeBuffer、 wxConsole、 WeixinWorker、 JavaScript兼容（这部分为猜测）、 Reporter、 wx、 exparser、 virtualDOM、 appServiceEngine 几部分组成。 其中除了 wx 和 WeixinJSBridge 这两个基础 API 集合， exparser, virtualDOM, appServiceEngine 这三部分作为框架的核心， appServiceEngine 提供了框架最基本的接口如 App，Page，Component； exparser 提供了框架底层的能力，如实例化组件，数据变化监听，view 层与逻辑层的交互等；而 virtualDOM 则起着链接 appServiceEngine 和 exparser 的作用，如对开发者传入 Page 方法的对象进行格式化再传入 exparser 的对应方法处理。 框架对外暴露了以下API：Behavior，App，Page，Component，getApp，getCurrentPages，definePlugin，requirePlugin，wx。 3、业务代码的加载 在小程序中，开发者的 JavaScript 代码会被打包为 [代码]define('xxx.js', function(require, module, exports, window, document, frames, self, location, navigator, localStorage, history, Caches, screen, alert, confirm, prompt, fetch, XMLHttpRequest, WebSocket, webkit, WeixinJSCore, Reporter, print, WeixinJSBridge) { 'use strict'; // your code }) [代码] 这里的 define 是在框架中定义的方法，在框架中提供了两个方法：require 和 define 用来定义和使用业务代码。其方式有些像 AMD 规范接口，通过 define 定义一个模块，使用 require 来应用一个模块。但是也有很大区别，首先 define 限制了模块可使用的其他模块，如 window，document；其次 require 在使用模块时只会传入 require 和 module，也就是说参数中的其他模块在定义的模块中都是 undefined，这也是不能在开发者工具中获取一些浏览器环境对象的原因。 在小程序中，JavaScript 代码的加载方式和在浏览器中也有些不同，其加载顺序是首先加载项目中其他 js 文件（非注册程序和注册页面的 js 文件），其次是注册程序的 app.js，然后是自定义组件 js 文件，最后才是注册页面的 js 代码。而且小程序对于在 app.js 以及注册页面的 js 代码都会加载完成后立即使用 require 方法执行模块中的程序。其他的代码则需要在程序中使用 require 方法才会被执行。 下面详细介绍了 app.js，自定义组件，页面 js 代码的处理流程。 4、加载 app.js 与注册程序 在 app.js 加载完成后，小程序会使用 require(‘app.js’) 注册程序，即对 App 方法进行调用，App 方法是对 appServiceEngine.App 方法的引用。 下图是框架对于 App 方法调用时的处理流程： [图片] App 方法根据传入的对象实例化一个 app 实例，其生命周期函数 onLaunch 和 onShow 因为使用不同的方式获取 options的参数。在有些需要根据场景值来实现需求的，或许使用 onShow 中的场景值更合适。 在实际开发过程中发现，在微信顶部唤起小程序和在小程序列表唤起的 options 也是不一样的。在该案例中通过点击分享的小程序进入后，关闭小程序，再通过不同方式进入小程序，通过顶部唤起的还是 options 的 path 属性还是分享出来的 path，但是通过列表中打开直接回到了首页，这里 App 中的 onShow 就会获取到不同的 options。 5、加载自定义组件代码以及注册自定义组件 自定义组件在 app.js 之后被加载，小程序会在这个过程中加载完所有的自定义组件（分包中自定义组件没有有测试过），并且是加载完成后自动注册，只有注册完成后才会加载下一个自定义组件的代码。 下图是框架对于 Component 方法处理流程： [图片] 图中介绍了框架如何对传入 Component 方法的对象的处理，其后面还有很多深入的对于组件实例化的步骤没有在图中表示出来，具体可以在文章最后的附件中查看。 自定义组件在小程序中越来越完善，其拥有的能力也比 Page 更强大，而后面会提到在使用自定义组件的 Page 中，Page 实例也会使用和自定义组件一样的实例化方式，也就是说，他拥有和自定义组件一样的能力。 6、加载页面代码和注册页面 加载页面代码的处理流程和加载自定义组件一样，都是加载完成后先注册页面，然后才会加载下一个页面。 下图是注册一个页面时框架对于 Page 方法的处理流程： [图片] Page 方法会根据是否使用自定义组件做不同的处理。使用自定义组件的 page 对象会被处理为和自定义组件的结构，并在页面实例化时使用不同的处理流程进行实例化。当然对于开发而言没任何不同。 从图中可以发现 Page 传入的（生命周期）代码并不会在这里被执行，可以通过下面小节了解 Page 实例化的详细过程。 7、等待页面 Ready 和 Page 实例化 还记得上面介绍的启动流程中最后一步等待页面 Ready？严格来讲是等待浏览器 Ready，小程序虽然有部分原生的组件，不过本质上还是一个 web 程序。 在小程序中切换页面或打开页面时会触发 onAppRoute 事件，小程序框架通过 wx.onAppRoute 注册页面切换的处理程序，在所有程序就绪后，以 entryPagePath 作为入口使用 appLaunch 的方式进入页面。 下图是处理导航的程序流程： [图片] 从图中可以看出页面的实例化是在进入页面时进行，下图是具体的实例化过程： [图片] 下图是最终可得到 Page 实例： [图片] 可以发现其中多了 onRouteEnd API，实际该接口不会被调用。其中以 component 标记的表示只有在使用了自定义组件时才会有的方法和属性。在前面第 5 小节提到了对于使用自定义组件的页面会按照自定义组件方式解析，这些属性和方法与自定义组件表现一致。 8、关于 setData 小程序框架是一个以数据驱动的框架，当然不能少了对他如何实现数据绑定的探索，下图是 Page 实例的 setData 执行流程： [图片] 其中 component:setData 表示使用自定义组件的 Page 实例的 setData 方法。 三、写在最后 这是一次不完全的小程序框架探索，是在微信开发工具中 debug 的结果。虽然对于实际开发没有什么太大的帮助，但是对框架如何对开发的 js 代码进行处理有了一个很明确的认识，在使用一些 js 特性时可以有明确的感知。如果你还疑惑“小程序框架对传入的对象等到底做了什么”那一定是我表达能力太差，说声对不起。 通过这一次 debug ，也给我引入了新的问题，还希望能够有更多的讨论： · 自定义组件太多启动时会耗时处理自定义组件 · 文件太多会耗时读文件 · 合理的设计分包很重要 当然最后对于框架中已有的能力，还是非常希望微信可以开放更多稳定的接口，并在文档中告知开发者，让开发变得简单一些。

特性Learn Once, Write Anywhere(小程序、小游戏、PC Web、Mobile Web) Write Once, Run Anywhere(小程序、小游戏、Web只需要修改[代码]new Stage[代码]传入参数即可) 支持小程序、小游戏以及 Web 浏览器渲染 小程序、小游戏和 Web 拥有相同简洁轻巧的 API 高性能且松耦合的渲染架构 超轻量级的代码体积 支持 Canvas 元素管理 支持 Canvas 元素事件体系 图灵完备的 group 嵌套体系 内置 to2to 的跨平台运动引擎 支持可以变形的 clip 裁剪体系 内置文本、位图、序列帧、绘图对象和多种矢量绘制对象 支持 SVG Path 渲染 支持几乎全部的 CSS 滤镜和其他常用滤镜 内置图片加载器 ——以上内容出自：https://github.com/dntzhang/cax

WeApp-Workflow 是一个专门为开发微信小程序打造的前端开发工作流，基于Gulp 4 开发，旨在通过工作流的方式解决微信小程序开发过程中写前端代码的痛点。 # 功能介绍 SCSS 实时编译为 WXSS WXSS(CSS) 中px 单位转小程序单位rpx图片压缩自动上传图片到CDN 并更新路径为https 绝对路径Font 文件转为base64 编码 全自动构建雪碧图及生成相应CSS更多请看如下介绍：

[图片] 非自定义导航栏高度怎么计算？ 自定义导航栏高度由谁决定？ 小程序自定义导航栏开发注意点与参考文档 一、默认导航栏高度怎么计算？（非custom情况下获取） wx.getSystemInfo 和 wx.getSystemInfoSync 获取机器信息 screenHeight - windowHeight   计算标题栏高度 [代码]{[代码][代码]       [代码][代码]'iPhone'[代码][代码]: 64,[代码][代码]       [代码][代码]'iPhone X'[代码][代码]: 88,[代码][代码]       [代码][代码]'android'[代码][代码]: 68[代码][代码] [代码][代码]}[代码]不完全统计（ip6 , ip5 , ip6p , ipx , 小米mix2  , 小米5等综合了开发工具提供的数据和真机数据）所得 二、自定义导航栏高度由谁决定？（自定义情况下，屏幕高度和窗口高度没有差别，所以要通过步骤1先获取数据，预定义到代码中） 开发时发现，自定义导航栏的实现需要 包含状态栏+胶囊 ：没有自定义导航栏的时候页面是全屏幕滚动会出现在状态栏的下一层 根据上一标题中步骤1的函数，可以获得状态栏高度 statusBarHeight demo，点击打开小程序开发工具 三、小程序自定义导航栏开发注意点与参考文档 微信官方设计指导中关于胶囊按钮的描述 由此得知胶囊宽度87pt=116px，设置之后，的确能产生较好的兼容性效果 社区Q&A：自定义标题栏高度计算、在 navigationStyle: 'custom',苹果X和8兼容问题 注意某些方法、参数的兼容性，时刻关注官方更新信息 开一个项目采集设备的screenHeight,windowHeight,pixelRatio等信息到一个数据库中，或者微信可以提供这样一个数据库便于计算，亦或者微信优化自定义标题栏（譬如通知栏可以改变颜色但不要算在自定义范围内，给出胶囊宽高到通知栏距离到右侧屏幕边框距离等相关参数）