mPaaS 小程序运行原理及优化

小程序的由来

在小程序没有出来之前，开始一些巨型App的webview成为移动web重要入口，这些厂商发布一整套网页开发东西包，称之为JS-SDK，给所有的web开发者翻开一扇全新的窗户，让所有开发者都能够运用到这些大型App的原生才能，去完结一些之前做不到或许难以做到的事情。但JS-SDK的形式并没有解决运用移动网页遇到的体会不良的问题，比方受限于设备功用和网络速度，会呈现白屏的或许。因而又规划了一个增强版的JS-SDK，首要是供给了资源离线存储，可是在杂乱的页面上依然会呈现白屏的问题，表现在页面切换的僵硬和点击的迟滞感。这时分就需求一个JS-SDK所处理不了的，运用户体会更好的一个体系，小程序就应运而生了。

小程序与一般网页开发的区别

小程序的开发同一般的网页开发比较有很大的相似性，小程序的首要开发言语也是 JavaScript，可是二者仍是有些差别的。

• 一般网页开发能够运用各种浏览器供给的 DOM API，进行 DOM 操作，小程序的逻辑层和烘托层是分隔的，逻辑层运转在 JSCore中，并没有一个完好浏览器目标，因而缺少相关的DOM API和BOMAPI。
• 一般网页开发烘托线程和脚本线程是互斥的，这也是为什么长期的脚本运转或许会导致页面失去呼应，而在小程序中，二者是分隔的，别离运转在不同的线程中。
• 网页开发者在开发网页的时分，只需求运用到浏览器，并且搭配上一些辅助东西或许编辑器即可。小程序的开发则有所不同，需求经过申请小程序帐号、安装小程序开发者东西、装备项目等等进程方可完结。

小程序运转机制

发动流程

小程序发动会有两种状况，一种是「冷发动」，一种是「热发动」。假设用户已经翻开过某小程序，然后在必定时刻内再次翻开该小程序，此刻无需从头发动，只需将后台状况的小程序切换到前台，这个进程便是热发动；冷发动指的是用户初度翻开或小程序被宿主APP自动销毁后再次翻开的状况，此刻小程序需求从头加载发动。

发动完好流程如下图所示：

小程序没有重启的概念，当小程序进入后台，客户端会维持一段时刻的运转状况，超越必定时刻后，会被宿主App自动销毁。

双线程架构

小程序的烘托层和逻辑层别离由两个线程办理：烘托层的界面运用 WebView 进行烘托；逻辑层选用 JSCore 运转 JavaScript 代码。一个小程序存在多个界面，所以烘托层存在多个 WebView。这两个线程间的通讯经由小程序 Native 侧中转，逻辑层发送网络恳求也经由 Native 侧转发，小程序的通讯模型下图所示。

相似于JSSDK 这样的 Hybrid 技能，小程序的界面首要由老练的 Web 技能烘托，辅之以许多的接口供给丰厚的客户端原生才能。一起，每个小程序页面都是用不同的 WebView 去烘托，这样能够供给更好的交互体会，更贴近原生体会，也防止了单个 WebView 的任务过于繁重。此外，界面烘托这一块咱们界说了一套内置组件以共同体会，并且供给一些基础和通用的才能，进一步下降开发者的学习门槛。值得一提的是，内置组件有一部分较杂乱组件是用客户端原生完成的同层烘托，以供给更好的功用。

为什么要规划双线程架构

为了管控和安全，小程序阻止开发者运用一些浏览器供给的，比方跳转页面、操作 DOM、动态履行脚本的开放性接口。将逻辑层与视图层进行别离，视图层和逻辑层之间只要数据的通讯，能够防止开发者随意操作界面，更好的保证了用户数据安全。

小程序视图层是 WebView，逻辑层是 JS 引擎。三端的脚本履行环境以及用于烘托非原生组件的环境是各不相同的：

咱们看一下单 WebView 实例与小程序双线程多实例下代码履行的差异点。

单 WebView 形式下，Page 视图与 App 逻辑同享同一个 JSContext，这样所有的页面能够同享大局的数据和办法，能够完成大局的状况办理。多 WebView 形式下，每一个 WebView 都有一个独立的 JSContext，尽管能够经过窗口通讯完成数据传递，可是无法同享数据和办法，关于大局的状况办理也相比照较杂乱，抽离一个通用的 WebView 或许 JS Engine 作为运用的 JSContext 就能够解决这些问题，可是一起引进了其他问题：视图和逻辑怎么通讯，在小程序里面数据更新后视图是异步更新的。

