ios js交互

移动端APP热更新方案(iOS+Android)

我与影子孤独终老i 提交于 2020-03-30 07:17:53
出自:http://www.cnblogs.com/Creator/p/7007694.html 为什么要做热更新 当一个App发布之后,突然发现了一个严重bug需要进行紧急修复,这时候公司各方就会忙得焦头烂额:重新打包App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装。 重点是还会有原来的版本遗留,无论你怎么提示都有人放弃治疗,不愿意升级,强制不能使用体验又足够糟糕到让人不能启齿。 如果这是一个影响公司收入或者体验影响极其不好的Bug,那完蛋了,可能公司老板会对整个技术团队的技术能力丧失信心,其对技术人员的伤害是致命的。 最后最致命的是: 有时候仅仅是因为不小心写错了一行代码,就让所有的加班都付之东流,苦不苦,冤不冤,想想都苦。 还有一种剧情是研发总监把锅甩给测试团队,测试不过关,测试摊摊手说我也不是神啊,总会有漏网之鱼. 那能不能神不知鬼不觉再没有产生较大影响前把bug快速修复了呢? 热更新的行业情况 先来说说Android 并不是因为Android更有料就先说他,而是它的用户量级比Iphone大,我们写文章也是讲究大数据分析的不是.. Andoid端在15年热补丁就比较火,先后出现了Dexposed、AndFix,Qzone超级补丁的类Nuwa方式,微信的Tinker, 大众点评的nuwa、百度金融的rocooFix,

iOS:OC与JS交互

廉价感情. 提交于 2020-03-12 08:09:04
目的是为了在webView页面截取到js操作,然后跳出到本地进行处理 第一种方法:使用原生的处理方式 1.下边是本地的 a.html 的源代码 <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"/> <meta http-equiv="X-UA-Compatible" content="IE=edge"/> <meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no"/> <script> function test() { alert('clicked'); } function testParams(a, b){ alert(a+b); } </script> </head> <body> <button onclick="test()">点击我</button> <button onclick="testParams('hello', 123)">点击我(带参数)</button> </body> </html> 2.导入JavaScriptCore.framework,在需要调用的web页面加上头文件#import

iOS下JS与原生的交互一

让人想犯罪 __ 提交于 2020-03-11 12:21:04
本篇主要讲的是UIWebView和JS的交互,在下一节会有wkWebView和JS交互的详解https://www.cnblogs.com/llhlj/p/9144110.html JS调用原生OC 方式一:url拦截,这里略过 注意:在iOS中拦截到的url scheme将全部转化为小写; html中需要设置编码,否则中文参数可能会出现编码问题; JS用打开一个iFrame的方式替代直接用document.location的方式,document.location 有一个很严重的问题,就是如果我们连续 2 次改 document.location 的话,在 delegate 方法中,只能截获后面那次请求,前一次请求由于很快被替换掉,所以被忽略掉。 方式二:通过JavaScriptCore(iOS 7之后),用来做JS交互,因此JS与原生OC交互也变得简单了许多。 //获取js上下文,及本地添加js调用方法,一般情况下都放在-(void)webViewDidFinishLoad:(UIWebView *)webView方法里。 -(void)webViewDidFinishLoad:(UIWebView *)webView{ //获取js上下文 self.jscontext = [webView valueForKeyPath:@"documentView.webView

Unity3D开发之unity和js通信交互

