神刀安全网

要不是因为苹果,混合应用开发将完胜 Native

在过去的 6 个月里,我一直在开发 Rizer。这是个手机应用,它让用户给各种分类(目前有动物、小孩、食物、搞笑、男人、自然和女人)的照片 PK 赛评分,用户也可以提交自己的照片到这些分类里,让别人评分。照片采用 ELO 算法来排名(就是 电影《社交网络》里介绍FaceMash网站的场景中Eduardo Saverin 在窗户上画的那个公式),评分最高的将出现在 Rizer 的排行榜上。

Rizer 是一个混合应用,采用 Apache Cordova开发, 通过它上面大量的 native 插件来获取用户设备上的重要的原生功能,例如推送通知、用相机拍照以及进行应用内购买。

要不是因为苹果,混合应用开发将完胜 Native

目前我霸占了男人排行榜😎

一开始,一般用户并不知道 Rizer 是混合应用,这对我来说至关重要。这意味着它必须设计良好,性能出色 (嘿,performant不是个英语单词),不缺少用户会对此类应用期望的任何原生功能,并且当设备失去网络连接时不至于无法使用。幸运的是,根据我的40名亲友做beta测试的反馈,我实现了这个目标(我甚至可能都同意他们的看法了)。

如果你不相信我,或者你已经玩过一阵子混合应用,那么我推荐你去下载 Rizer,给照片比赛评分,看看排行榜上的一些分类,并且如果你有勇气的话,上传一些自己的照片。体验完后你很可能会被混合应用的能力所折服,如果没有,那至少也欣赏了一些可爱的动物和小宝贝。

毫无疑问,转向混合应用是绝大多数应用的正确选择

理解以下三个关键点非常重要:

  • 一个应用的混合版本一定不会跟原生版本一样快,但这无关紧要,只要混合版本足够快。 简单来说,如果你的用户从来不抱怨应用的性能,那么你的应用就是足够快的。作为一个性能狂,知道自己的应用运行得尽可能地快,我理解这种吸引力,但是我们必须小心避免过早发生和过度优化。知道自己的原生应用在页面上渲染 100 张照片比混合应用版本快 8 毫秒,内心可能自我感觉良好,但用户能感觉得到或者在乎吗?不会。

  • 非常耗资源的 3D 游戏或类似的东西,不在我定义的 “应用”范围内。 这种情况下原生应用当然是你的最好选择,因为混合应用想要变快会非常吃力。Canvas 的性能在最近几年已经改善了很多,但是在旧设备上运行耗资源的应用还是会很慢。

  • 设计良好的混合应用,在现代 JavaScript UI 框架上运行,绝对够快。性能差不再是放弃混合方式的借口了。如果你最近尝试做一个混合应用,发现性能不够满意,那你应该认真重新评估一下你选择的设计模式,或者是用了大量像 jQuery 这样不需要的库。学习下现代的 DOM API,如果还没学的话。我们的应用的所有的目标设备都支持它。

混合方式有一些主要的优势:

  • 你可以利用现有的 JS,HTML和CSS技术开发一套代码,可同时运行在 iOS 和 Android 上。这是混合应用最明显的优势,但也不能过分强调。在我的项目中,需要根据运行的平台来写分支代码的次数不超过十次(这只是为了解决一个 iOS 上的 bug,后面再详细说)。代码里的分支看起来像这样:
if (device.platform === "iOS") {   doRidiculousWorkaround(); } else {   doThingThatWorksAsExpected(); }
  • 开发阶段在设备上查看变动几乎是瞬时的。整个开发过程中,我在自己的 Galaxy S7 Edge 上测试了所有代码改动。这个手机连上我的电脑,启用 USB 调试模式,运行 Rizer 的 debug 版本。在 Chrome 地址栏输入 chrome://inspect/#devices ,你会看到连接到你的电脑的设备上运行的所有 Chrome 标签页。点击列表里的 Rizer 页面,将会打开一个开发工具窗口,我就可以完整地分析 App 了,就像调试一个普通网站一样。这个功能加上构建系统里的 live reload 工具,我就可以在改动代码后几秒内在设备屏幕上看到更新后的结果了。棒呆。

  • 你可以把更新后的 JS,CSS,HTML,字体文件和图片直接推送给用户,无需重新编译 App 的二进制代码,也无需 App store 的审核。Rizer 使用了 微软的 CodePush 服务(目前免费)以及它的Cordova 插件,每次启动时用来检查更新,说实话没有它我都不知道该怎么做。或者, Ionic 的 Deploy 也可以用同样的方式使用,但是因为它不免费并且我没有用 Ionic,没理由去用它。

  • 你可以选择自己最喜欢的 UI 框架和构建工具。 Rizer 运行在我自己的前端框架 Samson.js上(别去用这个,它没有文档,并且为了满足我个人的需求经常变化),但我本来也可以用 React,Vue 或者 Ionic/Angular 来开发。

