小程序技术全解| 青训营笔记

104 阅读5分钟

这是我参与「第四届青训营 」笔记创作活动的第15天。

小程序技术全解

一:发展历程

17、18年是小程序的发展初期,这个阶段最早由微信开始进行探索。17.1小程序正式发布, 这个时候小程序就有了很高的关注度,但这个时候还没有完全对个人开发者开发,到3月份,小程序正式面向个人开发者开放,自此,小程序数量进入爆发期。

4月份最重要的带来了称为小程序码的新型图形码,为什么说小程序码很重要。因为它的到来真正能够让线下场景和线上小程序沟通串联起来。

9月份支付宝小程序也开始了公测,标志着各大厂竟相进入到小程序领域开始竞争,因为围绕着小程序各大超级app能够构筑和丰富独属于自己的生态。

12月份轻度游戏,小游戏上线,跳-跳风靡一时,不知道大家都有没有玩过进入18年,小程序在1月份带来了打开app的能力,这也标志着小程序为其他弓|流功能的功能开放。

同时在18年,百度小程序,qq小程序、头条小程序(现在叫字节小程序), 都相继上线。“巨头‘都加速布局小程序生态19年, 小程序被纳入腾讯最高战略,同时微信为小程序带来更加丰富的入口,开放更多的流量,如,微信主页下拉出现小程序桌面,微信搜索也可以搜索到小程序,同时微信公众号也可以自由挂载小程序,这些入口意味着更多的场景渗透。

9月份,小程序开放贴片广告,正式开始商业化建设,其实对所有企业来说所以业务最终都是为了赚钱嘛。随着小程序越来越复杂,小程序包4M的限制越来越无法满足,所以在11月份小程序开发包的总包上线上升至12M,让开发者能够构建更加复杂的小程序应用。

进入2020年疫情的出现也加速了各种小程序的出现,同时微信为小程序赋予了直播和小商店更多的属性,为小程序的商业化带来更多的可行性。后面的就不说了,总之就是越来越多的场景,小程序整体也逐渐发展的越来越成熟

二:业务价值

1.      与Web的区别

  1. 有精固定的语法以及统一的版本管理,平台可以更方便的进行审核
  2. 平台相够控制各个入口,如二维码,文章内嵌,端内分享,入口上也组带来更好的用户体验
  3. 小程序基于特殊的架构,在流畅度上比WEB更好,有更优秀的跳转体验

2.      三大价值

  1. 渠道价值:由于小程序的便捷性,依托于超级平台小程序能够充分为很多场果导流如美团和美团优选微信小程序带来的流量占比分别是40%和80%
  2. 业务探索价值:相比原生APP未说,小程序的开发难度和成本却降低的很多。这就创造了很多场最开发者能够用小程序未快连试错,不断探索新的业务价值
  3. 数字升级价值:线下到线上如何做?从轻消费关的快餐、系饮到地产汽车等大宗消费,小程序都展示了良好的容常空间。我们线下场景的小程序覆盖范田很广。

三:技术解析

1.      第三方开发应用最简单最方便的方式是webview(渲染层)和jsbridege(逻辑层)

webview我们可以简单理解为app内置的浏览器,我们可以在app内展示网页,但是除了web本省,我们想让开发者能够通过js调用更多app上的功能怎么办App_上的功能比如打开相机,打开地图等,这些单靠web api本身做不到,这就需要泳道我们的jsbridege了 ,顾名思义jsbridege就是js和native代码之间的桥梁,让两者能够沟通相互调用,实现jsbridge的方式有很多,如代码注入,url拦截等

2.      需要设计一种新的方案。

(如果卡,就是数据传递这个方面的问题)

方案特点:

a)      开发门槛低:大部分开发者都会,并且很容易学习的技术。没错就是我们的前端三板斧(HTML+css+JS)。

b)       接近原生的使用体验:资源加载+渲染+页面切换

c)        安全管理:独立JS沙箱

3.      小程序语法:

a)       TTML:

<view

    tt:for="{{list}}'

    tt:if="{{isOpen}}"

    bindtap=" onTap"

/>

b)       JS:

Page({

    data: {

        list: ["a""b""C"],

        isOpen: true;

    }

    onTap: function( ) {

        console.log( 'tap me!' )

    }

})

c)        TTSS:

view {

    backgroud-color :“red";

    width: 750rpx;

}

 

四:相关扩展

1.      跨端框架:复杂应用构建:一次开发可以跨多段

2.      跨端框架原理:

编译时:

<View>{ foo ? <View /><Text /> }</View>

<view><block tt: if={ foo}><view /></block><block tt:else><text /></block></view>

编译时方案有个天然的缺陷,无法完全抹平差异,不论是React和vue等各种框架,它们的用法都十分多样,而且会不断添加新的特性,而小程序本身确有很多的限制,那么在转换过程中,很多特性没有办法进行转换,所以就要给框架的书写代码的时候加上很多限制,这背离了我们的初衷,所有现在更多的方案采用运行时的方案。

运行时:使用的是虚拟DOM和Template