高可用、高可扩展的原生WebView通信架构的思考

一、为什么学WebView？

为什么学习Webview，主要是指WebView的应用场景，当前大环境里应用越来越广泛，主要有两方面的制约因素：

1. 硬件，手机的性能，CPU 2.8GHz，内存RAM 12G，处理速度越来越快；
2. 网络，应用的内容实时从服务器拉取，网络带宽高/延时低，5G，体验提高。

二、是否会替代原生开发？

不会。早在2012年就开始鼓吹html一统天下…

1. 操作系统的原因，Android和iOS风格不同，如果实现原生效果，需要大量if-else；
2. 很难做到html要和PC兼容（三端统一），宽高比例不同，PC大多为横向，手机大多竖向，同样需要大量if-else（包括responsive响应式开发）；
3. 小程序/uniapp，依赖微信平台，有政策风险，账号被封了怎么办？作为引流、辅助成不了气候，大型公司和主流App都不会考虑这个方案；
4. 浏览器的兼容性是很复杂的工作，存在碎片化问题。

三、什么情况用html开发？

1. 与操作系统风格无关的页面
   1）游戏（完全定制化，unity3d/Cocos2d）一套生成三端
   2）about页面、privacy页面、help页面、反馈页面、活动（抽奖、问卷）、电商类页面
2. 页面层次很深，用户使用很少的页面，经常变化的页面。

四、Html需要和原生进行大量的通信（重要）

1. 将WebView做成一个独立组件；
2. 使用方便；
3. 可扩展性，灵活的扩展通信能力；
4. 可靠性；
5. 可配置性；
6. 全面详细的文档，swagger / javadoc / html；
7. 升级部署，gradle -> artifactory pro -> gradle依赖（给其他团队使用）。

五、搭建WebView和Java的通信架构

1. kotlin / compose，采用新的技术实战；
2. View/ViewGroup，从Android诞生以来，当前Android的UI系统用的是View / ViewGroup，xml定义布局 + Java / Kotlin，命令式UI，已经过时；
3. Swift / Flutter / Compose，独立的UI系统，声明式UI，数据驱动，推荐。

六、组件化实现

组件化，各个Module中的引用版本必须一致，否则编译失败。
组件之间没有横向依赖，如果依赖需要接口下沉（common），组件要提供给别人用，app是组件的组装器。
删除test相关，加快编译速度。
新建module -> library(webview + common + usercenter + base)
y依赖关系：app -> webview -> common（AutoService） -> base

6.1 这里common模块和base模块的区别

都像是工具类的作用，但是架构作用是不同的：

• common：所有的工程师都能改的代码
• base：框架、基类，架构师管理的代码

6.2 AutoService

常见的组件化方案有，各有优势：

方案	特点
ARouter	基因中自带支持从webview中调用、不用互相注册（不用知道需要调用的app的进程名称等信息）等
ComponentCaller	集成简单、功能丰富、全程监控、改造老项目成本低等
AutoService	Google推荐、继承简单、功能强大

6.3 依赖传递：

• api/compile(gradle 3.0之前)：相当于java的public，除了自己用，使用的地方也可以用，组件中一般使用api引入，方便连续依赖调用。
• implementation：相当于java的private，只能自己用。

不同组件里面重复的引入，打包之后不会重复

6.4 思考：使用WebView的方式有哪些？

1. Fragment
2. Activity->Fragment
3. 为什么没有Compose？
   目前Compose中没有独立的webview的组件，WebView仅仅是浏览器的盒子，没必要包装成一个AndroidView放到Compose中

6.5 定制化

• 显示title标题
• 是否显示actionBar
• smartrefreshLayout刷新
• loadSir加载状态处理（错误、失败……）
• ……

6.6 WebView页面三元素

WebView = Html（视图、元素） + CSS（样式） + JavaScript（交互、动态执行）

6.7 WebView包含四个部分

0. WebView自身负责创建对象，加载URL，生命周期管理，状态管理
1. WebChromeClient：辅助WebView处理Javascript对话框，网站图标、标题…
2. WebViewClient：处理各种通知、请求事件
3. WebSettings：配置管理
4. JavascriptInterface

6.8 可靠性（OOM）

1. webView 需要兼容90年代到目前为止所有的html，代码复杂度不亚于操作系统的复杂度，千万行代码工程。
2. 独立进程只能针对Activity、Service，Fragment依附于Activity不能放到独立进程。
   1） 实现：android:process=":customwebview"
   2） 好处：操作系统以进程为单位，复杂容易崩溃，崩溃后不影响App（主进程）使用。
   3） 副作用：需要使用AIDL跨进程通信

6.9 可扩展性

加命令 -> Webview -> addJavaScriptInterface（只有一个，不需要修改）

基于命令模式的设计框架 + AutoService