烘托一个hello world页面

mPaaS 小程序开发在语法方面与传统的前端网页开发非常相似，开发者首要编写 .axml、.acss、.js三部分文件，别离对标前端开发中的HTML、CSS、JS。

page 由四个文件组成，别离是：

其间 .axml 的内容如下所示，AXML 是小程序结构规划的一套标签言语，用于描绘小程序页面的结构。.js 的内容用于完成小程序的事务逻辑。.acss 的内容如下所示，ACSS 是一套款式言语，用于描绘 AXML 的组件款式，决定 AXML 的组件的显示效果。

// index.axml
<view>{{ msg }}</view>
// index.js
Page({
  onLoad: function () {
    this.setData({ msg: 'Hello World' })
  }
})
// index.acss
view {
  padding-left: 10px;
}

AXML先转成JS目标，然后再烘托出真实的Dom树，回到“Hello World”那个例子，咱们能够看到转换的进程。

经过setData把msg数据从“Hello World”变成“Goodbye”，产生的JS目标对应的节点就会发生变化，此刻能够比照前后两个JS目标得到变化的部分，然后把这个差异运用到原来的Dom树上，然后达到更新UI的意图，这便是“数据驱动”。

这一点和vue其实是共同的。

既然小程序是根据双线程模型，那就意味着任何数据传递都是线程间的通讯，也便是都会有必定的延时。

一切都是异步。小程序选用多个webview烘托，愈加接近原生App的用户体会。假如为单页面运用，独自翻开一个页面，需求先卸载当时页面结构，并从头烘托。多页面运用，新页面直接滑动出来并且掩盖在旧页面上即可。这样用户体会非常好。

页面的载入是经过创立并插入webview 来完成的。mPaaS小程序做了约束，在mPaaS小程序中翻开的页面不能超越10个，达到10个页面后，就不能再翻开新的页面。所以咱们在开发中，要防止路由嵌套太深。

代码打包

小程序发动时，客户端会从CDN下载小程序离线包，这个离线包是将原项目打包后的一个 .tar 文件，存放在 /data/data/com.eg.android.AlipayGphone/files/nebulaInstallApps 目录下。从真机上拖出来解压后得到目录。其间 index.html、index.js、index.worker.js便是之前咱们编写的代码所编译出的js代码。其间index.worker.js是小程序所有页面的事务逻辑代码,对应着开发者编写的pageName.js中的内容；index.html、index.js中的内容对应着acss与axml，其间axml的组件信息、层次结构相同被会被编译成js代码，在运转时由这些js进行烘托。

通讯原理

小程序逻辑层和烘托层的通讯会由 Native （微信客户端）做中转，逻辑层发送网络恳求也经由 Native 转发。

视图层组件:
内置组件中有部分组件是利用到客户端原生供给的才能，既然需求客户端原生供给的才能，那就会涉及到视图层与客户端的交互通讯。这层通讯机制在 iOS 和安卓体系的完成办法并不一样，iOS 是利用了 WKWebView 的供给 messageHandlers 特性，而在安卓则是往 WebView 的 window 目标注入一个原生办法，终究会封装成 XXXJSBridge 这样一个兼容层，首要供给了调用（invoke）和监听（on）这两种办法。

咱们知道小程序逻辑层没有浏览器的 DOM/BOM，视图层的更新借助于 Virtual DOM。用 JS 目标模仿 DOM 树 -> 比较两棵虚拟 DOM 树的差异 -> 把差异运用到真实的 DOM 树上，状况更新的时分，经过比照前后 JS 目标变化，进而改动视图层的 Dom 树。实际上，在视图层与客户端的交互通讯中，开发者仅仅直接调用的，真实调用是在组件的内部完成中。开发者插入一个原生组件，一般而言，组件运转的时分被插入到 DOM 树中，会调用客户端接口，告诉客户端在哪个方位烘托一块原生界面。在后续开发者更新组件特点时，相同地，也会调用客户端供给的更新接口来更新原生界面的某些部分。

逻辑层接口:
逻辑层与客户端原生通讯机制与烘托层相似，不同在于，iOS 平台能够往 JavaScripCore 结构注入一个大局的原生办法，而安卓方面则是跟烘托层共同的。

