2016 - 2024

感恩一路有你

reactnative 在桌面创建快捷入口 一个小程序的实施技术方案?

浏览量:3194 时间:2023-05-16 20:01:31 作者:采采

一个小程序的实施技术方案?

小程序下线大半年,大部分技术原理也有文章能介绍了,本文尝试从需求出发探讨一番小程序技术方案的来源,以及最近不删档测试的支付宝小程序技术方案的考量。

小程序

小程序的需求是让第三方开发者可以接入,也可以可以使用的能提供的接口去开发应用贴入在里。对于这个需求,最简单的实现方案是:让外部开发者开发纯H5应用,在的H5容器里打开,容器能提供接口,就行了。在有小程序之前,早就有很多这样的业务接入,像京东购物,钱包里的各种友商大众点评/滴滴出行等,都这个可以如果说是一个“小程序”,内嵌在里,能调用接口,你是不是沿着这种模式下去,把相应的接口开放给第三方,再提供个入口就行了?

实际上这种简单点方案没法满足用户的需求,在产品上小程序有另外两个很重要的是的需求:

管控。充当一个平台要对接入到的应用有管控能力,要能不要精确控制应用的内容和类型,毕竟若又出现非法经营应用平台是要承担部分责任的,H5的极为自由,开发者是可以时刻改变整个应用的内容,平台未必能可以检测到这些改变,根本无法管控。另H5开发质量参差不齐,平台也根本无法管控,这相对于从来有洁癖的来说都无法接受。

体验。另外一个“小程序”要让想体验逼近原生,而上述像京东购物这些普通H5页面的可以体验不太行,和启动速度/页面切换流畅度都是问题,跟原生体验没法比。

所有小程序的技术方案全是是为这两个需求服务。

管控

为了满足管控的需求,技术上做了两个事情:小程序框架和只是分离JS运行环境。

框架/DSL

H5太自由,简单要做的那就是没限制它的自由,怎么才能限制修改?肯定是做个框架栓住,让开发者没有办法按框架的规则去开发。那应该是使用怎样的框架?

在PCSNS时代,Facebook做开放平台时有类似的场景,就是为了第三方开发者能在Facebook平台上开发,同样的又能取消住开发者的权限,Facebook具体的要求开发者在用下拉菜单的一套DSL(FBML)去开发,而这个DSL能怎莫写,结果能转成什么,该如何执行,大都平台说了算,同样的也可以不很方便做代码扫描和审查。

小程序趁着能广泛借鉴这样的设计思路,界面不不使用HTML开发,只不过是选项卡一套DSL,这样的就可以很容易对付审核/代码扫描/域名限制等系列措施做个管控,这是小程序这一套框架的来源。这套框架按照wxml去具体描述界面,wxss具体解释样式,js去处理逻辑和数据,再是从工具一系列如何处理把这些转为HTML/CSS/JS没显示在webview上,并处理界面交互和数据更新。

这样的话用一套框架去限制修改开发,再造一层DSL,以外管控外也有一个好处,那是容易通过针对性优化,DSL结果转成什么,到最后如何负责执行渲出都由框架确定,上层不感知,可以可以做成由webview颜色渲染,有条件也这个可以用类似于RN的方案自己利用软件渲染层。

JS环境

按照框架限定开发后,管控上还有个问题,应该是该如何限制修改运用端类JS语言动态链接库domAPI?小程序跑在webview上,软件渲染时势必要实际JS操作dom,假如小程序框架和应用JS代码应该有权限操作dom,应用很可能会通过各种在下线后绕到检查,融入JS全局函数dom接口去如何修改页面结构和内容,变成跟审核时不一样的的应用。怎么样才能能限制应用形式的JS调用dom的权限?想了个都很创新和改革的解决方案,那就是:JS运行环境与浏览器再分离,不运行在不能的JS引擎上。

逃出了浏览器,JS也就没有dom的动态链接库权限,任何跟webview界面相关的API都不能拿到。而小程序框架核心JS运行在webview上,也可以神圣你操作dom,按照小程序框架符号表示的机制,应用端按照wxml/wxss定义且固定的3d渲染样式,JS端只管开口数据手机绑定,数据也可以实际framework桥梁从JS引擎传递到webview,JS端难以做任何颜色渲染相关的你操作,可以对渲出的内容有完整的管控权。

的的的JS运行环境以外满足的条件管控需求外,也附加给予一些好处和一些坏处,好处本质:

多个页面这个可以宽带共享一个JS运行环境,数据这个可以很比较方便地网络共享,整个小程序生命周期里网络共享同一个上下文,更距离APP的开发体验。

JS与页面颜色渲染分离左行不能执行,不会再次出现JS不能执行时卡住页面渲出的情况,提升到渲染性能。

坏处取决于人:

多了数据序列化传输的开销,数据需要从JS传到webview给视图层软件渲染,不需要序列化为字符串格式再接受传输。

iOS上WKWebview的JS引擎比JavaScriptCore多了JIT优化,执行速度快很多倍,小程序的JS不运行在JavaScriptCore上根本无法享受啊到这个优化。

的原因管控需求实在是太刚需,这个方案给予坏处可以不认可。

体验

