1. 微信小程序不会取代大型App，应用市场该怎么做怎么做。Native App 更不会消亡。这个跟性能无关。
2. 低频应用 是最有可能转入到 小程序 平台的。扫码搞活动也会更方便。
3. 小程序 是否能做起来，要看 微信 对其开放什么样的入口，比如：朋友圈直接显示界面？ 聊天窗口直接显示界面？ 聊天窗口直接发起游戏？ 单独的小应用 Tab？ 如果这些都不开，跟现在的H5没本质区别。
4. 估计会兴起一批“聊天窗口”游戏/应用

Update: 据说

应用号的入口是在发现tab购物游戏下面，之所以叫小程序是因为AppStore审核不通过应用号三个字，并且已经和苹果约法三章应用号不能做游戏产品，以及，一个用户只能添加20个。

噫…不愧是企鹅爸爸


作为一个只写Script语言的人我是很支持腾讯干掉PhoneGap/Cordova/Ionic的【重要的事情要说三遍

不过我就想问一件事…苹果能允许么…
小程序安装或者升级的话要不要苹果再审核一遍？这就跟用ReactJS Live Update一样，属于苹果的灰色地带，一个普通App这么做可以睁一只眼闭一只眼，有潜力做成OS的话苹果能答应么？

Apple’s guidelines explicitly permit you to push executable code directly to your app, bypassing the App Store, under these two conditions:

1. The code is run by Apple’s built-in WebKit framework or JavascriptCore
   
2. The code does not provide, unlock or enable additional features or functionality
   

安装一个app就相当于微信不用苹果审核就*增加*一项功能，这比加个patch快速修复一个bug可*过份*多了…

鉴于微信在苹果发布会上出现的频率，微信团队很可能跟苹果沟通过了，所以像360那样被下架的可能性比较小，不过如果别的厂子看见了也蠢蠢欲动，那可是动摇了AppStore的根基啊【反X亡A，不反X亡B的感觉

1、一个多月前一篇《别开发App了》曾经刷屏，我当时朋友圈评价“我相信当下和未来微信生态以及微信应用号的前景，但是我不觉得微信应用和App之间是非此即彼的二选一关系。对于绝大多数企业来说，必然是两手抓两手都要硬的。作者应该更多是在说资源相对匮乏的初创企业更适合从低成本微信应用号切入会更快速”。

2、一个多月后，微信小程序发布了内测，从现在的信息看，我依然持有一个月前的观点。

3、很遗憾又意料之中的看到各路评论家一边倒的激动的讴歌微信小程序颠覆App Store，以及颠覆这颠覆那的，总之颠覆了全世界。我深深的怀疑你们绝大多数人肯定没经营过一个企业，我也深深的怀疑张小龙自己是否有你们一样的“小程序大梦想”。

4、如果你是一名都不用太老的司机，那应该记得QQ也曾经探索过Widget类似的模式甚至QQ桌面，从结果看不是很成功。当然PC时代与移动时代可能有巨大的差异，但是似曾相识的欢呼声，当年也有不少。相比当年，我肯定更看好微信小程序的前景，但谈颠覆，我可没这洞察力。至于能有多好，我也说不清。毕竟全中国现在也没多少个内测的邀请，还没一个人开发出来小程序呢，我也不知道你们看好颠覆的依据到底是什么。

5、微信小程序一定还是有红利期的，我预测第一波红利的获得者是昨天和今天写评论文章的微信订阅号上的自媒体们；第二波红利的获得者是干微信小程序培训的“老师”们，他们应该大多数是从微信营销培训迅速转型过来的；第三波红利的获得者应该是那些获得内测邀请资格的人们，毕竟上架时间早啊。再往后，就难说了……什么好东西，拼的都是执行力。

6、当然，好东西永远是稀缺的。我不相信你开发一个App是垃圾，现在开发一个微信小程序就不是垃圾了。App Store和微信平台都只是一个载体，你的产品是不是用户需要的，是不是用户喜欢的才是核心。以微信小程序远低于App的开发成本，可以想象未来提交审核的小垃圾程序是多如牛毛的，衷心希望微信能有比App Store更加严格的审核程序，否则，微信用户真的要遭殃了。这点，微信肯定想的比我清楚多了。

7、互联网终归是一个流量的游戏。微信最让人垂涎的也是其用户量和流量，但是除了腾讯大额投资的那些企业能获得一定流量之外，并没有看到谁能轻易的获得。无论QQ、微信还是百度、淘宝，对于任何一个平台来说，流量永远在那里，但能获得的永远是少数人。iOS有多少用户，安卓上又有多少用户，但是那些用户并不是你开发一个App就能获得的，微信小程序亦如此。当然，微信有社交关系、有强传播力，这是优势，但也不是每个人都能玩转。

8、如果你没有足够强的方法和技巧获得那些用户和流量，那就只能花钱买了。各路安卓应用市场已经被商业化玩烂了，App Store也开始了广告的探索。未来，微信小程序会不会也如此商业化呢？估计会的，但相信不会如安卓市场那样的泛滥。所以，和微信小程序新闻相比，我更关注的是同时发布的“朋友圈本地广告正式上线”的新闻。

9、互联网上的流量并不是全在微信手里，所以对于一个成熟的企业来说，怎么可能因为有了微信的流量就放弃了其他平台上的流量；怎么可能有了微信小程序就放弃了开发App?微信小程序的优势在于开发成本低、更快速的迭代，这倒是一个快速测试用户需求的利器。通过微信小程序明确用户需求，再开发App获取其他平台的用户，这应该是绝大多数企业的正道。

10、别激动下结论，更不能对着一个开发文档和几个截图就下颠覆的结论。我还是先想法弄一个微信小程序的内测邀请，看看能不能赶上开发者的初期红利，多给公司挣点钱吧……

这次我不站张小龙，虽然他说的「用完即走」的道理在，但我并不认为小程序会形成生态。

1.
仅仅从抽象场景上来讲，小程序当然很美好。

对开发者来说，不用费尽心思开发好多平台的 APP 了，不用考虑适配各种奇形怪状的机型了，更重要的是，不用每次发版都提心吊胆唯恐出事，或者有紧急需求要上线却只能日盼夜盼盼苹果爸爸早点把审核通过。

对用户来说，不需要安装 APP，想打车了直接搜出滴滴的小程序来用，想订外卖了直接搜美团的小程序来用。冷僻的、可能只会用一次的应用，不用那么麻烦去下载，也是打开网页就解决一切，实在太方便。

事情真的这么美好吗？

