
cordova和react-native 底层的实现思路的区别是什么
1个回答
展开全部
cordova当中主要有3者协同工作,一个native runtime,一个js bridge,一个web view。
js bridge为web view封装了一堆native api供调用。
当你只想跑一个普普通通的网页的时候,web view提供的那些浏览器js api就够用了,你调用它们,就只和web view打交道。
而如果你要调用cordova给你封装的那一堆扩展的api,这些调用就最终落实到native runtime上面来实现。
react native中主要也有3者协同工作,一个native runtime,一个js bridge,一个js runtime。
这个js runtime不是web view,你可以理解为它就是个类似于nodejs这类的东西吧,所以它自然也不会有浏览器里那些window/document这类的api。
当你在js runtime里调用native api,比如生产了一个Button,js bridge会把这件事告诉native runtime,native runtime就生成了一个native的Button。
由于两个runtime之间无法直接交换数据,所以js bridge一般会用id mapping方式来实现对象式的试图操作(当然react native是不是这么做的我不太清楚)。
比如,native runtime那边给native Button分配一个id,js bridge就给js runtime这边分配一个具有相同id的“傀儡”Button,这两者就通过这个id关联起来了。
你调用button.show()的时候,js bridge事实上是传递一个,打个比方,{ id: 10, method: 'show', arguments: [] }的消息给native runtime,后者照做就行。
这样做的结果是,你在js runtime里做的任何接口调用,都通过js bridge,落实到native runtime上来实现。
说简单点
cordova对浏览器做了一大堆扩展api,你的程序是一个网页。
react native是在native app里引入了一个脚本语言,只是,这个脚本语言刚好是js,它也可以是lua也可以是别的,你写的程序是js在“遥控”一个native app。
js bridge为web view封装了一堆native api供调用。
当你只想跑一个普普通通的网页的时候,web view提供的那些浏览器js api就够用了,你调用它们,就只和web view打交道。
而如果你要调用cordova给你封装的那一堆扩展的api,这些调用就最终落实到native runtime上面来实现。
react native中主要也有3者协同工作,一个native runtime,一个js bridge,一个js runtime。
这个js runtime不是web view,你可以理解为它就是个类似于nodejs这类的东西吧,所以它自然也不会有浏览器里那些window/document这类的api。
当你在js runtime里调用native api,比如生产了一个Button,js bridge会把这件事告诉native runtime,native runtime就生成了一个native的Button。
由于两个runtime之间无法直接交换数据,所以js bridge一般会用id mapping方式来实现对象式的试图操作(当然react native是不是这么做的我不太清楚)。
比如,native runtime那边给native Button分配一个id,js bridge就给js runtime这边分配一个具有相同id的“傀儡”Button,这两者就通过这个id关联起来了。
你调用button.show()的时候,js bridge事实上是传递一个,打个比方,{ id: 10, method: 'show', arguments: [] }的消息给native runtime,后者照做就行。
这样做的结果是,你在js runtime里做的任何接口调用,都通过js bridge,落实到native runtime上来实现。
说简单点
cordova对浏览器做了一大堆扩展api,你的程序是一个网页。
react native是在native app里引入了一个脚本语言,只是,这个脚本语言刚好是js,它也可以是lua也可以是别的,你写的程序是js在“遥控”一个native app。
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询