廉价感情. 提交于 2020-03-11 02:30:54
自己虽然最开始弄的就是webgl但是一直比ios和安卓记录的都要晚,因为一直没想到,所以这里结合某个博客加上自己的经历记录一下 一.老版方法 unity发布webplayer平台后会输出html和unity3d文件。我们的程序主要被打包在unity3d文件里,而html则是网页的界面显示。 1.Unity发送消息给JS unity想要和js交互,提供了一个函数:Application**.ExternalCall()**;此函数仅限于webplayer平台下。我们编辑发布的html文件,在里面加入我们的js脚本如下: function GetID ( id ) { alert ( "传入id:" + id ) ; } 在unity里我们在start函数里调用 Application . ExternalCall ( "GetID" , "吴彦祖" ) ; 使用浏览器打开html文件,就会出现如下弹窗: 2.JS发送消息给unity 我们在刚才的js函数里添加一句代码: function GetID ( id ) { alert ( "传入id:" + id ) ; //发送消息给unity 第一个参数:挂在脚本的物体 第二个参数:unity被调用的函数 第三个参数:函数传入的参数 u . getUnity ( ) . SendMessage ( "Main Camera" ,

WebViewJavascriptBridge详细使用

旧街凉风 提交于 2020-03-03 02:17:48
WebViewJavascriptBridge详细使用 源网址: https://www.cnblogs.com/jiang-xiao-yan/p/5345755.html 前言 WebViewJavascriptBridge是支持到iOS6之前的版本的,用于支持native的iOS与javascript交互。如果需要支持到iOS6之前的app,使用它是很不错的。本篇讲讲WebViewJavascriptBridge的基本原理及详细讲讲如何去使用,包括iOS端的使用和JS端的使用。 经过多番百度、Google,发现WebViewJavascriptBridge的资源讲解不是翻译官方文档就是直接说官方提供的demo。但是笔者在写这个demo时也遇到了不少问题,也想看看大家是怎么使用的,特别是JS端,弄了好久都没有回调,原来是因为log。 写下本篇文章,希望大家少走弯路吧! 本Demo效果图 iOS与H5交互的方案 纵观所有iOS与H5交互的方案,有以下几种: 第一种:有很多的app直接使用在webview的代理中通过拦截的方式与native进行交互,通常是通过拦截url scheme判断是否是我们需要拦截处理的url及其所对应的要处理的功能是什么。任意版本都支持。 第二种:iOS7之后出了JavaScriptCore.framework用于与JS交互,但是不支持iOS6

iOS中UIWebView使用JS交互

喜夏-厌秋 提交于 2020-02-29 11:23:57
iOS中偶尔也会用到webview来显示一些内容,比如新闻,或者一段介绍。但是用的不多,现在来教大家怎么使用js跟webview进行交互。 这里就拿点击图片获取图片路径为例: 1.测试页面html <!doctype html><html> <head> </head> <body> <div> <img src="test.png"/> </div> </body></html> 2.然后我们在controller中加载这一段html [_webview loadRequest:[NSURLRequest requestWithURL:[[NSBundle mainBundle]URLForResource:@"work" withExtension:@"html"]]]; 3.可以看到,这里只显示一张图片 4.加载相关js文件,命名为test.js function setImageClickFunction() { var imgs = document.getElementsByTagName("img"); for (var i=0;i<imgs.length;i++) { var src = imgs[i].src; imgs[i].setAttribute("onClick","click(src)"); } document.location = imageurls

H5与Native交互之JSBridge技术

谁说胖子不能爱 提交于 2020-02-27 06:17:55
一、原理篇 下面分别介绍IOS和Android与Javascript的底层交互原理 IOS 在讲解原理之前,首先来了解下iOS的UIWebView组件,先来看一下苹果官方的介绍: You can use the UIWebView class to embed web content in your application. To do so, you simply create a UIWebView object, attach it to a window, and send it a request to load web content. You can also use this class to move back and forward in the history of webpages, and you can even set some web content properties programmatically. 上面的意思是说UIWebView是一个可加载网页的对象,它有浏览记录功能,且对加载的网页内容是可编程的。说白了UIWebView有类似浏览器的功能,我们使用可以它来打开页面,并做一些定制化的功能,如可以让js调某个方法可以取到手机的GPS信息。 但需要注意的是,Safari浏览器使用的浏览器控件和UIwebView组件并不是同一个

OC与JS的交互(iOS与H5混编)

给你一囗甜甜゛ 提交于 2020-02-10 07:05:47
大神总结WKWebView的坑: https://mp.weixin.qq.com/s/rhYKLIbXOsUJC_n6dt9UfA 在开发过程中,经常会出现需要iOS移动端与H5混编的使用场景。 iOS中加载html网页, 可以使用UIWebView或WKWebView. 本篇博客将介绍两种控件使用过程中如何实现OC与JS的交互。 UIWebView delegate 协议方法 //网页即将开始加载 - (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType; //网页开始加载 - (void)webViewDidStartLoad:(UIWebView *)webView; //网页加载完成 - (void)webViewDidFinishLoad:(UIWebView *)webView; //网页加载失败 - (void)webView:(UIWebView *)webView didFailLoadWithError:(NSError *)error; //UIWebView自带了一个方法, 可以直接调用JS代码(转化为string类型的js代码)

React-native 跨平台原理

你说的曾经没有我的故事 提交于 2020-01-28 12:25:52
1、为什么React native 可以跨平台 其实通过react native的架构图就明白了,下面我们就根据架构图来理解一下为什么react native可以实现跨平台: (1)、React:不同平台上编写基于React的代码,“Learn once, write anywhere”。 (2)、Virtual DOM:相对Browser环境下的DOM而言,Virtual DOM是DOM在内存中的一种轻量级表达方式(原话是lightweight representation of the document),可以通过不同的渲染引擎生成不同平台下的UI,JS和Native之间通过Bridge通信。 (3)、Web/iOS/Android:上层与用户交互的UI界面。 React-Native在JavaScript中抽象操作系统原生的UI组件,代替DOM元素来渲染,使用的是Android或iOS的本地控件,所以在UI渲染上已经非常接近Native App了。尽管业务逻辑代码使用JavaScript,但由于JavaScript是即时编译的,也就是第一次使用时会将JavaScript代码编译成二进制文件,所以JavaScript得运行效率比较高。因此,React Native的运行效率要比基于HTML5、CSS等技术的PhoneGap、AppCan高很多

WebView性能、体验分析与优化

我怕爱的太早我们不能终老 提交于 2020-01-09 01:03:26
在App开发中,内嵌WebView始终占有着一席之地。它能以较低的成本实现Android、iOS和Web的复用,也可以冠冕堂皇的突破苹果对热更新的封锁。 然而便利性的同时,WebView的性能体验却备受质疑,导致很多客户端中需要动态更新等页面时不得不采用其他方案。 以发展的眼光来看,功能的动态加载以及三端的融合将会是大趋势。那么如何克服WebView固有的问题呢?我们将从性能、内存消耗、体验、安全几个维度,来系统的分析客户端默认WebView的问题,以及对应的优化方案。 性能 对于WebView的性能,给人最直观的莫过于:打开速度比native慢。 是的,当我们打开一个WebView页面,页面往往会慢吞吞的loading很久,若干秒后才出现你所需要看到的页面。 这是为什么呢? 对于一个普通用户来讲,打开一个WebView通常会经历以下几个阶段: 交互无反馈 到达新的页面,页面白屏 页面基本框架出现,但是没有数据;页面处于loading状态 出现所需的数据 如果从程序上观察,WebView启动过程大概分为以下几个阶段: 如何缩短这些过程的时间,就成了优化WebView性能的关键。 接下来我们逐一分析各个阶段的耗时情况,以及需要注意的优化点。 WebView初始化 当App首次打开时,默认是并不初始化浏览器内核的;只有当创建WebView实例的时候,才会创建WebView的基础框架。