2.
我们具体问题具体分析，不说抽象的场景。

先说最常用的那些 APP，比如生活服务类产品（外卖、叫车）和影音产品（音乐视频）等。

但凡是这些大公司的主流大众产品，从他们自己角度来说，就不会屈就在微信，而只是借用微信的入口和平台流量，否则岂不是在苹果的各种限制下又多认了个爹？以后微信也要分成咋办？

从用户角度，也不会习惯在微信上用这些高频主流的 APP。既然每天都用，为什么不放在桌面，而是放在微信的某个列表里？

还有更关键的：微信解决不了多任务运行的问题，或者说无法达到操作系统一样的效果。试想，在微信里打开某个音乐播放器，编辑某个文档，再随时来回切换聊天界面，每次可能都要刷新网页，效果会是怎样，能不能保证多任务的效率？

对这样的 APP 来说，不会舍弃自己的领地，充其量就跟滴滴出行目前在微信里的样子差不多，只提供最简单的功能，就是一个入口而已。


3.
再说第二类 APP，就是压根无法移植过来的，最典型的就是游戏（要想实现，先让微信内支持 Unity3D 再说）。

另外还有很多比较重的应用、消耗系统资源多的，在微信里运行的效果肯定也要大打折扣。

第三类 APP，是那些很低频或很垂直的应用，许多媒体都看好小程序会给他们带来很多机会。这同样是抽象的判断，基于「小程序总比 APP 好做」和「小程序是 APP 的替代品」的假设。

首先，APP 创业热潮的消退已经有目共睹，我们手机里装的常用 APP 也逐渐固定下来，接受新应用的可能性不断下降，各种生活服务类、工具类的应用逐步合并，集成在了那些平台产品里；其次，能够产生创业机会的领域也远没有过去想象的那么多，除了每年会热炒的几个主题（前有 O2O ，后有 P2P，现在有直播），大部分互联网创业项目都做了分母、成了炮灰，大众的需求基本已被巨头垄断。

大众主流需求（不管高频还是低频）的产品正在不可避免地发生融合，小公司被淘汰或者并购，逐渐都加入 BAT 大家庭。我们生活里遇到的大多数消费场景，在微信和支付宝都能够完成了。近几年频发的巨头并购案，以及马上要发生的外卖大战落幕，都预示着未来所有大众主流需求都会掌握在几个巨头手里。

那非主流的垂直需求呢？不可否认有很多垂直类的 APP 活得很好，他们有固定的用户群体，有稳定的发展路线和收入。正因如此，他们只需要关注自己的核心用户，而不需要借助微信的平台优势（像神经猫一样病毒传播）。同时，垂直的需求比较复杂，功能往往都比较重，做成轻便的、能够有效营销的小程序并没有太大意义。

这是一个悖论：在生活服务、消费领域里，大众级的产品，已经都被巨头垄断，微信只需要放那么几个入口；小众的非主流产品，也并不特别需要借助微信。

我觉得未来的小程序，这些就完全够了：


4.
微信小程序会火，只是大家由过去「掌握了入口就掌握了用户、掌握了用户就掌握了生态」这样的经验猜想的。但我们放到实际场景中，就发现事情全然不同。

从本质上说，微信是社交场景的平台，流转的大多数还是信息这种消费品。公众号能很快火起来，是由于它们的文章作为信息能够快速在朋友圈、群组和私聊中传播，很好地契合了社交的场景。其它的互联网消费产品，比如电商产品和服务产品并没有在这种场景上得到发挥。购买电商产品和服务产品究竟是在微信上、是在淘宝还是在独立 APP 上，并无太大差别。

总的来说，我觉得「用完即走」并不能代表什么，这是一种理想的目标，但不能构成现在用户弃用 APP 转投微信小程序的理由，也不能构成开发者们弃用 APP 转投微信小程序的理由。

所以最终，小程序大概只会成为服务号的一个优化。

笔者注：本文来自于迅雷首席工程师刘智聪的个人分享，他毕业于南昌大学化学系，加入迅雷后设计开发了多款迅雷核心产品，凭借“大规模网络流媒体服务关键支撑技术”项目获得2015年国家科学技术进步奖二等奖，同时也是第四代UI交互技术-----BOLT 界面引擎的发明人，目前担任WebApp解决方案商--火速移动的首席技术顾问。

21号晚上正和朋友一起打牌，难得的小七对刚刚定口，突然间手机传来了“叮咚”的消消息提示音，随后就是“叮叮，咚咚”的连续震动。打开手机一看，微信上一堆人发信息给我，先是一篇《微信应用号来了》，然后就是：“你怎么看？”

虽然之前曾经得到过消息说“微信应用号”会在年底发布，但没想到居然来的这么快，而且还改名叫“微信小程序了”（简称小程序）。已经无心打牌，赶紧完成一吃三后速度回到电脑前开始了持续几天的研究。而且这几天里各种相关资料都开始相继出现，内测用的开发工具也有破解版漏出了。

身边已经有不少朋友已经根据资料开始干活了，差不多有如下几类：

1）好好释放想象力，要是能在公测的时候做个有趣的小程序出来一炮而红那就赚大了

2）公司有一打的服务号，其实改成小程序会更合适（管它合不合适，改了再说！）

3）又是一轮洗牌的机会！那个公众号的功能是我先想到的但被别人抢了，这次我要在小程序里第一个做出来并做到第一名！

4）微信果然是互联网的“国务院”，新政策草案刚出立刻引起全行业的连夜研究。这么重要的关头，变革的前夜，我认为正确的做法是“战术上立刻响应，站略上不必着急”。不学习，不了解微信小程序是万万不行的，但立刻根据现在的资料，调整公司的方向，也有点为时过早。毕竟现在还在内测阶段，万一内测结果是“回炉重造”或则“大幅调整”（目前泄漏的资料已经处于正式发布的状态，应该不会大改了），那花在这里的时间都赔进去了还没地哭。所以我觉得对公司来说比较合理的做法是在立刻成立一个短期的临时小组，鼓励对小程序有兴趣的同学加入，一起开发几个有趣的小程序，主要目的就是学习。如果做出来的结果好还能赚一波眼球。等微信小程序正式公测了，再决策要不要把这个临时小组升级成一个正式的产品团队。

这几天通过目前公开的资料我已经对小程序的整体架构有了个初步的认识。我的风格一向是从架构和系统设计的视角做一些深度的，有观点的分析。现在终于可以回应朋友们的问题，谈谈我怎么看了。

微信小程序是什么？

官方这么说：