相同地，开发者也是直接地调用到与客户端原生通讯的底层接口。一般咱们会对逻辑层接口做层封装后才暴露给开发者，封装的细节或许是共同入参、做些参数校验、兼容各平台或版本问题等等。

小程序更新机制

小程序冷发动时假如发现有新版本，将会异步下载新版本的代码包，并一起用客户端本地的包进行发动，即新版本的小程序需求等下一次冷发动才会运用上。假如需求立刻运用最新版本，能够运用 getUpdateManager API 进行处理。

mPaaS这边没有完成getUpdateManager 这个API，咱们这边自己供给了桥接办法支撑了更新功用。

同层烘托

什么是同层烘托

众所周知，小程序傍边有一类特别的内置组件——原生组件，这类组件有别于 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 等容器内，经过 AXSS 设置原生组件的款式等等。启用「同层烘托」之后的界面层级如下图所示：

同层烘托原理

iOS端

小程序在 iOS 端运用 WKWebView 进行烘托的，WKWebView 在内部选用的是分层的办法进行烘托，它会将 WebKit 内核生成的 Compositing Layer（组成层）烘托成 iOS 上的一个 WKCompositingView，这是一个客户端原生的 View，不过可惜的是，内核一般会将多个 DOM 节点烘托到一个 Compositing Layer 上，因而组成层与 DOM 节点之间不存在1对1的映射联系。不过咱们发现，当把一个 DOM 节点的 CSS 特点设置为 overflow: scroll （低版本需一起设置 -webkit-overflow-scrolling: touch）之后，WKWebView 会为其生成一个 WKChildScrollView，与 DOM 节点存在映射联系，这是一个原生的 UIScrollView 的子类，也便是说 WebView 里的翻滚实际上是由真实的原生翻滚组件来承载的。WKWebView 这么做是为了能够让 iOS 上的 WebView 翻滚有更流通的体会。虽说 WKChildScrollView 也是原生组件，但 WebKit 内核已经处理了它与其他 DOM 节点之间的层级联系，因而你能够直接运用 AXSS 操控层级而不必担心遮挡的问题。

小程序 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 预览，会发现实际上它也是根据 标签完成的。

这种办法能够用于 map、video、canvas、camera 等原生组件的烘托，关于 input 和 textarea，选用的计划是直接对 chromium 的组件进行扩展，来支撑一些 WebView 本身不具备的才能。

比照 iOS 端的完成，Android 端的「同层烘托」真实将原生组件视图加到了 WebView 的烘托流程中且 embed 节点是真实的 DOM 节点，理论上能够将任意 WXSS 特点效果在该节点上。Android 端相对来说是愈加完全的「同层烘托」，但相应的重构成本也会更高一些。

功用优化

网络图片

网络恳求图片过大

阐明
网络恳求图片过大会影响恳求耗时，然后影响页面发动耗时，且消耗过多的网络流量，影响资源流耗。

最佳实践

• 主张单张图片大小不超越 100KB。将图片格局转换 WebP 或许 SVG。WebP 和 SVG 格局的图片能够在不下降图片质量的前提下减小图片的体积。
• 合理压缩、取舍图片大小。根据图片实际需求对图片进行合理压缩和取舍。
• 大图主张从 CDN 途径上传，且需求操控并发加载数量，并敞开 HTTP 缓存，下次加载相同图片，直接从缓存读取。
• 较小的图片主张放到源码包中，防止不必要的小图片的恳求耗时影响全体发动耗时。在以往的功用办理事例中，呈现过将几 KB 的图片放到线上且没有运用 CDN，导致对发动耗时影响了 10%，这样的状况应该防止。

图片并发恳求过大

阐明
短时刻内主张太多图片恳求会加剧网络带宽压力，且并发恳求太多也会导致图片加载慢。

最佳实践

• 同域名耗时超越 300ms 的图片恳求并发数不超越 6 个。
• 首屏页面应下降事务的杂乱度，削减图片恳求的频率。
• 图片敞开 HTTP 缓存操控，下次加载相同图片，直接从缓存读取。
• 未运用到的图片或许屏幕外的图片选用懒加载处理。

发动阶段图片恳求数过多

阐明
小程序发动阶段网络恳求的图片过多，一方面会消耗网络资源，导致网络通道拥挤，网络处理时长添加，另一方面不断加载的图片会导致页面不断重排、重绘引起页面不断颤动，推延初度可交互的时刻。尤其是线上许多小程序实际用户运用场景对错 WiFi，简单呈现网络不稳定的状况，比方健康码相关的小程序场景，因而此类场景下，假如图片恳求过多会导致线上用户的发动耗时比较长。

