Native | Hybrid | Web App选型及演进方案
目录
-
App形态
Web App
Native App
Hybrid App
-
Web App模型方案和应用 (待完成)
SPA (Single Page Application) 单页应用
PWA (Progressive Web App) 渐进增强Web应用
模块化单页应用
-
Hybrid App模型和实现原理
现有的Hybrid形态
Hybrid的实现原理
Codova实践方案
React Native 实践方案
-
Native App (待完成)
Native组件化&容器化
Native的粒度、切面和Business层的抽取
-
App的选型方案和演进路线
各种不同类型App选型方案
升级:ABTesting (待完成)
升级:用户事件收集 - 无埋点 vs 埋点方案 (待完成)
EJU Router方案(待完成)
App形态
Web App
DEFINITION 定义
A web application or web app is any software that runs in a web browser. It is created in a browser-supported programming language (such as the combination of JavaScript, HTML and CSS) and relies on a web browser to render the application.
Web applications are popular due to the ubiquity of web browsers, and the convenience of using a web browser as a client, sometimes called a thin client. The ability to update and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity, as is the inherent support for cross-platform compatibility. Common web applications include webmail, online retail sales, online auctions, wikis and many other functions. --wiki
在浏览器端构建的基于HTML/CSS/JS进行开发,使用浏览器进行渲染的应用程序。
其特点体现在几个方面
update and maintain web applications without distributing and installing software 升级和维护不需要分发和安装
the inherent support for cross-platform compatibility 良好的跨平台性
The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps. And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today. So developers, we think we’ve got a very sweet story for you. You can begin building your iPhone apps today. --Steve Jobs
Jobs其实是最早的web app
的倡导者之一,在当时的构想中是没有native app
这种形式的,所有的app
都是以web
的形式存在的,但是当时的Jobs需要面对3个问题
移动网络根本无力承担这种变革
如何使webapp让Apple盈利
webapp运行的体验非常糟糕
而基于此的讨论和考虑才逐步衍生出后来的Native App
和`App Store
Chromium OS vs Firefox OS
很有意思的一件事情是,很多年之后。有两家公司实现了Jobs当年没有实现的梦想,分别推出了基于浏览器操作系统的PC和手机。
基于Chromium OS的Google Chrome Book 官网 视频
ChromeBook的推出,才逐渐让市场上开始产生真正的Web App。至今我们能够看到的很多出色产品,都是以此为开端或者以此为契机,其中很著名的有:trello | slack
基于FireFox OS移动端手机,不过很不幸2015年Q3开始,Mozilla宣布停止对Firefox OS的开发,就如很多方兴未艾的手机系统一样,它还没怎么被认识,就寿终正寝了。视频
CASE STUDY 案例
Native App
DIFINITION 定义
Apps are usually available through application distribution platforms, which began appearing in 2008 and are typically operated by the owner of the mobile operating system, such as the Apple App Store, Google Play, Windows Phone Store, and BlackBerry App World. Some apps are free, while others must be bought. Usually, they are downloaded from the platform to a target device, such as an iPhone, BlackBerry, Android phone or Windows Phone, but sometimes they can be downloaded to laptops or desktop computers. For apps with a price, generally a percentage, 20-30%, goes to the distribution provider (such as iTunes), and the rest goes to the producer of the app.[1] The same app can therefore cost the average Smartphone user a different price depending on whether they use iPhone, Android, or BlackBerry 10 devices. --wiki
基于手机操作系统的应用程序,使用其原生程序进行构建
其特点体现在几个方面
operated by the owner of the mobile operating system 在对应操作系统平台进行应用程序的开发
available through application distribution platforms 需要分发应用(下载)的市场 — 卖钱
CASE STUDY 案例
部落战争 在游戏中大量采用OpenGL ES对于效果的开发非常有帮助,而WebGL的演进漫长
HYBRID APP
DEFINITION 定义
A hybrid mobile application (or hybrid mobile app) is a mobile application that runs inside of a native container and leverages the device’s web browser to display locally hosted HTML pages.[29] Hybrid mobile apps are composed mostly of HTML, JavaScript, and CSS. Device specific functionalities such as camera access, geolocation, and accelerometer readings are exposed through a JavaScript API. --wiki
其特点体现在几个方面
runs inside of a native container 运行在原生的容器内
Device specific functionalities are exposed through a JavaScript API 通过
JS API
暴露底层的功能接口
优缺点
Pros
Hybrid mobile apps allow code reuse across platforms. Let the library or framework you are using take care of the platform specific differences and use the same JavaScript code on both platforms. 跨平台的代码复用 - 在不同的平台使用相同的Javascript代码
JavaScript is something that many developers are already familiar with where something like the iOS development tools are more specialized. It can be argued that there is less of a learning curve when developing hybrid mobile apps compared to native apps. Javascript使用的通用性解决了iOS开发者的专用属性,开发hybrid mobile的学习曲线更简单。
The app's interface and logic can be built and debugged in the web browser using an emulation framework. This could lower development costs depending on the tools required to develop native apps for the target platforms. app的ui和逻辑都可以在浏览器中构建和debug,减少在目标平台上的花费。
The HTML5 application development with CSS3 gives the compelling structure to the interface of game app and this ensures pleasing user-interface. 使用CSS3让用户界面和游戏开发更加生动。
Cons
Hybrid mobile apps are more susceptible to user interface lag due to the extra layers of abstraction.[29]
Only a certain subset of native functionality is available which depends on the framework. All others native functions are accessible developing Plugins. 大部分native层的功能都需要通过plugin的方式进行调用。As for native apps, the hybrid code base requires recompilation and resubmission to the distribution network where it is possible to instantly update a mobile web app’s codebase. 相对于web app来说,hybird需用重新编译和分发才能完成更新
HTML5 in mobile devices H5在Web容器里的兼容性问题
CASE STUDY 案例
街旁国内最早的
Hybrid
模式的倡导者
选择
WEB APP
, HYBRID APP
& NATIVE APP
选择哪种形态?
决定哪种模式之前需要问自己这些问题:
App
的体验和开发周期何者为先?APP
的更新周期是否频繁?开发资源
应用平台
Hybrid App模型和实现原理
现有的Hybrid形态
在Native
与Web
之间构建一层Bridge
, 将底层的接口映射到JS API
上
View
的渲染依赖于浏览器自身的渲染引擎,即使游戏也不需要去写openGL
Bridge
在不同的平台通过不同的native
层实现,在各自平台下完成编译Business
可以实现在Web
也可以实现在Native
Plugin
构成了Bridge
的扩展
现有平台
案例
使用JS
编写通用的业务逻辑,使用Nodejs编译不同平台的Native app
视频
View
通过Ti.UI
进行调用Native
实现,在不同的操作系统中调用不同的Native UI
实现。Ti.UI
可以定义部分Native UI
Business
通过JS
编写最后编译成Native
代码Bridge
和Build
工具进行了整合,理论上可以跨所有平台
现有平台
在我写这篇文章第一稿的时候,Facebook发布了React Native,从Coding的思想上RN不一样
案例
Hybrid App实现原理
Titanium
严格来说不属于Hybrid
,因为其最终产生的仍然是Native App
,过于牛B,不在本文知识范围内。本文限于讨论类似Cordova
的Hybrid
实现。
Native调用JS
native通过string调用js
webview调用js解释器的eval方法将string转化为js方法
webview调用js方法
JS调用Native
javascript改变url,通过url传递调用的方法和参数
webview监听到了URL变化,并且探测到url中定义的方法和参数
寻找对应的映射表,找到native对应接口api进行调用
执行javascript调用方法时传入的回调string并添加数据
webview解析string转化为javascript进行调用
URL Schemes
为了区别普通的http
访问的url
与hybrid
调用native
的url
,参考openurl
的标准apple提出了url schema的方法
系统自定义了可以被识别的协议和url,例如
mailto:frank@wwdcdemo.example.com
tel:1-408-555-5555
sms:1-408-555-1212
app自身可以自定义url schema,并且把自定义的url注册在调度中心, 例如
ctrip://wireless 打开携程App
weixin:// 打开微信
阅读
早期的Android采用了JavascriptInterface
,但是这种方案存在注入的安全隐患,所以在Android 4.0以上的版本开始就支持了URL Schema方案。
Hybrid URL Schema在实现中的问题
存在短时间内高并发的问题,例如:一次定位没有完成期间,反复调用定位
执行http的url访问还没有返回就调用了新url schema,导致了前一次行为没有生效
在ios中native调用js是实时的,在Android中native调用js是异步的,在异步调用中出现alert这种阻塞进程的会直接crash app
关于这里的实践,需要读Cordova的JS Bridge
Cordova实践方案
Cordova诞生于PhoneGap,早起的PhoneGap是一个开源平台,所有的代码、编译都可以使用PhoneGap平台完成。在被Adobe收购Nitobi,同时把PhoneGap其中的核心层代码进行了开源,新版本后的PhoneGap进入商业化。所以现在在PhoneGap平台上如果是用它的编译,需要付费。
但有了Cordova,我们就可以造一个新的PhoneGap~~不是吗,所以有了Ionic
Cordova架构:
就如我们前面说的,Cordova的方案就是放一个WebView所有的UI都是通过WebView进行呈现,通过JS Bridge调取Native方法。Cordova将JS Bridge做成了一种插件式的方式,便于扩展。
所有采用Cordova方案或者类似以WebView作为呈现的Hybrid方案,在Android上遇到一个最大的问题,就是不同ROM中WebView的兼容性问题
之前华为系统的webview内核有问题,只要有js交互,占用内存无限上升;某次测试达到恐怖的380M,简直吓尿;由于是webkit内核问题,无能为力;我们只能检测到是华为系统的这个特定版本的时候谈个Toast,告诉用户不要在页面逗留太长时间。。(现在这个bug已经修复了,当时系统版本:NXT-TL00C 01B1 29SP02)— 知乎用户
下一个问题:如果用Crosswalk包太大怎么破?用Crosswalk Lite或者只用Arm的包
React Native 实践方案
就如前面的Titanium,RN里面Javascript是用来写业务的,UI是交给Native的,所有如果有很多的自定义View的话,其实开发量也不小~
React-Native系列Android——自定义View组件开发
我说RN和Titanium不一样,为什么?因为CodePush,CodePush是Microsoft推出的React Native的热部署方案。简单来说就是业务层都使用JS来写,把JS打包成Bundle,然后把Bundle文件下发下去。那么不同在什么地方?
Titanium是需要完全编译的,最终是不是把JS代码都转成了Java或者C的代码不了解,但是有很大可能。像C和Java需要完整的编译,在Runtime的时候打开去注入,其实是很难的。但是RN把业务层抽到Bundle,这是一种Meta Programming的思想,这就意味着,随着发展未来你只要推js代码上去,RN就可以完成更新。
App的选型方案和演进路线
各种不同类型App选型方案
两个问题:
Native | Hybrid | Web 他们之间是不是非此即彼的关系?
如果一个App初期选择一个Native | Hybrid | Web中的一个,是不是意味着只能一条路走到黑?如果中间想加或者想转其他的形态需要多大的努力?
所以要回答这个问题,我先来说一个我过去做的案例
最早我们在做丰趣海淘的时候,我们大量的人力和时间都投入在PC站点、移动站点和后台的搭建中,我们还在尝试其他的商业模型,所以没有人力投入在App的开发中。有一天下午,我和我们大前端的负责人讨论了一下之后,决定出一个App,放App Store和Google Play,然后大概2天左右时间,我把当时做的移动端站点扔进去,发布了当时我们第一个版本~~
上线之后,发现了一个让人惊喜的数据:周复购xx%~~当时老板大手一挥,做移动端。到今天,xx%以上的购买都从移动端来,历时一年半。
所以我们当时初期的架构就是纯粹的Web,然后我们就开始了演进。这个要说到我们当时的前端架构,我们用了CanJS,但是没有做纯粹的单页应用。我们做了模块化的单页应用,简单的说,首页我认为它是一个模块,我为他单独做一个单页应用。所有单页应用有个切面层,做服务端的签名、csrftoken的处理等等。
然后我们开始做原生化,为什么要做原生化,因为要让用户体验有大的提供、因为要做用户心智
所以基于一个个模块,开始做,我们原则是:
下单主流程原生化,让用户最快速度的付钱
产品化比较好的模块先原生化
经常变化并且变化非常大的模块,不做原生化 - 用hybrid的方案走
Hybrid最开始我们采用了Cordova的架构,但是后来放弃了,Cordova太重了,没必要,我们自己写了JS Bridge通过URL Scheme的方式进行调用,封装了调用堆栈,同时引入了Crosswalk解决华为机的兼容性问题。
所以我们总结一些一般的演进流程:
按照不同的App分类,做个简单的建议
电商类:70% Native + 10% Web + 20% Hybrid
工具类:80% Native + 20% Hybrid
社交类:50% Native + 20% Web + 30% Hybrid
游戏类:95% Native + 5% Web
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。