“我们提供了一种新的开放能力，让开发者可以快速地开发一个小程序。小程序可以在微信内被便捷地获取和传播，同时具有出色的使用体验”。

听起来非常美好，咱们具体一点，结合目前公开的信息和微信目前其它的开放形式对比一下吧

可以看到，腾讯还是非常有诚意的，这次在微信小程序上新开放的能力很多，不再是渐进式的演变而有一点像革命了。

小程序的入口在哪？

目前公开的资料里对大家最关系的入口问题只提到了小程序可以扫二维码打开，于是业界对小程序的入口有了这么几种流行的假设：

假设零：朋友圈，朋友可以把自己喜欢的小程序分享在朋友圈，看到了可以点击打开直接使用。

[配图1]

可能性:99%。小程序不能出现在朋友圈，流量从哪来？

假设一：出现在发现tab页面中，游戏下面（每个小程序占用一列），同时摇一摇也可以得到附近的小程序

[配图2]

可能性:80%。和一把腾讯的游戏挤在一起，不亏待你吧。

假设二：和当前的公众号、服务号类似，安装出现在会话列表

[配图3]

可能性:90%。新的开放能力和旧的开放能力用一样的入口不奇怪吧。

假设三：安装后和native app一样，直接出现在桌面

可能性:10%。和微信在同一级入口，腾讯同意Apple都不一定同意。

假设四：微信多一个小程序的tab

[配图4]

可能性:1%。多一个tab太丑了，而且小程序刚发布，不可能立刻就对微信的整体结构产生影响。

假设五：出现在一些内置流程中（比如和好友的聊天界面内，发朋友圈的界面（拍照后处理）

[配图 5]

可能性:1%。小程序和微信本体使用不同的框架技术开发，互相嵌套有困难。

微信小程序框架浅析

官方已经正式公开了小程序的开发资料（https://mp.weixin.qq.com/debug/wxadoc/dev/?t=1474887501556），小程序的开发框架包含两大块内容，分别是：API 与 组件。官方的资料在组织和内容上都写的还不错，阅读体验也很顺畅，没看过的话推荐先简单的通读一遍。基本上有一定经验的前端开发都可以没有什么障碍的掌握目前资料里的内容，我就不去做入门性的介绍了，直接浅析吧。

先看框架的底层API部分。微信一直有一个贯穿的"JS-SDK"在不断演进。对比一下小程序的底层API的功能范围，和JS-SDK还是有很多相似的感觉，相信未来会在形式上达到统一(JS-SDK这名字也足够霸气，塞进去什么都不会觉得奇怪。不过JS-SDK的很多接口设计的实在不敢恭维，希望这次统一的进程也能重新修正下)。小程序的API部分由于可以跳出浏览器的框架，理论上肯定可以是JS-SDK的超集。

这里面我觉得比较有意思的地方有：

>>网络通信

只要目标服务器的域名在小程序配置的安全列表之类，就可以直接通信。不用考虑js的跨域问题了。

既然跨域都支持了，没准以后能像nodejs一样，直接在小程序里使用tcp,udp协议，并基于buffer有一定的二进制协议的开发能力。跳出HTTP协议的框架，对于IoT方向是很有想象空间的。

>>数据缓存

数据缓存接口的设计看起来和 HTML5里的localStorage基本上一样，本来没什么好说的。但文档里的一句话引起了我的兴趣：

“注意： localStorage 是永久存储的，但是我们不建议将关键信息全部存在 localStorage，以防用户换设备的情况。”

难道微信提供的数据缓存能力虽然不是永久的存储，但可以做到跟随用户账号而不是当前设备？ 也就是说，不管用户怎么换手机，已安装使用过的小程序都能使用同一份缓存（不存在不登陆使用小程序的场景）？虽然微信自己的聊天记录跨设备漫游都没做，但这种app personal file cloud的支持，还是能在不增加开发的工作量的情况下，大幅提升用户体验的（作为一个steam的重度用户我已经完全离不开游戏存档的自动同步功能）。这也让我对小程序在云端的能力，开始有了一些初步的想象。

>>并不兼容一些常见js底层框架

小程序的官方QA里有一段话：

“zepto/jquery 会使用到window对象和document对象，所以无法使用”

这意味着所有基于HTML5的已有底层代码资产，并不能完全无缝的迁移过来。不过连jQuery这么常用的库都不能兼容还是有一点伤的。当然，现在用裁剪或兼容的方法，提供能在小程序平台运行的常见js底层库，短期内会很有市场。

MINA框架剖析

接下来我要解读微信小程序提供的界面部分功能，也是最令人兴奋的部分。一个小程序，必须基于MINA框架（从泄漏的资料里得知这个框架叫MINA,正式的资料里删除了这个名字，但为了后面行文方便，我会一直把小程序的应用框架称之为MINA）构建。一个典型的小程序的结构如下：

[配图7]

app.json 小程序配置：

小程序里一共包含哪些页面。

页面套在一个怎么样的 window里显示。

window是否需要支持多tab,支持的话每个tab的默认page是什么。

一些底层组件的默认参数。

app.js（可以理解为入口函数）

处理app的几个关键事件:onLaunch,onShow

定义了app级（可以在不同的页面之间共享）的数据的格式

app.wxss 公用样式表

每个页面的样式表，都是从这个应用级公有样式表继承下来的。

MINA一个最主要的核心概念是Page，一个Page是应用内可以导航到的最小粒度的界面。而如何构建Page是与大家过去猜测差别最大的地方。微信并没有使用HTML5，而是提供了一套新的设计。新的设计要求每个 Page由3个文件构成：

index.js :包含Page的逻辑处理代码

其中比较重要的就是定义Page的数据（wxml可以通过数据绑定机制直接访问）

index.wxml : Page的布局文件

随便从demo中选一个布局文件来看，其整体结构非常简介清晰，即使没有提供任何资料也大概能看出来表达了一个什么样的页面。

.wxml不算是完全的静态布局文件，还支持条件渲染和列表渲染。

.wxml使用{{}}语法来简单直接的支持数据绑定。

可以通过template的方法进行复用

index.wxss: 样式表

决定了在wxml中定义的各种组件最终应该如何显示。官方文档并没有列出wxss的selector语法和支持的style，只是说“具有CSS的大部分特性”，wxss样式表里也扩展了一些微信小程序专用的样式是属性。

Page的整体设计上有比较明显的“反应式”编程风格，相信有vue.js,angularJS，reactive.js开发经验的同学可以很快上手。由于没有内测资格所以没法在手机上测试性能，不清楚小程序的这套框架有没有反应式编程常见的性能问题。这个等公测后写个有10万条数据的列表，看看滚动流不流畅就知道了。

