一个网页除了可以运行在公共的浏览器上,也可以运行在 APP 端内的 WebView 组件上。由于这些 Hybrid Web 网页运行在一个相对封闭的环境里,所以 APP 本身可以向 WebView 中注入一些 JS 代码,对 Web 页面做定向增强(最典型的运用就是 JSBridge,提供了一道 Web <--> Native 通信的桥梁)。
英文版本:How to Locate the JS Code Injected into Hybrid Web Pages by Native
一个网页除了可以运行在公共的浏览器上,也可以运行在 APP 端内的 WebView 组件上。由于这些 Hybrid Web 网页运行在一个相对封闭的环境里,所以 APP 本身可以向 WebView 中注入一些 JS 代码,对 Web 页面做定向增强(最典型的运用就是 JSBridge,提供了一道 Web <--> Native 通信的桥梁)。
英文版本:How to Locate the JS Code Injected into Hybrid Web Pages by Native
React Native 开发时,如果只是写些简单的页面,基本上按着官方文档 reactnative.dev就能写出来,但是 React Native 的 API 有几百个,没有一定的开发踩坑经验,面对一些新的需求时确实会抓不到重点。
本文总结了我个人开发 React Native 中遇到的问题和一些冷门的 API,如果有有缘人看到这篇文章并解决了实际问题,那就最好不过了。
上一篇文章主要从 Native 的角度分析了 React Native 的初始化流程,并从源码出发,总结了几个 React Native 容器初始化的优化点。本文主要从 JavaScript 入手,总结了一些 JS 侧的优化要点。
Web 开发有一个经典问题:「浏览器中从输入 URL 到页面渲染的这个过程中都发生了什么?」
据我考据这个问题起码有十年历史了。在日新月异学不动的前端圈子里,这个问题能一直被问,就是因为因为它是个非常好的问题,涉及非常多的知识点,平时做一些性能优化,都可以从这个问题出发,分析性能瓶颈,然后对症下药进行优化。
不过今天我们不谈 Web 的性能优化,只是借助刚刚的那个那个经典问题的分析思路,从 React Native 的启动到页面的第一次渲染完成,结合 React Native 的源码和 1.0 的新架构,探索 React Native 的启动性能优化之路。
在一般的移动端开发场景中,每次更新应用功能都是通过 Native 语言开发并通过应用市场版本分发来实现的。但是市场瞬息万变,Native 语言在开发效率上存在一定不足,并且从 APP 版本更新
到 应用市场审核发布
再到 用户下载更新
,总会存在一定的时间差,这样就导致新的功能无法及时覆盖全量用户。
为了解决这个问题,开发者们一般会在项目里引入一门脚本语言,提速 APP 的研发流程。在移动端应用比较广泛的脚本语言有 Lua 和 JavaScript,前者在游戏领域用的比较多,后者在应用领域用的比较多。本篇文章主要是想探讨一下移动双端(iOS & Android)的 JavaScript 引擎选型。由于个人水平有限,文章总会有遗漏和不足的地方,还请各位大佬多多指教。
本文是我在学习多个平台 UI 框架后的一些感触,受精力和技术水平所限,文中定有不足之处,请各位大佬多多指教
React Native 作为一款跨端框架,有一个最让人头疼的问题,那就是版本更新。尤其是遇到大版本更新,JavaScript、iOS 和 Android 三端的配置构建文件都有非常大的变动,有时候三者的配置文件又互相耦合在一起,往往牵一发而动全身。
文章已于 2022-08-29 更新「图片」优化内容
文章已于 2022-01-22 更新「Fabric」架构章节
文章已于 2021-07-01 更新 Redux 优化内容
2020 年谈 React Native,在日新月异的前端圈,可能算比较另类了。文章动笔之前我也犹豫过,但是想到写技术文章又不是赶时髦,啥新潮写啥,所以还是动笔写了这篇 React Native 性能优化的文章。
本文谈到的 React Native 性能优化,还没到修改 React Native 源码那种地步,所以通用性很强,对大部分 RN 开发者来说都用得着。
产品为了提高推送送达率,提了一个需求:在 APP 推送关闭的情况下显示一个小 TIP,点击 TIP 跳转到 APP 消息设置界面。
我们的 APP 是基于 React Native 开发的,这些功能 Facebook 官方没有提供,需要我们开发对应的原生模块。