達成するための小さなプログラムを探索

小さなプログラムの開発と機能の緩やかな改善によって、より多くの製品は、そのような集合の代表として、サトイモなどのコミュニティのためのクロスプラットフォームソリューション、共通でより多くのものを持ってAPPの機能を小さなプログラムが必要です多端末操作に機構コード、それは達成するためにも使用することができ、ネイティブ言語としてスウィフトを使用するiOSアプリケーションに小さなプログラムのデモを実行し、アンドロイドを使用&&ネイティブ同じラインを反応します。

関連コードリポジトリ：https://github.com/taixw2/rmini

コンパイル層

コンパイルの目的は、機能的なWebコンポーネントアプレットを達成するために、アプレットH5との違いを滑らかにVueの使用データバインディング、使用コンポーネントです。

文書の公式サイトから見ることができ、プログラムのニーズは（オリジナルと相互作用する能力を持つ）小さなフレーム（データバインディングレンダリング）、コンポーネント（アプレットレンダリング部）、APIを実行します。

フレームワークの実装

単一ページのアプリケーション（実行可能な解）に変換

すべてのjsページにパッケージ化し、すべてのjsの管理や状態をルーティングし、このソリューションは、ウェブランニング側に適している、そしてプログラムは、単一のエンジンであり、シミュレートされたリターンネイティブ右スライド効果が不十分であることなどが挙げられるでしょう。

複数ページに変換

我々はすべて知っているように、小型双発プログラムのためのフレームワークがあり、上記のプログラムは明らかに要件を満たすことができない、ツインエンジンは、JavaScriptのブラックボックスを実行している特徴は、DOM && BOMなどにアクセスすることはできません。ネイティブJavaScriptCoreにおけるで実行するすべてのロジックコード、JavaScriptエンジンは、WebViewの中でデータバインディングの責任、および解決することが困難である上読んで、JavaScriptCoreにおけるWebViewのイベントを実行する方法、JavaScriptCoreにおけるにsetDataメソッドのWebViewのレンダリングを通知する方法です。

スムーズなWXML

wxml 是一种类 html 标记语言，他负责所有的渲染规则，包括条件渲染、列表渲染、数据绑定等，与其再实现一种框架，还不如直接利用 Vue 实现同样的功能，再利用各种转换库将 wxml 中的事件转换成 Vue 能够识别的事件，如利用 post-html 可以做到如下的转换:

每一个事件绑定的方法全都在原生的 JSContext 中运行，所以此时的事件只需要传递给 JSContext 的作用。

抹平WXSS

wxss 作为小程序的样式语言，其余 css 的主要区别就是多了一个 rpx 单位，以下是官网的换算表：

根据上表可得知， rpx = (750 / 屏幕宽度) * px;
在传统的移动端页面，我们的高清方案，一般需要获取 dpr， 然后修改动态修改 viewport 和 html 上的 font-size，但是小程序的代码因为是放在了设备本地，所以可以在下载小程序页面之后，我们还有一次编译机会，这时就可以把 rpx 根据当前设备的屏幕宽度替换成对应的 px。

还有一个 @import，则利用 scss 或 less 就可以合并到同一个 css 文件中,
而全局样式则可以在构建 WXML 的时候再植入进入

抹平组件

组件具有独特的功能和自己的渲染规则，比如 scroll-view 具有 scroll-x 和 scroll-y 等属性控制滚动条。在 HTML5 中有一个重大的功能web-component，它能够自定义 html 元素，并且能够监控属性的变化，非常适合实现小程序组件。如：（使用了 lit-element 框架）

这里用了 lit-element 这个框架，能够简化一些操作。

抹平 Page 和 App

App 负责整个应用的生命周期以及存一些全局的数据，getApp 能获取到 app 的信息。 所以类似的结构可能是这样的：

getApp 能够直接访问到内部对象，并且在最顶层声明，这样每一个的地方都能访问到 getApp。

初始化一个页面都需要是实例化 PageClass, 即使再次进入（不是返回到这个页面）这个页面页需要再次重新实例化，每次实例化都需要关联一个 webviewId, 这个 ID 与原始的 webview 关联，这样每个 PageClass 中的 setData 都能找到对应的 webview 进行再次渲染，所以对应的代码可能是这样的：

抹平 API

通过 API 能够直接调用原生的功能，比如 wx.request， 如果直接在 webview 中的 JSContext 中运行的话，则可能存在跨域，但是放在原生就不会存在这个问题。

实现JSContext 调用原生代码的功能，需要给 JSContext 中植入一个 JSBridge，如： JSBridge.invoke 和 JSBridge.on, invoke 负责同步任务，on 负责异步任务，原生再利用反射（原生的反射真麻烦）调用对应的原生方法，原生可以利用 while(true) 挂起 JSContext，既可以达到同步和异步的方法。

打包 Javascript

Javascript 代码打包后被放在 JavascriptCore 中运行，唯一与 Webview 中的 JSContext 打交道的只有 setData, 先看一下打包流程：

1. 利用 App.json 构建入口文件
2. 利用 rollup 等工具将所有 Javascript 打包成一个文件（目前没有分包）

打包流程及其简单，接下来看一下两个 Javascript 引擎的交互过程。

打通 JSContext 到 WebView JavascriptCore

新しいをインスタンス化する必要性を彼らは、このページにWebViewのIDを割り当てるために必要とされるときに、ページを入力して、これは非常に重要である、WebViewのと対話するネイティブとなJSContext（ジャバスクリプト実行しているネイティブのコンテキストオブジェクト）一意の識別子として、なJSContextたびにこのIDに関連付けられているPageClass、IDによりネイティブのWebViewを保持する参照。次のようなネイティブとの相互作用のためのJSBridgeなJSContext注入では、JSBridge.setData(webviewId, appId, data)JSBridge setDataメソッドはVueの中でデータを受信した後、setDataメソッドで、その後渡されたのWebView、APPID + webviewIdによって対応のWebViewを見つけるために呼ばれたときレンダリング、全体のプロセスが示されています：

WebViewのJavaScriptCoreにおけるなJSContextを介して取得します

伏線の従来の方法では、その後のWebViewなJSContextをコールする方法を見て、WebViewのなJSContextのみイベントと対話するための唯一の方法は、イベントトリガの後、いくつかの方法で、メソッドなJSContextの必要性をトリガし、そして最終的に戻って再呼び出しのsetDataへWebViewのレンダリング。

次のような多くのWebViewバインドメソッド名、： bindtap="a", bindtap="b", bindtap="c"：のような、結局など、「WXMLを滑らかに」時間を通じて1つの出口だけを保つことができる
v-on:click="callClick('a', $event)"対応を実現することができる唯一の少数のイベントを必要とし、このVUEの方法では、例えば：

エンディング

、2つのエンジンの間の通信のブリッジとしてネイティブの利点を活用通知を受信するための責任なJSContextをレンダリングするのWebView、および送信イベントなJSContextネイティブになJSContext、の両方がアクセスできないように、独立して実行するwindowオブジェクトを、それがアクセスすることはできませんdocumentオブジェクトを。