——个人平时笔记，看到的同学欢迎指正错误，文中多处摘录于各大博主与书
籍精华

一、混合开发几款移动跨平台App开发框架比较

1.PhoneGAP
2.Cordova
3.Dcloud
4.APICloud
5.APPCan
6.Lonic
主流的：Ionic、React Native
非主流：AppCan、Jquery Mobile（主要用于做移动Web）

二、移动跨平台方案

image.png

移动开发10年历程
React Native、weex、Flutter
1.Hybrid开发（H5+原生混合）——使用webview渲染
使用安卓WebView或者iOS的WKWebView来加载H5网页的方式实现。通过JsBridge接口的方式与原生通讯。

2.React Native框架和阿里Weex——映射为原生控件渲染
界面DOM树UI会通过JavaScriptCore映射为原生控件树去渲染

• React Native是Facebook早先开源的JS框架 React 在原生移动应用平台的衍生产物，目前支持iOS和安卓两大平台。RN使用Javascript语言，类似于HTML的JSX，以及CSS来开发移动应用，因此熟悉Web前端开发的技术人员只需很少的学习就可以进入移动应用开发领域。
• 阿里Weex框架能够完美兼顾性能与动态性，让移动开发者通过简捷的前端语法写出Native级别的性能体验，并支持iOS、安卓、YunOS及Web等多端部署。

3.Flutter框架——调用系统API渲染
Flutter是谷歌的移动UI框架，使用Dart语言开发，可以快速在iOS和Android上构建高质量的原生用户界面。使用自绘引擎，自绘引擎是直接调用系统API来绘制UI的。 Flutter可以与现有的代码一起工作。

android_跨平台.png

4.从本质上来讲，React Native 和 Weex 可以算作 Hybrid 的方案。把它们和 Cordova 纯 HTML 开发的 App 进行对比的原因，是因为 React Native 和 Weex 都支持将资源文件（例如 HTML、CSS 或 JS）打包到 App 进行发布。

5.RN 和 Weex 的原理都是在 iOS 或者 Android 操作系统上利用 JavaScript 引擎进行 Bundle 的解析，利用操作系统原生的 UI 框架进行渲染的。这种方案解决了 Hybrid 性能的不足，也提供了动态化和网页开发的体验。

6.Flutter 之所以受到如此多的关注是因为它与之前的 Hybrid、React Native、Weex 有着很大的不同。

首先第一点，也是最本质的区别：Flutter 使用自己的绘制引擎开发，系统级 API 进行渲染，新的一套跨平台ui框架，客户端仅需要提供一块画布就可以支持应用展示。这一点使其脱离了原生的渲染，让我们可以获得高度一致的渲染体现。除了一致性以外，Flutter 大量利用了 GPU 绘制的 Skia 图形引擎，在渲染速度和动画效果上都给出了更有体验。

其次是开发的效率和开发的生态环境，Flutter 从一开始就很关注开发的效率，利用 Hot-Reload 的亚秒级刷新能力开发人员可以非常快速的进行调试和开发，也能随时查看编写代码呈现的效果。另外 Flutter 采用 Dart 语言进行开发，Dart 语言兼有 JIT 和 AOT 两种运行模式，既可以保证开发模式下快速的部署和调试，也可以保证产品模式下高速的运行。Dart 语言易学易用，可以很方便的从 Java、Objective-C、JavaScript 等语言迁移过来。

• Flutter 下层使用 C / C++ 编写的 Framework，上层用 Dart 进行视图和功能组件的搭建
• 自绘引擎解决的是UI的跨平台问题，如果涉及其它系统能力调用，依然要涉及原生开发。

• Flutter与原生安卓交互有三种方法，分别是MethodChannel，EventChannel与BasicMessageChannel。与ios也是类似。

  
  
  image.png
  
  
  image.png
  
  
  image.png

三、Hybrid 混合开发问题

1.在webview与java交互中，只有Android 4.2，API 17开始只有被@JavascriptInterface 注解标识的公有方法可以被JS代码安全访问，才能不被拦截后反射调用。
2.在webview与java交互中，如何保持与http请求同步？

• session技术则是服务端的解决方案。在Java中是通过调用HttpServletRequest的getSession方法（使用true作为参数）创建的。在创建了Session的同时，服务器会为该Session生成唯一的Session id，而这个Session id在随后的请求中会被用来重新获得已经创建的Session；在Session被创建之后，就可以调用Session相关的方法往Session中增加内容了，而这些内容只会保存在服务器中，发到客户端的只有Session id；当客户端再次发送请求的时候，会将这个Session id带上，服务器接受到请求之后就会依据Session id找到相应的Session，从而再次使用之。正式这样一个过程，用户的状态也就得以保持了。
  由此我们可以得出，session是解决http协议无状态问题的服务端解决方案，它能让客户端和服务端一系列交互动作变成一个完整的事务，能使网站变成一个真正意义上的软件。
• cookie技术是客户端的解决方案。浏览器访问一个支持Cookie的网站的时候，用户会提供包括用户名在内的个人信息并且提交至服务器；接着，服务器在向客户端回传相应的超文本的同时也会发回这些个人信息，当然这些信息并不是存放在HTTP响应体（Response Body）中的，而是存放于HTTP响应头（Response Header）；
• cookie和session的方案虽然分别属于客户端和服务端，但是服务端的session的实现对客户端的cookie有依赖关系的，上面我讲到服务端执行session机制时候会生成session的id值，这个id值会发送给客户端，客户端每次请求都会把这个id值放到http请求的头部发送给服务端，而这个id值在客户端会保存下来，保存的容器就是cookie，因此当我们完全禁掉浏览器的cookie的时候，服务端的session也会不能正常使用（注意：有些资料说ASP解决这个问题，当浏览器的cookie被禁掉，服务端的session任然可以正常使用，ASP我没试验过，但是对于网络上很多用php和jsp编写的网站，我发现禁掉cookie，网站的session都无法正常的访问）
• 最终解决方案，通过CookieManager 管理webview，服务端返回的sessionId是存储在cookies中，httpclient登录到服务器的时候，从http的cookie中取出sessionId放入到webview中（同步cookie，cookie信息保存在请求头发送到后端服务），webview访问业务的时候，由于sessionId一致，服务器会认为该用户已登录。