别开发App了

微信服务号的会话和好友的会话一样，被混合在一个列表里。虽然在「通信录」里有专门的公众号入口，但里面的公众号无法自由排序。

这意味着，用户并不能像在手机桌面上自由挪动图标一样，把常用的放在第一屏，或做分类。

这样会让公众号的留存降低，因为用户需要通过搜索或一层一层的结构寻找之前关注过的公众号。

网页应用有没有可能更快?

从技术角度来说，阻碍更多人「只」开发微信公众号的原因可能是：

1. HTML5 网页加载速度慢

2. 无法离线使用

那么，有没有办法可以解决这个问题?

Nike 广告的启示

里约奥运会第一天，我的朋友圈被 Nike 的这一广告刷屏了：

刷屏并不是因为广告内容，而是它的加载速度，看起来，就像原生的微信功能。

后来，微信官方发文说这是微信的「原生广告」，加载速度比以往快 10 倍。这个倍数不知道他们是如何测量的。

这个广告之所以加载如此迅速，是因为：

1. 最新版的微信 app 里已经集成了显示这个广告的控件，也就是说，这个广告不完全是 HTML5 网页，有一部分结构是原生在微信客户端里的。

2. 用户接收到广告但未打开时(朋友发给你，或你即将在朋友圈看到)，广告就已经在加载，而不是点击后才加载。

虽然微信官方并没有公布「原生广告」的原理，但基本上上面的猜测八九不离十。

也就是说，网页应用，也可以加载得像原生 app 那么快。

Progressive Web App 的启示

我要开始说一点被社会投资更难懂但有趣的东西了。

Google 在非常非常久之前，就致力于推动 web app 发展，它鼓励开发者开发网页应用，并提供各种技术和 API 方面的支持。然而，之前的方案并没有特别推动 web app 发展，直到不久前，Google 推出了 Progressive Web App (PWA) 这个概念。

PWA 是运行在浏览器里的应用，这个概念其实是一系列技术的封装，直接翻译过来很好理解：渐进式网页应用。我们不需要理解它背后的技术，只需要理解它能做什么就可以了：

1. 即时加载。加载速度比以往可能不止快 10 倍，即使网速很慢，也能有极高的可靠性。

2. 体验流畅。操作网页，就像操作原生 app 那么流畅。

3. 添加到主屏。PWA 可以生成一个图标，并被添加到主屏。

4. 推送通知。即使关掉浏览器，用户依然能收到 PWA 的推送。

5. 响应式。适配各种屏幕和设备。

6. 安全。所有数据通过 https 传输。

7. 渐进式加载。先加载框架，再填充内容。

8. 离线使用。没有网络，依然可以使用。

之所以能做到这些，是因为 PWA 得到了浏览器支持，最新版的 Chrome， Opera， Firefox 均已支持 PWA，这些浏览器提供一系列统一的 API，让渐进式网页应用(PWA)得以运行。

用一句话总结：

PWA 是网页应用，但体验和原生客户端几乎一样。

比较遗憾的是，Safari 还未支持 PWA。

网页应用的好时代已经带来

不管是 Nike 的微信广告，还是 Google 正在推动的渐进式网页应用，都在告诉我们：网页应用可以加载得很快、离线是有可能的、网页应用是可以与原生客户端相媲美的，这意味着，微信公众号的体验，必将也和原生客户端越来越相似。

不得不提的是，前面所说的 Nike 广告，如果你将手机开到飞行模式，再打开这个广告，广告一样能显示。

或许，微信已经支持与 PWA 类似的技术。

应用号会长什么样子?

微信从宣布即将推出应用号到现在已经差不多一年了，不管从任何渠道，没有任何外部的人知道应用号将会长什么样、会为开发者提供什么功能。

在我很厚脸皮跟微信团队讨论 PWA 时，他们回复了我一句：我们会在组件和 web 间取得最佳的平衡，保证应用的一致性和运行效率，又兼顾到开发的方便性。

结合这句话，从开发者的需求，到 PWA 技术的启示，我们大致可以猜测，微信应用号具有什么样的功能。

原生的控件

从加载更快的角度考虑，应用号会为开发者提供一系列统一的控件。

这些控件可能是内嵌到微信里的 HTML 前端控件，也可能是客户端的原生控件，或者两者都有。

比如，应用号可能会提供信息列表控件，如果你做的是一个新闻应用号，你只需要对接新闻数据，内容将在原生的控件里呈现。

又比如，你做的是一个购物应用号，你需要做的是开发一个后台和做好 API 对接，让商品直接在原生的列表框架里显示。

开发者可能能对原生控件进行一些自定义，但可能并不能做特别大的改动。

强大的 API

目前，微信为开发者提供了音频、分享等 API，从应用号趋近原生 app 的角度考虑，微信可能会为开发者提供更多在线和本地的 API。

比如图形方面的接口，比如辅助运算，又比如后台加载。

这些接口会让应用号的离线运行变得可能。

原生控件、前端技术、Bot 相结合

前面两点意味着微信应用号将趋近于原生 app ，拥有更快的加载速度、本地运算能力、离线使用等。开发者可以根据自己的需求，调整官方提供的原生控件。

对于自由度要求较高应用，可能依然需要做大量的前端开发，但结合应用号的 API，这些前端页面的加载可能依然非常迅速。

包括原有的 Bot 模式(就是你给公众号发消息，公众号返回图文信息)，应用号将会是原生控件、前端技术、Bot 相结合。

应用号互通

应用号与应用号之间，可能会逐渐实现数据互通。

最简单的，一个应用号可以将内容分享给另一个应用号。类似这样：

更深一点，应用号之间可以跳转。

再深一点，应用号之间可能会共享一个特殊存储空间，就像 iCloud 那样，应用号可以集中在这个空间里处理文件。

更开放的通知系统

目前，利用微信的客服接口，服务号可以向过去 48 小时与服务号之间有互动的关注者推送无数条信息，而要推送给所有人，一个月只能推送 4 次。

一个月 4 次的推送，显然是不够的。

或许应用号会降低推送的限制，让用户自行选择接收推送的频率，而不是统一地限制所有服务号一个月只能推送 4 次 — 就像原生 app 那样，如果 app 的推送太厉害，用户可以自行选择关闭。

如果这样，微信可能会在客户端里添加统一的通知管理界面。

打通桌面端

记得前面提到的 Google 的 PWA ?PWA 是响应式的，这意味着一个应用开发完成后，它可以在手机上，也可以在电脑上运行。

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!