东坡下载：内容最丰富最安全的下载站！
→ 微信小程序是什么意思 微信小程序有什么用
作者：专题点击：10次评论：0次标签：
微信小程序是一款微信最新推出的一个功能，当微信小程序出现的时候，就意味着很多的APP都可以“下架”了，为什么会这么认为呢？因为微信小程序所带来的功能可以满足各种APP需求，现在就详情的介绍一番吧！微信小程序是什么意思 有什么功能9月22日消息，今日凌晨，微信公众平台对200个服务号发送了小程序内测邀请。小程序就是张小龙之前要做的微信“应用号”。为什么不叫之前订好的名字呢？据天使投资人王冠雄透露，之所以微信“应用号”改名小程序，马化腾私下说因为苹果不让叫应用号。在今年1月11日举行的微信公开课PRO版上，“微信之父”张小龙说希望做一种新的公众号，用户关注了一个公众号，就像安装了一个APP一样，用户找这个公众号的时候就像找一个APP。微信内测邀请函也证实了张小龙年初的说法，邀请函只有短短两句话，“我们提供了一种新的开发能力，开发者可以快速地开发一个程序。小程序可以在微信内被便捷地获取和传播，同时具有出色的使用体验。”微信小程序为开发者提供微信的服务和支撑，这是否意味着微信小程序提供了一种关于未来的想象――不仅“人人做订阅号”，而且“人人做开发者”？有些网友表示“对于我这种内存严重不足的还是很期待小程序的到来，如果体验真能跟原生app媲美的话。” 你是看好还是唱衰？先跟小编一起瞧一瞧大V和科技媒体们怎么说。“100亿以下的传统企业，就不要做自己的app了”天使投资人王冠雄评论，小程序会加剧市场集中，继iOS、安卓开发者之后，微信开发者将越来越多，生态越来越强，而企业移动端应用的成本也将继续下降。触电商务创始人龚文祥称，以后100亿以上级别的传统公司，才配拥有自己的app。其他100亿以下的传统企业，就不要做自己的app了。36氪撰文《不开发APP的日子还会远吗？》认为很多企业可能以后不用再开发app了。“可能是草根程序员的春天？”这可能是草根程序员的春天，厚薄网络创始人陈柱子觉得开发和推广app对草根（负担）太重，张小龙可能在探求一种轻量级的idea简易爆发的可能性。找同行网CEO刘宇波也认为，“短时间会让前端再火一把。但长远看，其实是进一步降低开发门槛和成本。”也许经过一段时间，市场对h5程序员的需求会降低。因为工具的进步，以前3个人要做的事情，现在1个人就够了。不合格的程序员被更先进的开发工具淘汰，是必然的趋势。“手机操作系统未来依然是APP的天下。”不过也有大V认为小程序产生的影响可能不会如很多互联网从业者想象的那么大。微车创始人徐磊指出，手机操作系统的核心展示是APP收藏夹，而微信是聊天窗口。这个本质不改变，就很难改变“应用APP”和“小应用”在各自体系里的地位。网友LCmoon也认为“没有一家公司满足于微信小程序，就像没有一家公司停留在小而美的盈利上一样。”小程序也许只是一家公司发展的第一步，当公司发展越来越来越大不会满足于此。但无论如何，“看到了一个开放的微信。”自媒体字头社指出，微信赋能开发者更多的能力，搭建的是一个平台，而不是自己涉足各种各样的功能对开发者造成威胁，这都符合马化腾的“开放、连接”战略。张小龙说微信的野心不是一个内容提供平台，而是一家服务平台。现在微信小程序迈出了这一步。未来会变成什么样？会取代app store吗？草根创业者能否迎来自己的春天？还是这一切只是大V、媒体的一场自嗨，小程序根本激不起太多水花……一切的一切都等待未来给予我们答案
电脑版相关软件
手机版相关软件
03-0702-2310-1410-1410-1410-1410-1410-1410-1410-14
阅读本文后您有什么感想? 已有
人给出评价!
本类常用软件
名称大小下载
1 下载量：584507
2 下载量：471604
3 下载量：420835
4 下载量：367090
5 下载量：365990微信小程序（应用号）到底是什么？又意味着什么？
9月22号凌晨，微信公众平台开始陆续对外发送小程序内测邀请
据了解，此次微信小程序内测资格面向服务号开放，首批有200个内测名额
居然没有到群网！伤心！
相信对于拿到内测名额的服务号们来说肯定是非常兴奋的，就如微信小程序的内测页面所说：我们提供了一种新的开放能力，开发者可以快速地开发一个小程序。小程序可以在微信内被便捷地获取和传播，同时具有出色的使用体验。
这句话，也就意味着不开发app的时代真的到来了！
相信HTML5行业方面的人，此时的表情....
话虽如此，但小编还是以跟风的姿势，说说不一样的态度。
事实上，目前为止，APP
的用户规模和活跃度规模总体还是高于公众号很多的。不要因为微信活跃度高，而认为公众号或者“小应用”的活跃度就会高了。如果这么类比，“小应用”和微信活跃度的关系，应该对应
APP 和手机活跃度的关系上了。
而微信公众平台小程序，在组件和 web 之间取得了最佳的平衡，保证了应用的一致性和运行效率，同时又兼顾了开发的方便性。
其实你也可以理解为一个微信版本的 App Store。
到群网相信正式开放之后，会有大批服务号都想利用公众平台新开放的能力做点尝试的。
这是个机会！真的！
对于外界关注的一些问题，也有了一些解答：
Q：小程序是什么？它有着什么样的功能？
A：小程序是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或者搜一下即可打开应用。也体现了“用完即走”的理念，用户不用关心是否安装太多应用的问题。应用将无处不在，随时可用，但又无需安装卸载。
下一步将全面开放申请
Q：我是一个开发者，目前没有收到小程序的测试邀请，有什么渠道可以申请注册小程序？
A：目前，小程序仍然处于内测阶段。全面开放申请后，主体类型为个人、企业、政府、媒体或其他组织的开发者，均可申请注册小程序。
Q：现在已经有部分帐号收到小程序的内测邀请了，接下来是否会继续开放内测邀请？
A：关于小程序的上线节奏：本次内测采用邀请制，其内容客户端暂时对用户不可见。之后小程序会全面开放申请，所有小程序将在统一时间向用户开放。
Q：小程序可以和现有的 App 打通吗
A：小程序可以借助微信联合登录，和开发者已有的 App 后台的用户数据进行打通，但不会支持小程序和 App 直接的跳转。
小程序提供全新平台
Q：微信已经有了订阅号、服务号、企业号，小程序和这三者有什么不同？
A：小程序、订阅号、服务号、企业号目前是并行的体系。
Q：外界有说法称，小程序的推出意味着微信要做一个应用分发市场，是这样吗？
A：微信推出小程序，并非想要做应用分发市场，而是给一些优质服务提供一个开放的平台。
最后到群网想说：微就是一个操作系统
当然，这也不能说APP就能要落寞了，优势是必定存在的。
有人可能会认为小程序的出现会冲击我们现有的商业模式，但是对于到群网络来说，Ta就是一个充满无限可能的新事物，我们试着去拥抱Ta……
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。【昨天被微信小程序的消息刷屏，本着好奇的心百度了下】
虽然没有看到开发文档，但从泄露出来的消息资料也看到了很多的信息点可以说的，这又是一个可以媲美 Appstore 的大金矿！
上图中张小龙对小程序的诠释足够简单，这是对于 C 端普通用户的第一感观，从这段话中可以知道小程序一定是基于 Html5+微信原生能力 的产品形态。
无需下载安装
说明跟 App Store 的 APP 是不一样的，小程序是嵌在微信 APP 内的，微信提供标准化入口，当用户订阅或者“安装”该小程序后，小程序是在微信提供的入口处展示（被发现并进入）。
用户扫一扫或者搜一下即可打开应用
这里跟微信公众平台的订阅号、服务号是一致的，（极有可能）提供参数二维码的能力，搜索跟订阅号服务号的入口应该一致，但是否在搜索时增加标签选项（存异）？目前是提供了公众号的搜索入口。
用户不关心是否安装太多应用的问题，无处不在随时可用，无需安装卸载
可以想到的是小程序所使用的微信原生功能是重用的，也就是微信开放的能力中例如进度条、视图、操作反馈、导航条等能力是重复使用的，而不是某小程序特有的，小程序的开发者也无需对这些功能做太多研究，UI 是一致的，用户习惯，设计规范是一致的，微信不会让开发者在基本能力上有太多的选择，不会让你做的太花里胡哨，你的功能和逻辑可以千差万别，但在外表和进入退出操作习惯上，必须要遵循微信的规范。
那么开放给开发者的能力包括哪些？以组件和 API 的形式开放了如下服务以及支撑能力：
视图容器：视图(View)、滚动视图、Swiper
基础内容：图标、文本、进度条
表单组件：按钮、表单等等
媒体组建：音频、图片、视频。
文件操作能力
网络：上传下载能力、WebSocket
数据：数据缓存能力
位置：获取位置、查看位置
设备：网络状态、系统信息、重力感应、罗盘
界面：设置导航条、导航、动画、绘图等等
开放接口：登录，包括签名加密，用户信息、微信支付、模板消息
开放能力之多，令我兴奋不已，无限的想象！
如果你用过微信的 JS-SDK，应该对上述开放能力不陌生。得到具体的消息还有：
微信不仅提供了详细的开发文档，还提供了多平台的开发工具，包括 Mac Linux Windows。（没啥好说的，太棒了）
小程序开发后，不能直接发布，需要经过审核，类似App Store，但版本迭代是否经过审核，如果需要经过审核那么审核的周期是多少？
猜测：小程序的页面是基于 web 的，web 页面是开发者所提供的，也就是 C 端用户肯定还是直接访问开发者服务器中的数据，正常来说这个 web 页面的迭代是开发者可以直接迭代并展示给 C 端用户的，但微信是否会提供一个web 的封装入口以限制开发者必须通过审核才能迭代呢？
微信提供的小程序开发文档，还提供了比服务号更详尽的设计规范以及布局时会用到的控件，上文也提到过，微信一定会提供一套规范来约束/引导开发者，也要让微信小程序有统一的操作习惯、UI 规范，这类似 iOS 和 Android 都有不同的设计规范。
比服务号更强的能力。小程序不同于服务号，服务号的功能需要全部在 webAPP 中提供，而小程序是微信中的 native程序，是有缓存能力的，C 端用户订阅（暂且这样说）某小程序后，当有缓存的时候不仅会提高用户体验，同时也加快了程序加载速度，用户在网速不佳的时候的等待时间将大大减少，同时带来的一个问题是，微信更大了，我的微信 APP 占用手机空间在16G 左右，而一些微信深度用户或者资深从业者可能要达到20多 G，这比最小的iPhone 容量16G 还要大很多。
还有一点值得考虑的是小程序与服务号的关系，服务号是否可以转为应用号？这个不得而知，但我相信肯定有大批的服务号是想转变为应用号的，一些服务号的功能属性远大于媒体属性，例如有硬件设备连接需求的服务号、京东购物的服务号、滴滴出行等服务号，如果让这些服务号主体再去开发小程序未免太折腾，主体下的服务号和小程序之间功能也会有重叠，浪费资源，也占用用户的资源，所以我的猜测是认证的服务号是可以转（升级）为小程序的。在之前订阅号是可以“升级”为服务号的，如果有这个可能，微信可能也会给出是否“升级”的选择；因为从得到的消息来看，微信的态度是订阅号、服务号、企业号、小程序是完全并行的四种形态，所以服务号的继续存在一定还有其服务号的意义，但如何升级不得而知，例如粉丝迁移？小程序的用户是不是还有粉丝这一说？应该叫用户？
目前看到的截图，小程序的 URL 是
http://mp./xxxxxx
，也就是在公众号的pc登录页面，小程序还是归属在 mp 平台下，另一张显示URL 的截图没找到。小程序离订阅号服务号更近一些。
在全面开放申请之后，主体类型包括个人、企业、政府、媒体或其他组织，这一点很有意思，小程序是有个人主体类型的，我们知道订阅号是可以申请个人主体的，但服务号不可以为个人主体的，对此有很多的疑问，小程序是有微信支付能力的，而小程序可以面向个人开放？税务问题呢？对于个人来言的可信度整体来说一定要小于企业的可信度的，或者小程序的开放也是对不同组织有区别对待？例如个人开发者是没有微信支付功能的，不然收款到哪里？个人账户？服务号的微信支付都是关联企业对公账户的，微信不会给你提供逃税的能力。
小程序的上线节奏，本次是邀请制，内容是在客户端看不到的，之后会全面开放申请，所有的小程序会在统一时间向用户开放。也就是说，现在获得内测的也就是先看到开发文档，先开发小程序，等大家开发的差不多了，会一起开放给用户。相信这个时间不会太长，从1月份微信团队爆出应用号这个东西至今已经9个月的时间了，准备工作基本都做完了，这次大规模的放出消息，已经是最后的号角，内测开发者要抓紧时间，我猜测1~2个月的时间小程序就可以和用户见面了，下两个版本左右就可以看到。
小程序是可以与 APP 打通，但并没有提与服务号的打通，其实与服务号的打通是完全没有问题的，但微信并没有提这一点，猜测服务号是可以升级小程序的。但不支持小程序与 APP 的直接跳转。（能做的都在小程序内做就好了，搞那么多跳转没有意义）
小程序不会是应用分发市场，而是一个开放平台，小程序更多的是提供优质服务的，这个服务可以比服务号更宽泛。现在的微信订阅号是媒体属性的，服务号是功能+媒体（消息触达）属性的，小程序应该是功能+消息触达的，小程序会不会有推送图文这回事？可能有，但我的观点倾向于没有，有的是消息触达，但没必要做图文了。
小程序是否会对开发者收费？对比iOS 开发者，iOS 开发者是收费的，两者都是需要经过审核的，虽然现在没有任何关于小程序是否面相开发者收费的消息，但这并不是不可能，服务号、订阅号的认证是收费的，认证之后获得了未认证所没有的能力，比如微信支付；我猜测小程序是会有收费的通道，类似认证费一样（但可能不会叫认证费），然后获得未认证所没有的能力，或者叫其他名字的费用，按年收取。
小程序一定还有消息触达的能力，但群发能力（相当于APP 的消息推送）次数限制应该还是会有的（是否与服务号的4条一致？），其他业务通知使用消息模板来解决，但消息模板的 UI 是否应该变一下了（招商银行的消息模板已经变了，消息模板上也是有菜单选项的），微信应该也会提供屏蔽小程序消息的选项，不然恶意营销的企业会烦死用户的。
开发小程序的产品框架Html5+PHP/JAVA/node.js...+微信框架组件，技术圈叫：Hybrid APP，混合式开发应用。但一个缺点是不能跨平台，只能在微信中打开使用，想在 Safari 中打开可能不太现实了。可以预见到的是JavaScript 工程师会非常吃香。相信以后互联网公司会增加一个小组或者部门，叫微信小程序开发小组，
小程序正式上线后，可以预见到的是：大量企业会第一时间尝鲜，以及服务号升级小程序的操作（如果可以升级的话），小程序的开发成本远小于开发独立 APP，推广也更有优势（扫码、搜索），并且不会占用用户太多资源空间，还有什么理由不选择小程序而去开发一个独立 APP 呢？
同时，在大批企业开发小程序的时候，很多的传统行业又想不落后，不能被时代淘汰，为了赶时髦而赶进度，实际上很多企业未必会有小程序的开发需求，如果只是展示公司情况 展示产品 或者服务号订阅号更适合。但很多传统企业一定还是会开发一个没有多少人用的甚至只有公司内部人体验的小程序的。
会不会涌现出大的微信第三方，例如：有赞？某些行业会的，但我认为更多的还是会往平台化的小程序发展，例如停车，使用一个小程序就够了，要订阅那么多小程序并不会提高服务的质量，因为一个平台使用一个小程序就够了。小程序的产品形态远比服务号复杂，功能性 UI的想象空间都有了很大的提升，不再是完全标准化的需求了，例如有赞，其实大家看重的是各个行业的支付方案，把支付做的更适合商家可以做营销做 CRM 一站式对公众号有简单操作的系统服务。但小程序则不然，应该所有的小程序都是不一样的，因为需求不一样。
微信小程序首先会涌现出哪些行业案例？滴滴出行 京东 微票以及所有在微信钱包下可以看到的第三方服务，以及腾讯旗下产品会是第一批崛起的小程序。
微信小程序相对独立 APP 一定也会有很多不足，微信提供的是在微信框架内的能力，用小程序去做一个3D 网游是不可能的事情，更多基于APP原生能力的 APP 几乎都不能使用小程序来代替，而基于 webAPP 的 APP基本都可以使用小程序来代替。再者，微信的封闭特性也是有想象空间的天花板的，灵活性肯定不如独立 APP，独立 APP 可以把常用功能放到小程序里，小程序为主还是独立 APP 为主，这并不一定，因为每个 APP 的功能需求不一样的。
本文来自微信公众账号提交，由微信啦收录，转载请注明出处。
微信扫码 分享文章您的位置：
迅雷首席架构师刘智聪：微信小程序的架构与系统设计的几点观感
作者：三少爷的剑
　　笔者注：本文来自于迅雷首席工程师刘智聪的个人分享，他毕业于南昌大学化学系，加入迅雷后设计开发了多款迅雷核心产品，凭借“大规模网络流媒体服务关键支撑技术”项目获得2015年国家科学技术进步奖二等奖，同时也是第四代UI交互技术-----BOLT 界面引擎的发明人，目前担任WebApp解决方案商--火速移动的首席技术顾问。
　　21号晚上正和朋友一起打牌，难得的小七对刚刚定口，突然间手机传来了“叮咚”的消消息提示音，随后就是“叮叮，咚咚”的连续震动。打开手机一看，微信上一堆人发信息给我，先是一篇《微信应用号来了》，然后就是：“你怎么看?”
　　虽然之前曾经得到过消息说“微信应用号”会在年底发布，但没想到居然来的这么快，而且还改名叫“微信小程序了”(简称小程序)。已经无心打牌，赶紧完成一吃三后速度回到电脑前开始了持续几天的研究。而且这几天里各种相关资料都开始相继出现，内测用的开发工具也有破解版漏出了。
　　身边已经有不少朋友已经根据资料开始干活了，差不多有如下几类：
　　1)好好释放想象力，要是能在公测的时候做个有趣的小程序出来一炮而红那就赚大了
　　2)公司有一打的服务号，其实改成小程序会更合适(管它合不合适，改了再说!)
　　3)又是一轮洗牌的机会!那个公众号的功能是我先想到的但被别人抢了，这次我要在小程序里第一个做出来并做到第一名!
　　4)微信果然是互联网的“国务院”，新政策草案刚出立刻引起全行业的连夜研究。这么重要的关头，变革的前夜，我认为正确的做法是“战术上立刻响应，站略上不必着急”。不学习，不了解微信小程序是万万不行的，但立刻根据现在的资料，调整公司的方向，也有点为时过早。毕竟现在还在内测阶段，万一内测结果是“回炉重造”或则“大幅调整”(目前泄漏的资料已经处于正式发布的状态，应该不会大改了)，那花在这里的时间都赔进去了还没地哭。所以我觉得对公司来说比较合理的做法是在立刻成立一个短期的临时小组，鼓励对小程序有兴趣的同学加入，一起开发几个有趣的小程序，主要目的就是学习。如果做出来的结果好还能赚一波眼球。等微信小程序正式公测了，再决策要不要把这个临时小组升级成一个正式的产品团队。
　　这几天通过目前公开的资料我已经对小程序的整体架构有了个初步的认识。我的风格一向是从架构和系统设计的视角做一些深度的，有观点的分析。现在终于可以回应朋友们的问题，谈谈我怎么看了。
　　微信小程序是什么?
　　官方这么说：
　　“我们提供了一种新的开放能力，让开发者可以快速地开发一个小程序。小程序可以在微信内被便捷地获取和传播，同时具有出色的使用体验”。
　　听起来非常美好，咱们具体一点，结合目前公开的信息和微信目前其它的开放形式对比一下吧
　　可以看到，腾讯还是非常有诚意的，这次在微信小程序上新开放的能力很多，不再是渐进式的演变而有一点像革命了。
　　小程序的入口在哪?
　　目前公开的资料里对大家最关系的入口问题只提到了小程序可以扫二维码打开，于是业界对小程序的入口有了这么几种流行的假设：
　　假设零：朋友圈，朋友可以把自己喜欢的小程序分享在朋友圈，看到了可以点击打开直接使用。
　　可能性:99%。小程序不能出现在朋友圈，流量从哪来?
　　假设一：出现在发现tab页面中，游戏下面(每个小程序占用一列)，同时摇一摇也可以得到附近的小程序
　　可能性:80%。和一把腾讯的游戏挤在一起，不亏待你吧。
　　假设二：和当前的公众号、服务号类似，安装出现在会话列表
　　可能性:90%。新的开放能力和旧的开放能力用一样的入口不奇怪吧。
　　假设三：安装后和native app一样，直接出现在桌面
　　可能性:10%。和微信在同一级入口，腾讯同意Apple都不一定同意。
　　假设四：微信多一个小程序的tab
　　可能性:1%。多一个tab太丑了，而且小程序刚发布，不可能立刻就对微信的整体结构产生影响。
　　假设五：出现在一些内置流程中(比如和好友的聊天界面内，发朋友圈的界面(拍照后处理)
　　可能性:1%。小程序和微信本体使用不同的框架技术开发，互相嵌套有困难。
　　微信小程序框架浅析
　　官方已经正式公开了小程序的开发资料，小程序的开发框架包含两大块内容，分别是：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)构建。一个典型的小程序的结构如下：
　　app.json 小程序配置：
　　1.小程序里一共包含哪些页面。
　　2.页面套在一个怎么样的 window里显示。
　　3.window是否需要支持多tab,支持的话每个tab的默认page是什么。
　　4.一些底层组件的默认参数。
　　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应用”
　　“以后互联网的发展方向可能更偏重于HTML5”
　　而有的人又认为
　　我们真的需要“小程序”么?| HTML5老兵如是说
　　“微信虽然用了 HTML5 技术来做应用号(正式名称：小程序)，但是它并没有真正用到 HTML5 的精髓——开放、互联，也就决定了它可能无法实现“微信OS”的最终野心。”
　　这两个观点是矛盾的，那么，到底那种观点是正确的呢?首先简化一下问题，微信小程序是基于HTML5开发的么?
　　通过分析小程序的运行原理，这个答案是明确的：小程序的开发过程会用到大量HTML5相关的技术,但并不是使用HTML5开发。有 HTML5经验的前端工程师学习微信小程序的开发相对会更容易一些。微信小程序的运行并不需要一个完整支持HTML5特性的标准浏览器内核，但也可以通过添加一些辅助设施，让小程序在个完整支持HTML5标准的浏览器上运行起来。
　　“由于框架并非运行在浏览器中，所以 JavaScript 在 web 中一些能力都无法使用，如 document，window 等。” 也就是说，一个已存在的HTML5页面，并不能通过自动转换工具变成一个合法的Page，而需要有工程师根据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的具体平台特性无关的。
　　要面向更多的非专业开发者，所以学习门槛要低。
　　大规模的专业团队进行团队开发时，能有足够的工程支持。工程支持包括：
　　模块化
　　代码易于长期维护和修改。这意味着基于框架的实现具体需求的结果要足够清晰，好读。
　　可复用性设计。
　　小程序不需要安装就可以快速开始使用，只需要加载必要的资源就可以尽快展现用户需要的页面。
　　进一步思考这些需求该如何解决，并对不同的解决方案进行评价需要的领域知识非常多，已经超过了本文的讨论范围。我在这里要做的只是带你入门，让你开始思考设计问题就够了。这也是本文的核心目的：学会对新技术，新设计进行独立的分析和判断。至于结果么，现在小程序还处于一个早期的状态，等公测了之后在下结论也不迟。
　　而如何更好更快的探索小程序的可能性，也将是我接下来创业的方向。我将以火速移动技术顾问的身份，和小伙伴们一起从微信小程序开始，去探索移动Web的可能性。
　　感谢各位关心。
(转载请保留)
热门话题大家都在看
互联网的一些事，已超50万小伙伴关注！