我要提问
- 关于
滚动监听
的搜索结果
回答
终极解决答案... 经过一年多的探索... 给大家一个答案... 我也是日了狗了...<body> <ui-view class="container" style="display: block; height: 100%; overflow: auto"></ui-view> <div id="showDetail" class="show-detail" ng-show="showDetail" ng-include="'showDetail.html'"></div> </body>这里 ui-view这个标签是正常显示的，点击上面的元素后弹出showDetail。 一次无意间的测试，在ui-view的标签上加了一个overflow：auto 滚动就不穿透了...如果不在对应的需要滚动的容器上，加这个样式的话，最后滚动条会在body上。 射了这个样式的话 window.on('scroll') 也会失效。这个时候要监听container上的scroll
回答
根据题猪提供的测试案例调试了下， 发现 iSlider 无法捕获到iframe中的 touchmove事件。如果要解决上述问题确实比较蛋疼，得在 iframe中监听 touchmove事件，然后在合适的时机（页面滑到底部/顶部）告诉父级页面，执行翻页操作（这种方法太 ugly 啦~）。如果你可以保证你的的 iframe不会出现滚动条，或者即使出现也不让用户滚动的话，那么你可以给iframe一个属性值pointer-events: none;，这是最简单的解决问题的方式（不完美~）。另外，我决定比较好的方案是采用 ajax 请求的方式来获取 iframe 中的内容，然后填充到一个容器中，这样就不存在上述问题了。
回答
根据题猪提供的测试案例调试了下， 发现 iSlider 无法捕获到iframe中的 touchmove事件。 如果要解决上述问题确实比较蛋疼，得在 iframe中监听 touchmove事件，然后在合适的时机（页面滑到底部/顶部）告诉父级页面，执行翻页操作（这种方法太 ugly 啦~）。如果你可以保证你的的 iframe不会出现滚动条，或者即使出现也不让用户滚动的话，那么你可以给iframe一个属性值pointer-events: none;，这是最简单的解决问题的方式（不完美~）。另外，我决定比较好的方案是采用 ajax 请求的方式来获取 iframe 中的内容，然后填充到一个容器中，这样就不存在上述问题了。
回答
Fresco 是 Facebook 推出的开源图片缓存工具，主要特点包括：两个内存缓存加上 Native 缓存构成了三级缓存，
优点：
图片存储在安卓系统的匿名共享内存, 而不是虚拟机的堆内存中, 图片的中间缓冲数据也存放在本地堆内存, 所以, 应用程序有更多的内存使用, 不会因为图片加载而导致oom, 同时也减少垃圾回收器频繁调用回收 Bitmap 导致的界面卡顿, 性能更高。 渐进式加载 JPEG 图片, 支持图片从模糊到清晰加载。 图片可以以任意的中心点显示在 ImageView, 而不仅仅是图片的中心。 JPEG 图片改变大小也是在 native 进行的, 不是在虚拟机的堆内存, 同样减少 OOM。 很好的支持 GIF 图片的显示。
缺点:
框架较大, 影响 Apk 体积 使用较繁琐
Universal-ImageLoader：（估计由于HttpClient被Google放弃，作者就放弃维护这个框架）
优点：
1.支持下载进度监听
2.可以在 View 滚动中暂停图片加载，通过 PauseOnScrollListener 接口可以在 View 滚动中暂停图片加载。
3.默认实现多种内存缓存算法 这几个图片缓存都可以配置缓存算法，不过 ImageLoader 默认实现了较多缓存算法，如 Size 最大先删除、使用最少先删除、最近最少使用、先进先删除、时间最长先删除等。
4.支持本地缓存文件名规则定义
Picasso 优点
自带统计监控功能。支持图片缓存使用的监控，包括缓存命中率、已使用内存大小、节省的流量等。
2.支持优先级处理。每次任务调度前会选择优先级高的任务，比如 App 页面中 Banner 的优先级高于 Icon 时就很适用。
3.支持延迟到图片尺寸计算完成加载
4.支持飞行模式、并发线程数根据网络类型而变。 手机切换到飞行模式或网络类型变换时会自动调整线程池最大并发数，比如 wifi 最大并发为 4，4g 为 3，3g 为 2。 这里 Picasso 根据网络类型来决定最大并发数，而不是 CPU 核数。
5.“无”本地缓存。无”本地缓存，不是说没有本地缓存，而是 Picasso 自己没有实现，交给了 Square 的另外一个网络库 okhttp 去实现，这样的好处是可以通过请求 Response Header 中的 Cache-Control 及 Expired 控制图片的过期时间。
Glide 优点
不仅仅可以进行图片缓存还可以缓存媒体文件。Glide 不仅是一个图片缓存，它支持 Gif、WebP、缩略图。甚至是 Video，所以更该当做一个媒体缓存。 支持优先级处理。 与 Activity/Fragment 生命周期一致，支持 trimMemory。Glide 对每个 context 都保持一个 RequestManager，通过 FragmentTransaction 保持与 Activity/Fragment 生命周期一致，并且有对应的 trimMemory 接口实现可供调用。 支持 okhttp、Volley。Glide 默认通过 UrlConnection 获取数据，可以配合 okhttp 或是 Volley 使用。实际 ImageLoader、Picasso 也都支持 okhttp、Volley。 内存友好。Glide 的内存缓存有个 active 的设计，从内存缓存中取数据时，不像一般的实现用 get，而是用 remove，再将这个缓存数据放到一个 value 为软引用的 activeResources map 中，并计数引用数，在图片加载完成后进行判断，如果引用计数为空则回收掉。内存缓存更小图片，Glide 以 url、view_width、view_height、屏幕的分辨率等做为联合 key，将处理后的图片缓存在内存缓存中，而不是原始图片以节省大小与 Activity/Fragment 生命周期一致，支持 trimMemory。图片默认使用默认 RGB_565 而不是 ARGB_888，虽然清晰度差些，但图片更小，也可配置到 ARGB_888。
6.Glide 可以通过 signature 或不使用本地缓存支持 url 过期
回答
先说结论：
不要对接！不要对接！不要对接！
开个玩笑，以上仅代表个人观点，大家也知道这种“三体式警告”根本没有用的，我自己也研究如何对接，说不定做完后就觉得“真香”了。
为什么要对接？
首先讨论一下为什么要把 Flutter 对接到 Web 生态。
Flutter 现在是一个炙手可热的跨平台技术，能够一套代码运行在 Android、iOS、PC、IoT 以及浏览器上，被认为是下一代跨平台技术。相比于 Weex 和 React Native 可以很好地解决多平台一致性问题，原生渲染性能相近，上层没有 JS 那么厚的封装层次，整体性能会略好一些。
但是大部分兴冲冲去学 Flutter 的人疑惑的第一个问题就是：为什么 Flutter 要用 Dart？一个全新的语言意味着新的学习成本，难道 JS 不香吗？JS 不香不是还有 TypeScript 吗！事实上 Flutter 抛弃的岂止是 JS 这门语言，也抛弃了 HTML 和 CSS，设计了一套解耦得更好的 Widget 体系，Flutter 抛弃的是整个 Web，致力于打造一个新的生态，但是这个生态无法复用 Web 生态的代码和解决方案。尤其是之前所有跨平台方案 Hybrid、React Native、Weex 都是对接 Web 生态的，这让 Flutter 显得有些格格不入，也让大部分前端开发者望而却步。
下面是我整理出来的，前端开发者使用 Flutter 的各方面成本：
因为 Flutter 的开发模式和前端框架比较像（可以说就是抄的 React），所以框架的学习成本并不高，稍微高一些的是 Dart 语言的学习成本，另外还要学习如何用 Widget 组装 UI，虽然很多布局 Widget 设计得和 CSS 很像，灵活度还是差了很多。要想在真实项目中用起来，还要改造整个工具链，以“Native First”的视角做开发，开发 Flutter 和开发原生应用的链路是比较像的，和开发前端页面有较大差异。最高的还是生态成本，前端生态的积累无论是代码还是技术方案都很难复用，这是最痛的一点，生态也是 Flutter 最弱的一环。
无论是为了先进的技术理念还是出于商业私心，先不管 Flutter 为什么抛弃 Web 生态，现实问题是最大的 UI 开发者群体是前端，最丰富的生态是 Web 生态，我觉得 Web 技术也是开发 UI 最高效的方式。如果能在上层使用 Web 技术栈开发，在底层使用 Flutter 实现跨平台渲染，不是可以很好的兼顾开发效率、性能和跨平台一致性吗？还能复用 Web 技术栈大量的技术积累。
可能这些理由也不够充分，暂且先照着这个假设继续分析，最后再重新讨论到底该不该对接。
关于 Flutter 和 Web 生态的对接涉及两个方面：
从 Web 到 Flutter。就是使用 Web 技术栈来开发，然后对接到 Flutter 上实现跨平台渲染。对 Web 来说是解决性能和跨平台一致性问题，对 Flutter 来说是解决生态复用问题。从 Flutter 到 Web。就是官方已经实现的 Web support for Flutter，把已经用 Dart 开发好的 App 编译成 HTML/JS/CSS 然后运行在浏览器上，可以用于降级和外投场景。
如何实现“从 Web 到 Flutter”？
首先分析一下 Flutter 的架构图，看看可以从哪里下手。 Flutter 可以分为 Framework 和 Engine 两部分，Engine 部分比较底层也比较稳定了，最好不要动，需要改的是用 Dart 实现的 Framework。要想对接 Web 生态的话，JS 引擎肯定是要引入的，至于是否保留 Dart VM 有待讨论。图中最上面 Material 和 Cupertino 两个 UI 库前端是不需要的，前端有自己的。关键是 Widget 这部分，是替换成 HTML/CSS 的方式写 UI，还是继续保留 Widget 但是把语言换成 JS，不同方案给出的解法也不一样。
有不少方案可以实现对接，业界有挺多尝试的，我总结了下面三种方式： - TS 魔改：用 JS 引擎替换掉 Dart VM，用 JS/TS 重新实现 Flutter Framework（或者直接 dart2js 编译过来）。 - JS 对接：引入 JS 引擎同时保留 Dart VM，用前端框架对接 Flutter Framework。 - C++ 魔改：用 JS 引擎替换掉 Dart VM，用 C++ 重新实现 Flutter Framework。
TS 魔改
TS 魔改就是完全抛弃掉 Dart VM，用 TypeScript 重新实现一遍用 Dart 写的 Flutter Framework。
为啥是 TS 而不是 JS？这不是因为 TS 是个大热门嘛，而且向下兼容 JS，现在几乎所有时髦的框架都要用 TS 重写了。
这种方案的出发点是“如果能把 Flutter 的 Dart 换成 JS 就好了”，最容易想到的路就是把 Dart 翻译成 TS，或者直接用 dart2js 把代码编译成 js，但是编译出来的代码包含很多 dart:ui 之类的库的封装，生成的包也挺大的，也比较难定制需要导出的接口，不如干脆用 TS 重写一遍，工具链更熟悉一些，还可以加一些定制。
理论上讲翻译之后 Flutter 绝大部分功能都依然支持，可以复用各种 npm 包，还可以动态化，但是丧失了 AOT 能力，JS 语言的执行性能应该是不如 Dart 的。而且所有节点的布局运算都发生在 JS，底层只需要提供基础的图形能力就好了，就好像是基于 Canvas API 写了一套 UI 框架，性能未必有现存前端框架的性能高。
此外最大的问题是如何与官方 Flutter 保持一致，假如现在是从 v1.13 版本翻译过来的，以后官方升级到了 v1.15 要不要同步更新？这个过程没啥技术含量，而且需要持续投入，做起来比较恶心。
另外还需要考虑上层是用 Widget 的方式写 UI，还是用前端熟悉的 HTML+CSS。如果依然用 Widget 的话，那大部分前端组件还是用不了的，UI 还是得重写一遍。反正要重写的话，成本也没降下来，那就用 Dart 重写呗…… 直接用官方原版 Flutter 也避免每次更新都要翻译一遍 Dart 代码。所以既然选择了对接前端生态，那就要对接 CSS，不然就没有足够的价值。然而 CSS 和 Widget 的对接也是很繁琐的过程，而且存在完备性问题。
JS 对接
翻译代码的方式不够优雅，那就保留 Dart，把 JS/CSS 对接到 Widget 上面不就好了？
当然可以，这种方式是仅把 Flutter 当做了底层的渲染引擎，上层保持前端框架的写法，仅把渲染部分对接到 Flutter。现存的很多前端框架都把底层渲染能力做了抽象，可以对接到不同渲染引擎上，如 Vue/Rax 同时支持浏览器和 Weex，用同样的方式，可以再支持一个 Flutter。
这种方式对前端框架的兼容性比较好，但是链路太长了，业务代码调用前端框架接口做渲染，一顿操作之后发出了渲染指令，这个渲染指令要基于通信的方式传给 Flutter Framework，这中间涉及一次 JS 到 C++ 再到 Dart 的跨语言转换，然后再接收到渲染指令之后还要转成相应的 Widget 树，从 CSS 到 Widget 的转换依然很繁琐。而且 Widget 本身是可以带有状态的，本身就是响应式更新的，在更新时会重新生成 widget 并 diff，如果在前端更新 UI 的话，前端框架在 js 里 diff 一次 vdom，传到 Flutter 之后又 diff 一次 widget。
如果要绕过 Widget 直接对接图中的 Rendering 这一层，可以绕过 widget diff 但是得改 Flutter Framework 的渲染链路，既然要改 Flutter Framework 那为什么不直接用 TS 魔改呢，还绕过了 JS 到 Dart 的通信，又回到了第一种方案。
总结来说，这个方案的优点是：实现简单、能最大化保留前端开发体验，缺点是：渲染链路长、通信成本高、响应式逻辑冲突、CSS 转 Widget 不完备等。
C++ 魔改
想要干掉 Dart VM，就需要用其他语言重新实现用 Dart 开发的 Framework，用 JS/TS 可以，用 C++ 当然可以，最硬核的方式就是用 C++ 重新实现 Flutter 的 Framework，然后接入 JS 引擎，通过 binding 把 C++ 接口透出到 JS 环境，上层应用还是用 JS 做开发。
把 Framework 层下沉到 C++ 之后，不仅会有更好的性能，也能支持更多语言。原本 Flutter Framework 是在 Dart VM 之上的，必须依赖 Dart VM 才能运行，所以对 Dart 有强依赖；用 C++ 重新实现之后，JS 引擎是在 C++ 版 Framework 之上的，框架本身并不依赖 JS 引擎，还可以对接其他各种语言，如对接了 JVM 之后可以支持 Java 和 Kotlin，对接回 Dart VM 可以继续支持 Dart。
这个方案可以增强性能，也能保持和 Flutter 的一致性，但是改造成本和维护成本都相当高。C++ 的开发效率肯定不如 Dart，当 Flutter 快速迭代之后如何跟进是很大的问题，如果跟进不及时或者实现不一致那很可能就分化了。从 CSS 到 Widget 的转换也是不得不面对的问题。
几种方案对比
把上面几种方案画在同一张图里是这个样子的：
图中实线部分表示了跨语言的通信，太过频繁会影响性能，虚线部分表示了其他对接可能性。
从下到上，Flutter Engine 是不需要动的，这一层是跨平台的关键。Framework 则有三种语言版本，JS/TS、Dart、C++，性能是 C++ 版本最好，成本是 Dart 版本最低。然后还需要向上处理 HTML/CSS 和 Widget 的问题，可以直接对接一个前端框架，也可以直接在 C++ 层实现（不然需要透出的 binding 接口就太多了，用通信的方式也太过频繁了）。
如何实现“从 Flutter 到 Web”？
这个功能官方已经实现了，可以把使用 Dart 开发的 App 编译成 Web App 运行在浏览器上，官方文档以介绍用法和 API 为主，我这里简单分析一下内部具体的实现方案。
实现原理 结合 Flutter 的架构图来看，要实现 Web 到 Flutter 需要改造的是上层 Framework，要实现 Flutter 到 Web 需要改造的则是底层 Engine。
Framework 对 Engine 的核心依赖是 dart:ui，这是库是在 Engine 里实现的，抽象出了绘制 UI 图层的接口，底层对接 skia 的实现，向上透出 Dart 语言的接口。这样来看，对接方式就比较简单了：
使用 dart2js 把 Framework 编译成 JS 代码。基于浏览器的 API 重新实现 dart:ui，即 dart:web_ui。
把 Dart 编译成 JS 没什么问题，性能可能会有一点影响，功能都是可以完全保留的，关键是 dart:web_ui 的实现。在原生 Engine 中，dart:ui 依赖 skia 透出的 SkCanvas 实现绘制，这是一套很底层的图形接口，只定义了画线、画多边形、贴图之类的底层能力，用浏览器接口实现这一套接口还是很有挑战的。上图可以看到 Web 版 Engine 是基于 DOM 和 Canvas 实现的，底层定义了 DomCanvas 和 BitmapCanvas 两种图形接口，会把传来的 layer tree 渲染成浏览器的 Element tree，但是节点上仅包含了 position, transform, opacity 之类的样式，只用到 CSS 很小的一个子集，一些更复杂的绘制直接用 2D canvas 实现。
存在的问题
我编译了一个还算复杂的 demo 试了一下，性能很不理想，滑动不流畅，有时候图片还会闪动。生成出来的 js 代码有 1.1MB (minify 之后，未 gzip)，节点层次也比较深，我评估这个页面用前端写不会超过 300KB，节点数可以少一半以上。
另外再看一下 Flutter 仓库的 issue，过滤出 platfrom-web 相关的，可以看到大量：文字编辑失效、找不到光标、ListView 在 ios 上不可滚动、checkbox/button 行为不正常、安卓滚动卡顿图片闪烁、字体失效、某些机型视频无法播放、文字选中后无法复制、无法调试…… 感觉 flutter for web 已经陷入泥潭，让人回想起前端当年处理各种浏览器兼容性的噩梦。
这些性能和兼容性问题，核心原因是浏览器未暴露足够的底层能力，以及浏览器处理手势、用户输入和方式和 Flutter 差异巨大。
实现 Flutter Engine 需要的是底层的图形接口和系统能力，虽然canvas 提供了相似的图形接口，如果全部用 canvas 实现的话很难处理可访问性、文本选择、手势、表单等问题，也会存在很多兼容性问题。所以真实方案里用的是 Canvas + DOM 混合的方式，封装层次太高了，渲染链路太长。就好像 Flutter Framework 里进行了一顿猛如虎的操作之后，节点生成好了、布局算好了、绘制属性也处理好了，就差一个画布画出来了，然后交到浏览器手里，又生成一遍 Element，再算一遍布局，在处理一遍绘制，最终才交给了底层的图形库画出来。
再比如长页面的滚动，浏览器里只要一条 CSS (overflow:scroll) 就可以让元素可滚动，手势的监听以及页面的滚动以及滚动动画都是浏览器原生实现的，不需要与 JS 交互，甚至不需要重新 layout 和 paint，只需要 compositing。如上图所示，在 Flutter 中 Animation 和 Gesture 是用 Dart 实现的，编译过来就是 JS 实现的，浏览器本身并不知道这个元素是否可滚，只是不断派发 touchmove 事件，JS 根据事件属性计算节点偏移，然后运算动画，然后把 transform 或者新的 position 作用到节点上，然后浏览器再来一遍完整的渲染流程……
优化方案
性能和兼容性的问题还是要解决的，短期内先把 issue 解掉，长线的优化方案，官方有两种尝试：
使用 CSS Painting API 做绘制。 a, 这是还处于提案状态的新标准，可以用 JS 实现一些绘制功能，自定义 CSS 属性。 b. 目前还未实现，需要等浏览器先把 CSS Houdini 支持好。 使用 WebAssembly 版本的 Skia 做绘制 https://skia.org/user/modules/canvaskit a, 这样可以发挥 wasm 的性能优势，并且保持 skia 功能的一致。但是目前 wasm 在浏览器环境里未必有性能优势，这里不展开讨论了。 b. 已经部分实现，参考这里的配置启用功能： https://github.com/flutter/flutter/issues/41062#issuecomment-533952994
这两个方案都是想更多的利用到浏览器的底层能力，只有浏览器暴露了更多底层能力，才能更好的实现 Flutter 的 Web Engine。不过这个要等挺久的时间，我们也参与不了，现阶段想要使用 flutter for web，还是得保持现有架构，一起参与进去把 issue 解决掉，优先保障功能，其次优化性能。
一种适应性更好的架构
如果理想化一点，能不能从架构角度让 Flutter 和 Web 生态融合的更好一些呢？
回顾文章最开始的官方架构图，上面是 Framework(Dart)，下面是 Engine(C++)，切分在 Foundation 这一层，双方之间的交互是几何图形信息。如果还保持这个架构，把切分层次划分的更靠上一些，如下图所示，划分在 Widgets 和 Rendering 这一层，理论上讲对 Flutter 的开发者来说是无感知的，因为上层的开发语言和 Widget 接口都是不变的。 切分在这一层，Framework 和 Engine 之间的交互就不再是几何图形而是节点信息，Widget 的组合、setState 响应式更新、Widget diff 都还在 Dart 中，展开后的 RenderObject 的布局、绘制、裁剪、动画全都在 C++ 中，不仅有更好的性能，还可以与 Engine 有更好的结合。
或者说，还原本保留 Engine 的设计，把下沉的这部分逻辑上划分成 Renderer，就有了如下三层的结构： 这样划分出来的每一层都有明确的定位：
Framework: 开发框架。为开发者提供可编程 API，实现响应式的开发模式，提供细粒度 Widget 供开发者自由封装和组合。Renderer: 渲染引擎。专门实现布局、绘制、动画、手势的的处理，这部分功能相对独立，是可以与开发框架解耦的，也不必与特定语言绑定。Engine: 图形引擎。实现跨平台一致的图形接口，合成输入的层并绘制到屏幕上，处理好平台力的接入和适配。 这样切分除了有性能优势以外，也使得渲染引擎摆脱了对 Dart 的依赖，能够支持多种语言，也能支持多种开发模式。对接到 Dart VM 就可以用 Dart 写代码，对接到 JS 引擎就可以用 JS 写代码，对接到 JVM 还可以写 Java，但是无论怎么写，底层的渲染能力是一样的，一套统一的布局算法，动画和手势的处理行为也是一致的。
在这样的架构下，对接 Web 生态就更容易了。Dart 和 Widget 是前端不想要的，希望能换成 JS 和 CSS，但是又想要底层的跨平台一致渲染引擎，那从 Renderer 层开始对接就好了，绕过了所有不想要的，也保留了所有想要的。 要实现 Flutter for Web 也更简单了一些。在 Engine 层做对接，一直苦于浏览器透出的底层能力不够，如果是在 Renderer 之上做对接就更容易一些，基于 JS/CSS/DOM/Canvas 的能力封装出一套 Rendering 接口，供 Widget 调用就好了，这样可以使渲染链路更短一些，但是依然要处理 Widget 和 DOM/CSS 之间的兼容性问题。
再讨论一遍：为什么要对接？
技术上已经分析完了，要想搞定 Flutter 生态和 Web 生态的对接，需要投入很大的成本，所以真正决定做之前，要先讨论清楚为什么要做对接？到底要不要做对接？
首先 Google 官方对 Flutter 的定位就是个问题。Flutter 设计之初就是不考虑 Web 生态的，甚至在刻意回避，倡导的是更贴近原生的开发方式。我之所以在开头说不要对接，原因也很简单：两种技术设计理念不同，不是朝着一个方向发展的，生态不通，技术方案不通，强行融合很可能让彼此都丧失了优势。但是业界又有很多团队在做这种尝试，说明需求是存在的，如果 Google 抵制这个方向，那就不好做了。不过现在官方已经支持了 Flutter for Web，已经向 Web 生态迈了一步，未来是否进一步与 Web 融合，也是有可能的。
另外就是跨平台技术本身的问题，浏览器发展了二三十年，已经是个很强大的跨平台产品了，几乎是 Web 的代名词了，这一点无人能敌。但是也臃肿不堪，有大量历史包袱，性能和体验不够好，和 Native 的结合度差，尤其在移动和 IoT 平台。虽然硬件性能在不断提升，但这是所有软件共享的，浏览器的性能和体验总会比 Native 差一些，差的这一些很可能就是新业务和新场景的发挥空间。观察一下近几年新诞生的业务场景，很多都是利用到了 Native 新提供的能力才火爆起来的，如 AI/AR/ 视频 / 直播 等，有因为新的 Web API 而孵化生出来的商业模式吗？
原文链接： https://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650405725&idx=1&sn=0b7476f7c7c01df7fdafda578f9ceb98&chksm=83953345b4e2ba53917ac30b709c07be15bd1c2fd5ae2a8ecfbb129b3813f771621b8fac95ca&scene=27#wechat_redirect
回答
概述 App() 代表顶层应用，管理所有页面和全局数据，以及提供生命周期回调等。它 也是一个构造方法，生成 App 实例。 一个小程序就是一个 App 实例。 每个小程序顶层一般包含三个文件。 app.json：应用配置 app.js：应用逻辑 app.acss：应用样式（可选） 简单示例 一个简单的 app.json 代码如下：
"pages": [
"pages/index/index",
"pages/logs/logs"
],
"window": {
"defaultTitle": "Demo"
} }
这段代码配置指定小程序包含两个页面（index 和 logs），以及应用窗口的默认 标题设置为 “Demo”。 一个简单的 app.js 代码如下：
onLaunch(options) {
// 第一次打开
},
onShow(options) {
// 小程序启动，或从后台被重新打开
},
onHide() {
// 小程序从前台进入后台
},
onError(msg) { // 小程序发生脚本错误或 API 调用出现报错 console.log(msg); }, globalData: { // 全局数据 name: 'alipay', }, }); 26 app.json 全局配置 app.json 用于对小程序进行全局配置，设置页面文件的路径、窗口表现、多 tab 等。 以下是一个基本配置示例：
"pages": [
"pages/index/index",
"pages/logs/index"
],
"window": {
"defaultTitle": "Demo"
} }
完整配置项如下： 属性 类型 是否必填 描述 pages Array 是 设置页面路径 window Object 否 设置默认页面的窗 口表现 tabBar Object 否 设置底部 tabbar 的表现 pages app.json 中的 pages 为数组属性，数组中每一项都是字符串，用于指定小程序 的页面。在小程序中新增或删除页面，都需要对 pages 数组进行修改。 pages 数组的每一项代表对应页面的路径信息，其中，第一项代表小程序的首 页。 页面路径不需要写任何后缀，框架会自动去加载同名的 .json、.js、.axml、.acss 文件。举例来说，如果开发目录为：
│ ├──index
│ │ ├── index.json
│ │ ├── index.js
│ │ ├── index.axml
│ │ └── index.acss
│ ├──logs
│ │ ├── logs.json
│ │ ├── logs.js
│ │ └── logs.axml
├── app.json
├── app.js
└── app.acss
app.json 中应当如下配置： { "pages":[ "pages/index/index", "pages/logs/logs" ] } window window 用于设置小程序的状态栏、导航条、标题、窗口背景色等。 示例代码： { "window":{ "defaultTitle": "支付宝接口功能演示" } } 属性 类型 是否必 填 描述 最低版本 defaultTitle String 否 页面默认标题 - pullRefresh String 否 是否允许下拉刷新。默认 NO, 备注：下拉刷新生效的 前提是 allowsBounceVertical 值 为 YES
allowsBounceV ertical String 否 是否允许向下拉拽。默认 YES, 支持 YES / NO
28 transparentTitl e String 否 导航栏透明设置。默认 none，支持 always 一直透 明 / auto 滑动自适应 / none 不透明
titlePenetrate String 否 是否允许导航栏点击穿透。 默认 NO，支持 YES / NO
showTitleLoadi ng String 否 是否进入时显示导航栏的 loading。默认 NO，支持 YES / NO
titleImage String 否 导航栏图片地址 - titleBarColor HexCol or 否 导航栏背景色，十六进制颜 色值（0-255） - backgroundCol or HexCol or 否 页面的背景色，十六进制颜 色值（0-255） - backgroundIm ageColor HexCol or 否 下拉露出显示的背景图底 色，十六进制颜色值（0- 255） - backgroundIm ageUrl String 否 下拉露出显示的背景图链接 - gestureBack String 否 iOS 用，是否支持手势返 回。默认 NO，支持 YES / NO
enableScrollBa r Boolea n 否 Android 用，是否显示 WebView 滚动条。默认 YES，支持 YES / NO
onReachBotto mDistance Number 否 页面上拉触底时触发时距离 页面底部的距离，单位为 px。相关文档页面事件处理 函数 1.19.0 ，目前 iOS 在 page.json 下设 置无效，只能全 局设置。 29 tabBar 如果你的小程序是一个多 tab 应用（客户端窗口的底部栏可以切换页面），那么 可以通过 tabBar 配置项指定 tab 栏的表现，以及 tab 切换时显示的对应页 面。 注意： 通过页面跳转（my.navigateTo）或者页面重定向（my.redirectTo）所到达的页面，即使 它是定义在 tabBar 配置中的页面，也不会显示底部的 tab 栏。 tabBar 的第一个页面必须是首页。 tabBar 配置项有以下： 属性 类型 是否必填 描述 textColor HexColor 否 文字颜色 selectedColor HexColor 否 选中文字颜色 backgroundColor HexColor 否 背景色 items Array 是 每个 tab 配置 每个 item 配置： 属性 类型 是否必填 描述 pagePath String 是 设置页面路径 name String 是 名称 icon String 否 平常图标路径 activeIcon String 否 高亮图标路径 icon 图标推荐大小为 60×60 px 大小，系统会对传入的非推荐尺寸的图片进行非 等比拉伸或缩放。 示例代码：
"tabBar": {
30
"textColor": "#dddddd",
"selectedColor": "#49a9ee",
"backgroundColor": "#ffffff",
"items": [
{
"pagePath": "pages/index/index",
"name": "首页"
},
{
"pagePath": "pages/logs/logs",
"name": "日志"
}
]
} }
app.acss 全局样式 app.acss 作为全局样式，作用于当前小程序的所有页面。 ACSS 是一套样式语言，用于描述 AXML 的组件样式，决定 AXML 的组件的显 示效果。 为适应广大前端开发者，ACSS 和 CSS 规则完全一致，100% 可以用。同时为更 适合开发小程序，对 CSS 进行了扩充。 ACSS 支持 px，rpx，vh，vw 等单位。 rpx rpx（responsive pixel）可以根据屏幕宽度进行自适应，规定屏幕宽为 750rpx。以 Apple iPhone6 为例，屏幕宽度为 375px，共有 750 个物理像 素，则 750rpx = 375px = 750 物理像素，1rpx = 0.5px = 1 物理像素。 设备 rpx 换算 px（屏幕宽度 / 750） px 换算 rpx（750 / 屏幕宽 度） iPhone5 1rpx = 0.42px 1px = 2.34rpx iPhone6 1rpx = 0.5px 1px = 2rpx iPhone6 Plus 1rpx = 0.552px 1px = 1.81rpx 样式导入 使用 @import 语句可以导入外联样式表，@import 后需要加上外联样式表相对 路径，用;表示结束。 示例代码：
.sm-button {
padding: 5px; }
/** app.acss **/
@import "./button.acss";
.md-button {
padding: 15px; }
导入路径支持从 node_modules 目录载入第三方模块，例如 page.acss: @import "./button.acss"; /相对路径/ 32 @import "/button.acss"; /项目绝对路径/ @import "third-party/page.acss"; /第三方 npm 包路径/ 内联样式 组件上支持使用 style、class 属性来控制样式。 style 属性 用于接收动态样式，样式在运行时会进行解析。行内样式不支持!important 优先 级规则。
class 属性 用于接收静态样式，属性值是样式规则中类选择器名（样式类名）的集合，样式类 名不需要带上.，多个类名间以空格分隔。请静态样式写进 class 中，避免将静态 样式写进 style 中，以免影响渲染速度。
选择器 同 CSS3 保持一致。 注意： .a-, .am- 开头的类选择器为系统组件占用，不可使用。 不支持属性选择器。 全局样式与局部样式 app.acss 中的样式为全局样式，作用于每一个页面。 页面文件夹内的 .acss 文件中定义的样式为局部样式，只作用在对应的页面，并会覆盖 app.acss 中相同的选择器。 本地资源引用 ACSS 文件里的本地资源引用请使用绝对路径的方式，不支持相对路径引用。例 如： /* 支持 / background-image: url('/images/ant.png'); / 不支持 */ background-image: url('./images/ant.png'); 33 app.js 注册小程序 App(object: Object) App() 用于注册小程序，接受一个 Object 作为属性，用来配置小程序的生命周 期等。 App() 必须在 app.js 中调用，必须调用且只能调用一次。 object 属性说明 属性 类型 描述 触发时机 onLaunch Function 生命周期回调：监 听小程序初始化 当小程序初始化完 成时触发，全局只 触发一次 onShow Function 生命周期回调：监 听小程序显示 当小程序启动，或 从后台进入前台显 示时触发 onHide Function 生命周期回调：监 听小程序隐藏 当当前页面被隐藏 时触发，例如跳 转、按下设备 Home 键离开 onError Function 监听小程序错误 当小程序发生 js 错误时触发 onShareAppMessage Function 全局分享配置 - 前台/后台定义： 小程序用户点击右上角关闭，或者按下设备 Home 键离开支付宝时，小程序并不会直接销 毁，而是进入后台。 当用户再次进入支付宝或再次打开小程序时，小程序会从后台进入前台。 只有当小程序进入后台 5 分钟后，或占用系统资源过高，才会被真正销毁。 onLaunch(object: Object) 及 onShow(object: Object) object 属性说明： 属性 类型 描述 34 query Object 当前小程序的 query，从启动参数的 query 字段解析而来 scene number 启动小程序的 场景值 path string 当前小程序的页面地址，从启动参数 page 字段解析而来，page 忽略时默认为首页 referrerInfo Object 来源信息 比如，启动小程序的 schema url 如下: alipays://platformapi/startapp?appId=1999&query=number%3D1&page=x%2Fy%2 Fz 小程序首次启动时，onLaunch 方法可获取 query、path 属性值。 小程序在后台被用 schema 打开，也可从 onShow 方法中获取 query、path 属性值。 App({ onLaunch(options) { // 第一次打开 console.log(options.query); // {number:1} console.log(options.path); // x/y/z }, onShow(options) { // 从后台被 schema 重新打开 console.log(options.query); // {number:1} console.log(options.path); // x/y/z }, }); referrerInfo 子属性说明： 属性 类型 描述 最低版本 appId string 来源小程序 - sourceServiceId string 来源插件，当处于插件运行模式时可见 1.11.0 35 extraData Object 来源小程序传过来的数据。 - 注意： 不要在 onShow 中进行 redirectTo 或 navigateTo 等操作页面栈的行为。 不要在 onLaunch 里调用 getCurrentPages()，因为此时 page 还未生成。 onHide() 小程序从前台进入后台时触发 onHide() 。 示例代码： App({ onHide() { // 进入后台时 console.log('app hide'); }, }); onError(error: String) 小程序发生脚本错误时触发。 示例代码： App({ onError(error) { // 小程序执行出错时 console.log(error); }, }); onShareAppMessage(object: Object) 全局分享配置。当页面未设置 page.onShareAppMessage 时，调用分享会执行 全局的分享设置，具体见 分享 。 globalData 全局数据 App() 中可以设置全局数据 globalData。 示例代码： // app.js App({ globalData: 1 }); getApp 方法 小程序提供了全局的 getApp() 方法，可获取当前小程序实例，一般用于在子页 面中获取顶层应用。 var app = getApp(); console.log(app.globalData); // 获取 globalData 使用过程中，请注意以下几点： App() 函数中不可以调用 getApp()，可使用 this 可以获取当前小程序实例。 通过 getApp() 获取实例后，请勿私自调用生命周期回调函数。 请区分全局变量及页面局部变量，比如： // app.js App({ //定义全局变量 globalData，在整个 App 中有效 globalData: 1 }); // a.js // 定义页面局部变量 localValue，只在 a.js 有效 var localValue = 'a'; // 获取 app 实例 var app = getApp(); // 拿到全局数据，并改变它 app.globalData++; // b.js // 定义页面局部变量 localValue，只在 b.js 有效 var localValue = 'b'; // 如果 a.js 先运行，globalData 会返回 2 console.log(getApp().globalData); a.js 和 b.js 两个文件中都声明了变量 localValue，但并不会互相影响，因为各 个文件声明的局部变量和函数只在当前文件下有效。
内容来源:https://developer.aliyun.com/article/756818?spm=a2c6h.12873581.0.dArticle756818.26162b70Su1GZy&groupCode=tech_library