最佳实践

• 小程序发动阶段网络恳求的图片小于 10 个。
• 削减发动阶段的非必要图片恳求。屏幕外的图片能够运用 懒加载，假如不确定，能够给所有图片都加上该特点，具体运用办法参考加载屏幕外图片里的最佳优化计划。
• 关于较小的图片，主张放到代码包里，或许运用雪碧图来削减图片恳求数，雪碧图的运用可检查图片并发恳求过大。
• 图片敞开 HTTP 缓存操控，下次加载相同图片，直接从缓存读取，然后削减非初度访问的发动耗时。

JSAPI接口

同步 JSAPI 调用次数过多

阐明
同步的 JSAPI 尽管开发比较便利，可是会有很大的功用损耗。具体表现在同步 JSAPI 的调用过多将形成进程的堵塞，影响后续事务逻辑的履行，形成呼应变慢，因而准则便是 能不必就不必，非要用要稳重 。优化经历中发现，getSystemInfoSync、getStorageSync、setStorageSync、getLocation、getCities 是同步调用的高发区。

最佳实践

• 应防止过度运用 Sync 结尾的同步 API，同种 JSAPI 同步履行次数应不超越 5 次。
• 在小程序初始化代码和发动相关的几个生命周期 app.onLaunch 、app.onShow、page.onLoad、page.onShow、page.onReady 中，应防止过度运用 Sync 结尾的同步 API，同步履行转化成异步履行。
• 关于getSystemInfo、getSystemInfoSync 、getExtConfigSync、getExtConfig这类的 JSAPI，调用的成果应进行缓存，防止重复运用。比方经过 getSystemInfo 获取信息后能够用变量来做缓存，后续运用时直接运用变量即可。
• 关于 getStorageSync、setStorageSync 同步 JSAPI 调用次数过多的状况：my.setStorageSyncmy.getStorageSync 规划意图是为给小程序供给相似于 前端 localStorage 即本地缓存的功用，并非是供给相似 Redux/Vuex 的大局状况办理的最佳实践。在开发进程中，主张合理运用这两个同步 JSAPI，简略的状况办理能够运用 App.globalData，杂乱的运用 herculex 或跨端开发结构供给的状况办理。
• 兼并多个字段到一个目标，削减需求的次数。

JSAPI 重复调用次数检测

阐明
JSAPI 重复调用指的是 JSAPI 名称和参数都相同的状况下，屡次重复调用恳求的状况，最常见的是屡次网络恳求 request 而其间 url 相同；首屏页面加载中，JSAPI 屡次重复调用会添加无用耗时，影响小程序全体的发动耗时。

最佳实践

• 同种 JSAPI 可重复调用次数应不超越 5 次。
• 选用数据缓存办法处理前要履行 JSAPI 后的成果数据，防止重复调用，关于 getSystemInfo、getSystemInfoSync 获取信息后能够用变量来做缓存，后续运用时直接运用变量即可。
• 不要把 storage 相关 API 作为状况办理东西，能够把信息存在 APP 实例上：

App({
  someDataInAppLifecycle: {}, // 能够把运用运转时需求的信息放在App实例上
});
// 后续经过getApp() 读取实例存储值

• 同步 JSAPI 的优化可检查 同步 JSAPI 调用次数过多。

JSAPI 并发检测

阐明
JSAPI 不是免费的，当调用 JSAPI 时，底层的链路为：小程序调用 JSAPI > 告诉客户端（Android、iOS 支付宝客户端）履行对应的逻辑 > x ms 之后履行完毕 > 把成果回来给小程序 > 小程序回调；因而 JSAPI 并发过高会导致客户端呼应变慢、堵塞其他 JSAPI 的呼应（或许会堵塞其他事务逻辑）、用户耗电添加、恳求超时等问题（例如网络通讯吞吐量有限的状况下，部分恳求会堵塞、超时，乃至直接以失利回来，影响事务）。

最佳实践

• JSAPI 并发次数应不超越 20 次/s。
• 选用数据缓存办法处理前要履行 JSAPI 后的成果数据，削减调用次数。
• 削减并发履行次数。比方运用排队等战略，保证高优先级的事务恳求。
• 同步 JSAPI 的优化可检查同步 JSAPI 调用次数过多。

