[视频] *所有课程源码的链接：https://gitee.com/geektime-geekbang_admin/weapp_optimize 你好，我是李艺，是腾讯云TVP 、小程序从0到1的作者，极客时间 微信小程序全栈开发实战课程讲师。 小程序上线已经5年时间了，日活目前已经达到了4.5亿+，已然成为任何一家互联网企业都不能忽视的产品运营阵地。小程序的开发能力经过微信团队数年来的不断地努力，目前已经日臻完善，它早已经不是那个随随便便翻翻文档就可以完成开发的一个简易框架了，尤其是在性能优化方面，会优化与不会优化 ，对于产品的运行效果可以说有霄壤之别。 首先我们看第一部分，需要明确一下有哪些需要优化的现象。不知道你的小程序产品有没有遇到过这样的一些问题，点开小程序一直都是白屏什么也看不到、Loading加载提示转了好几圈页面还不显示，单击页面链接的时候页面跳转迟钝迟迟打不开、有的按钮单击了好几次一点反应也没有，长列表内容在滑动的时候越往下滑 页面越卡顿。你有没有因为这些问题而遭受过用户的抱怨，你会以为这些问题都是因为平台技术不完善而造成的吗？ 那么为什么京东 滴滴等大厂的一些小程序，它们的功能那么繁杂。但使用起来却还是那么流畅呢，当我们抱怨框架不够给力的时候，我们对微信小程序的性能优化技巧又真正了解和使用多少？性能优化它是一个现人现地的活，讲究具体问题具体分析，需要有一个字节 一个字节去抠，一个毫秒 一个毫秒去节省的这样的一个细致精神。这个课程我们会演示相关的性能优化技巧。我准备了一个性能比较堪忧的项目，这个课程我们就一起诊断 优化这个项目，让它从体态臃肿的一个状态慢慢变得健步如飞，为了更好地理解和应用小程序优化技巧，在开始实践之前，我们十分有必要看一下小程序整体的运行环境以及启动的流程。小程序的运行环境大体可以分为三类，第一类是iOS端、Mac微信端，第二类是Android端 PC微信端，第三类就是我们开发者经常使用的微信开发者工具模拟器端。另外还有儿童手表上面也有微信，但是那个环境它没有小程序，所以不在我们的讨论范围之内。 三类的运行环境，虽然它们在底层是基于不同的技术实现的，但是它们的启动流程大体上是相似的，小程序的优化主要是指从小程序开始启动到首页完全渲染显示，也就是Page.onReady事件派发，这个过程之间的一个优化。这个过程主要包含了三个流程的节点，这一步包括小程序运行进程及运行环境的准备，这里面具体又包括拉取小程序基本信息，包括代码包版本 地址等信息，另外还有Native小程序进程和微信基本模块的一个初始化。例如在Android环境里面有Activity活动组件的一个初始化，再往下是代码包的下载 校验以及初始化，再往后是系统组件 WebView组件容器和原生组件的一个初始化，最后是JS引擎初始化以及域的创建。 下面我们看第二步关于代码注入，这一步主要包含两大部分：第一部分是框架及第三方基础代码的一个初始化，这里面又分为三个小部分： 第一部分是小程序基础库的注入； 第二小部分是扩展库，例如我们在配置文件里面通过使用useExtendedLib引入的WeUI以及kbone这样的一个类库的初始化； 第三小部分是插件、自定义组件 扩展库代码的一个注入。 第二部分是开发者代码的一个注入，这个里面主要分为两个小部分： 第一个小部分是开发者逻辑层代码的一个注入，这里会派发小程序里面的App.onLaunch还有App.onShow这些事件的一个派发，这些事件都是在这个阶段进行派发的； 第二小部分是开发者视图层代码的一个注入，包括公共代码以及页面代码的一个注入。 下面我们看第三部分关于首屏渲染，这个部分大致可以分为五个小部分： 第一小部分是页面的初始化，这个时间点是initDataSendTime这个时间点的一个触发时机，会有Page.onLoad一个事件的派发； 第二小部分是时间点走到viewLayerReaderStartTime这样的一个时间点的阶段，这个时候会有Page.onShow事件的一个派发； 第三小部分是开发者代码从后端拉取数据，准备data数据，这个时候也是一个阶段，是第三小部分； 第四小部分是页面的一个整体的渲染； 第五部分是当这个时间点走到viewLayerReaderEndTime这个时间点的时候，它会有一个Page.onReady事件的派发，这个时候就标志着我们首屏渲染的一个完成。 小程序采用逻辑层、视图层双线程运行机制，Native的工作准备它是先于这两个线程开始之前开始的，基础的执行环境准备好以后，逻辑层与视图层两个线程才开始工作，并且两个线程几乎是并发执行的。在视图层与逻辑层它代码完全注入以后，这个时间点它会对齐以后才会进入下一个阶段，也就是首屏渲染这个阶段的开始执行。 这些节点它并不是每一次小程序启动时都会经历的，有些会有，有些不会有。微信有运行环境预加载机制，如果小程序在启动时命中了预加载的环境，有关准备运行环境的节点就可以省略掉，这一部分的启动时间也可以节省了。对于开发者紧跟小程序框架的更新，及时使用用户覆盖率最广的基础库版本，让自己的小程序运行环境大众化、普通化，则有助于预加载环境的一个命中，终端类型不同经历的节点也不尽相同。 在Android上小程序启动的时候，微信它开启了新线程，在iOS上则没有 iOS上小程序它在启动的时候，它会复用与微信相同的一个进程，因此Android上有小程序进程与Activity初始化这样的一个节点，在iOS上则没有，再加上iOS的设备它普遍的性能是高于Android设备的，所以这使得iOS的设备的启动的效率普遍就高于Android。 对于相同版本的小程序在同一性能级别的设备上运行，iOS设备平均会比Android大概会少0.5的这样一个启动时间，另外还有启动方式对流程经历的节点也有影响。 下面我们看一下启动方式。小程序按启动方式不同分为冷启动和热启动两种方式。 什么是冷启动？什么是热启动？如果小程序在用户设备上是第一次打开或者是销毁后再次打开，这个时候的启动就是冷启动。热启动是相对冷启动而言的，热启动是小程序启动的一种优化机制，小程序进入后台30分钟以内再次进入前台，可以直接从后台状态然后恢复到前台，在这种热启动方式里面，像前面我们提到的小程序基本信息、拉取代码包的下载还有JS引擎初始化等等这些流程节点，甚至像App.onLaunch、Page.onLoad以及Page.onReady这些一次性的流程事件都不会有了。小程序第一次启动以及冷启动30分钟以后被系统回收重新再启动都是冷启动。 前面我们讲的启动流程的主要节点是冷启动流程的节点。我们说的小程序性能优化主要是指冷启动性能的一个优化以及运行时渲染性能的一个优化，在小程序冷启动流程里边涉及到一些程序以及页面事件。下面我们统一看一下这些事件。 在小程序中App与Page都有它们各自的一个生命周期函数，这些周期函数有一些与启动流程是密切相关的。我们先看一下App周期函数，这里面有三个事件需要我们注意： 第一个是onLaunch，它是监听小程序初始化的一个事件； 第二个是onShow 监听小程序启动或切前台这样一个事件； 第三个是onHide 监听小程序切后台这样的一个事件。 下面我们再看一下Page周期函数。这个里面有五个事件是与优化相关的： 第一个是onLoad它监听页面加载； 第二个是onShow监听页面显示； 第三个是onReady监听页面初次渲染完成； 第四个是onHide监听页面隐藏； 第五是onUnload监听页面卸载。 App.onShow事件和Page.onShow事件是视图界面开始显示时派发的，它们会重复派发与启动流程优化密切相关的一次性事件，主要有App.onLaunch Page.onLoad和Page.onReady这三个事件，在这三个事件节点恰当的安排执行合适的逻辑代码是优化的重要技巧一。 至于像App.onShow App.onHide以及Page.onHide Page.onUnload是与运行时性能优化十分相关的一些事件，下面我们根据小程序的冷启动流程以及与其相关的密切相关的一些八个生命周期函数大致讲一下有哪些节点是可以优化的。 第一条在这个环境准备阶段中，在拉取小程序基本信息阶段，这个阶段是有可能优化的。微信对用户设备上经常使用的小程序它会有轮询机制，在轮询的时候会自动拉取小程序的一个基本信息，正常情况下这个小程序的基本信息的一个拉取它是同步的，它会阻塞我们后续流程节点的一个执行，如果通过轮询节省了这样的一个过程，启动流程跳过这个节点时间是可以节约的，当然这个节点开发者基本上做不了什么事情，开发者并不能左右微信的轮询机制。但是越受用户欢迎的一个小程序因为它属于经常使用的小程序，它会命中轮询机制，启动的一个性能也会更好，而那些不被用户经常访问的小程序反而没有这个福利，这大概就是技术里面的一个马太效应，就是好的会更好然后坏的会越差。 针对环境准备阶段微信提供了环境预加载机制，微信客户端会根据用户设备的使用场景和设备资源的一个消耗情况，依据一定的一个策略，在小程序启动之前对运行环境进行部分的预加载，这个过程开发者基本也无法干涉，开发者能做的仅是紧跟小程序基础库的一个更新，积极使用最新的、最普遍的、最广泛的一个基础库版本以及提高预加载环境的一个命中率。 在代码注入阶段，逻辑层与视图层代码都需要注入，两个线程的代码都注入完成以后首屏渲染流程才能开始，Page.onLoad事件才能触发。我们可以想方设法减少代码的一个注入量和复杂度以期减少启动时间，小程序在这方面有分包、有独立分包、有按需注入、有用时加载和占位组件等等这些特性，这些都是这一阶段的一些优化技巧。这些技巧稍后我们在课程里面都会详细介绍。 在合适的生命周期函数节点执行合适的代码也可以优化启动性，Page.onReady事件派发于首屏渲染完成的时候，如果我们要从后端拉取数据并在首页上进行渲染，在这个事件函数里面执行拉取操作，势必会造成二次渲染的CPU资源浪费，但如果我们在Page.onLaunch这个事件触发的时候就开始数据拉取，又可能会阻塞小程序正常的一个启动流程，在这种情况下我们要怎么去做？我们可以使用异步转同步的编程范式以及使用并发复合命令，在多个文件里边对齐这个代码的执行点，这样的话就显得尤为重要了。具体的优化办法，稍后我们在课程里面会详细讲解。 从Page.onLoad事件派发页面开始渲染到Page.onReady这个事件派发首屏渲染完成，这中间涉及到的动态数据加载，其加载的数据量有多少、网络请求所需的时间有多少还有图片等静态资源它加载所需要的时间有多少，都会影响首屏渲染的一个效率，这个阶段使用骨架屏技巧包括压缩图片、提高服务器接口响应效率和数据传输效率等等，这些都可以优化首屏渲染的一个用户体验。针对小程序里面用到的一些数据，微信还提供了数据预加载周期性更新机制，不需要开发者自己去拉取微信就可以代为拉取，小程序在启动的时候，直接取用这些已经加载好的数据就可以了，这也是优化启动流程的一个技巧之一。 当然了这个技巧是微信团队特意为开发者而设计的，针对低端机首次渲染需要较长的一个时间，微信提供了初始渲染缓存机制，启用初始渲染缓存可以使视图层不需要等待逻辑层代码初始化完毕就可以直接提前将这个页面初始化的数据渲染的结果展示给用户。 以上就是针对启动流程中部分节点的一个性能优化技巧，稍后我们在课程里面都会详细地进行讲解在运行的时候针对小程序的双线程运行机制和视图重渲染机制也有相关的一些性能优化技巧。下面我们就再看一下这方面的一些技巧。

