原生APP中js怎样与Android和ios进行交互

Posted 2023-04-15

参考技术A 　　从使用场景上，Web App用户面临比原生APP用户更严峻的问题： 　　1、 页面跳转更加费力，不稳定感更强 　　思考点：如何减少跳转(扁平结构、页面布局技巧)，增加数据及展示的流畅流程及稳定性(技术) 　　2、 更小的页面空间(由于浏览器的导航本身占用一部分屏幕空间)，更大的信息记忆负担 　　移动设备的屏幕要小得多。这种如同透过门缝进行的阅读增加了认知的负担。人脑的短期记忆是不稳定的，用户在滚动屏幕的过程中需要临时记忆的信息越多，他们的表现就会越差。——《贴心设计：打造高可用性的移动产品》 　　思考点：排版更清晰、信息更简练 (可在原生APP基础上去掉一些丰富、复杂的视觉表现) 　　3、 导航不明显，原有底部导航消失，有效的导航遇到挑战 　　思考点：如何有效的提供导航?有哪些形式? 　　4、 交互动态效果收到限制，影响一些页面场景、逻辑的理解。 　　思考点：比如登录注册流程的弹出、完成及异常退出，做好文字提示。 　　针对以上困境，解决方法总结如下： 　　首先，从APP到WAP版，在产品上，最明显且核心的： 　　1、 精简功能，只将核心的任务实现，非核心的枝节可考虑删减。 　　2、 做好新的Web App导航. 　　3、 补充从Web App 对 下载原生APP 的引导。 　　一、常见的几种Web APP导航样式 　　1.1顶部底部导航的设计： 　　1.2导航快捷键设计： 　　美团：顶部栏固定位置 　　淘宝：悬浮圆圈–可的按钮 　　优酷：非首屏时页面右侧悬浮 　　二、有效的导航设计 　　1、 基本的快捷导航中包括 返回常用页面(如 首页 我的 等)的快捷方式 　　2、 出现深层架构时 及时补充返回重要层级页面的快捷方式 　　3、 情境式导航，方便用户快捷跳转到ta想去的页面，如购买结束时提供查看订单详情的按钮。 　　PS：Web APP更加需要画页面跳转的流程图，摸清各个页面的入口，尤其是页面返回的流程;有些简化的返回按钮，可以特殊注明返回到的页面 　　在哪里出现引导？ 　　一般首页、核心任务的页面(如 电商Web APP的商品详情页 、视频Web APP的视频观看页) 　　二、引导下载APP有哪些形式? 　　页面顶部放置下载条 　　页面底部悬浮层引导 　　融合在页面首屏中 　　下载按钮形式 　　底部Foot里含客户端下载入口 　　其次，在设计Web App时，有以下小技巧可以参考： 　　1、 从页面布局上减少跳转：使用交互技巧隐藏文字(eg 腾讯视频) 　　利用收起按钮 减少页面跳转。 　　2、 取消float浮层，增大展示空间(eg：大众点评) 　　取消float浮层，同时在详情尾部再次加上 “购买”按钮。 　　浮层的转换处理。 　　3、 页面中对图片进行缩小(因情况而异)的处理、精简一些标签导航的视觉展示。 　　视觉微调。 　　技术上注意点： 　　1)各手机浏览器的兼容测试 　　2)底层服务的调取(能调取，但只有当其是核心功能时才保留 eg：新浪、美团等皆去掉了头像上传功能) 　　3)注意离线数据存储，减少数据请求频率。 　　4)考虑保存用户的哪些数据：设置、个人数据、阅读锚点、跳出页面等。 　　5)避免动效与浏览器的交互冲突 　　6)按顺序 异步加载 eg： 腾讯视频 　　腾讯视频异步加载。 　　虽然Web App目前处于比较尴尬的地位，我们是由于原APP客户端中一些页面需要分享出去才开启制作Web App版。 　　但是不得不承认，基于Web的轻APP 更新迭代起来更方便，随着H5技术的成熟和发展，也许以后就是基于H5的Web App的天下了 0.0 参考技术B 定义接口

Flutter 与 iOS 原生 webView 对比

参考技术A

本文对比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加载速度，内存使用情况。

测试网页打开的速度，只需要获取 WebView 在开始加载网页和网页加载完成时的时间戳，时间戳的差即为打开网页的时间

为了使差异更明显，我们选择较为复杂的 新浪首页 进行加载的对比，为了减小网络对加载速度的影响，我们让手机连接同一个网络，分别进行 10 次测试然后取平均值，另外，我们需要关闭 WebView 的缓存，防止缓存对加载速度产生影响

下面使笔者进行 10 次测试所得到的数据

结果让我有点惊讶，一直以为 WKWebView 会是个王者。结果看，速度上 WKWebView 略慢一点，不过总体差异不大（该结果仅仅是测试新浪的结果，仅供参考啦）

在这里，笔者又加了一个测试，尝试记录从 viewController 的 viewDidLoad 到 webview 的 didFinish 时间，测试了新浪的数据，如下：
UIWebViewA ： 4970、3808、3815、4250、3556 avg(4079.8) （加载完所有页面）
UIWebViewB ： 4103、3124、3070、3256、2835 avg(3277.6)（加载sina完毕）
WKWebView ： 3672、3032、2892、2912、2739 avg(3049.4)
flutter_webView ： 4532、3901、4310、3496、3378 avg(3923.4)

其中可以看到，webView 有两行，UIWebViewB 的数据就是加载 sina 主站的时间；UIWebViewA 的数据是因为在加载完 sina 主站之后，新浪又加载了一个 https://r.dmp.sina.cn/cm/sinaads_ck_wap.html ，所以导致总时间延长，不过即使按照 UIWebViewB 的数据来比较，也是 wkWebView 略胜一筹。
此处可以看出 flutter_webView 使用的是 wkwebView，所以它吃亏的主要原因是 flutter 包了一层。

结论：
速度（didStart -> didFinish） UIWebView > flutter_webview > WKWebView
速度（viewDidLoad -> didFinish）WKWebView > UIWebView > flutter_webview

这里查看内存使用的是 xcode 的 debug session 中的 memory。

首先看之前测试时，连续打开十次新浪的内存情况

接着我们在看一下打开淘宝首页的内存情况

从图上可以看出，WKWebView 在内存方面有很大的优势啊，UIWebView 的内存是真的伤啊，然后 debug 看了一下 flutter_webView，他使用的就是原生的 webView 。
他相比较原生 WKWebView 的内存开销稍大一点，从测试表现来看，一般大个 30 MB 左右。

结论：内存 WKWebView > flutter_webview > UIWebView

可以在 html5test 中对浏览器的兼容性进行评分，通过测试发现得分分别如下

因为 flutter 里使用的就是 WK，所以和原生的 WKWebView 一样都是 444 分，比 UIWebView 的 437 略胜一筹

结论：兼容性 WKWebView = flutter_webview > UIWebView

UIWebView : 速度相比较 WKWebView 稍快一点，但是内存是一大硬伤，所以只要条件允许，就不推荐使用了
WKWebView : 速度略慢一点，不过差别不大，总体可以接受。是比UIWebView更好的选择，推荐使用。
flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以总体和 native WKWebView 表现差不多。如果是混编项目中，因为它被包了一层，所以页面加载上存在一定的劣势，所以混编项目中仍然推荐使用 WKWebView。不过如果从多端考虑、以及项目可迁移等，那么使用也未尝不可，就是维护成本要增加一些，需要维护两套 webView。这个就需要根据自己的情况自己取舍了。