setData

setData 数据量检测

阐明
由 setData 底层原理可知，因为逻辑层和视图层通讯时，数据需求序列化，并经过 evaluateJavascript 履行脚本，因而，setData 传递的数据量过大时，会影响首屏烘托功用。

最佳实践

• 首屏页面单次 setData 调用，传递的字符串数据量应不超越 256KB。
• 削减数据量，防止一次性 setData 传递过长的列表。
• 分批处理。首屏请勿一次性构造太多节点，服务端或许一次恳求传递许多数据，请勿一次性 setData，可先 setData 一部分数据，然后等候一段时刻（比方 400ms，具体需求事务调节）再调用 $spliceData 将其他数据传输曩昔。

setData 调用次数检测

阐明
页面 setData 调用次数不宜过多，否则会导致 JS 线程一直在履行编译和烘托，视图层和逻辑层数据交互堵塞，或许导致用户的事件操作传递到逻辑层不及时，一起逻辑层的处理成果也不能很快的传递到视图层，然后形成用户滑动时的卡顿和操作反馈延时。

最佳实践

• 页面 setData 调用次数应不超越 20 次/s。
• 页面等级或组件等级防止频频触发 setData 或许 $spliceData。在分析的事例中，有些页面存在倒计时逻辑且过于频频触发（ms 等级的触发）。
• 需求频频触发从头烘托时，防止运用页面等级的 setData 和 $spliceData，将这一块封装成自界说组件，然后运用组件等级的setData或$spliceData 触发组件从头烘托。
• 运用 $batchedUpdates 兼并屡次 setData 恳求为一次 setData，进而削减逻辑层到视图层的更新次数。留意：只会兼并办法中同步的 setData 调用。

网络恳求

恳求耗时检测

阐明
单次网络恳求（如 http），从主张恳求到数据回来的耗时，网络恳求耗时过长将导致数据等候，延迟首屏初度烘托开始的时刻，会让用户一直等候乃至脱离。

最佳实践

• 单次网络恳求耗时时长不超越 400ms。
• 数据缓存存储网络恳求成果。支付宝供给 my.setStorage / my.getStorage 等异步读写本地缓存的才能，将数据存储在本地，回来成果的速度会比网络恳求快。关于部分网络恳求数据，可优先从缓存中获取数据来烘托视图，等候网络恳求回来后进行更新。
• 防止重复恳求。在曩昔事例中常见同一 url 主张屡次网络恳求 request。
• 优化好服务器处理时刻。服务端可做 CDN 缓存，做网络恳求的预加载（预热），让前端恳求能快速呼应。
• 页面资源的域名尽量选用相同域名。底层网络能够复用相同的 TCP 衔接做资源恳求，节省了重复的 DNS > TCP 建连 > HTTPS 握手等冗杂的网络交互作业，这样能够大幅提高资源加载功率。
• 页面资源依靠切勿依靠国外站点，跨国访问遍及比较慢，应该将国外站点资源发布到自己的服务器，能够大幅提高网页翻开的功用。
• 非要害资源应该做好阻隔。防止非要害资源加载过慢，导致整个页面烘托不出来。
• HTTP 恳求长耗时服务器规划。假如服务器处理时刻较长，需求 10s+才能回来成果的状况，必须规划为可轮询查状况的形式，切勿一个 http 恳求上去等 10s+ 的 Response，很简单触发 Socket 读超时导致事务失利。并且移动网络也不行稳定，中心假如呈现网络颤动导致断链事务就会失利， 所以客户端能够采纳间断性轮询恳求服务器的办法去查服务器处理成果。

恳求 url 长度过长

阐明
小程序发送给服务端的数据包过大，会延长数据传输时长和处理时长，终究影响小程序发动耗时。mPaaS网络库处理反常（mPaaS客户端约束 URL 长度）、服务端处理反常（服务端对 URL 长度约束），进而导致恳求失利。

最佳实践

• 网络恳求 url 长度应不超越 2000 个字符。
• 针对以上的第一种状况，主张将GET 恳求转换成 POST 恳求；但需求留意的是，这样的办法并不能解决第二种状况里数据包过大的问题。别的，在选用解决计划时，开发者需求验证服务端是否支撑这种恳求类型；
• 针对数据包过大的第二种状况，主张对数据进行合理拆分，分页、分级恳求和展示，然后削减 URL 的长度。

（本文作者：郭宏伟）