React-Native散记

来源:互联网 发布:打印机网络共享设置 编辑:程序博客网 时间:2024/04/30 03:50

关于主流的hybrid框架 (Cordova Ionic React-Native)

1.Cordova  资格比较老  使用js css webView  一般不需要熟悉原生 就可以实现一个app  性能不好  瓶颈就是webView  再4.1以下的环境下性能很差 而且框架比较重  

2.Ionic (基于anglearjs) 性能相对来说比较好  UI非常漂亮 但是 平台特性(ios android) 不明显   而且 基于anglarjs  (1.0 和2.0 不兼容 ) 打包使用的Cordova 也就是构建使用cordova  但是 一般对于web来说DOM树过于复杂的话 那么会造成页面比较卡顿(编写一次处处运行)


3.React-Native(Reactjs)(学习一次处处编写 )构建 打包使用的是原生 (它是将js解析成原生的控件 使用的是js桥协议)此时 js和原生语言的交互 不是使用webView 而是使用JNI(C层)  性能上面更好  最终生成的是原生app 而不是使用web View进行渲染的 但是 再RN上面 是保存平台差异性的 (android ios) 也就是需要在一些控件上进行处理 (platform)



4.RN 虚拟DOM 是Facebook自己的一个算法  使用真实的DOM树 进行全部渲染的话 那么就会造成卡顿  而虚拟DOM通过deep算法 判断虚拟DOM中改变的部分  从而将改变的部分映射到真实的DOM树上  就不用再进行整个DOM树的渲染(降低了性能损耗 突破了DOM树的瓶颈)


国内使用:天猫weex (阿里基于RN开发的 ) 携程 moles框架(携程基于RN开发的) 饿了吗(使用RN和原生进行混合开发) 腾讯(使用RN源码定制开发)进行开发  但是比较重 更新比较麻烦  


RN缺点: android 打包提及过大 解决:官方(高性能的js桥 是通过JNI实现的  也就是要打包出so库  那么就会打出ami-va7 x86等包)根据cpu架构来打包拆分  在谷歌市场能够支持 cpu架构的区分 

            没有1.0release 坑无法避免

            生态未完善  许多组件 自己桥接

            不兼容web 端

            页面降级 (当页面出现错误的时候 如何进行处理) 目前方向 跳转web端  也就是让web来处理 最终能够和web端进行合并处理

0 0
原创粉丝点击