目前demo没有使用ES6，所以看起来没那么“现代化”，这也可能是因为小程序这个项目立项比较早的缘故吧。不过ES6是大势所趋，相信未来小程序会支持使用ES6开发。

一个基于MINA的小程序最后是如何跑起来的呢？

官方这么说：

“开发者写的所有代码最终将会打包成一份 JavaScript，并在小程序启动的时候运行，直到小程序销毁。类似 ServiceWorker，所以逻辑层也称之为 App Service。”

网上已经有不少人通过琢磨开发工具的实现的方法，做了比较深度的研究了，推荐阅读：

(微信小程序「官方示例代码」剖析【下】：运行机制 微信小程序「官方示例代码」剖析【下】：运行机制)

简单的总结一下：

wxml文件通过编译会得到html，wxss 文件通过编译会得到css，分离的各个页面的JS和App的主JS文件最终会打包在一起得到App Service。 开发状态下运行小程序，基于blink内核，每个html会加载一些moko js用来支持框架功能。生产环境在手机上估计是运行在一个专用，定制的浏览器内核中。

为什么是MINA?

业界对目前微信使用的UI框架，有两种截然相反的观点：

微信“小程序”带动HTML5发展 数据波来助力 微信“小程序”带动HTML5发展 数据波来助力-CSDN.NET

“微信小程序的本质说来就是一个HTML5应用”

“以后互联网的发展方向可能更偏重于HTML5”

而有的人又认为

我们真的需要“小程序”么？| HTML5老兵如是说 我们真的需要“小程序”么？

“微信虽然用了 HTML5 技术来做应用号（正式名称：小程序），但是它并没有真正用到 HTML5 的精髓——开放、互联，也就决定了它可能无法实现“微信OS”的最终野心。”

这两个观点是矛盾的，那么，到底那种观点是正确的呢？首先简化一下问题，微信小程序是基于HTML5开发的么？

通过分析小程序的运行原理，这个答案是明确的：小程序的开发过程会用到大量HTML5相关的技术,但并不是使用HTML5开发。有 HTML5经验的前端工程师学习微信小程序的开发相对会更容易一些。微信小程序的运行并不需要一个完整支持HTML5特性的标准浏览器内核，但也可以通过添加一些辅助设施，让小程序在个完整支持HTML5标准的浏览器上运行起来。

“由于框架并非运行在浏览器中，所以 JavaScript 在 web 中一些能力都无法使用，如 document，window 等。” 也就是说，一个已存在的HTML5页面，并不能通过自动转换工具变成一个合法的Page，而需要有工程师根据HTML5页面的功能，使用MINA框架再实现一次。

[配图 HTML5与MINA在功能上有交集，但并不相等]

搞清楚MINA和 HTML5的关系后，我们还是没有搞清楚为什么微信要提供一个新的MINA框架 。事实上这个问题是一个讨论设计的问题，所以要回答这个问题，需要具备一定的设计能力，而不是只是停留在研究MINA实现的层面。而设计能力，是一种比较稀缺的能力。

想要系统的提升自己的设计能力，简单的来说就是“多看+多想”，那么如何多想呢？我有一套还算完整的方法的，简单来说有如下几步：

首先，在研究一个新东西以前，先想想这个新东西，是为了解决什么样的问题出现的。问题要多提，往深了提，反复提炼，最后得到几个好问题。或则从一个问题，引申出一些子问题。很多时候只要问题提对了，设计就明白了大半。

下一步就是试着自己解决一下，回答一下自己提的问题，并比较不同的解决思路的优劣，形成一个对问题解的标准。比如说问题是“如何在一个超长文本中查找子串？” 那么对问题的评价标准就可以是查找速度，以及查找过程中的内存占用。

接下里就是看别人是如何解决这些问题的了。如果和自己的设计差不多，一边窃喜一边开始按自己预先设计的评价标准对别人的设计的好坏进行判断。如果是自己完全没想到过的解法（这通常会出现在第一次接触某个领域问题），可以按图索骥的补充一些基础知识，再回来看。如果这个领域或解法非主流到不是常见范式，那么可以安下心来好好搞清楚，想明白。 这样带着问题研究设计，才能有效的提高自己的设计能力。

介绍完套路后咱们回到正题：我们如何来评价微信小程序选择MINA框架？让我来持续提问吧。

第一个问题：“为什么微信小程序不使用HTML5而是使用MINA来构建Page？”

不用HTML5我可以提供一个非技术答案：微信需要通过这种方法来转化开发者，这些开发者未来会逐渐演变成“微信OS平台”的忠实开发者。其实开发者通常都有患有“斯德哥尔摩综合症”，一旦在一个平台上投入了智力资源进行学习，就会开始下意识的维护这个平台（比如看不到平台的缺点，只看到平台的优点）。如果使用HTML5作为开发方式，那么现在小程序聚拢的开发者都是为了流量来的，并没有投入额外的学习成本，对平台不够忠诚。而微信要成为OS是一个长期的演变过程，那么现在就要通过要求学习一个新的开发框架的方法开始多转化一些忠诚的开发者。

当然是不是这个原因也只有张小龙自己知道了，这是一个揣摩动机的答案，所以没有评价标准。问题终结。

为什么不用HTML5的技术答案可以是非常庸俗的。毕竟业界对于HTML5技术的优劣讨论已经持续了一段很长的时间了。但基本上，大家认为HTML5的主要缺点集中在性能上：同样的交互，用HTML5实现需要更多的系统资源，也可能会不够流畅。同时，应用还需要集成一个非常巨大的浏览器内核。

这个答案尽管能让大部分人满意，但实际上是非建设性的（这些对HTML5性能的结论，是别人告诉你的）。大家一边相信HTML5的美好前景，一边把对性能问题的解决寄托于几家传统的浏览器厂商。按我们的套路，这个性能问题再往深了问是这样的：“渲染指定页面最少需要多少资源？”，“在当前硬件水平下，渲染指定页面最快需要多少时间？”，“实现一个完整支持HTML5标准的浏览器内核，需要大概多少代码？”。要回答这些问题就需要了解浏览器的实现了，这不会是一件容易的事情，在阅读浏览器的实现的时候，肯定会持续提出针对HTML的设计问题。最终你会对浏览器厂商什么时候能解决性能问题，得到一个更合理的预期：至少在5年内，HTML5的性能是不够的。

