含着金钥匙的小程序，还未展现全貌，就已经成了研发界的头条大事儿。有人不以为然、嗤之以鼻，有人奉若神明、投怀送抱。敢于尝鲜的已经开始动手了——不管合不合适，先借那个热度来一波关注是不错的选择：

        所谓“不登高山,不知天之高；不临深溪,不知地之厚“。我生怕看不清小程序这座大山，滚去做了个demo。

        假如不考虑性能以及各种复杂的动效，小程序的感受已经很接近原生植物App了。

        已经有许多的主流新闻媒体对小程序进行了解读，本文将从一些不一样的角度来解读小程序的特性。

        1 小程序 VS APP

        我先举个例子来直观感受下小程序和APP有甚么不同。大家都用过网银，在其外部包含着许多小的服务项目：智能手机充值、城市服务项目、生活缴费、信用卡还款、加油服务项目，吧啦吧啦一大堆服务项目。那些细小的、机能单个的服务项目放在网银那个超级App里，你并不觉得有甚么问题，而且用起来也很方便。那假如那些小的应用领域都单独拿出来，成为一种独立的App，你每用一种服务项目都须要从AppStore里离线，而他们其中许多服务项目，你可能将几个月才采用一次，甚至只会采用一次，但却要长时间的占用你的智能手机内部空间。这种的模式，可能将多数人都不会喜欢。

        小程序有些类似于上面寄生在网银里的各种服务项目。他们具有业务经济发展直观、明确，采用频率较高（你不可能将每天都交话费、也不可能将天天都交水电费）等特点。这类服务项目，假如单独做成App，一是研发效率高，二是采用者的智能手机内部空间有限，所以把那些小的服务项目都“折叠”进中，无需离线，采用者想用时就搜一扫，用完即走。

        轻量、机能单个的服务项目适宜小程序；而业务经济发展复杂的应用领域适宜用App。这里不太认同主流新闻媒体们说的：低频适宜小程序，低频适宜App。那个说法太绝对，低频低频不应该成为合适不合适的分界线 。本来就是超低频应用领域，许多人一天要关上十几次吧，我在采用的时候顺手就采用了小程序服务项目，那个情景是不是也合情合理？我认为的超低频采用次数能弥补小程序出口处较深的缺点（而且出口处究竟在哪里官方并没给出准确的位置）。此外，低频低频是个非常模糊的概念，很难去界定，一天用一次算低频却是低频？网银算低频却是低频？

        所以，不要被低频和低频限制你的观念，那个吗不是关键。

        轻和重是从小程序和App的特性上在区分两者的差异，这里我提出一种按商品规模划分小程序和App的观点： 绝大多数投资人将在MVP阶段，采用小程序方案；而当商品经济发展到一定的规模，投资人依然会研发他们的App。

        可口不必等最初只在里向采用者提供更多“排队等候叫号”服务项目。你只需扫描一扫店家的条码，就能去逛街了。那个服务项目号会在快排到你的时候向你发送一条提醒，你不须要守在店里排队等候。 这种的一种情景放在现在，非常适宜采用小程序来研发，它满足业务经济发展直观、频率不高的特点（你不可能将一日三餐都在餐馆吃饭，又恰恰每次都要排队等候）。在采用者数量达到一定的规模后，可口不必等迅速面世了他们的App，尝试将采用者向他们App内转移。 围绕着“排号”那个核心机能，可口不必等App增加了点评、实景拍照、排行榜、美食专题等一些列额外机能。这种从一种直观的MVP商品瞄准采用者某一痛点，成功后旋即面世一系列被“重定向的机能”，这在网络商品里太常见了。滴滴从在线打出租车瞄准，经济发展到专车、快车、拼车、代驾、班车、巴士；罗辑观念从一种每天推送一条语音的自新闻媒体，到在里卖书，再到现在面世他们的App得到。为甚么可口不必等和罗辑观念在生态环境中做的相当成功后还要面世App？就在外部深化产业链不好吗？可能将有以下三点原因：

        第一：单个的服务项目在中国极难产生回报，商品须要不断的重定向。国内的付费习惯还没养成，想靠出售服务项目盈利在现阶段情况下很困难，尤其是To C的商品。大多数商品会依靠一款拳头商品瞄准市场，在以获取采用者后，开辟一系列增值业务经济发展和额外机能，这才可能将有盈利的想像内部空间。任何一种商品都很难保持克制和不膨胀，这是资本、模式的须要。马云一直讲克制，一直和百度外部诸多“势力”博弈，但却是成为了一种超级App，日渐臃肿。由直观到复杂，由低级到高级，这是商业模式的趋势，也是万物进化的规律。假如你熟悉成熟网络子公司的业务经济发展分布是多么的广泛，就会对那个结论不足为奇。

        那么小程序有可能将承载那些额外的增值业务经济发展，允许研发人员逐渐完善他们的商品及商业布局吗？现阶段看来，可能将性比较小，因为这和小程序的初衷是相违背的。即使放开政策，能 想像的内部空间也很小，你只能在给你划定的一种小范围内做用户数量的变现，这远远不及独立出一种App所带来的价值。

        第二：对生态环境的不信任感，导致了这种“逃离”。最近和一种投资人聊天，我问他，小程序来了，你还考虑做APP吗？他说：做，小程序和APP都会考虑做。我问他为甚么？他说：我总感觉小程序不是我他们的，而APP会给我一种踏实的感觉，我会觉得我对APP有绝对的控制权，即使做小程序也只是为了给我的APP引流。 有这种感觉的人应该不在少数，可能将是对Web App技术的不信任，可能将是对将应用领域建立在另一种应用领域这种模式的不信任，也有可能将是对百度的不信任。

        百度对他们利益保护是毫不手软的， U步、虾米音乐、微软小冰，都曾被封禁过。淘宝就更不必说了，相爱相杀，斗智斗勇，年年都是大戏。孰是孰非，很难界定。那些商品由于只是借助的矛盾链，而并非完全寄生于，被封禁也只是少了一种推展途径，没了还有微博等其他媒介。 而完全根植于生态环境的小程序，假如被封禁或是被规则打压，几乎没退路可走。

        那App就很可靠吗？现阶段看来确实比小程序要靠谱许多。主要一点却是生态环境主宰者的格局 。无论谷歌却是苹果子公司，都是科技界的顶尖子公司，这种的子公司盈利手段、业务经济发展方向、商品级别都要高出普通子公司若干个等级，他们关注的是科技趋势和标准经济发展，很少在消费业务经济发展上同投资人竞争。此外，谷歌与苹果子公司对研发人员更多的是抱有“合作心态”，我须要你帮我壮大生态环境，你须要我为你提供更多网络平台。那些引领科技方向的子公司，更容易给投资人们足够的信心。相反，百度投资了许多的C端消费领域子公司：京东、滴滴、饿了么、人人车、SuperCell、盛大文学、龙珠直播，几乎覆盖了电商、金融、娱乐文化、O2O、在线教育等各个领域，投资人几乎不可能将绕开百度的利益圈。百度既是裁判也间接的是运动员，能否保持一种公正和开放的态度，还须要时间来验证。

        第三：生存在AppStore和夹缝中的小程序将承受更多规则阻力。在内不仅会受到的政策阻力，还会受到苹果子公司的阻力，小程序的政策环境只可能将比AppStore更加苛刻。小程序虽然积极支持HTML5的Canvas，但据说苹果子公司不允许在小程序里做游戏；每个采用者可能将最多只能安装20个小程序；那些限制是外部规则的第一种阻力。毕竟是寄托在另一种生态环境上的App，本身就会受到约束。 随着小程序生态环境的演进，这种的内外部阻力会逐渐增强，投资人们再次选择App也就不是甚么稀罕事儿了。

        所以，小程序更多的会和原生植物App互补，服务项目于商品的不同阶段。建议投资人在商品早期用MVP观念来构建一种小而美的商品，研发成小程序来试错，利用天然的获客能力和散播链条来推展。后期再考虑将用户数量引到原生植物APP中进行用户数量变现。

        虽然有以上诸多不稳定因素，但小程序生态环境的出现对整个中国网络的经济发展依然是个利好，它给了独立研发人员以及初创团队更多的想像内部空间，以前不敢尝试的idea都能借助小程序那个网络平台进行试错，我期待更多小而美的商品在中爆发。

        2 已存在的众多App将如何应对小程序的到来？

        按照现阶段小程序的定位，位于AppStore榜首的中大型应用领域，不是小程序的“那盘菜”。小程序更适宜轻量且机能单个、操作直观的商品。大部分的商品却是会以原生植物APP为主。

        但我预计，各种应用领域（阿里系的商品除外）大部分都会面世相应的小程序版 。适宜小程序的顺其自然研发一种小程序版的应用领域；超大型应用领域也会想办法将他们的业务经济发展拆分出一部分来研发成小程序。原因有以下3点：

        蹭热点，刷存在。难得的无公害、低效率营销手段，何乐而不为？多一种用户数量的出口处，的矛盾链却是不容小觑的。也是最重要的一点：小程序的未来是星光璀璨却是黯淡无光，谁都无法肯定。那么面对不确定的因素，做好防御性的姿态是很重要的。没比率先在新生态环境面世他们的商品更好的防御措施。尤其对那些没技术和数据壁垒的子公司，商品很容易被取代，必须做好一些列的防御措施。网银、、等超级应用领域都曾以观望的姿态在WP网络平台面世他们的商品，那商品质量和版更新速度差的简直不忍直视，“察言观色”的态度不言而明。反正那个网络平台有我的商品，网络平台经济发展的好采用者量多我就加大投入，完善版；有竞争对手的商品出现，我就快速迭代迅速扼杀；假如网络平台经济发展的不好，反正也没投入多少，挥一挥手跟微软说拜拜就是了。3 张小龙说的搜一扫可以关上小程序到底是个甚么鬼？

        张小龙在那段被发烂的截图中提到：采用者扫一扫或是搜一搜就可以关上小程序。扫一扫那个情景很容易想像到，将条码额外在各种营销活动中，采用者扫描或是长按条码就可以关上小程序享受服务项目。但我更感兴趣的是“搜一搜”那个动作。那个搜一搜的搜寻对象是甚么？能利用语义分析、人工智能来分析采用者的行为数据（掌握着海量的采用者数据）并向采用者提供更多精准的服务项目吗？

        采用者做搜寻时，其本意是去以获取他所须要的讯息（服务项目），而非以获取App，他并不关心那个服务项目来自于哪个APP。现在的原生植物APP，在讯息和服务项目上加上一层壳，成为一种封闭的行尸。而采用者须要采用服务项目时，无法直达服务项目，采用者与服务项目之间隔着一种“壳”，这也是为甚么APP会让人觉得很“重”的原因之一。百度当年的“框计算”，也是为了解决讯息行尸的问题，直接以服务项目为搜寻对象，即搜即得、即搜即用（这和现在小程序的经营理念何其相似），从而拔掉应用领域这层盖在服务项目之上的壳，解决讯息行尸的问题。

        小程序是云端应用领域，理论上能消除这种的讯息行尸，直达应用领域外部。我很期望小程序的搜寻是语义化的搜寻，搜寻的是采用者的需求，而不是直观的去搜寻的小程序的关键字。那么小程序能实现这种的或是类似这种的经营理念吗？我来看看百度“框计算”的技术结构：

        最难的部分应该是需求识别和精准分析那个框里的技术。现阶段人工智能及机器学习都还停留在理论阶段，并没很好的商业化案例，小程序想实现这种的能力，挺难。 那假如无法实现，小程序所谓的“搜一搜”依然却是同AppStore一样在搜寻“应用领域”的关键字和热词，那么这和做应用领域分发又有甚么区别？百度说不做应用领域市场的说法很值得商榷，无论如何一种隐形的应用领域市场依然存在。SEO、ASO等概念很可能将再次出现在小程序的生态环境圈里。

        4 小程序的研发效率吗比原生植物App低吗？

        考虑两个方面，研发效率和推展效率。

        原生APP一般要同时研发iOS和Android两套，而小程序只须要做一套。毫无疑问，这点是小程序最大的优势，从那个角度来看，小程序是“跨网络平台“的。

        具体到研发效率上，很遗憾，在现阶段，研发一套完整逻辑的应用领域流程，小程序的研发效率是低于APP的。小程序独立出了一种封闭的生态环境。我经常说不要重复的造轮子，可小程序现在是裸奔，你得他们去造轮子。而iOS和Android经过经年的累积，已有大批的成熟部件能采用。 相反，小程序现阶段还处于内测阶段，没任何优秀的第三方部件能采用。而官方提供更多的部件，USB非常的少，实现机能没问题，但你想他们去定义部件特性、式样是很困难的（这点吗很奇怪，所有部件没任何设置式样的USB）。

        我团队做了个直观的对比，研发同样一款直观的天气应用领域。iOS拿到UI结构设计稿后，轻车熟路两天搞定，各种交互不须要UE，都是iOS常用动画。web前端这边，拿着结构设计稿去找UI：

        那个透明的状态栏我没法实现，因为小程序的状态栏必须要有 。 底部的Tab栏我只能设置颜色和图片，结构设计稿里的式样我做不出来。 Banner轮播的指示点我改不了。

        UI一脸懵逼的看着他。

        我在小程序研发中遇到最棘手的2个问题：

        缺少统计、绘图部件，以前的echarts和hightcharts都无法采用，只能用canvas去绘制，耗费的时间之多可想而知。我现阶段正在着手修改一款基于canvas的开源绘图部件，让其积极支持小程序。小程序不积极支持WebView，大批已被静态化好的HTML页面完全没办法在小程序上展示。假如要积极支持格式化的文本显示，现阶段思路有二种： 编写工具，用正则表达式解析HTML，并转化成小程序的标签。那个过程很繁琐，不仅要处理标签还要处理式样。比如html中的 ul 签，处理起来就很棘手；再比如小程序里的中是无法冗余的（冗余后外部的text式样无效），而这种的冗余在html中太常见了。编写一种针对ml的文本编辑器，用这种的编辑器重新打印和格式化文本（这就是小程序带来的一种挺好的机会）

        小程序原生植物积极支持WebView的可能将性很小。假如积极支持WebView，那以前用HTML5研发的各种WebApp又能在小程序里跑了，iOS —-> —-> 小程序—-> WebView，这复杂的结构是要逆天的。但有可能将会开放一种只积极支持CSS+HTML的WebView，无法运行Javascript。

        研发人员在研发小程序之前一定要预先对那些技术问题做充分的了解，并在结构设计上、机能规划上尽可能将的规避。

        现阶段，你想按照你的UI结构设计去研发，困难不小。有人说现阶段小程序还在内测，未来会有大批的部件出现。会有部件出现我毫不怀疑，但部件的质量怎么样，研发人员的热情有多高，能无法形成一种良好的社区氛围，那些都是未知数。中国能够静下心来做开源的研发人员，吗挺少。

        至于推展效率和采用者以获取上，许多人都认为小程序会有绝对的优势，它处于外部，理应离矛盾链条更近。可至今没给小程序分享的USB，也许以后会给新的USB，也许会将小程序绑定到，借助来散播，也许根本不给小程序提供更多分享的USB。

        谁知道呢？

        APP以获取采用者效率高的一种根本原因是采用者智能手机里的APP已经饱和状态了，我无法拿一种新兴生态环境的采用者以获取效率和一种已经饱和状态的生态环境做对比。当小程序的生态环境也饱和状态的时候，那个效率还低吗？点开你里的下载号，刺目的红色数字有没亮瞎你的眼？而你又认真去阅读的文章有几篇？大批刷来的采用者那不叫采用者，想以获取一种真实的采用者的效率从来都不低。

        这里却是建议各位研发人员，把精力真正的放在商品上，不要一味的盯着着的散播优势和网络平台优势。小程序由于门槛较高，竞争的激烈程度将远超iOS和Android。Web经济发展这么多年, 积累的大批前端人才，极有可能将被这波热潮释放。把精力投入在打磨商品上，结合他们商品的特点适度营销，这才是王道。

        5 下载号、服务项目号、民营企业号、小程序以后会如何经济发展？

        预测一下，订阅号、小程序会并存; 服务项目号和民营企业号会慢慢的消退。

        留存下载号和小程序是因为他们具备不同的特性：下载号具有新闻媒体特性，小程序具有服务项目特性。从现阶段对小程序在散播、分享上的限制来看，小程序就是做服务项目，他不具有很强新闻媒体特性，所以这两个不同特性的“号”应该会共存。

        而服务项目号本身就是个怪胎，是为平衡采用者感受和高级机能的一种中间产物。大多数的新闻媒体、商户、创业团队都同时拥有下载号和服务项目号2个号，用服务项目号的高级USB做服务项目，然后将重定向额外到下载号的模板消息或是菜单中推展，怎么样都能绕开服务项目号的限制。这种的平衡，对研发人员没甚么好处，对采用者来讲，也不见得有甚么感受上的巨大提升。既没下载号的每天能群发一条消息的能力，又不具备小程序接近原生植物的感受（大多数服务项目号的感受真是差差差差差，你不绑定每次进去就要做身份验证，毫无缓存能力，比如招商银行的服务项目号，每次进去都要输入十几位的身份证号或是卡号，你烦不烦？），那服务项目号有甚么存在的价值。小程序完全能融合到下载号中，何苦搞那么多号。当然，马云直接砍掉服务项目号的可能将性不大，那个任务交给研发人员去选择，自然淘汰就能了。

        至于民营企业号，本身价值就在于提供更多了一种便捷的民营企业员工矛盾链导入和管理工具，仅此而已。用过民营企业号的都知道，感受是吗差。本身移动端就只适宜做讯息的展示，不太适宜做讯息的打印，而民营企业号又偏偏有大批的讯息打印操作，操作极度困难。既然民营企业号的价值在于便捷的员工矛盾链管理，那只须要将员工矛盾链对小程序开放，并给民营企业的小程序一种沙箱环境，用小程序取代民营企业号就可以。

        相比于小程序带来的机会与红利，我更认同小程序的经营理念，直观、干净、用完即走。而这恰恰是现阶段网络商品形态所缺少的，也是采用者急需的。小程序在商品经营理念上给我的商品经理上了一课：有时候，少就是多，让采用者触手可及，才能让投资人和采用者站的更近，更容易传递你的商业价值。