1.小さなプログラムと通常の Web 開発の違い
1. 動作環境が異なります
- Webページはブラウザ環境で動作します
- ミニプログラムはWeChat環境で実行されます
2. さまざまな API
- 実行環境が異なるため、DOM と BOM の API をアプレット内で呼び出すことはできません。
- ただし、ミニ プログラムは、WeChat 環境によって提供される次のようなさまざまな API を呼び出すことができます。
l 地理位置情報コードをスキャンします私が支払います
3. さまざまな開発モデル
- Web開発モデル: ブラウザ + コードエディタ
- ミニ プログラムには、独自の標準開発モデルのセットがあります。
lミニプログラム開発アカウントを申請するlミニプログラム開発者ツールをインストールするlミニプログラムプロジェクトの作成と構成
2. ミニプログラムプロジェクトの基本構造
1. ページはすべてのアプレットのページを保存するために使用されます。
2. utils は、ツールのプロパティを含むモジュールを保存するために使用されます (例: フォーマット時間のカスタム モジュール)。
3. app.js アプレットプロジェクトのエントリファイル
4. アプレットプロジェクトのapp.jsonグローバル設定ファイル
5. アプレットプロジェクトのapp.wxssグローバルスタイルファイル
6. project.config.json プロジェクト構成ファイル
7. sitemap.json は、ミニ プログラムとそのページが WeChat によってインデックス付けされることを許可するかどうかを構成するために使用されます。
3. ミニプログラムページのコンポーネント
ミニ プログラム関係者は、すべてのミニ プログラム ページをページ ディレクトリに保存し、別のフォルダーに存在させることを推奨しています。
その中で、各ページは次の 4 つの基本ファイルで構成されます。
1. .js ファイル(ページのスクリプトファイル、ページデータの保存、イベント処理関数など)
2. .json ファイル (現在のページの設定ファイル、設定ウィンドウの外観、パフォーマンスなど)
3. .wxml ファイル (ページテンプレート構造ファイル)
4. .wxss ファイル(現在のページのスタイルシートファイル)
4番目、設定ファイルの役割
1. JSON はデータ形式であり、実際の開発では、JSON は必ず設定ファイルの形式で表示されます。アプレット プロジェクトも例外ではありません。さまざまな .json 構成ファイルを通じて、アプレット プロジェクトをさまざまなレベルで構成できます。
ミニプログラム プロジェクトには、次の4種類のjson構成ファイルがあります。①プロジェクトルートディレクトリにあるapp.json設定ファイル②プロジェクトのルートディレクトリにあるproject.config.json設定ファイル③プロジェクトルートディレクトリのsitemap.json設定ファイル④各ページフォルダ内の.json設定ファイル
2. app.json は、現在のミニ プログラムのグローバル構成であり、ミニ プログラムのすべてのページ パス、ウィンドウの外観、インターフェイスのパフォーマンス、下部のタブなどが含まれます。デモ プロジェクトの app.json 構成コンテンツは次のとおりです。
: _ _①pages: 現在のアプレットのすべてのページのパスを記録するために使用されます。②ウィンドウ:ミニプログラムの全ページの背景色、文字色などをグローバルに定義します。③style: アプレットコンポーネントが使用するスタイルバージョンをグローバルに定義します。④sitemapLocation: sitemap.jsonの場所を示すために使用されます。
3. project.config.json はプロジェクト構成ファイルで、ミニ プログラム開発ツール用に作成した個人用の構成を記録するために使用されます。次に例を示します。
l 設定はコンパイル関連の設定を保存しますl プロジェクト名は projectname に保存されます。l appidに保存されるのはミニプログラムのアカウントIDです
4. Wechat はミニ プログラムで検索をオープンしました。その効果は PC の Web ページの SEO と同様です。sitemap.json ファイルは、ミニ プログラム ページで WeChat インデックス作成を許可するかどうかを構成するために使用されます。開発者が WeChat のインデックス作成を許可すると、WeChat はクローラーを使用してミニ プログラムのページ コンテンツのインデックスを作成します。ユーザーの検索キーワードがページのインデックスに一致すると、検索結果にミニプログラムのページが表示される場合があります。
注: サイトマップのインデックス プロンプトはデフォルトで有効になっています。サイトマップのインデックス プロンプトをオフにする必要がある場合は、ミニ プログラム プロジェクト構成ファイル project.config.json の設定でフィールド checkSiteMap を false に構成できます。
5. ミニ プログラムの各ページでは、.json ファイルを使用してこのページのウィンドウの外観を構成できます。ページ内の構成項目は、 app.json のウィンドウ内の同じ構成項目を上書きします。例えば:
6. app.json -> Pages にページのストレージ パスを追加するだけで、ミニ プログラム開発者ツールを使用して、対応するページ ファイルを自動的に作成できます。
写真が示すように:
プロジェクトのホームページを変更するには、 app.json -> pages 配列内のページ パスの順序を調整するだけで済みます。アプレットは、図に示すように、最初のページをプロジェクトのホームページとしてレンダリングします。
7. WXML は、ミニ プログラム フレームワークによって設計されたタグ言語のセットで、ミニ プログラム ページの構造を構築するために使用され、その機能は Web 開発における HTML に似ています。
WXMLとHTMLの違い
①レーベル名が違うlHTML(div、span、img、a)lWXML(ビュー、テキスト、画像、ナビゲータ)② 異なる属性ノードl<a href="#">ハイパーリンク</a>l<ナビゲーター url="/pages/home/home"></ナビゲーター>③ Vueと同様のテンプレート構文を提供lデータバインディングl リストのレンダリングl 条件付きレンダリング
WXS (WeiXin Script) は小規模プログラム用の独自のスクリプト言語で、WXML と組み合わせることでページの構造を構築できます。
ページの js で定義された関数は WXML で呼び出すことはできませんが、WXS で定義された関数は WXML で呼び出すことができます。したがって、小規模なプログラムでは、WXS の典型的な適用シナリオは「フィルター」です。
8. WXSS は、Web 開発における CSS に似た、WXML コンポーネント スタイルを記述するために使用されるスタイル言語のセットです。
WXSSとCSSの違い
①rpxサイズ単位を追加lCSS では、rem などの手動のピクセル単位変換が必要ですlWXSS は最下層で新しいサイズ単位 rpx をサポートし、アプレットはさまざまなサイズの画面で自動的に変換を実行します。②グローバルスタイルとローカルスタイルを提供l プロジェクトのルートディレクトリにある app.wxss は、すべてのアプレットページに作用します。lローカル ページの .wxss スタイルは、現在のページでのみ有効です③WXSS は一部の CSS セレクターのみをサポートしますl.class と #id要素l 共用体セレクター、子孫セレクターl::after や ::before などの疑似クラス セレクター
9. プロジェクトはインターフェイスの表示だけを提供するだけでは十分ではなく、ミニ プログラムでは .js ファイルを通じてユーザーの操作を処理します。例: ユーザーのクリックに応答する、ユーザーの位置情報を取得するなど。
ミニ プログラムの JS ファイルは、次の 3 つの主要なカテゴリに分類されます。
①app.jsl は、ミニ プログラム プロジェクト全体のエントリ ファイルです。ミニ プログラム全体は、App() 関数を呼び出すことによって開始されます。②ページの.jsファイルl はページのエントリ ファイルです。ページは、Page() 関数を呼び出すことによって作成および実行されます。③共通.jsファイルl は通常の関数モジュール ファイルで、ページで使用するパブリック関数または属性をカプセル化するために使用されます。
5. ホスト環境とアプレットのレンダリングプロセス
ホスト環境(ホスト環境) とは、プログラムの実行に必要な依存環境を指します。例えば:Android システムと iOS システムは 2 つの異なるホスティング環境です。Android 版 WeChat アプリは iOS 環境では動作しないため、Android ソフトウェアのホスト環境は Android となり、ホスト環境から切り離されたソフトウェアは意味がありません。
ミニ プログラムのホスト環境は WeChat です。
ミニプログラム開催環境の内容
①通信模型
②動作機構
③構成部品
④API
アプレット内の通信の主体は、レンダリング層とロジック層であり、その中には次のものがあります。
①WXMLテンプレートとWXSSスタイルはレンダリングレイヤーで動作します
②JSスクリプトはロジック層で動作します
アプレットの起動プロセス:
①アプレットのコードパッケージをローカルにダウンロードします。
② app.json グローバル設定ファイルを解析する
③app.jsアプレットエントリファイルを実行し、App()を呼び出してアプレットインスタンスを作成します。
④ アプレットのホームページをレンダリングする
⑤ アプレットが起動しました
アプレットのページ レンダリング プロセス:
① 解析ページの.json設定ファイルを読み込みます
②ページの.wxmlテンプレートと.wxssスタイルを読み込みます
③ページの.jsファイルを実行し、Page()を呼び出してページインスタンスを作成します。
④ページレンダリング完了
ミニプログラムのコンポーネントの分類
ミニ プログラムのコンポーネントもホスト環境によって提供され、開発者はコンポーネントに基づいて美しいページ構造を迅速に構築できます。公式には、ミニ プログラムのコンポーネントは次の 9 つのカテゴリに分類されます。
①コンテナを見る
②基本的な内容
③フォームコンポーネント
④ナビゲーションコンポーネント
⑤メディアコンポーネント
⑥mapマップコンポーネント
⑦canvasキャンバスコンポーネント
⑧オープン機能
⑨アクセシビリティ
よく使用されるビューコンテナコンポーネント
①見るl通常表示エリアl は HTML の div に似ており、ブロックレベルの要素です。lページレイアウト効果を実現するためによく使用されます②スクロールビューlスクロール可能なビューエリアlスクロールリスト効果を実現するためによく使用されます③スワイパーとスワイパーアイテムlカルーセルコンテナコンポーネントとカルーセルアイテムコンポーネント
6. 共同作業とミニプログラム開発プロセス
1. プロジェクトメンバーの組織構成
ミニ プログラム メンバーの管理は、管理者のミニ プログラム プロジェクト メンバーとエクスペリエンス メンバーの管理に反映されます。
①プロジェクトメンバー:l ミニプログラムの開発・運営に携わるメンバーを意味しますlミニプログラム管理バックグラウンドにログインできますl管理者はプロジェクトメンバーの追加、削除、プロジェクトメンバーの役割の設定が可能②体験会員:l はミニ プログラムの内部ベータ エクスペリエンスに参加したメンバーを示しますlミニプログラムの試用版は使用できますが、プロジェクトメンバーではありませんl 管理者とプロジェクトメンバーはエクスペリエンスメンバーを追加および削除できます
開発者の許可声明
① 開発者権限:ミニプログラム開発者ツールの使用とミニプログラム機能のコード開発が可能②体験者権限:ミニプログラムの体験版を利用できます。③ ログイン権限:管理者の確認なしでミニプログラム管理バックグラウンドにログインできます。④ 開発設定:アプレットサーバーのドメイン名を設定し、メッセージをプッシュし、共通リンクのQRコードをスキャンしてアプレットを開きます⑤ Tencent Cloud Management: クラウド開発関連の設定
2. 小規模プログラムの開発プロセス
3. ソフトウェア開発プロセスにおける異なるバージョン
ソフトウェア開発プロセスでは、次のようなさまざまなタイム ノードに従ってさまざまなソフトウェア バージョンが生成されます。
① 開発者がコードを書いている間に、プロジェクトコード(開発版)をセルフテストします。
② プログラムが安定して体験可能な状態に達するまで、開発者は体験版をプロダクトマネージャーとテスターに渡して体験テストを行います。
③最終的にプログラムのバグを修正した後、外部ユーザーが利用できる正式版をリリースする
4. アプレットのバージョン
5. ミニプログラムの公開と起動
小規模なプログラムのリリースと起動には、通常、コードのアップロード -> レビュー用に送信 -> 公開という 3 つのステップが必要です。
七、アプレットの構成
1. グローバル設定ファイルと一般的に使用される設定項目
ミニ プログラムのルート ディレクトリにある app.json ファイルは、ミニ プログラムのグローバル構成ファイルです。一般的に使用される設定項目は次のとおりです。
①ページl現在のミニプログラムのすべてのページのストレージパスを記録します②窓lアプレットウィンドウの外観をグローバルに設定する③バータブlミニプログラムの下部にtabBar効果を設定します④スタイルl新しいバージョンのコンポーネント スタイルを有効にするかどうか
ウィンドウノードでよく使用される設定項目
2. ページ構成とグローバル構成の関係
ミニプログラムでは、app.json のウィンドウ ノードで、ミニ プログラム内の各ページのウィンドウ パフォーマンスをグローバルに構成できます。
一部のミニ プログラム ページで特別なウィンドウ パフォーマンスが必要な場合は、「ページレベルの .json 構成ファイル」でこの要件を実現できます。
注: ページ構成がグローバル構成と競合する場合、近接性の原則に基づき、最終的な効果はページ構成に基づきます。
ページ構成でよく使用される構成項目
8. ミニプログラムのライフサイクル
ライフサイクル(Life Cycle)とは、オブジェクトの生成→運用→破壊に至るまでの段階全体を指し、期間を重視します。例えば:
l 張三の誕生は、この人のライフサイクルの始まりを示していますl張三の死は、この人の生涯の終わりを意味するl 張三の人生の真ん中は張三のライフサイクルですそれぞれの小さなプログラムの実行プロセスをライフサイクルに要約できます。
lアプレットの起動はライフサイクルの始まりを示しますlアプレットの終了はライフサイクルの終了を示しますl中間アプレットを実行するプロセスはアプレットのライフサイクルです
ミニ プログラムでは、ライフサイクルは次の 2 つのカテゴリに分類されます。
このうち、図に示すように、ページのライフサイクルの範囲は小さく、アプリケーションのライフサイクルの範囲は大きくなります。
ライフサイクル機能:アプレットフレームワークが提供する組み込み機能で、ライフサイクルに沿って順番に自動実行されます。
ライフサイクル機能の役割: プログラマーが特定の時点で特定の操作を実行できるようにします。たとえば、ページがロードされたばかりの場合、onLoad ライフサイクル関数でページ データを初期化できます。
注: ライフ サイクルは期間を強調し、ライフ サイクル関数は時点を強調します。
9. コンポーネントのライフサイクル
1. コンポーネントのすべてのライフサイクル機能
2. コンポーネントの主なライフサイクル機能
最も重要なライフサイクル関数は、作成、アタッチ、およびデタッチの3 つです。それぞれの特徴は次のとおりです。
① コンポーネントインスタンスが作成されたばかりの場合、作成されたライフサイクル関数がトリガーされます。l現時点では setData を呼び出すことができませんl通常、このライフサイクル関数は、コンポーネントのこれにいくつかのカスタム属性フィールドを追加するためにのみ使用する必要があります。② コンポーネントが完全に初期化され、ページ ノード ツリーに入ると、付属のライフ サイクル関数がトリガーされます。lこの時点で、this.dataは初期化されています。lこのライフサイクルは非常に便利で、ほとんどの初期化作業をこの時点で実行できます(初期データを取得するリクエストの送信など)。③ コンポーネントがページノードツリーから離れると、切り離されたライフサイクル関数がトリガーされます。lページを終了すると、ページ内の各カスタムコンポーネントの切り離されたライフサイクル関数がトリガーされます。l今は掃除をするのに良い時期です
10. 下請け
サブパッケージ化とは、完全な小規模プログラム プロジェクトを要件に応じてさまざまなサブパッケージに分割し、構築中にそれらをさまざまなサブパッケージにパッケージ化し、ユーザーが使用するときにオンデマンドでロードすることを指します。
ミニプログラムを外注する主なメリットは、
●ミニプログラムの初回起動時のダウンロード時間を最適化できる
●複数チームで共同開発する際の連携をより適切に分離できる の2点です。
下請けに出す前に、ミニ プログラム プロジェクト内のすべてのページとリソースが一緒にパッケージ化されていたため、プロジェクト全体が大きくなりすぎ、ミニ プログラムの初回起動時のダウンロード時間に影響を与えていました。
下請け後のミニ プログラム プロジェクトは、1 つのメイン パッケージ + 複数の下請けで構成されます。
メイン パッケージ: 通常、プロジェクトのスタートアップ ページまたは TabBar ページと、すべてのサブパッケージが使用する必要があるいくつかのパブリック リソースのみが含まれます。
l 下請け: 現在の下請けに関連するページとプライベート リソースのみが含まれます。
サブパッケージの読み込みルール
① ミニプログラムを起動すると、デフォルトでメインパッケージがダウンロードされ、メインパッケージ内のページが起動します
● tabBar ページはメインパッケージ内に配置する必要があります。
② ユーザーがサブパッケージ内のページを入力したとき完了後の表示
●tabBar 以外のページは、機能に応じてサブコントラクトに分割し、オンデマンドでダウンロードできます。
下請け数量制限
現在、ミニ プログラムのサブパッケージのサイズには次の 2 つの制限があります。
● ミニ プログラム全体のすべてのサブパッケージのサイズは 16M (メイン パッケージ + すべてのサブパッケージ) を超えることはできません。
● 1 つのサブパッケージのサイズ/main パッケージは 2M を超えることはできません
下請けを利用する
1.設定方法
2. 包装原則
① ミニ プログラムはサブパッケージの構成に従ってサブパッケージ化され、サブパッケージの外部のディレクトリはメイン パッケージにパッケージ化されます。 ② メイン パッケージには
独自のページ (つまり、最も外側のページ フィールド) を持つこともできます。
③ tabBar ページは次のようにする必要があります。 ④ サブパッケージを
相互にネストすることはできません
3. 引用の原則
① メインパッケージはサブコントラクト内のプライベートリソースを参照できない、
サブコントラクト同士は相互にプライベートリソースを参照できない、
③ サブコントラクトはメインパッケージ内のパブリックリソースを参照できる。
独立した下請け
1. 単独下請けと通常下請けの違い
主な違い: 実行するメイン パッケージに依存するかどうか
● 通常のサブパッケージは実行するメイン パッケージに依存する必要がある
● 独立したサブパッケージは、メイン パッケージをダウンロードせずに独立して実行できる
2. 応用シナリオ
開発者は、必要に応じて、機能的に独立した特定のページを独立したサブパッケージに構成できます。その理由は以下の通りです。
●通常の下請けページからミニプログラムを起動する場合、最初に本体パッケージをダウンロードする必要がある
●単独下請けは本体パッケージに依存せずに実行できるため、下請けの起動速度が大幅に向上します。ページ。注: ミニプログラムには複数の独立したサブコントラクトが存在する場合があります。
3. 引用の原則
独立したサブコントラクト、通常のサブコントラクト、およびメイン パッケージは互いに分離されており、互いのリソースを参照できません! 例:
① メイン パッケージは、独立したサブコントラクト内のプライベート リソースを参照できません。
② 独立したサブコントラクトは、互いのプライベート リソースを参照できません。 リソース
③ プライベート リソースは参照できません。単独下請と通常下請の区別
④ 特記事項:本体パッケージ内の公開リソースは単独下請では参照できません
事前ダウンロードを委託
サブパッケージの事前ダウンロードとは、ミニ プログラムの特定のページに入るときに、フレームワークが必要なサブパッケージを自動的に事前ダウンロードすることで、後続の下請けページに入るときの起動速度を向上させます。
1. 委託先の事前ダウンロードを構成する
2. 委託先による事前ダウンロードの制限
最後に次のように書きます。
一部のコンポーネント、ナビゲーション、パラメータ転送、通信などに関連する詳細が多すぎます。~そして、この部分については公開されているドキュメントを読む方が良いので、ここではメモしません。