虽然SAY NO的理由，有一条就够了。但如能从其它角度思考一下为什么不是HTML5,可以得到一些更有建设性的答案。

第二个问题：“MINA作为一个新框架，为什么会设计成现在的样子？”

可以肯定的是，这是MINA的架构师在综合了多个因素后，拿出来的一个自己最满意的答案。所以这是一个非常有建设性的问题，思考这个问题的时候，就开始逐步代入MINA的架构师视角了。

让我们一起进入MINA架构师的角色，首先在否决了HTML5后，要设计一个什么样的框架来支持小程序的交互开发？第一步就是要给这个新框架提一些基础性的目标与需求。

这是一个现代化的框架，在最终表现力上要足够好。

小程序跑在微信里，所以必然是和android,iOS的具体平台特性无关的。

要面向更多的非专业开发者，所以学习门槛要低。

大规模的专业团队进行团队开发时，能有足够的工程支持。工程支持包括：
模块化
代码易于长期维护和修改。这意味着基于框架的实现具体需求的结果要足够清晰，好读。

可复用性设计。

小程序不需要安装就可以快速开始使用，只需要加载必要的资源就可以尽快展现用户需要的页面。

进一步思考这些需求该如何解决，并对不同的解决方案进行评价需要的领域知识非常多，已经超过了本文的讨论范围。我在这里要做的只是带你入门，让你开始思考设计问题就够了。这也是本文的核心目的：学会对新技术，新设计进行独立的分析和判断。至于结果么，现在小程序还处于一个早期的状态，等公测了之后在下结论也不迟。

微信小程序的未来？

虽然现在小程序开放的功能并不丰富，处于一个早期的状态，但结合上面的观点去看微信小程序的设计，还是能从中读到许多远大的理想。而微信的核心愿景之一是“连接一切”，没准小程序是腾讯实现这个愿景道路上的重要一步。有超过7亿用户的微信如果成为一个新的平台，具有不可忽视的能量，下面让我来对小程序的下一步动作做一些无责任的预测吧。

假设一、微信小程序未来会解决应用内搜索的问题

目前小程序规范的页面结构很方便实现应用内搜索。以后使用微信的搜索功能可以直达小程序内部的某个特点内容页面。

这种规范的设计也方便实现小程序之间的互相访问，可以通过一个类似wxapp://appid/pageid/的URL直接导航到另一个小程序的某个特定页面。这是App时代的超连接系统，App的信息孤岛也许就此打破。

假设二、微信小程序会从本地数据读取开始，进化出一定的云端API.

现在小程序只提供了前端的开发功能，但从整体逻辑上已经包含了应用的上传，审核，发布流程。

以后腾讯也许会为小程序提供托管服务（https://www.qcloud.com/act/event/yingyonghao.html），让应用开发者可以用更少的精力完成一个完整小程序的开发，而不需要去管服务器申请，后台开发，服务器运维等反繁琐的工作，进一步降低一个真正小程序的开发门槛。我相信微信一定有团队在为这个方向努力，但最终实现目标需要更有创造力的云端API设计，这是需要有大智慧的工作。

假设三、使用小程序连接一切

我并不认为小程序只是一个体验更好的服务号。张小龙说小程序是“触手可及”，“用完即走”，“无处不在”的。那么什么场景会需要这种能力? 我觉得“有复杂程序的低频商业行为”会有这种需求。举两个实际的例子：

例1：有一间智能会议室，入口处有一个二维码。会议室的使用者扫描后可以打开一个小程序，通过这个小程序可以更好的访问、控制会议室的各种设备，比如灯光，窗帘，幕布等。

例2：去体检，体检表上有个二维码，扫描后打开一个小程序，通过这个小程序可以更好的引导用户自助完成自己的体检项目。

这两个场景的需求能通过小程序解决，意味着小程序的种类极大丰富，硬件厂商对微信生态的极大支持。我们可以通过小程序简单方便的进入各种陌生的环境，让生活更加智能。未来已经悄悄敞开了大门。

而如何更好更快的探索小程序的可能性，也将是我接下来创业的方向。我将以火速移动技术顾问的身份，和小伙伴们一起从微信小程序开始，去探索移动Web的可能性。

感谢各位关心。

【李慕阳关于小程序的几点思考】
几个问题，已经知道的同学拜托帮忙解答一下：
1、小程序的初次发现机制是什么？搜索、二维码和微信的应用中心（会有吗）？如果是搜索，抢关键词会不会很重要，小程序so会不会变成一个重要的活儿？如果是二维码和关键词推广，那么已有公众号的直接宣传会不会很重要？
2、小程序的重复调用机制是怎样的？在没有关注的情况下，如何锁定用户的某个使用场景，使其愿意通过文字输入去调用？
3、小程序的广告机制是怎样的，毕竟不能外链？如果涉及交易，微信官方容忍的底线是怎样的？
4、直播游戏互推不能上，还有哪些不能上，微信官方容忍的底线是怎样的？
是的，以上三点就是拉新、留存和变现，是作为商人最容易关心的话题。
那么接下来会发生什么：
1、所有需要下载app的高频工具，如天气、大姨吗、课程表、唱吧、美图……都会有小程序出现，如果那些公司不做，就会有其他人趁虚而入。所以大家现在应该都是在环顾市场，看谁的更好做。
2、由于重复调用机制不明，又无关注，以往脸萌、足记这样火一把就死的应用也会出现在小程序中，但更多以小额收费的形式，赚一波就走，就像最近出现的修改定位。
3、微信开放不开放关系链不知道，但以前一些因为无法冷启动或用户水化而用户体验不佳、完成不了基本诉求的创新社交和垂直社交产品，貌似会有一个机会，毕竟真实的关系链在这里已经存在，机会大小得看微信开放的力度。
4、电商和交易是重中之重，是可以补足微信基因的。
5、最终商业价值最大的，可能是具备稳定高频场景和用户习惯搜索获取的高流量小程序，并且因为某种原因使用户愿意同步下载一个app备案，只把小程序作为一个快速入口。
以上源自李慕阳对小程序的一点小小思考。

我个人并不是很看好。

html5，js以及类似的技术替代原生大家喊了很久了，就是大热的react native目前看来也依然很不完善。微信的应用应该都是运行在腾讯浏览器的X5内核里，这东西怎么样大家心里也都有数。我感觉还是只能做一些低交互的应用，大概也就是比网页快捷方式高一级别，要利用os的炫酷特性，原生还是跑不掉，而且目前原生开发很成熟了，框架库很多，门槛也很低。