基于业务需要，小程序内指定的页面不允许分享（或仅限特定的人分享），想要做到这一点，需要注意的分享口子有哪些？ 页面内右上角分享菜单：通过wx.hideShareMenu()禁用页面内自定义的分享按钮（button[open-type=share]）：wx:if控制按钮显示/隐藏小程序码（或包含小程序码的海报）分享： 禁止生成该页面的小程序码有分享权限的人转发到群聊：在onShareAppMessage的返回信息中添加参数：withShareTicket: true，可以避免被二次转发有分享权限的人转发给微信用户（单人聊天窗口）： 经测试目前无法避免被二次转发（哪位大佬有办法限制吗？）公众号回复小程序链接：回复内容可以被转发到群聊或个人，回复内容本质上是个超链接，微信已经对超链接的appid、path等参数加密，转发出去也无法添加到其它公众号下使用（这个目前有办法绕过吗？）。小卡片嵌入公众号文章：PC端打开文章可以直接获取到小程序码小程序链接嵌入公众号文章：PC端打开文章可以直接获取到小程序码 求教大佬们，此外还有哪些途径需要注意的？

onShareAppMessage: function (options) {     console.log(options);     const { webViewUrl } = options;     const i = webViewUrl.indexOf('?');     let search = '',       url = webViewUrl;     if(i !== -1) {       url = webViewUrl.slice(0, i);       console.log({url});       search = `${webViewUrl.slice(i + 1)}`;       console.log({search});     }     const shareObj = {       title: "这是标题",        // 默认是小程序的名称(可以写slogan等)       dec:"sadasdsadasdasd",       path: `/pages/index/index?url=${url}${search ? '&' : ''}${search}`,        // 默认是当前页面，必须是以‘/’开头的完整路径，通过拼接的方式，把需要分享的web-view的url以及参数拼接进去，然后在该`web-view`的页面中去做参数判断，一旦传入了对应的url和参数，就进入对应的url并携带对应的参数       //imageUrl: '',     //自定义图片路径，可以是本地文件路径、代码包文件路径或者网络图片路径，           }     console.log({shareObj});     // 来自页面内的按钮的转发     if (options.from == 'button') {       var data= options.target.dataset;       console.log(data.name);     // shareBtn       // 此处可以修改 shareObj 中的内容       // shareObj.path = '/pages/index' + data.name;     }     // 返回shareObj     return shareObj;   }

首先，是我要渲染的list，结构如下图: [图片] 接下来就是在debug中的代码 [图片] 已知，我有两种访问方式，一种是，点击按钮渲染，另一种是直接从onLoad进去渲染。 然后都debug到这一步，特意对比了appData的数据，还有两个list的数据，都是一模一样。 随后点击到setData执行结束以后，点击按钮渲染的可以正常地把我想要的数据渲染出来，渲染的就是commodity中的rows，但是onLoad进去的，就渲染失败了，只给出两个空的架子，里面的rows渲染不到。 请问是怎么回事？求解决方法。

请问小程序如何获取当前页面路径？、

从云数据库中取数成功，res.data[0]是一个对象，已经成功取到数据了。但是无法通过this.setdata赋值，提示Uncaught (in promise) ReferenceError: traininglist is not defined，哪位大神指点一下，不胜感激。 onLoad: function (options) {     var that = this ;     const db = wx.cloud.database();     db.collection('traininglist').get().then(res =>{       that.setData({          traininglist:res.data[0]        })        console.log(traininglist)      })     },

在 2019 年 7 月 2 日的小程序基础库版本更新 v2.7.3 中，小程序新增了一个页面间通讯的接口，帮助我们的小程序完成不同页面间数据同步的功能。 页面间通信接口能干嘛？ 在 v2.7.3 之前，小程序不同页面间的大批量数据传递主要有两种： 借助诸如 Mobx 、Redux 等工具，来实现不同页面间的数据传递。 借助小程序提供的 storage ，来完成在不同页面间数据的同步。 前者需要引入一些第三方工具库，从而提升了整个应用的大小，同时，引入的工具也带来了学习生本。而后者则是基于小程序提供的存储，先将数据存入存储，再到另外一个页面去读取，如果数据涉及到了多个页面，则可能会导致数据的紊乱。 新的页面间通信接口则直接解决了上述的两个问题，你可以直接使用 API 在两个页面之间传递数据，再也无需担心数据的紊乱。 新增的页面间通信接口应当如何使用？ 关于页面间通信接口的使用非常简单。 这里，我们假设存在 A 和 B 两个页面，其中 A 是首页，B是详情页。 A 向 B 传递数据 如果你需要从首页向详情页传递数据，则可以这样操作。 在页面 A 执行代码 [代码]wx.navigateTo({ url: 'test?id=1' success: function(res) { // 通过eventChannel向被打开页面传送数据 res.eventChannel.emit('acceptDataFromOpenerPage', { data: 'test' }) } }) [代码] 这样，当 A 跳转到 B 时，就会出发 B 当中定义的 acceptDataFromOpenerPage，并将后续的数据传递过去。 在 B 中，你可以在 onLoad 去定义 eventChannel 的相关方法 [代码]Page({ onLoad: function(option){ // 监听acceptDataFromOpenerPage事件，获取上一页面通过eventChannel传送到当前页面的数据 let eventChannel = this.getOpenerEventChannel(); eventChannel.on('acceptDataFromOpenerPage', function(data) { console.log(data) }) } }) [代码] B 向 A 传递数据 如果需要被打开的页面向打开的页面传递数据，则可以使用如下代码: 在 A 中的跳转时，加入 events 的定义，定义你自己的函数，以及对应的处理函数。 [代码]wx.navigateTo({ url: 'test?id=1', events: { someEvent: function(data) { console.log(data) } }, }) [代码] 然后在 B 中，调用如下代码来发信息 [代码]Page({ onLoad: function(option){ const eventChannel = this.getOpenerEventChannel() eventChannel.emit('someEvent', {data: 'test'}); } }) [代码] 这样，就可以在 B 页面将数据传回到 A 页面了。 页面间通信接口使用注意事项？ 在使用页面间通信接口时需要注意两点： 该功能从基础库 2.7.3 开始支持，低版本需做兼容处理。

目前已知的自定义转发功能需要在onShareAppMessage里实现，如果在Page.js里面写上了onShareAppMessage,页面右上角就会出现转发按钮，如果不在Page.js里设置，只是把button的open-type设置为share，就无法自定义title和图片，请问有没有什么办法既能实现只通过button转发，又能自定义呢？ ps：我尝试了在button的bindtap中加入this.onShareAppMessage = function(){.....}这种方法，但是第一次点击没有效果，关闭分享窗口后再次点击即可实现自定义

我在做的小程序图片和短音频较多，直接用小程序云端的网络地址，每次打开相应的页面不能立即展示图片，有延迟，效果不太好。怎么样把那些资源提前缓存，提高小程序的用户体验？

页面滑动出现抖动，什么原因？

[图片] 3.20更新 最近没有更新游戏，觉得该做个游戏推广视频，于是就自己下载了final cut pro 研究了一下做了个视频 这个是放在游戏开始的时候播放的 https://v.youku.com/v_show/id_XNDEwMzE5OTIzMg==.html?spm=a2h3j.8428770.3416059.1 还有个两分钟的长版，这个节奏掐的比较好，短板是在长版的基础上截取的，长版更像是宣传视频 https://v.youku.com/v_show/id_XNDEwMDQyNjUwMA==.html?spm=a2h3j.8428770.3416059.1 不想做后期的程序员不是好司机！ 在小游戏上做大型手游确实有点费劲，因为小程序没有JIT，出来的性能会相较浏览器差很多，单单优化就耗时两三个月。 完成图预览 [图片] [图片] -----------不太华丽还有点短的分割线------------- 做游戏之前是开发安卓和ios，一直有个游戏梦，所以还要特别感谢微信小游戏。之前也没有多少游戏经验，天资不足只能拿时间来凑。 之所以做了两年，后端和前端，外加美工，策划，测试…等等。小兵还需要建模导出，确实耗费了太多的精力，每天都熬夜，因为自己也还有工作任职技术总监，真是争分夺秒的做。 因为做这款游戏，女朋友都快没了，发际线也越来越靠后了，因为自己也还有工作，好吧，扯远了，打算做这个游戏的时候年龄二十八九，做完已经三十岁了。 后台java分布式，七个项目分布，各有不同功能，所以不需质疑代码量，几十万行很轻松… ps，带回车(括号内容表达出技术人员的严谨来) 做的这款游戏虽然看着是个2D游戏，等真的做的时候会发现游戏逻辑很多很多，为了实现前端动作无延迟，后端还要再写一次判断，比如金币够不够，工人够不够之类，这样类型的游戏用户针对性强，也算是一次赌注 相信小游戏平台也需要高丰富度的游戏。 [图片] [图片] 首创怪物入侵，外加防守用的合剂药水。 特别吐槽一下小程序没有JIT 最开始高估了小游戏的性能，最后不得不修改一些游戏逻辑，比如update中的条件判断改为触发执行等等。 因为内容很多，也不好择哪个拿出来说，看坛友对哪方面感兴趣我特别的说一下或做个demo。 软著相关。 中国版权中心在上海北京都有实体点，可以把文件准备好后直接现场办理，这样相对邮寄更快一些。现场办理需要预约，微信预约都要提前一个星期，提前关注好公众号预约！切记！ 申请软著需要：软件说明书，申请单（官方网站填写，填写好后打印），游戏代码（前30页，后30页） 因为软著特别要求格式，其实你的代码他们都不会看的，有几个要注意的地方 1.说明书header标题格式要带上版本号，如：溪谷游戏软件V1.0说明书 2.说明书及代码都要带上页码，可以是‘第1页／共30页’，也可以是‘1/30’ 3.代码中不要有任何一行空格！ 4.还有一个，申请书打印的时候会发现下面带了一个URL，这个URL一定要打印！ 5.代码第30页的最后一行一定是代码结束符号 } 6.代码后30页的最后一页 最后一行，加上 ----完----- 个人推广不易，望大家多多支持 [图片]

想在input前部添加一个搜索图标，使用padding-left时，图标就变成两个了 <view class='home-top-mid '>     <input class='home-top-search' placeholder='搜索想要的书籍'></input> </view> .home-top-search{     width: 100%;     height: 100%;     font-size:24rpx;     /* text-indent: 60rpx; */     border-radius: 34rpx;     background-image: url(data:image/jpeg;base64,/);//base64省略     background-size: 30rpx 30rpx;     background-position: 19rpx 19rpx;     background-repeat: no-repeat;     background-color: #F5F5F5;     padding-left: 60rpx;//使用该属性时，出现两个背景图     }

微信小程序 onPullDownRefresh在苹果机会上弹

html代码： [代码]<cover-view class='items'> <cover-view class='name'>设备名</cover-view> <cover-view class='display' bindtap='inputNameState'> {{nameInfo}} </cover-view> <cover-view class='border'></cover-view> <input type="text" focus="{{nameTrue}}" bindinput="inputName"></input> </cover-view> [代码] js代码： [代码]inputNameState(){ this.setData({ nameTrue: true }) }, inputName(e){ this.setData({ nameInfo: e.detail.value }) } [代码] 实际效果 [图片]

用cover-view 来显示，input来输入，通过bindinput来赋值，用cover-view来覆盖input的位置，同时把cover-view的背景颜色设置透明，这样既不会被其它组件盖住，也能显示出input的光标出来。

Enhanced Wechat App Development Toolkit (微信小程序增强开发工具) 项目地址：https://github.com/lyfeyaj/ewa，欢迎试用 ~ 为什么开发这个工具？厌倦了不停的对比 wepy 或者 mpvue 的特性，间歇性的踩雷，以及 [代码]code once, run everywhere[代码] 的幻想。只想给小程序开发插上效率的翅膀 ~ 功能特性async/await 支持 Javascript ES2017 语法 原生小程序所有功能 微信接口 Promise 化 支持安装 NPM 包 支持 SCSS 以及 小于 16k 的 background-image 支持 source map, 方便调试 添加新页面或新组件无需重启编译 允许自定义编译流程 更多特性正在赶来 ... 敬请期待 👇 LESS 支持 可跨项目复用的小程序组件或页面（通过NPM包管理） Redux 支持 Mixin 支持 安装需要 node 版本 >= 8 [代码]npm i -g ewa-cli 或者 yarn global add ewa-cli[代码]如何使用创建新项目[代码]ewa new your_project_name[代码]集成到现有小程序项目，仅支持小程序原生开发项目转换注意：使用此方法，请务必对项目代码做好备份！！！ [代码]cd your_project_dir && ewa init[代码]启动运行 [代码]npm start[代码] 即可启动实时编译 运行 [代码]npm run build[代码] 即可编译线上版本（相比实时编译而言，去除了 source map 并增加了代码压缩混淆等，体积更小） 上述命令运行成功后，可以看到本地多了个 [代码]dist[代码] 目录，这个目录里就是生成的小程序相关代码。 使用微信开发者工具选择 [代码]dist[代码] 目录打开，即可预览项目 目录结构[代码]├── .ewa                         特殊占位目录，用于检查是否为 ewa 项目 ├── dist                         小程序运行代码目录（该目录由ewa的start 或者 build指令自动编译生成，请不要直接修改该目录下的文件） ├── node_modules                 外部依赖库 ├── src                          代码编写的目录（该目录为使用ewa后的开发目录） │   ├── components               小程序组件目录 │   ├── pages                    小程序页面目录 │   │   ├── index │   │   │   ├── index.js│   │   │   ├── index.wxml│   │   │   └── index.wxss│   │   └── logs │   │       ├── logs.js│   │       ├── logs.json│   │       ├── logs.wxml│   │       └── logs.wxss│   ├── templates                小程序模版目录 │   ├── utils │   │   └── util.js│   ├── app.js                   小程序入口文件 │   ├── app.json                 小程序全局配置文件 │   ├── app.wxss                 小程序全局样式文件 │   └── project.config.json      微信开发者工具小程序项目配置文件 ├── ewa.config.js                ewa 配置文件 ├── .gitignore├── .eslintrc.js                 eslint 配置 └── package.json[代码]微信接口 Promise 化[代码]const { wx } = require('ewa'); Page({  async onLoad() {    let { data } = await wx.request({ url: 'http://your_api_endpoint' });  } })[代码]配置ewa 通过 [代码]ewa.config.js[代码] 来支持个性化配置。如下所示： [代码]// ewa.config.jsmodule.exports = {  // 公用代码库 (node_modules 打包生成的文件)名称，默认为 vendors.js  commonModuleName: 'vendors.js',  // 通用模块匹配模式，默认为 /[\\/]node_modules[\\/]/  commonModulePattern: /[\\/]node_modules[\\/]/,  // 是否简化路径，作用于 page 和 component，如 index/index.wxml=> index.wxml，默认为 false  simplifyPath: false,  // 文件夹快捷引用  aliasDirs: [    'apis',    'assets',    'constants',    'utils'  ],  // 需要拷贝的文件类型  copyFileTypes: [    'png',    'jpeg',    'jpg',    'gif',    'svg',    'ico'  ],  // webpack loader 规则  rules: [],  // webpack 插件  plugins: [],  // 嫌不够灵活？直接修改 webpack 配置  webpack: function(config) {    return config;  } };[代码]常见问题 & Tipswxss 中可以直接编写 scss 样式代码 可以使用 [代码]@[代码] 来代替源代码根目录来引入代码或样式，如 [代码]const utils = require('@/utils/util')[代码]