小程序推荐 1、在平时 开发，我们经常会遇到内容安全监测的服务，推荐官方小程序 如需体验、接入安全能力，请扫一扫如下小程序二维码进行详细了解。 珊瑚内容安全助手 [图片] 占位 2、在测试小程序时，时常遇到手机兼容性问题，可以扫码获取手机具体信息 [图片] 具体扫码截图如下所示 [图片] [图片] [图片]

我们都知道，JavaScript是有5种原始类型的： number string boolean undefined null 检测原始类型 检测原始类型的最佳选择是使用[代码]typeof[代码] [代码]typeof 'abc' // string typeof 123 // number typeof true // boolean typeof undefined // undefined [代码] [代码]typeof[代码]有一个好处就是：未声明的变量也不会报错 [代码]typeof someVariable //此时someVariable是未定义，返回undefined [代码] 检测复合类型 复合类型内置有（不只以下几种，只是举例说明）： Object Array Date Error 当我们使用[代码]typeof[代码]检测的时候，就会看到都是返回object [代码]typeof {} //object typeof [] //object typeof new Date() //object typeof new Error() //object [代码] 此时的最佳选择是使用[代码]instanceof[代码] [代码]var today = new Date() today instanceof Date // true [代码] 到这里好像全部的检测类型都搞定了。 但是，检测类型并不能这么简单地分为原始类型和复合类型，因为复合类型会涉及到构造函数的问题。 检测函数 当我们的页面内嵌了其他的frame时，问题就来了。因为不同的frame的构造函数是独立的，即会发生以下问题： [代码]// 在frame A定义的函数test function test(){} // 在frame B检测 test instanceof Function //false // 而使用typeof则可以正确返回 typeof test // function [代码] 故检测函数的时候，最佳选择是使用[代码]typeof[代码] 检测数组 数组的问题和函数是一样的，因为不同的构造函数。而此时[代码]typeof[代码]也不灵了，因为只返回object。 Douglas Crockford则提供了一种叫duck typing(鸭式辩型)的方式： [代码]function isArray(value){ return typeof value.sort === 'function'; } [代码] 其实，这种方式是默认的认为只有数组才有sort方法。其实传入任何有sort方法的对象也是返回true的。因此这个方法并不完美。 最终的解决方案也是ECMAScript 5的实现方案，就是来自Kangax大神的方法： [代码]function isArray(value){ return Object.prototype.toString.call(value) === '[object Array]' ; } [代码] 这个方法能完美地辨别是否为数组。 在ECMAScript 5则可以使用Array的内置方法： [代码]Array.isArray([]) // true [代码] 检测属性 我发现，在检测一个对象的属性是否存在的时候，常常是这样的： [代码]if(object.someProps){ //一些逻辑 } [代码] 或者是这样的： [代码]if(object.someProps != null){ //一些逻辑 } [代码] 或者是这样的： [代码]if(object.someProps != undefined){ //一些逻辑 } [代码] 其实以上都是有问题的！因为以上方式都忽略了object可能存在假值的情况（即是属性存在，但是等于null或者undefined或者0或者false或者空字符串等等）。因此最佳的方式是使用[代码]in[代码]运算符： [代码]if(someProps in object){ //一些逻辑 } [代码] 以上检测数据类型的所有方式。 参考： 《Maintainable JavaScript》

再次开始之前先问几个问题： 你是否知道[代码]Page[代码]生命周期 与 [代码]pagelifetimes[代码] 生命周期执行顺序? 你是否知道[代码]behaviors[代码]中的生命周期与组件生命周期执行顺序? 你是否知道[代码]Page[代码]生命周期 与 组件[代码]pagelifetimes[代码]生命周期执行顺序? 要回答上面的问题，首先我们看看小程序生命周期有哪些： App onLaunch onShow onHide Page onLoad onShow onReady onHide onUnload Component created attached ready moved detached 想一下加载一个页面（包含组件）的加载顺序，按照直觉小程序加载顺序应该是这样的加载顺序（以下列子中[代码]Component[代码]都是同步组件）： App（onLaunch） -> Page(onLoad) -> Component(created) 但其实并不然，小程序的加载顺序是这样的： 首先执行 [代码]App.onLaunch[代码] -> [代码]App.onShow[代码] 其次执行 [代码]Component.created[代码] -> [代码]Component.attached[代码] 再执行 [代码]Page.onLoad[代码] -> [代码]Page.onShow[代码] 最后 执行 [代码]Component.ready[代码] -> [代码]Page.onReady[代码] 其实也不难理解微信这么设计背后的逻辑，我们先看下官方的的生命周期： [图片] 可以看到，在页面[代码]onLoad[代码]之前会有页面[代码]create[代码]阶段，这其中就包含了组件的初始化，等组件初始化完成之后，才会执行页面的[代码]onLoad[代码], 之后页面[代码]ready[代码]事件也是在组件[代码]ready[代码]之后才触发的。 下面我们来看看 [代码]Behavior[代码], [代码]Behavior[代码] 与 [代码]Vue[代码]中的 [代码]mixin[代码] 类似，猜想下其中的执行顺序： Behavior.created => Component.created 测试下来和预期相符，其实在[代码]Vue[代码]的文档中有一段这样的描述： 另外，混入对象的钩子将在组件自身钩子之前调用。 这样的设计和主流设计保持一致。接下来我们看看 [代码]pageLifetimes[代码],有[代码]show[代码]和[代码]hide[代码]生命周期对应页面的展示与隐藏，预期的执行顺序： pageLifetime.show => Page.onShow 测试下来也和预期相符，那么我们可以推断出如下的结论： 当页面中包含组件时，组件的生命周期(包括pageLifetimes)总是优先于页面，[代码]Behaviors[代码]生命周期优先于组件的生命周期。但其实有个例外：页面退出堆栈，当页面[代码]unload[代码]时会执行如下顺序： Page.onUnload => Component.detached 看了以上的分析你应该知道了答案，最后做个总结（demo）： [图片] 最后的最后布置个作业 异步组件（异步渲染的组件，通常是通过if条件判断是否渲染）的生命周期执行顺序是怎样的，pagelifetimes会不会执行？