对于不用下app省空间我不是很理解，只不过是把app浪费的空间挪动到微信里而已。

微信所倡导的用完即走的理念也只有腾讯有资本装b才会这么说，其它公司无论如果始终还是会想办法更多的占用用户的时间。

腾讯现在原本就掌握了渠道，现在连app的审核等生杀大权也都掌握，你说苹果恶心，但他起码还勉强算公平，而腾讯可以随便打着为了用户（和你妈说为了你好）进行系统抖动，非腾讯系全都会抖，想怎么搞你怎么搞你。


结局都是类似的，中小型公司都很激动，以为有了小应用他们就有了腾讯爸爸的几亿用户，这种幻觉很美好，但他们可能会面临更加惨烈的竞争，变成临时解决用户欲望的千斤顶，以及腾讯渠道那可怕的推广分成费用。大公司肯定都很不情愿的跟进，又没办法，估计会简单开发一些应用，然而尽可能的往自己原生的app上导入，心态很微妙，不过短期内肯定会先爆发一波星座血型算命起名你的前世今生颜值计算能活多少岁等一些QQ空间喜闻乐见的低质量辣鸡应用，目前也不知道腾讯审核时是否会做一些限制。

微信也许已经不是聊天软件了，我朋友偶尔用了一下QQ，惊叹的说，QQ真好用呀，聊天记录都能自动存下来! 微信当初也许吸引大家的是我们只想要一个广聊天的QQ，现在已经要变成微信os了，是不是以后也要走和当年QQ一样的路？整个腾讯系全压在这款app中？ 我不知道，在集团利益，业绩增长的车轮下，什么张小龙王小龙，什么鬼的用户体验，什么产品经理说不的坚持，有多少碾碎多少。

仅是个人一点感悟和粗浅看法，不太对请见谅

微信小程序这个东西的出现早有苗头：在客户端/浏览器集成一个运行环境，用js去驱动native ui，这个事情腾讯QQ浏览器早就做过。

这种做法我认为它有反 web 反开放的嫌疑。

Web 是最开放最容易被解析被索引的技术，网站的内容可以被用户随意选取和分享，可以被搜索引擎收录，甚至在网站已经死亡之后其内容仍然能存活在 http://archive.org 这种数字档案馆里。

而 App 则自给自足，很难去解析去索引，如果一个 App 死了，它的用户和内容就会流失。

如果市场上越来越多的部分都被 App 占据，每一个 App 都是封闭的王国，互联网会越来越封闭，搜索引擎也将毫无用武之地。

正是看到这种趋势， Google 急得像热锅上的蚂蚁。现在 Google 正在大力推广的 PWA 技术，就是以 HTML 为主， JS 渐进增强的 Web App 方案，在保证内容开放性（discoverable） 的同时又具有 App-like 的体验。关于这一点，可以看看 Google 的介绍： https://developers.google.com/web/progressive-web-apps/

从这一点来说，我是对微信小程序这种技术是有反感的，虽然它确实大大扩展了 JS 的业务范围。

但在现实中，它又确实有可取之处，微信的巨大用户量、轻型应用的可传播性、相对较好的性能和一致性的用户体验，时时刻刻吸引着应用开发者来使用这种技术。

时代的洪流浩浩荡荡，我们每个人都只能顺势而为。

＝＝＝＝

虽然微信这一次的代码和文档质量都还不错，小程序的特性也令人印象深刻，却也并非完美。

以下吐槽一下微信小程序目前的一些问题。

1. Android 下，input 组件中输入文字，切换键盘显示/不显示状态，文字会错位。
2. Android 下 Canvas demo 刚开始动画时丢帧。而且大部分涉及动画的组件，如 swiper/progress 等，都有丢帧的现象（骁龙650 啊，不应该啊
3. 在 scroll-view 上用手指滑一下然后松开，界面发生滚动，但手指松开后会错误地触发 click 。
4. getApp() 、Page() 等框架函数没有放在命名空间下。
5. tabBar 分割线只能用黑白两种颜色，且图标不支持 svg 。
6. HexColor 只支持 RGB，不支持 alpha。
7. swiper 组件的 indicate dots 好丑，也没法定制 - -
8. API 不如 Vue.js 优雅。
9. 赶工的痕迹还是挺明显的，比如 <map> 组件，我传进去参数了，显示出来的地图上也打点了，但是用户在地图上操作的行为呢？没有事件传出来，业务代码没法获取到用户操作。
10. IDE 没有实现 live reload ，在 IDE 里需要手动刷新，在手机上需要反复扫码。
11. 不开放编译和打包过程，没有集成 babel 支持。
12. 不会将引用的 npm 包打包到项目里，需要自己另想办法。
13. 好像没有提供远程调试？反正我没找到真机调试打断点的地方。
14. 没有提供真正的退出小程序的功能，无论是返回键还是菜单中的“离开”，都只是睡眠和隐藏而已。
15. 没有提供删除小程序本地缓存的功能，改了后台配置之后用户端的没有更新，我只好 root 之后进 /data 分区手动删除缓存文件。
16. 文档中有一些锚点链接点了没反应，比如配置里的 tabBar。
17. wx.request() 这个 API 的限制非常严格，比 Web 里的 http request 限制严格得多。
18. wxml 是写死在源码里的，那么如何在运行时动态生成页面结构？
19. 似乎没有 webview 组件。
20. js 和 wxml 的引入是方式是不一样的，js 用 require() ，wxml 用 <import>/<include> 。这就很尴尬了，既不能像 vue 那样整个 .vue 文件作为组件一块引入，又不能像 react 那样，一切皆是hyperscript 。在微信小程序里把 wxml + js 组件化会非常麻烦。
21. 文档里说了“规定屏幕宽为750rpx”，我试了之后发现不是，此处应有黑人问号脸。
22. 在 wxss 规则里写 vw 单位会各种bug，现在还没找出规律。但在 wxml 元素的 style 属性里用 vw 单位又是ok的。黑人问号脸。
23. 小程序与小程序之间如何跳转？
24. 占位，慢慢修改

个人观点：

总的来说，亮点有，但在 Android 上暂时还并未表现出来秒杀 Web App 的特点；开发不算复杂，但开发体验有待改进；性能不算太差，也并非极好，自由度和表现力离 Web 尚有一些差距；微信小程序捆绑的 js 框架降低了新手入门的门槛，但增加了业务迁移的成本；bug极多。