小程序最主要的两个技术点—框架和JS正常运行分离的过程都是源于管控需求,而体验上的需求就是由各种细致的性能优化排成了,很多文章也结论过,这里简单的说下,除了:

离线状态包:整个小程序打包下发通知,不必须再打开每个页面都去只是请求,减少俩次再打开时间以及页面切换时间。

预加载:预加载多一个wkwebview放后台,用户可以打开小程序时会省系统初始化wkwebview时间。别外对于一个小程序内的页面可以切换,得益于框架的设计,是可以做到预软件渲染模板,切换到时再图案填充数据,加快渲出速度。

缓存:退出小程序后不会立马全部销毁,会在后台再跑5分钟,期间用户切回小程序时速度快。

视觉:小程序榜首次打开程序按照loading和动画的过渡,回绝白屏,给人种快的感觉,同样提升到了小程序的标识度。

只剩的应该是不断小程序这个平台的周边建设和发展了,像组件,native接口,IDE,后台管理,版本管理,权限控制等基础支持。

支付宝小程序

策略

小程序会推出时主要注意面向的场景是线下,如果能商家能开发小程序,做像服务员上菜去买票这样的即时性应用,提升线下商户体验,支付宝作为线下战场的要注意竞争对手也就要再跟踪。

支付宝去做小程序应该怎样做?可以据自身的情况,定义另一套技术体系,让第三方接入。但这样的话第三方如果没有要同样接入和支付宝,需要变更土地性质两套程序,成本很高,而有去发和平台优势,很可能会变得只变更土地性质小程序而放弃你接入支付宝小程序,所以建议的做法是降低这里的接入成本,让小程序的代码是可以并行化在支付宝小程序上。所以小程序接合的框架/API/组件要是跟小程序逼近或追求精益求精一致,技术上没得你选,因为看的到支付宝小程序公测版的文档很多跟一致。

基于

支付宝小程序框架正式接口是跟一样的,又毕竟同样有管控/安全和想体验的需求,有些策略是相似的,像相当于JS环境,不联网包,缓存策略等,但在小程序框架的实现上就跟彻底不一样。小程序框架才是一层屏蔽了基于细节的DSL层,最终实际什么技术手段实现程序都是可以是由框架底层自由设计定制的,这边技术底层基于组件蚂蚁前端团队多年的积累,到了最后web版小程序是以react为基础实现方法。

React Native

除了作为的跟完全不同的web版小程序,内部总是在一段时间React Native版小程序,软件渲染层不可以参照webview,只是用RN去颜色渲染,提升性能和体验,这都是小程序DSL层用处,底层渲染引擎这个可以很方便啊地替换实现方法方案,甚至同时存在多套方案。

很多人问为么用不着weex,按我再理解简单的方法是蚂蚁的前端技术栈基于条件react,直接切换成本高,一个RN相对weex成熟度高,社区允许度高,并保持着不间断的更新,相对于敌视。

RN本身不基于浏览器,iOS/Android有各自的写法,在RN的使用上,业界很多人各自实现方法了实现RN的跨三端或两端的开发(的或JDReact),也就是第二次开发,能另外接受RN在iOS/Android平行放置做原生软件渲染,也支持什么fallback到webview3d渲染。这里小程序也算得这样的话一套方案,上层实际自定义设置DSL开发业务,作战部署时通过工具分别转换的成三个平台相同的代码,在三个平台运行。

内部应用

小程序是一套联合的方案,要注意应用于第三方应用接入,毕竟上文也说了,框架上很多技术方案也是是为满足对第三方管控和安全方面的需求,而小程序相关的很多亲身体验系统优化其功能强大纯H5也可以不做到,内部业务用web版小程序开发完全没有受到什么好处,反到增强学成本。但RN版小程序不一样的,它有一些优势,除开:

RN要比webview性能优势明显,秒开率高,交互也更流畅的体验。

相对于前者建议使用RN开发,在用小程序也可以被屏蔽平台差异,实现方法跨平台一次开发。

小程序有设配的开发环境/IDE/包管理等基础设施意见,无需再反复重复建设。

这对业务开发者,小程序也不是全新的一套开发,在业界可复用,对于框架利用者,RN都是业界流行开源方案,有强大的社区支持。对内对外都尽量的避免了另外创建一套只能在内部不使用的技术体系,如此大减低技术成本。

基于条件这些原因,在腾讯理财通这边一些内部此刻估计可以使用H5实现程序的业务,也正一段时间更多地可以使用小程序实现程序,以提升用户体验,目前部分设计和实现小程序RN版开发的业务已大侠帮帮忙上稳定运行,情报营也会再继续接触把小程序RN版坚持了打造成高性能稳定的三端统一动态化方案。

JavaScript、nodejs和reactjs以及react、react native是什么关系?

Javascript是电脑语言。

node.js是这个可以在服务器上在用javascript的开发环境,设计和实现google的v8,用c写的。

React.js是一个前端的模板(也不是库)用javascript写的,可在遊览器和node.js下不运行。

NativeScript是在手机上可以用Javascript做APP开发,由几种相同语言书写(看运行平台)Java,Objective C,swiftetc.

程序 框架 方案 JS 开发

版权声明:本文内容由互联网用户自发贡献,本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。