本文大致需要 14m+ 的阅读时间。 简述小程序的通信体系 为了大家能更好的开发出一些高质量、高性能的小程序，这里带大家理解一下小程序在不同端上架构体系的区分，更好的让大家理解小程序一些特有的代码写作方式。 整个小程序开发生态主要可以分为两部分： 桌面 nwjs 的微信开发者工具（PC 端） 移动 APP 的正式运行环境 一开始的考虑是使用双线程模型来解决安全和可控性问题。不过，随着开发的复杂度提升，原有的双线程通信耗时对于一些高性能的小程序来说，变得有些不可接受。也就是每次更新 UI 都是通过 webview 来手动调用 API 实现更新。原始的基础架构，可以参考官方图： [图片] 不过上面那张图其实有点误导行为，因为，webview 渲染执行在手机端上其实是内核来操作的，webview 只是内核暴露的一下 DOM/BOM 接口而已。所以，这里就有一个性能突破点就是，JSCore 能否通过 Native 层直接拿到内核的相关接口？答案是可以的，所以上面那种图其实可以简单的再进行一下相关划分，新的如图所示: [图片] 简单来说就是，内核改改，然后将规范的 webview 接口，选择性的抽一份给 JsCore 调用。但是，有个限制是 Android 端比较自由，通过 V8 提供 plugin 机制可以这么做，而 IOS 上，苹果爸爸是不允许的，除非你用的是 IOS 原生组件，这样的话就会扯到同层渲染这个逻辑。其实他们的底层内容都是一致的。 后面为了大家能更好理解在小程序具体开发过程中，手机端调试和在开发者工具调试的大致区分，下面我们来分析一下两者各自的执行逻辑。 tl;dr 开发者工具 通信体系 (只能采用双向通信) 即，所有指令都是通过 appservice <=> nwjs 中间层 <=> webview Native 端运行的通信体系： 小程序基础通信：双向通信-- ( core <=> webview <=> intermedia <=> appservice ) 高阶组件通信：单向通信体系 ( appservice <= android/Swift => core) JSCore 具体执行 appservice 的逻辑内容 开发者工具的通信模式 一开始考虑到安全可控的原因使用的是双线程模型，简单来说你的所有 JS 执行都是在 JSCore 中完成的，无论是绑定的事件、属性、DOM操作等，都是。 开发者工具，主要是运行在 PC 端，它内部是使用 nwjs 来做，不过为了更好的理解，这里，直接按照 nwjs 的大致技术来讲。开发者工具使用的架构是 基于 nwjs 来管理一个 webviewPool，通过 webviewPool 中，实现 appservice_webview 和 content_webview。 所以在小程序上的一些性能难点，开发者工具上并不会构成很大的问题。比如说，不会有 canvas 元素上不能放置 div，video 元素不能设置自定义控件等。整个架构如图： [图片] 当你打开开发者工具时，你第一眼看见的其实是 appservice_webview 中的 [代码]Console[代码] 内容。 [图片] content_webview 对外其实没必要暴露出来，因为里面执行的小程序底层的基础库和 开发者实际写的代码关系不大。大家理解的话，可以就把显示的 WXML 假想为 content_webview。 [图片] 当你在实际预览页面执行逻辑时，都是通过 content_webview 把对应触发的信令事件传递给 service_webview。因为是双线程通信，这里只要涉及到 DOM 事件处理或者其他数据通信的都是异步的，这点在写代码的时候，其实非常重要。 如果在开发时，需要什么困难，欢迎联系：开发者专区 | 微信开放社区 IOS/Android 协议分析 前面简单了解了开发者工具上，小程序模拟的架构。而实际运行到手机上，里面的架构设计可能又会有所不同。主要的原因有： IOS 和 Android 对于 webview 的渲染逻辑不同 手机上性能瓶颈，JS 原始不适合高性能计算 video 等特殊元素上不能被其他 div 覆盖 … 一开始做小程序的双线程架构和开发者工具比较类似，content_webview 控制页面渲染，appservice 在手机上使用 JSCore 来进行执行。它的默认架构图其实就是这个： [图片] 但是，随着用户量的满满增多，对小程序的期望也就越高： 小程序的性能是被狗吃了么？ 小程序打开速度能快一点么？ 小程序的包大小为什么这么小？ … 这些，我们都知道，所以都在慢慢一点一点的优化。考虑到原生 webview 的渲染性能很差，组内大神 rex 提出了使用同层渲染来解决性能问题。这个办法，不仅搞定了 video 上不能覆盖其他元素，也提高了一下组件渲染的性能。 开发者在手机上具体开发时，对于某些 高阶组件，像 video、canvas 之类的，需要注意它们的通信架构和上面的双线程通信来说，有了一些本质上的区别。为了性能，这里底层使用的是原生组件来进行渲染。这里的通信成本其实就回归到 native 和 appservice 的通信。 为了大家更好的理解 appservice 和 native 的关系，这里顺便简单介绍一下 JSCore 的相关执行方法。 JSCore 深入浅出 在 IOS 和 Android 上，都提供了 JSCore 这项工程技术，目的是为了独立运行 JS 代码，而且还提供了 JSCore 和 Native 通信的接口。这就意味着，通过 Native 调起一个 JSCore，可以很好的实现 Native 逻辑代码的日常变更，而不需要过分的依靠发版本来解决对应的问题，其实如果不是特别严谨，也可以直接说是一种 "热更新" 机制。 在 Android 和 IOS 平台都提供了各自运行的 JSCore，在国内大环境下运行的工程库为： Anroid: 国内平台较为分裂，不过由于其使用的都是 Google 的 Android 平台，所以，大部分都是基于 chromium 内核基础上，加上中间层来实现的。在腾讯内部通常使用的是 V8 JSCore。 IOS: 在 IOS 平台上，由于是一整个生态闭源，在使用时，只能是基于系统内嵌的 webkit 引擎来执行，提供 webkit-JavaScriptCore 来完成。 这里我们主要以具有官方文档的 webkit-JavaScriptCore 来进行讲解。 JSCore 核心基础 普遍意义上的 JSCore 执行架构可以分为三部分 JSVirtualMachine、JSContext、JSValue。由这三者构成了 JSCore 的执行内容。具体解释参考如下： JSVirtualMachine： 它通过实例化一个 VM 环境来执行 js 代码，如果你有多个 js 需要执行，就需要实例化多个 VM。并且需要注意这几个 VM 之间是不能相互交互的，因为容易出现 GC 问题。 JSContext: jsContext 是 js代码执行的上下文对象，相当于一个 webview 中的 window 对象。在同一个 VM 中，你可以传递不同的 Context。 JSValue: 和 WASM 类似，JsValue 主要就是为了解决 JS 数据类型和 swift 数据类型之间的相互映射。也就是说任何挂载在 jsContext 的内容都是 JSValue 类型，swift 在内部自动实现了和 JS 之间的类型转换。 大体内容可以参考这张架构图： [图片] 当然，除了正常的执行逻辑的上述是三个架构体外，还有提供接口协议的类架构。 JSExport: 它 是 JSCore 里面，用来暴露 native 接口的一个 protocol。简单来说，它会直接将 native 的相关属性和方法，直接转换成 prototype object 上的方法和属性。 简单执行 JS 脚本 使用 JSCore 可以在一个上下文环境中执行 JS 代码。首先你需要导入 JSCore: [代码]import JavaScriptCore //记得导入JavaScriptCore [代码] 然后利用 Context 挂载的 evaluateScript 方法，像 new Function(xxx) 一样传递字符串进行执行。 [代码]let contet:JSContext = JSContext() // 实例化 JSContext context.evaluateScript(&quot;function combine(firstName, lastName) { return firstName + lastName; }&quot;) let name = context.evaluateScript(&quot;combine(&#39;villain&#39;, &#39;hr&#39;)&quot;) print(name) //villainhr // 在 swift 中获取 JS 中定义的方法 let combine = context.objectForKeyedSubscript(&quot;combine&quot;) // 传入参数调用: // 因为 function 传入参数实际上就是一个 arguemnts[fake Array]，在 swift 中就需要写成 Array 的形式 let name2 = combine.callWithArguments([&quot;jimmy&quot;,&quot;tian&quot;]).toString() print(name2) // jimmytian [代码] 如果你想执行一个本地打进去 JS 文件的话，则需要在 swift 里面解析出 JS 文件的路径，并转换为 String 对象。这里可以直接使用 swift 提供的系统接口，Bundle 和 String 对象来对文件进行转换。 [代码]lazy var context: JSContext? = { let context = JSContext() // 1 guard let commonJSPath = Bundle.main.path(forResource: &quot;common&quot;, ofType: &quot;js&quot;) else { // 利用 Bundle 加载本地 js 文件内容 print(&quot;Unable to read resource files.&quot;) return nil } // 2 do { let common = try String(contentsOfFile: commonJSPath, encoding: String.Encoding.utf8) // 读取文件 _ = context?.evaluateScript(common) // 使用 evaluate 直接执行 JS 文件 } catch (let error) { print(&quot;Error while processing script file: \(error)&quot;) } return context }() [代码] JSExport 接口的暴露 JSExport 是 JSCore 里面，用来暴露 native 接口的一个 protocol，能够使 JS 代码直接调用 native 的接口。简单来说，它会直接将 native 的相关属性和方法，直接转换成 prototype object 上的方法和属性。 那在 JS 代码中，如何执行 Swift 的代码呢？最简单的方式是直接使用 JSExport 的方式来实现 class 的传递。通过 JSExport 生成的 class，实际上就是在 JSContext 里面传递一个全局变量（变量名和 swift 定义的一致）。这个全局变量其实就是一个原型 prototype。而 swift 其实就是通过 context?.setObject(xxx) API ，来给 JSContext 导入一个全局的 Object 接口对象。 那应该如何使用该 JSExport 协议呢？ 首先定义需要 export 的 protocol，比如，这里我们直接定义一个分享协议接口： [代码]@objc protocol WXShareProtocol: JSExport { // js调用App的微信分享功能 演示字典参数的使用 func wxShare(callback:(share)-&gt;Void) // setShareInfo func wxSetShareMsg(dict: [String: AnyObject]) // 调用系统的 alert 内容 func showAlert(title: String,msg:String) } [代码] 在 protocol 中定义的都是 public 方法，需要暴露给 JS 代码直接使用的，没有在 protocol 里面声明的都算是 私有 属性。接着我们定义一下具体 WXShareInface 的实现： [代码]@objc class WXShareInterface: NSObject, WXShareProtocol { weak var controller: UIViewController? weak var jsContext: JSContext? var shareObj:[String:AnyObject] func wxShare(_ succ:()-&gt;{}) { // 调起微信分享逻辑 //... // 成功分享回调 succ() } func setShareMsg(dict:[String:AnyObject]){ self.shareObj = [&quot;name&quot;:dict.name,&quot;msg&quot;:dict.msg] // ... } func showAlert(title: String, message: String) { let alert = AlertController(title: title, message: message, preferredStyle: .Alert) // 设置 alert 类型 alert.addAction(AlertAction(title: &quot;确定&quot;, style: .Default, handler: nil)) // 弹出消息 self.controller?.presentViewController(alert, animated: true, completion: nil) } // 当用户内容改变时，触发 JS 中的 userInfoChange 方法。 // 该方法是,swift 中私有的，不会保留给 JSExport func userChange(userInfo:[String:AnyObject]) { let jsHandlerFunc = self.jsContext?.objectForKeyedSubscript(&quot;\(userInfoChange)&quot;) let dict = [&quot;name&quot;: userInfo.name, &quot;age&quot;: userInfo.age] jsHandlerFunc?.callWithArguments([dict]) } } [代码] 类是已经定义好了，但是我们需要将当前的类和 JSContext 进行绑定。具体步骤是将当前的 Class 转换为 Object 类型注入到 JSContext 中。 [代码]lazy var context: JSContext? = { let context = JSContext() let shareModel = WXShareInterface() do { // 注入 WXShare Class 对象，之后在 JSContext 就可以直接通过 window.WXShare 调用 swift 里面的对象 context?.setObject(shareModel, forKeyedSubscript: &quot;WXShare&quot; as (NSCopying &amp; NSObjectProtocol)!) } catch (let error) { print(&quot;Error while processing script file: \(error)&quot;) } return context }() [代码] 这样就完成了将 swift 类注入到 JSContext 的步骤，余下的只是调用问题。这里主要考虑到你 JS 执行的位置。比如，你可以直接通过 JSCore 执行 JS，或者直接将 JSContext 和 webview 的 Context 绑定在一起。 直接本地执行 JS 的话，我们需要先加载本地的 js 文件，然后执行。现在本地有一个 share.js 文件： [代码]// share.js 文件 WXShare.setShareMsg({ name:&quot;villainhr&quot;, msg:&quot;Learn how to interact with JS in swift&quot; }); WXShare.wxShare(()=&gt;{ console.log(&quot;the sharing action has done&quot;); }) [代码] 然后，我们需要像之前一样加载它并执行： [代码]// swift native 代码 // swift 代码 func init(){ guard let shareJSPath = Bundle.main.path(forResource:&quot;common&quot;,ofType:&quot;js&quot;) else{ return } do{ // 加载当前 shareJS 并使用 JSCore 解析执行 let shareJS = try String(contentsOfFile: shareJSPath, encoding: String.Encoding.utf8) self.context?.evaluateScript(shareJS) } catch(let error){ print(error) } } [代码] 如果你想直接将当前的 WXShareInterface 绑定到 Webview Context 中的话，前面实例的 Context 就需要直接修改为 webview 的 Context。对于 UIWebview 可以直接获得当前 webview 的Context，但是 WKWebview 已经没有了直接获取 context 的接口，wkwebview 更推崇使用前文的 scriptMessageHandler 来做 jsbridge。当然，获取 wkwebview 中的 context 也不是没有办法，可以通过 KVO 的 trick 方式来拿到。 [代码]// 在 webview 加载完成时，注入相关的接口 func webViewDidFinishLoad(webView: UIWebView) { // 加载当前 View 中的 JSContext self.jsContext = webView.valueForKeyPath(&quot;documentView.webView.mainFrame.javaScriptContext&quot;) as! JSContext let model = WXShareInterface() model.controller = self model.jsContext = self.jsContext // 将 webview 的 jsContext 和 Interface 绑定 self.jsContext.setObject(model, forKeyedSubscript: &quot;WXShare&quot;) // 打开远程 URL 网页 // guard let url = URL(string: &quot;https://www.villainhr.com&quot;) else { // return //} // 如果没有加载远程 URL，可以直接加载 // let request = URLRequest(url: url) // webView.load(request) // 在 jsContext 中直接以 html 的形式解析 js 代码 // let url = NSBundle.mainBundle().URLForResource(&quot;demo&quot;, withExtension: &quot;html&quot;) // self.jsContext.evaluateScript(try? String(contentsOfURL: url!, encoding: NSUTF8StringEncoding)) // 监听当前 jsContext 的异常 self.jsContext.exceptionHandler = { (context, exception) in print(&quot;exception：&quot;, exception) } } [代码] 然后，我们可以直接通过上面的 share.js 调用 native 的接口。 原生组件的通信 JSCore 实际上就是在 native 的一个线程中执行，它里面没有 DOM、BOM 等接口，它的执行和 nodeJS 的环境比较类似。简单来说，它就是 ECMAJavaScript 的解析器，不涉及任何环境。 在 JSCore 中，和原生组件的通信其实也就是 native 中两个线程之间的通信。对于一些高性能组件来说，这个通信时延已经减少很多了。 那两个之间通信，是传递什么呢？ 就是 事件，DOM 操作等。在同层渲染中，这些信息其实都是内核在管理。所以，这里的通信架构其实就变为： [图片] Native Layer 在 Native 中，可以通过一些手段能够在内核中设置 proxy，能很好的捕获用户在 UI 界面上触发的事件，这里由于涉及太深的原生知识，我就不过多介绍了。简单来说就是，用户的一些 touch 事件，可以直接通过 内核暴露的接口，在 Native Layer 中触发对应的事件。这里，我们可以大致理解内核和 Native Layer 之间的关系，但是实际渲染的 webview 和内核有是什么关系呢？ 在实际渲染的 webview 中，里面的内容其实是小程序的基础库 JS 和 HTML/CSS 文件。内核通过执行这些文件，会在内部自己维护一个渲染树，这个渲染树，其实和 webview 中 HTML 内容一一对应。上面也说过，Native Layer 也可以和内核进行交互，但这里就会存在一个 线程不安全的现象，有两个线程同时操作一个内核，很可能会造成泄露。所以，这里 Native Layer 也有一些限制，即，它不能直接操作页面的渲染树，只能在已有的渲染树上去做节点类型的替换。 最后总结 这篇文章的主要目的，是让大家更加了解一下小程序架构模式在开发者工具和手机端上的不同，更好的开发出一些高性能、优质的小程序应用。这也是小程序中心一直在做的事情。最后，总结一下前面将的几个重要的点： 开发者工具只有双线程架构，通过 appservice_webview 和 content_webview 的通信，实现小程序手机端的模拟。 手机端上，会根据组件性能要求的不能对应优化使用不同的通信架构。 正常 div 渲染，使用 JSCore 和 webview 的双线程通信 video/map/canvas 等高阶组件，通常是利用内核的接口，实现同层渲染。通信模式就直接简化为 内核 <=> Native <=> appservice。（速度贼快） 参考： 教程 | 《小程序开发指南》

