littlemoa 2022-08-11 13:23
笔者注：本文
[配图7]
app.json 小程序配置：
小程序里一共包含哪些页面。
页面套在一个怎么样的 window里显示。
window是否需要支持多tab,支持的话每个tab的默认page是什么。
一些底层组件的默认参数。
app.js（可以理解为入口函数）
处理app的几个关键事件:onLaunch,onShow
定义了app级（可以在不同的页面之间共享）的数据的格式
app.wxss 公用样式表
每个页面的样式表，都是从这个应用级公有样式表继承下来的。
MINA一个最主要的核心概念是Page，一个Page是应用内可以导航到的最小粒度的界面。而如何构建Page是与大家过去猜测差别最大的地方。微信并没有使用HTML5，而是提供了一套新的设计。新的设计要求每个 Pa优艾设计网_Photoshop交流ge由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的可能性。
感谢各位关心。
360U3166866559 2022-08-11 13:26 我个人并不是很看好。html5，js以及类似的技术替代原生大家喊了很久了，就是大热的react native目前看来也依然很不完善。微信的应用应该都是运行在腾讯浏览器的X5内核里，这东西怎么样大家心里也都有数。我感觉还是只能做一些低交互的应用，大概也就是比网页快捷方式高一级别，要利用os的炫酷特性，原生还是跑不掉，而且目前原生开发很成熟了，框架库很多，门槛也很低。对于不用下app省空间我不是很理解，只不过是把app浪费的空间挪动到微信里而已。微信所倡导的用完即走的理念也只有腾讯有资本装b才会这么说，其它公司无论如果始终还是会想办法更多的占用用户的时间。腾讯现在原本就掌握了渠道，现在连app的审核等生杀大权也都掌握，你说苹果恶心，但他起码还勉强算公平，而腾讯可以随便打着为了用户（和你妈说为了你好）进行系统抖动，非腾讯系全都会抖，想怎么搞你怎么搞你。结局都是类似的，中小型公司都很激动，以为有了小应用他们就有了腾讯爸爸的几亿用户，这种幻觉很美好，但他们可能会面临更加惨烈的竞争，变成临时解决用户欲望的千斤顶，以及腾讯渠道那可怕的推广分成费用。大公司肯定都很不情愿的跟进，又没办法，估计会简单开发一些应用，然而尽可能的往自己原生的app上导入，心态很微妙，不过短期内肯定会先爆发一波星座血型算命起名你的前世今生颜值计优艾设计网_PS交流算能活多少岁等一些QQ空间喜闻乐见的低质量辣鸡应用，目前也不知道腾讯审核时是否会做一些限制。微信也许已经不是聊天软件了，我朋友偶尔用了一下QQ，惊叹的说，QQ真好用呀，聊天记录都能自动存下来! 微信当初也许吸引大家的是我们只想要一个广聊天的QQ，现在已经要变成微信os了，是不是以后也要走和当年QQ一样的路？整个腾讯系全压在这款app中？ 我不知道，在集团利益，业绩增长的车轮下，什么张小龙王小龙，什么鬼的用户体验，什么产品经理说不的坚持，有多少碾碎多少。仅是个人一点感悟和粗浅看法，不太对请见谅
比利的比利 2022-08-11 13:30 昨晚一推出应用号内测的消息，群里、朋友圈里就像陷入了一场狂欢一样，仿佛每个人都是时候靠着这一波微信新机会逆袭了。然而我并不是太看好，我觉得颠覆世界是大部分人的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.应用号是一个流量孤岛，应用号之间的流量不能流通，自身产生不了什么流量，单在微信生态内来说比较依赖订阅号的文章带来的流量导入我并不觉得会有太大的颠覆作用，等时间去验证把
德卡_2016 2022-08-11 13:31 1. 微信小程序不会取代大型App，应用市场该怎么做怎么做。Native A优艾设计网_设计pp 更不会消亡。这个跟性能无关。2. 低频应用 是最有可能转入到 小程序 平台的。扫码搞活动也会更方便。3. 小程序 是否能做起来，要看 微信 对其开放什么样的入口，比如：朋友圈直接显示界面？ 聊天窗口直接显示界面？ 聊天窗口直接发起游戏？ 多带带的小应用 Tab？ 如果这些都不开，跟现在的H5没本质区别。4. 估计会兴起一批“聊天窗口”游戏/应用
分裂的硬盘悔 2022-08-11 13:33 微信小程序这个东西的出现早有苗头：在客户端/浏览器集成一个运行环境，用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 的业务范围。但在现实中，它又确实有可取之处，微信的巨大用户量、轻型应用的可传播性、相对较好的性能和一致性的用户体验，时时刻刻吸引着应用开发者来使用这种技术。时代的洪流浩浩荡荡，我们每个人都只能顺势而为。＝＝＝＝虽然微信这一次的代码和文档质量都还不错，小程序的特性也令人印象深刻，却也并非完美。以下吐槽一下微信小程序目前的一些问题。Android 下，input 组件中输入文字，切换键盘显示/不显示状态，文字会错位。Android 下 Canvas demo 刚开始动画时丢帧。而且大部分涉及动画的组件，如 swiper/progress 等，都有丢帧的现象（骁龙650 啊，不应该啊在 scroll-view 上用手指滑一下然后松开，界面发生滚动，但手指松开后会错误地触发 click 。getApp() 、Page() 等框架函数没有放在命名空间下。tabBar 分割线只能用黑白两种颜色，且图标不支持 svg 。HexColor 只支持 RGB，不支持 alpha。swiper 组件的 indicate dots 好丑，也没法定制 - -API 不如 Vue.js 优雅。赶工的痕迹还是挺明显的，比如 <map> 组件，我传进去参数了，显示出来的地图上也打点了，但是用户在地图上操作的行为呢？没有事件传出来，业务代码没法获取到用户操作。IDE 没有实现 live reload ，在 IDE 里需要手动刷新，在手机上需要反复扫码。不开放编译和打包过程，没有集成 babel 支持。不会将引用的 npm 包打包到项目里，需要自己另想办法。好像没有提供远程调试？反正我没找到真机调试打断点的地方。没有提供真正的退出小程序的功能，无论是返回键还是菜单中的“离开”，都只是睡眠和隐藏而已。没有提供删除小程序本地缓存的功能，改了后台配置之后用户端的没有更新，我只好 root 之后进 /data 分区手动删除缓存文件。文档中有一些锚点链接点了没反应，比如配置里的 tabBar。wx.request() 这个 API 的限制非常严格，比 Web 里的 http request 限制严格得多。wxml 是写死在源码里的，那么如何在运行时动态生成页面结构？似乎没有 webview 组件。js 和 wxml 的引入是方式是不一样的，js 用 require() ，wxml 用 <import>/<include> 。这就很尴尬了，既不能像 vue 那样整个 .vue 文件作为组件一块引入，又不能像 react 那样，一切皆是hyperscript 。在微信小程序里把 wxml + js 组件化会非常麻烦。文档里说了“规定屏幕宽为750rpx”，我试了之后发现不是，此处应有黑人问号脸。在 wxss 规则里写 vw 单位会各种bug，现在还没找出规律。但在 wxml 元素的 style 属性里用 vw 单位又是ok的。黑人问号脸。小程序与小程序之间如何跳转？占位，慢慢修改个人观点：总的来说，亮点有，但在 Android 上暂时还并未表现出来秒杀 Web App 的特点；开发不算复杂，但开发体验有待改进；性能不算太差，也并非极好，自由度和表现力离 Web 尚有一些差距；微信小程序捆绑的 js 框架降低了新手入门的门槛，但增加了业务迁移的成本；bug极多。微信小程序尚且是一个新玩意，亮点和缺点共存。而由于微信的封闭性，这种技术并不能完全替代 Web App 。在手机性能越来越高、Web 技术进化越来越快的今天，微信小程序到底能在多大程度上挑战 Web 的地位，还有待观察。对于开发者，个人建议是不要太着急上火，把玩一下即可，继续观望也无妨。如果你的业务严重依赖微信、希望在用户体验上精益求精、在客户端技术上探索一些未来的可能性，那么你可以尝试一下这个技术，用在一些新的、轻型的业务上，做一个快速试错，看看后续的结果再决定是不是增加投入。但要在仓促之间把已经成熟的业务搬到一个新的技术平台上，恐怕不是一件容易的事情，也没有多大必要。
梦中一别 2022-08-11 13:35 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:The code is run by Apple’s built-in WebKit framework or JavascriptCoreT优艾设计网_Photoshop问答he code does not provide, unlock or enable additional features or functionality安装一个app就相当于微信不用苹果审核就*增加*一项功能，这比加个patch快速修复一个bug可*过份*多了…鉴于微信在苹果发布会上出现的频率，微信团队很可能跟苹果沟通过了，所以像360那样被下架的可能性比较小，不过如果别的厂子看见了也蠢蠢欲动，那可是动摇了AppStore的根基啊【反X亡A，不反X亡B的感觉
加载中,请稍侯......
精彩评论