如何评价 9 月 21 日开始内测的「微信小程序」? 财富值85？

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设计，这是需要有大智慧的工作。

假设三、使用小程序连接开发者_如何学Go一切

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

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

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

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

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

感谢各位关心。

应用号入口在哪里？

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

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

第一层：消息界面 +

第二层：发现/我 界面 +

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

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

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

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

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

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

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

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

应用号到底适合做什么？

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

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