“哇,Sam,那些优势听起来好赞!那有什么缺点吗?”

混合应用方式有一个主要的缺点:

  • 作为开发者,我们仍然需要操心 iOS,也就是说我们不得不忍受苹果的那些狗屎。嘿,还押韵呢。

你可能会困惑。即使选择原生方式,我们仍然要操心 iOS,因此也要忍受苹果的那些狗屎。对吧?

还真是。

无论采用哪种方式,我们都无法避免苹果的这些狗屎:

  • Xcode

  • 配置文件

  • 需要一台 Mac 来编译 App

  • 需要使用 TestFlight 构建 beta 版本

  • App 审核流程 不可否认,app 审核时长已经缩短到平均 2 天,但是当你的 app 像 Rizer 一样被拒 7 次(因为一些愚蠢的理由),你的耐心真的会磨没了。

除了以上几点,混合应用还要处理这坨狗屎:

  • iOS WebView

等等,什么?iOS WebView 真的有那么差劲吗?没错。

两种 WebView 的故事

混合应用里引入的 JavaScript 代码运行在 WebView 中,本质上它就是 app 里附带的原生浏览器。在 Android 上,我们的代码运行在基于 Chromium 的 WebView 里,大多数情况下会完全按照预期运行。在 iOS 上,我们可以选择让代码运行在两种 WebView 中: UIWebView 或 WKWebView.

如何选择这两种 WebViews 很伤脑筋.

UIWebView 在 iOS 2 中引入,当时是唯一的选择,直到 iOS 8 中加入了 WKWebView。UIWebView 与现有的大部分 Cordova 插件兼容性很好,但总体上太过臃肿、缓慢。两者之间 对 HTML 5 的支持情况差异很小, 但由于 WKWebView 使用了 Nitro JavaScript 引擎,性能差距非常大。

Nitishkumar Singh 所说, WKWebView 提供了:

极大减少内存占用,启动更快,JavaScript 即时编译,独立进程渲染,占用更少的存储空间,稳定性更好,更安全,采用最新 web 标准等等。

在 2014 年 iOS 8 发行之前,很多鼓吹 WKWebView 对混合应用的重要性的文章开始冒出来。能够利用 WKWebView 提供的以上优化特性,让混合应用的开发者们兴奋不已。

不幸的是,当 iOS 8 最终发版以后,WKWebView 完全不能兼容现有的混合应用,因为它缺少一些 必备的功能。整整 3 年之后,情况只是稍微改观了一点。

WKWebView 的现状

感谢 Ionic 团队的出色工作,一些自讨苦吃的开发者(包括我自己)开始在他们的混合应用里使用 WKWebView。我会第一个站出来说,当 WKWebView 不出问题的时候,的确非常好用。在我老婆的 iPhone 7 上,Rizer 冷启动并安装 CodePush 更新的速度比在我的 Galaxy S7 Edge 上快多了。但如果它出问题时会怎样?让我们继续探究。