微信小程序尚且是一个新玩意，亮点和缺点共存。而由于微信的封闭性，这种技术并不能完全替代 Web App 。在手机性能越来越高、Web 技术进化越来越快的今天，微信小程序到底能在多大程度上挑战 Web 的地位，还有待观察。

对于开发者，个人建议是不要太着急上火，把玩一下即可，继续观望也无妨。

如果你的业务严重依赖微信、希望在用户体验上精益求精、在客户端技术上探索一些未来的可能性，那么你可以尝试一下这个技术，用在一些新的、轻型的业务上，做一个快速试错，看看后续的结果再决定是不是增加投入。

但要在仓促之间把已经成熟的业务搬到一个新的技术平台上，恐怕不是一件容易的事情，也没有多大必要。

(有人说重点是大佬们都不睡觉的，我一看。。。还真是。。。）

昨天同时发生了两件有意思的事情。

一件是大多数人都看到的：

微信终于推出了应用号，并且取名“小程序”，向生态帝国和自己的App Store又迈进了一步。

另一件是大多数人都不会注意到的：

百度要出售旗下91无线的 iOS 业务，这彻底宣告了App分发时代的结束。

移动大潮刚兴起的时候，所有人都有一个争论，那就是 Web App 和 Native App 孰优孰劣的问题。最终这个讨论以Facebook彻底放弃Web App为一个阶段性的终结。Native App，也就是现在我们每个人手机里的应用获胜了。

那时候是2012年。移动会取代PC的大势变得清晰异常。

在PC时代，互联网最大的流量入口是搜索。几乎用户的所有需求都是由Google或百度分发出去的。但谁想到好日子没过多久，移动大潮就来了，而且来的无比之快。

Google有自己的手机操作系统，用开放的态势，占据了重要的位置，这是战略预判上的极大成功。百度也曾尝试过出手机，却失败的很惨，并且一直在移动布局中处于落后位置，这是战略上的极大误判，甚至长远来看是会丢掉小命的那种。移动浪潮对于其他公司来说是平台的迁移，但对于百度来说，则是商业模式的颠覆。

对 Google 和 Baidu 来说，Web App都是更好的更能接受的方案，但 Native App 获胜后，百度就被逼无奈地开始想：“我该怎样在移动端保住类似我在PC端的地位？”。百度在PC端是什么地位？入口和流量分发之王啊，那么百度自然就要找移动端的入口和流量分发途径。于是就有了我们都知道的故事：百度以19亿美金天价收购91无线。

那时候是2013年。百度以为自己拿到了一张移动世界的船票。

好景不长，百度后来发现这张船票是买在了浪潮的最高点。等潮流退去以后，才发现原来买到的是一艘借浪潮而舞动的小船，going to no where. （当然，同时航行在旁的还有另一艘小船，叫做豌豆荚。）

到今天为止，已经几乎没有人再下载新App，所以百度弄错的一件事情是，搜索作为入口和流量分发是持续的，而且信息量越冗杂越有价值，而App的分发是一时的，且反过来是越分发越让信息量冗杂、分散和没有价值。

不得不说，对于当时的百度来说，这就是饮鸩止渴，而且是好贵好贵的一杯毒酒。

到现在，大家最终发现移动端是群雄割据的时代。流量和入口其实是那些少数的头部App应用，大概每个用户最常用的就是那十多个App。其实这十多个App还原到PC时代，可以类比于那些成功的“中间页”，比如去哪儿、搜房，或甚至是爱奇艺。

李彦宏当时曾多次公开宣扬自己的“中间页战略”。入股、导流、变现，不断循环。当时，在各个最大的垂直领域，百度都有自己的投资布局，并且不论从资本操作还是从流量分发变现上来看，效果都还算不错。

所以现在回头来看，当初与其重金买下91，也许不如把网页端里面中间页的策略复制到移动端，去入股大量有潜力成为头部App的公司。当然，这已经是后话了，最终腾讯和阿里反而在投资布局上做的比百度要好太多。

2013年，百度收购91的同时，微信国内用户已经达到了4亿。如果说头部App是移动时代的入口，那么微信现在绝对是头部中的头部，这给了微信做平台和生态的机会。于是就有了微信订阅号、服务号、企业号，再到如今的应用号。微信在不断地为自己这个头接上四肢。

微信现在要做的就是用自己的头部效应带动长尾起来。其实，百度在13年推出的轻应用直达号，和如今的微信应用号如出一辙，也是瞄准了长尾市场。但由于百度缺乏社交账户体系，也没有如今微信如此强的闭环能力，再加上百度内部人员的战斗力问题，这个项目如百度的很多其他项目一样，都无疾而终了。当初负责这个项目的李明远，现在在百度内部也已经没有之前那么炽手可热。

而且据说，李彦宏当初对腾讯最大的担心是他们的搜索与微信的结合，所以当时李一直在密切关注腾讯soso，搜狗和360之间的交易进展。直到知道腾讯把soso卖给搜狗后李彦宏才松了一口气。

但其实，到今天搜索已经变成一个功能性的东西，而不是最早的入口。百度搜索本身当然是一个非常厉害的头部App，但和其他的十多个头部App是平行而没有区别的。就好像在网页端的时候，百度和淘宝或携程从流量分发的上下层级关系，慢慢变成并行竞争关系一样，垂直领域的品牌做到足够强大的时候，网站本身是不需其他人引流的。

这个现象在移动端来的更容易和明显。

那么微信的应用号是否能成功？我觉得相对来说也有一定的难度。要在微信内做App发现、分发其实一样是非常难的事情。所以应用号目前感觉还是对已有生态的一个良好的补充，并且更多是为B端服务，比如一些已有的知名品牌和服务商等。对于个人或小创业公司来说，应用号可利用的空间仍旧有限。

再有，如张小龙所说，应用号要实现的是应用的“触手可及”，最终让应用达到“无处不在”，这让我想起了现在无处不在的扫码支付。所以“应用号”大概率更多情况下是被动触发的场景，而不是主动寻找的，这对我来讲要更合理些。

其实，我最近一直觉得微信公众号就是现代年轻人的淘宝。当初有无数的年轻人立足于淘宝平台，每天没日没夜的上新品、做客服、寄包裹，而现在也有很多人到处抱着电脑，随时随地的推送和回复留言。这就是大生态的力量，它让一代年轻人找到了自己表达的窗口和自给自足的机会，让“给自己打工”和“个人的奋斗等比于回报”成为一种可能。

而现在应用号来了，我觉得这会不会就是给企业的天猫？

最后，更好玩的是，微信缔造了一个这么大的生态平台，却有一半是立足于另一个封闭生态“苹果”之下的。苹果对于腾讯的蚕食会做出如何的反应呢？腾讯和苹果的关系又会如何演进？我相信这会是未来最让马化腾头疼的问题之一。

P.S. Google恰好也是昨天刚推出了自己最新的即时通讯应用“Allo”，把AI助手作为主要切入点。这是否能让Google逆袭呢？不管怎么说，这对百度也是一个可借鉴之处。

本文首发自公众号：42章经（ID：MyFortyTwo）

昨晚一推出应用号内测的消息，群里、朋友圈里就像陷入了一场狂欢一样，仿佛每个人都是时候靠着这一波微信新机会逆袭了。然而我并不是太看好，我觉得颠覆世界是大部分人的YY，从入口的层级上来说就有问题。在对应的环境中做正确的事情才是对的，顺势而为，遵守这个系统的游戏规则，做这个生态里主人是更欢迎的事情，我这里会给出一些我的思考。


----------------------------------------------------------------------------------------------------------------------
关于微信昨晚推出内测小程序，我想大家已经在微信上看了足够多的东西了，我这边说说一些别人没有思考到的点。

应用号入口在哪里？

这是各种文章中对于应用号的入口的预测。以“发现”版和“我”版为主要猜测方向

如果是这样一个入口我觉得是非常深了，让我们来算一算如果是这样一个入口，对于一个应用来说叠加了几个层级

第一层：消息界面 +

第二层：发现/我 界面 +

第三层：应用号选择界面 +

第四层：进入真正的应用里 +

• 让我们从用户的使用场景来想象一下这个情况会造成的后果
  

场景一：你正在操作一个应用然后收到一个人的消息，你去回复一下，然后回去再次进入这个页面回到之前的位置，你的操作直至少需要4+x步（x为你操作到的位置），当然有一定的缓存（很有限），所以可能是4+x-n

对比一下Native App你会发现层级多了不是一点点，而懒是用户的天性，这样的操作体验无疑会大大减小使用率。

场景二：你在手机上有多高的频率切换自己的应用？如果每一次切换都要重新从首页开始操作是怎样一种体验？你是不是感觉要崩溃了。

你们在使用微信的第三方的时候应该有过类似的体验，这种难受你懂。

• 说一个我的看法：
  

从“界面设计”上来说应用号将可能成为除了“消息，通讯录，发现，我”这四个tab后“第五个Tab按钮”

这个点很多人表示无法赞同，甚至觉得可笑，参考上面说的场景你就能感觉到每少一个层级带来的操作简化有多少，这个重要性不言而喻，直接放在TAB5，直接相当于减少了2个层级，当用户操作多的时候，每次以2个层级叠加，简化的操作将不止一点点。

然而这个不太可能在内侧或者正式发布的前期就去这样做，更有可能在后期再给出更前端的入口，也就是tab‘，早期基本就应该是在“发现界面”或者“我界面”

那些说藏在钱包里的朋友我就不吐槽了，你脑补一下自己的产品体验的画面吧。

为什么应用号对于创业者来说是福音 

• 成本

native的成本到底有多高？

推广：平均成本5元一个下载 ，100万的下载量，月留存能有10w的都是少数中的少数
开发：安卓，ios要分开做，大量的机型、os版本差异、交互特殊等

就这两项能承受起的就不多了，最低起步价30w+左右，巨额的成本将大量的idea扼杀在摇篮里

而这些死掉的idea大部分就是因为市场小，盈利跟不上巨大的成本而看不到未来

• 从外部走进微信生态内部

服务更加快捷方便，用户的使用门槛大大降低。通过微信生态的流量转化更有效率，多少app的用户是通过微信文章推广流量带去的？一旦你就在这个生态里，只需要简单的操作，比如扫码，这个效率高了多少？

微信想为创业者提供怎样的价值

微信做的就是把开发和推广这两项成本尽可能的降低，推掉成本这座大山，改变移动互联网应用的规则，让创造者能把核心资源（钱和时间）关注到用户体验上，去真正为用户创造价值

应用号到底适合做什么？

微信已经做好了人与人的连接又做好了支付，现在微信希望的就是通过应用号将人和服务深度连接
连接上人与服务后微信的价值那就更是不可估量的了

服务是核心！

这就和native app时期有了一定的区别，这里更欢迎的是服务性的app，也就是他说的用完即时走。
早在8个月前，我就说微信要做的是一个长尾市场，聚合那些无法承担成本去独立做成app的服务。就像当年的亚马逊一样，几乎没有什么商品你在亚马逊上找不到一样。而现在微信就相当于是把商品变成了服务这种非标的东西。

“小而美”的产品更适合应用号，能获取较多的红利，真正高频常用的还是在原生app那边更好，当然像同程旅行火车票这种刚需路径短的还是很适合微信生态的。

小而美的服务是什么？
答：低频、非刚需基于场景的服务，在特定场景下（也就是够垂直）可以较好得解决用户需求。

许多付费的服务可能借力因此焕发出第二春，教育、医疗、家政、求职招聘、二手买卖、旅游、票务、金融理财、汽车后市场等等

最后再泼点凉水，让你冷静一下，给一些重要的建议

1.你所能获取的用户数据将非常有限，微信给你开放的用户数据基本就是头像和昵称还有一定的好友关系。数据对你自己的重要性一定要考虑清楚！

2.商业模式与native app将发生巨大改变，拿native app的思路去套，做好的可能性几乎为零，你要重新构思并快速去验证你的模式。

我觉得思考比行动更重要，在正式开发之前需要在，你要知道先入者不一定是先驱，更有可能是先烈！

3.免费的模式不一定就好，多考虑付费形式，不仅只是因为微信已经帮你做好了方便的支付接口，而是因为应用号的形态和设计初衷更适合基于场景需求的快速实现。

4.还是那句话，小而美，做垂直，功能复杂度有限制，如果想做成庞大的独角兽，必须是高频刚需但复杂度又不是太高，就像“同程旅游的火车票服务”一样。

5."用完即走"……因为没办法多任务处理，你的产品如果不能在一定时间内完成特定场景的需求并且达成自己的目标，你就比较难做。

6.产品层级不要深，操作路径要短，没法记录你操作到了什么地方，如果用户被打断，第二次进去是没法回到上一次操作的位置的(有一定的缓存)

7.应用号是一个流量孤岛，应用号之间的流量不能流通，自身产生不了什么流量，单在微信生态内来说比较依赖订阅号的文章带来的流量导入

我并不觉得会有太大的颠覆作用，等时间去验证把