在微信小程序的开发的过程中，我们会存在小程序和 H5页面共存的场景，而让小程序原生和web h5独立开发，往往会遇到需要两套人力去维护。对开发者而言，加大了工作量成本，对于产品而言，容易出现展示形态同步不及时问题。在这种情况下，我们急需要找到一个既能平衡性能，也能满足快速迭代的方案。 主流的小程序同构方案 web-view 组件 web-view组件是一个承载网页的容器，最简单的方案就是使用原h5的代码，通过 web-view组件进行展示。其优点是业务逻辑无需额外开发与适配，只需要处理小程序特有的逻辑，然后通过jssdk 与原生小程序通信。 使用 webview 加载 h5的问题也非常明显，首先是体验问题，用户见到页面会经过以下环节：加载小程序包，初始化小程序，再加载 webview中的 html页面，然后加载相关资源，渲染h5页面，最后进行展示。最终导致的结果是打开体验非常差。另外其他缺点是小程序对web-view部分特性有限制，比如组件会自动铺满整个小程序页面，不支持自定义导航效果等。 [图片] 静态编译兼容 静态编译是最为主流的小程序同构方案，类似的有 taro, mpvue等。其思路是在构建打包过程，把一种结构化语言，转换成另一种结构化语言。比如，taro 把jsx在构建时进行词法分析，解析代码获取AST，然后将 AST递归遍历生成wxml目标代码。 [图片] 静态编译的好处是非常明显，一套代码，通过编译分别转h5和小程序，兼具性能与跨平台。另一方面，随着这种方案的流行，大家也感受到了其明显的问题，首先，由于小程序本身的限制，比如无法dom操作，js 与 webview 双线程通信等，导致静态编译语法转换，不能做到彻底的兼容，开发体验受制于框架本身的支持程度，相信踩过坑的同学应该非常有痛的感悟。其次，静态编译转换逻辑需要与小程序最新的特性保持同步，不断升级。 小程序运行时兼容方案 静态编译的方案实现了同构，但它只是以一种中间态的结构化语法去编码，非真正的web，牺牲了大量的灵活性。我们来看下另外一种更灵活的方案———运行时兼容。 我们回到小程序本身的限制上来。由于小程序采用双线程机制，内部通过一个 webview 用于承载页面渲染，但小程序屏蔽了它原本的 DOM/BOM接口，自己定义了一套组件规范；另一方面，使用独立的js-core 负责对 javascript 代码进行解析，让页面和js-core之间进行相互通信（setData），从而达到执行与渲染的分离。而浏览器的 DOM接口是大量web得以显示的底层依赖，这也是h5代码无法直接在小程序中运行的主要原因。 那么如何突破小程序对DOM接口的屏蔽呢？ 最直接的思路就是用JS实现和仿造一层浏览器环境DOM相关的标准接口，让用户的JS代码可以无感知的自由操作DOM。通过仿造的底层DOM接口，web 代码执行完后，最终生成一层仿造的 DOM树，然后将这棵 DOM 树转换成小程序的wxml构成的DOM树，最后由小程序原生去负责正确的渲染出来。 [图片] kbone kbone 是微信官方出一套小程序运行时兼容方案，目前已经接入的小程序有小程序官方社区，及腾讯课堂新人礼包等。并且有专人维护，反馈及时~~。 kbone方案核心主要有两大模块，第一是miniprogram-render实现了对浏览器环境下dom/bom的仿造，构建dom树，及模拟 web 事件机制。第二个模块是miniprogram-element是原生小程序渲染入口，主要监听仿造dom树的变化，生成对应的小程序的dom 树，另外一个功能是监听原生小程序事件，派发到仿造的事件中心处理。 [图片] DOM/BOM仿造层 DOM、BOM相关的接口模拟，主要是按照web标准构建 widow、document、node节点等相关 api，思路比较清晰，我们简单看下其流程。 首先在用户层有一个配置文件miniprogram.config，里面有必要信息origin、entry等需要配置。在 miniprogram-render 的入口文件createPage方法中，配置会初始化到一个全局cache对象中，然后根据配置初始化 Window 和 Document 这两个重要的对象。Location、Navigator、Screen、History等 BOM 实例都是在 window初始化过程中完成。DOM 节点相关 api 都是在Document 类中初始化。所有生成的节点和对象都会通过全局的pageMap管理，在各个流程中都能获取到。 [图片] 小程序渲染层 miniprogram-element 负责监听仿造DOM仿造的变化，然后生成对应小程序组件。由于小程序中提供的组件和 web 标准并不完全一样，而我们通过 html 生成的 dom 树结构千差万别，如和保证任意的html dom树可以映射到小程序渲染的dom树上呢？kbone 通过小程序自定义组件去做了这件事情。 简单说下什么是自定义组件，既将特定的代码抽象成一个模块，可以组装和复用。以 react 为例，div、span 等标签是原生组件，通过react.Component将div 和 span 组合成一个特定的 react 组件，在小程序中用自带的 view、image 等标签通过Component写法就能组合成小程序自定义组件。 和大部分 web 框架的自定义组件类似，小程序自定义组件也能够自己递归地调用自己，通过将伪造的dom结构数据传给自定义组件作为子组件，然后再递归的调用，直到没有子节点为止，这样就完成了一个小程序 dom 树的生成。 [图片] [图片] [图片] 性能问题 多层dom组合 大量小程序自定义组件会有额外的性能损耗，kbone 在实现时提供了一些优化。其中最基本的一个优化是将多层小程序原生标签作为一个自定义组件。dom 子树作为自定义组件渲染的层级数是可以通过配置传入，理论上层级越多，使用自定义组件数量越少，性能也就越好。 [图片] [图片] [图片] 以上逻辑就是通过DOM_SUB_TREE_LEVEL 层级数对节点过滤，更新后，检测是否还有节点，再触发更新。 节点缓存 在页面onUnload卸载的过程中，kbone会将当前节点放入缓存池中，方便下次初始化的时候优先从缓存中读取。 [图片] [图片] kbone 接入与适配 kbone 作为一种运行时兼容方案，适配成本相对于静态编译方案而言会低很多，总体来说对原代码侵入性非常少，目前接入过程比较顺利（期间遇到的坑，非常感谢作者june第一时间帮忙更新版本） svg资源适配 小程序不支持 svg，对于使用 svg 标签作为图片资源的应用而言，需要从底层适配。在一开始我们想到的方案有通过 肝王的cax进行兼容，但评估后不太靠谱，cax 通过 解析svg 绘制成 canvas，大量 icon会面临比较严重的性能问题。那么最直接暴力的办法就是使用 webpack 构建过程直接把 svg 转 png？后面一位给力的小伙伴想到通过把 svg 标签转成Data URI作为背景图显示，最终实践验证非常可靠，具体可以参考kbone svg 适配。 网络层适配/cookie 微信小程序环境拥有自己定义的一套 wx.request API， web 中的XMLHttpRequest对象是无法直接使用。由于我们代码中使用了 axios，所以在预言阶段直接简单通过axios-miniprogram-adapter进行适配器，后面发现部分业务没有使用 axios，兼容并不够彻底。于是直接从底层构建了一个XMLHttpRequest模块，将web网络请求适配到 wx.request。同时做了 cookie 的自动存取逻辑适配（小程序网络请求默认不带 cookie）。这一层等完善好了看是否能 pull request到 kbone代码仓库中。 差异性 DOM/BOM API 适配 部分web 中的接口在小程序无法完全获得模拟，比如getBoundingClientRect在小程序中只能通过异步的方式实现。类似的有removeProperty、stopImmediatePropagation 等接口在 kbone 中没有实现，performance等web特有的全局变量的需要兼容。这些扩展API可以通过kbone对外暴露的dom/bom 扩展 API进行适配。 [图片] getBoundingClientRect 对于元素的的高度height \offsetHeight获取，我们只能通过$getBoundingClientRect异步接口，如果是body scroll-view 实现的，getBoundingClientRect 返回的是scrollHeight。 滚动 web的全局滚动事件默认是无法触发，需要通过配置windowScroll来监听，启用这个特性会影响性能。 [代码]global: { windowScroll: true }, [代码] 样式适配 标签选择器 kbone 样式有一个坑，就是它会将标签选择器转换成类选择器去适配小程序环境，比如 [代码]span { } => .h5-span{ } [代码] 这样带来的副作用就是选择器的权重会被自动提升，对选择器权重依赖的标签样式需要去手动调整兼容。 其他适配点 注意使用标准的style属性，比如有webkit-transform会不支持，及小程序样式和web差异性兼容等。 [代码] style: { 'WebkitTransform': 'translate(' + x + 'px, 0)' // 正确 // '-webkit-transform': 'translate(' + x + 'px, 0)' 报错 } [代码] 路由适配 在初始化路由阶段，曾经遇到过Redux 更新dom后偶现节点销毁，最终定位到是kbone对Location等BOM实例化过晚，最终在june帮忙及时调整了顺序，更新了一个版本，现最新本所有BOM对象会在业务执行前准备好。 [代码]//初始化dom this.window.$$miniprogram.init() ... //初始化业务 init(this.window, this.document) [代码] 隐式全局变量兼容 在模拟XMLHttpRequest模块的过程中遇到一个问题，什么时候初始化这个对象，我们可以选择在网络请求库初始化前引入它，挂载在仿造的 window 对象下。但仍然会出现一个问题，第三放库直接使用的是XMLHttpRequest 对象，而非通过 window 访问。 [代码]var request = new XMLHttpRequest() // 报错 var request = new window.XMLHttpRequest() // 正确 [代码] 在正常的 web 环境，window 是默认的顶层作用域，而小程序中隐式的使用window 对象则会报错。 为了解决这一问题，可以通过配置文件的globalVars字段，将 XMLHttpRequest 直接进行定义。 [代码] globalVars: [ ['XMLHttpRequest', 'require("libs/xmlhttprequest.js")'] ] [代码] 构建的过程中会在所有依赖前转成如下代码 ： [代码] var XMLHttpRequest = require("libs/xmlhttprequest.js") [代码] 这样做解决了隐式访问 window 作用域问题。但又面临另一个问题，那就是xmlhttprequest模块本身内部由依赖仿造window对象，比如 cookie 访问，而此时因为require的模块独立的作用域无法访问到其他模块的仿造window 对象。于是最终通过导入一个 function 传入 window 作用域，然后初始化xmlhttprequest。 [代码] globalVars: [ ['XMLHttpRequest', 'require("libs/xmlhttprequest.js").init(window, document)'] ] [代码] 多端构建 小程序和web端需要的资源及部分逻辑是有差异，通过webpck配置进行差异化处理，具体可以参考文档编写kbone webpack 配置。 大概是这样的区分跨端配置： [图片] 分离打包入口文件: [图片] 小程序打包入口依赖的 dom 节点，需要主动创建。详细示例参照官方demo. [代码]export default function createApp() { initialize(function() { let Root = require('./root/index').default; const container = document.createElement('div') container.id = 'pages'; document.body.appendChild(container); render(<Root />, container) }) } [代码] 由于小程序本身是没有真正userAgent，kbone内部是是根据当前环境进行仿造。 [代码]//miniprogram-render/src/bom/navigator#45 this.$_userAgent = `${this.appCodeName}/${appVersion} (${platformContext}) AppleWebKit/${appleWebKitVersion} (KHTML, like Gecko) Mobile MicroMessenger/${this.$_wxVersion} Language/${this.language}` [代码] 在业务中有需要区分小程序平台的场景，我们可以通过webpack DefinePlugin插件进行注入，然后通过定义变量进行判断。 [代码]if (!process.env.isWxMiniProgram) { render( <Root />, document.getElementById('pages') ); } [代码] 小程序分包 在腾讯文档的小程序中，有一个独立的小程序仓库。 而文档管理列表是另外一个独立的H5项目，嵌入到小程序webview动态加载。通过kbone转原生打包后，这部分代码需要继承到小程序仓库中。 首先我们可以通过脚本，在webpack构建过程，将kbone 编译后的包copy到独立小程序仓库的目录下，合并小程序相关配置，从而实现功能合并。同时通过FileWebpackPlugin过滤掉无用的web平台资源。 这样遇到的问题是主包大小仍然超过限制，最后通过小程序分包可以解决这个问题，将原小程序非首屏页面全部放分包之中，配置preloadRule 字段再预加载分包。 [代码]"subpackages": [ { "root": "packageA", "pages": [ "pages/cat" ] } ] "preloadRule": { "pages/index": { "network": "all", "packages": ["important"] } } [代码] 结 通过对目前各种小程序同构方案的对比与实践，kbone是一种非常值得推荐的新思路，新方法，兼具性能与灵活。唯一不足的地方就是目前仍有不少底层工作需要适配，更多的问题在继续探索中，相信随着不断迭代及采坑后的反馈，kbone会变得越来稳定和成熟。 （最后感谢作者junexie及dntzhang大神的鼎力支持~~也欢迎大家一起参与共建kbone）

众所周知，小程序当中有一类特殊的内置组件——原生组件，这类组件有别于 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

以下代码不一定都是本人原创，很多都是借鉴参考的（模仿是第一生产力嘛），有些已忘记出处了。以下分享给大家，供学习参考！欢迎收藏补充，说不定哪天你就用上了！ 一、第一种效果 [图片] [代码]//index.wxml <view class="zr"> <view class='user_box'> <view class='userInfo'> <open-data type="userAvatarUrl"></open-data> </view> <view class='userInfo_name'> <open-data type="userNickName"></open-data> , 欢迎您 </view> </view> <view class="water"> <view class="water-c"> <view class="water-1"> </view> <view class="water-2"> </view> </view> </view> </view> //index.wxss .zr { color: white; background: #4cb4e7; /*#0396FF*/ width: 100%; height: 100px; position: relative; } .water { position: absolute; left: 0; bottom: -10px; height: 30px; width: 100%; z-index: 1; } .water-c { position: relative; } .water-1 { background: url("data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+Cjxzdmcgd2lkdGg9IjYwMHB4IiBoZWlnaHQ9IjYwcHgiIHZpZXdCb3g9IjAgMCA2MDAgNjAiIHZlcnNpb249IjEuMSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM6c2tldGNoPSJodHRwOi8vd3d3LmJvaGVtaWFuY29kaW5nLmNvbS9za2V0Y2gvbnMiPgogICAgPCEtLSBHZW5lcmF0b3I6IFNrZXRjaCAzLjQgKDE1NTc1KSAtIGh0dHA6Ly93d3cuYm9oZW1pYW5jb2RpbmcuY29tL3NrZXRjaCAtLT4KICAgIDx0aXRsZT53YXRlci0xPC90aXRsZT4KICAgIDxkZXNjPkNyZWF0ZWQgd2l0aCBTa2V0Y2guPC9kZXNjPgogICAgPGRlZnM+PC9kZWZzPgogICAgPGcgaWQ9IuaIkSIgc3Ryb2tlPSJub25lIiBzdHJva2Utd2lkdGg9IjEiIGZpbGw9Im5vbmUiIGZpbGwtcnVsZT0iZXZlbm9kZCIgc2tldGNoOnR5cGU9Ik1TUGFnZSI+CiAgICAgICAgPGcgaWQ9Ii0iIHNrZXRjaDp0eXBlPSJNU0FydGJvYXJkR3JvdXAiIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0xMjEuMDAwMDAwLCAtMTMzLjAwMDAwMCkiIGZpbGwtb3BhY2l0eT0iMC4zIiBmaWxsPSIjRkZGRkZGIj4KICAgICAgICAgICAgPGcgaWQ9IndhdGVyLTEiIHNrZXRjaDp0eXBlPSJNU0xheWVyR3JvdXAiIHRyYW5zZm9ybT0idHJhbnNsYXRlKDEyMS4wMDAwMDAsIDEzMy4wMDAwMDApIj4KICAgICAgICAgICAgICAgIDxwYXRoIGQ9Ik0wLDcuNjk4NTczOTUgTDQuNjcwNzE5NjJlLTE1LDYwIEw2MDAsNjAgTDYwMCw3LjM1MjMwNDYxIEM2MDAsNy4zNTIzMDQ2MSA0MzIuNzIxMDUyLDI0LjEwNjUxMzggMjkwLjQ4NDA0LDcuMzU2NzQxODcgQzE0OC4yNDcwMjcsLTkuMzkzMDMwMDggMCw3LjY5ODU3Mzk1IDAsNy42OTg1NzM5NSBaIiBpZD0iUGF0aC0xIiBza2V0Y2g6dHlwZT0iTVNTaGFwZUdyb3VwIj48L3BhdGg+CiAgICAgICAgICAgIDwvZz4KICAgICAgICA8L2c+CiAgICA8L2c+Cjwvc3ZnPg==") repeat-x; background-size: 600px; -webkit-animation: wave-animation-1 3.5s infinite linear; animation: wave-animation-1 3.5s infinite linear; } .water-2 { top: 5px; background: url("data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+Cjxzdmcgd2lkdGg9IjYwMHB4IiBoZWlnaHQ9IjYwcHgiIHZpZXdCb3g9IjAgMCA2MDAgNjAiIHZlcnNpb249IjEuMSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM6c2tldGNoPSJodHRwOi8vd3d3LmJvaGVtaWFuY29kaW5nLmNvbS9za2V0Y2gvbnMiPgogICAgPCEtLSBHZW5lcmF0b3I6IFNrZXRjaCAzLjQgKDE1NTc1KSAtIGh0dHA6Ly93d3cuYm9oZW1pYW5jb2RpbmcuY29tL3NrZXRjaCAtLT4KICAgIDx0aXRsZT53YXRlci0yPC90aXRsZT4KICAgIDxkZXNjPkNyZWF0ZWQgd2l0aCBTa2V0Y2guPC9kZXNjPgogICAgPGRlZnM+PC9kZWZzPgogICAgPGcgaWQ9IuaIkSIgc3Ryb2tlPSJub25lIiBzdHJva2Utd2lkdGg9IjEiIGZpbGw9Im5vbmUiIGZpbGwtcnVsZT0iZXZlbm9kZCIgc2tldGNoOnR5cGU9Ik1TUGFnZSI+CiAgICAgICAgPGcgaWQ9Ii0iIHNrZXRjaDp0eXBlPSJNU0FydGJvYXJkR3JvdXAiIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0xMjEuMDAwMDAwLCAtMjQ2LjAwMDAwMCkiIGZpbGw9IiNGRkZGRkYiPgogICAgICAgICAgICA8ZyBpZD0id2F0ZXItMiIgc2tldGNoOnR5cGU9Ik1TTGF5ZXJHcm91cCIgdHJhbnNmb3JtPSJ0cmFuc2xhdGUoMTIxLjAwMDAwMCwgMjQ2LjAwMDAwMCkiPgogICAgICAgICAgICAgICAgPHBhdGggZD0iTTAsNy42OTg1NzM5NSBMNC42NzA3MTk2MmUtMTUsNjAgTDYwMCw2MCBMNjAwLDcuMzUyMzA0NjEgQzYwMCw3LjM1MjMwNDYxIDQzMi43MjEwNTIsMjQuMTA2NTEzOCAyOTAuNDg0MDQsNy4zNTY3NDE4NyBDMTQ4LjI0NzAyNywtOS4zOTMwMzAwOCAwLDcuNjk4NTczOTUgMCw3LjY5ODU3Mzk1IFoiIGlkPSJQYXRoLTIiIHNrZXRjaDp0eXBlPSJNU1NoYXBlR3JvdXAiIHRyYW5zZm9ybT0idHJhbnNsYXRlKDMwMC4wMDAwMDAsIDMwLjAwMDAwMCkgc2NhbGUoLTEsIDEpIHRyYW5zbGF0ZSgtMzAwLjAwMDAwMCwgLTMwLjAwMDAwMCkgIj48L3BhdGg+CiAgICAgICAgICAgIDwvZz4KICAgICAgICA8L2c+CiAgICA8L2c+Cjwvc3ZnPg==") repeat-x; background-size: 600px; -webkit-animation: wave-animation-2 6s infinite linear; animation: wave-animation-2 6s infinite linear; } .water-1, .water-2 { position: absolute; width: 100%; height: 60px; } .back-white { background: #fff; } @keyframes wave-animation-1 { 0% { background-position: 0 top; } 100% { background-position: 600px top; } } @keyframes wave-animation-2 { 0% { background-position: 0 top; } 100% { background-position: 600px top; } } .user_box { display: flex; z-index: 10000 !important; opacity: 0; /* 透明度*/ animation: love 1.5s ease-in-out; animation-fill-mode: forwards; } .userInfo_name { flex: 1; vertical-align: middle; width: 100%; margin-left: 5%; margin-top: 5%; font-size: 42rpx; } .userInfo { flex: 1; width: 100%; border-radius: 50%; overflow: hidden; max-height: 50px; max-width: 50px; margin-left: 5%; margin-top: 5%; border: 2px solid #fff; } [代码] 二、第二种效果 [图片] [代码]//index.wxml <view class="waveWrapper waveAnimation"> <view class="waveWrapperInner bgTop"> <view class="wave waveTop" style="background-image: url('https://s2.ax1x.com/2019/09/26/um8g7n.png')"></view> </view> <view class="waveWrapperInner bgMiddle"> <view class="wave waveMiddle" style="background-image: url('https://s2.ax1x.com/2019/09/26/umGZ38.png')"></view> </view> <view class="waveWrapperInner bgBottom"> <view class="wave waveBottom" style="background-image: url('https://s2.ax1x.com/2019/09/26/umGuuQ.png')"></view> </view> </view> //index.wxss .waveWrapper { overflow: hidden; position: absolute; left: 0; right: 0; height: 300px; top: 0; margin: auto; } .waveWrapperInner { position: absolute; width: 100%; overflow: hidden; height: 100%; bottom: -1px; background-image: linear-gradient(to top, #86377b 20%, #27273c 80%); } .bgTop { z-index: 15; opacity: 0.5; } .bgMiddle { z-index: 10; opacity: 0.75; } .bgBottom { z-index: 5; } .wave { position: absolute; left: 0; width: 500%; height: 100%; background-repeat: repeat no-repeat; background-position: 0 bottom; transform-origin: center bottom; } .waveTop { background-size: 50% 100px; } .waveAnimation .waveTop { animation: move-wave 3s; -webkit-animation: move-wave 3s; -webkit-animation-delay: 1s; animation-delay: 1s; } .waveMiddle { background-size: 50% 120px; } .waveAnimation .waveMiddle { animation: move_wave 10s linear infinite; } .waveBottom { background-size: 50% 100px; } .waveAnimation .waveBottom { animation: move_wave 15s linear infinite; } @keyframes move_wave { 0% { transform: translateX(0) translateZ(0) scaleY(1) } 50% { transform: translateX(-25%) translateZ(0) scaleY(0.55) } 100% { transform: translateX(-50%) translateZ(0) scaleY(1) } } [代码] 三、第三种效果 [图片] [代码]//index.wxml <view class="container"> <image class="title" src="https://ftp.bmp.ovh/imgs/2019/09/74bada9c4143786a.png"></image> <view class="content"> <view class="hd" style="transform:rotateZ({{angle}}deg);"> <image class="logo" src="https://ftp.bmp.ovh/imgs/2019/09/d31b8fcf19ee48dc.png"></image> <image class="wave" src="wave.png" mode="aspectFill"></image> <image class="wave wave-bg" src="wave.png" mode="aspectFill"></image> </view> <view class="bd" style="height: 100rpx;"> </view> </view> </view> //index.wxss image{ max-width:none; } .container { background: #7acfa6; align-items: stretch; padding: 0; height: 100%; overflow: hidden; } .content{ flex: 1; display: flex; position: relative; z-index: 10; flex-direction: column; align-items: stretch; justify-content: center; width: 100%; height: 100%; padding-bottom: 450rpx; background: -webkit-gradient(linear, left top, left bottom, from(rgba(244,244,244,0)), color-stop(0.1, #f4f4f4), to(#f4f4f4)); opacity: 0; transform: translate3d(0,100%,0); animation: rise 3s cubic-bezier(0.19, 1, 0.22, 1) .25s forwards; } @keyframes rise{ 0% {opacity: 0;transform: translate3d(0,100%,0);} 50% {opacity: 1;} 100% {opacity: 1;transform: translate3d(0,450rpx,0);} } .title{ position: absolute; top: 30rpx; left: 50%; width: 600rpx; height: 200rpx; margin-left: -300rpx; opacity: 0; animation: show 2.5s cubic-bezier(0.19, 1, 0.22, 1) .5s forwards; } @keyframes show{ 0% {opacity: 0;} 100% {opacity: .95;} } .hd { position: absolute; top: 0; left: 50%; width: 1000rpx; margin-left: -500rpx; height: 200rpx; transition: all .35s ease; } .logo { position: absolute; z-index: 2; left: 50%; bottom: 200rpx; width: 160rpx; height: 160rpx; margin-left: -80rpx; border-radius: 160rpx; animation: sway 10s ease-in-out infinite; opacity: .95; } @keyframes sway{ 0% {transform: translate3d(0,20rpx,0) rotate(-15deg); } 17% {transform: translate3d(0,0rpx,0) rotate(25deg); } 34% {transform: translate3d(0,-20rpx,0) rotate(-20deg); } 50% {transform: translate3d(0,-10rpx,0) rotate(15deg); } 67% {transform: translate3d(0,10rpx,0) rotate(-25deg); } 84% {transform: translate3d(0,15rpx,0) rotate(15deg); } 100% {transform: translate3d(0,20rpx,0) rotate(-15deg); } } .wave { position: absolute; z-index: 3; right: 0; bottom: 0; opacity: 0.725; height: 260rpx; width: 2250rpx; animation: wave 10s linear infinite; } .wave-bg { z-index: 1; animation: wave-bg 10.25s linear infinite; } @keyframes wave{ from {transform: translate3d(125rpx,0,0);} to {transform: translate3d(1125rpx,0,0);} } @keyframes wave-bg{ from {transform: translate3d(375rpx,0,0);} to {transform: translate3d(1375rpx,0,0);} } .bd { position: relative; flex: 1; display: flex; flex-direction: column; align-items: stretch; animation: bd-rise 2s cubic-bezier(0.23,1,0.32,1) .75s forwards; opacity: 0; } @keyframes bd-rise{ from {opacity: 0; transform: translate3d(0,60rpx,0); } to {opacity: 1; transform: translate3d(0,0,0); } } [代码] wave.png（可下载到本地） [图片] 在这个基础上，再加上js的代码，即可实现根据手机倾向，水波晃动的效果 wx.onAccelerometerChange(function callback) 监听加速度数据事件。 [图片] [代码]//index.js Page({ onReady: function () { var _this = this; wx.onAccelerometerChange(function (res) { var angle = -(res.x * 30).toFixed(1); if (angle > 14) { angle = 14; } else if (angle < -14) { angle = -14; } if (_this.data.angle !== angle) { _this.setData({ angle: angle }); } }); }, }); [代码] 四、第四种效果 [图片] [代码]//index.wxml <view class='page__bd'> <view class="bg-img padding-tb-xl" style="background-image:url('http://wx4.sinaimg.cn/mw690/006UdlVNgy1g2v2t1ih8jj31hc0p0qej.jpg');background-size:cover;"> <view class="cu-bar"> <view class="content text-bold text-white"> 悦拍屋 </view> </view> </view> <view class="shadow-blur"> <image src="https://raw.githubusercontent.com/weilanwl/ColorUI/master/demo/images/wave.gif" mode="scaleToFill" class="gif-black response" style="height:100rpx;margin-top:-100rpx;"></image> </view> </view> //index.wxss @import "colorui.wxss"; .gif-black { display: block; border: none; mix-blend-mode: screen; } [代码] 本效果需要引入ColorUI组件库