那些需要奇技淫巧的变通方案或者只能干脆放弃功能的 WKWebView 问题:

  • 不能访问应用根部 www目录以外的文件

  • 各种跨域问题,包括不能从 canvas 里提取图片数据,而这个 canvas 是用本地图片画上去的。 这差点搅黄了 Rizer,因为我需要允许用户裁剪照片和加滤镜效果,两者都需要在 canvas 里操作图片,然后从中提取像素数据。我之所以说 差点搅黄,是因为实际上我在 iOS 上通过代码分支曲线救国,做了下面这种扯淡的事:

  1. 把从设备上获取的照片 fileURL 传给 FileReader API 的 “readAsArrayBuffer” 函数。
  2. 用下面的函数将 “readAsArrayBuffer” 函数返回的 arrayBuffer 转成 base64 字符串:

     function arrayBufferToBase64(arrayBuffer) {    var binary = '';    var bytes = new Uint8Array(arrayBuffer);    var len = bytes.byteLength;    for (var i = 0; i < len; i++) {      binary += String.fromCharCode(bytes[i]);    }    return window.btoa(binary);  }
  3. 在返回的 base64 字符串前面加上 “data:image/jpeg;base64,”,以创建 DOM 可读的 “imageDataURL”

  4. 创建一个 Image 对象,加载我们的 imageDataURL 作为它的 “src”,当 image 加载完成时,创建一个新的 canvas 元素,把图片画上去。就像这样:

     var image = new Image();  image.onload = function() {    var canvas = document.createElement("canvas");    canvas.width = image.width;    canvas.height = image.height;    canvas.getContext("2d").drawImage(image, 0, 0);    callback(canvas); // No CORS issues  };  image.src = imageDataURL;
  5. 把你的电脑扔出窗外 🙂

  • 捉摸不定的垂直滚动行为,以及从我的经历来看完全不可用的水平滚动。有好几次,我老婆打开 Rizer 的排行榜页面后无法滚动照片,必须回到上一个页面并重新打开排行榜页面。这个问题如此严重,我到头来需要去实现 iScroll

  • 完全不支持 getUserMedia。这对 Rizer 来说不是问题,但是它阻止了我开始另一个需要这个特性的项目。都 2017 年了,这完全不可接受。也进一步证明了 Safari 成了新的 IE

  • 无法通过程序控制显示和隐藏键盘

  • 跟稳定版的 Cordova SplashScreen 插件有导致 App 崩溃的冲突

  • 跟稳定版的 Cordova In-App Browser 插件有导致 App 崩溃的冲突

你要知道,运行在 Android 上的混合应用不存在以上任何一个问题。

说真的,我对 Google 提供的应用开发部署流程没有任何不满。Google Play 开发者控制台非常不可思议,有健壮的发布管理,A/B 测试,应用内产品创建,订单管理,应用安装和使用统计,用户反馈收集,并且也没有荒唐的审核流程。锦上添花的是,我们知道混合应用会按照预期来渲染和运行,这要感谢 Android 基于 Chromium 的 WebView。 苹果在这点上落后太多了,以至于我一说起谷歌的产品就像个狂热粉丝。

毫无疑问,Rizer 的开发过程比我想象的更费时,也更令人沮丧……拜苹果所赐。

当我的家人问及 Rizer 的开发进度时,他们可以证明我对苹果和 iOS 有多深的怨念。我一直被这样一个事实打败: 世界上最有价值的公司提供了如此糟糕的开发体验。

我试图找出苹果为什么没有动力去改善混合应用开发的流程并让 Safari 像其他现代浏览器一样功能相当(它不像是没有资源去做这个),或者像其他平台(包括 Windows)一样直接允许使用第三方浏览器。难道他们是想让开发者在 Android 应用之前开发出 iOS 应用,然后 iPhone 或 iPad 用户就没那么想转向 Android 设备,因为他们每天使用的 App 在 Google Play 上没有? 我真心希望不是这样.

好吧,那……选择混合还是原生?

从我的经验来看,选择混合方式引起的所有潜在的卡壳问题,都有变通方案。发现和实现这些方案很麻烦,但的确能解决问题。因为这个原因,我很乐意说混合方式是你下一个 App 的正确选择。开发一个混合应用肯定会让你花费更长时间,但是依然比开发两个独立的原生应用要省时间,并且如果设计合理,对你的用户来说也会足够快。

嘿,或许将来某一天苹果迷途知返,会为我们提供我们应得的开发体验。在那天到来之前,我还是希望这个“混合与原生”之争继续火下去。

原文:If It Weren’t For Apple, Hybrid App Development Would Be The Clear Winner Over Native

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 要不是因为苹果,混合应用开发将完胜 Native

分享到:更多 ()

评论 3

  1. #1

    wh0cd1828217 cialis cheap

    BennyVom4周前 (07-09)
  2. #2

    wh0cd1828217 mobic

    匿名3周前 (07-14)
  3. #3

    direct lender payday loans quick cash online money lender [url=https://cashnow.cars]direct lender payday loans[/url]

    匿名4秒前