メインコンテンツへ移動
黯羽軽揚毎日少しずつ

リリースできないミニプログラム

無料2017-05-20#Toy#小程序类目审核#小程序案例#小程序demo#小程序审核规则

ミニプログラムは小型 App を完全に置き換えられ、プラットフォームの自然なプロモーションに依存できるようですが、開発完了後にリリースできないことが判明しました

はじめに

まだ自用の RSSHelper です。もともとミニプログラムでクロスプラットフォームを実現し、ionic を捨てようと思いましたが、後にリリースできないことが判明しました

零.注意事項

リリースしたいミニプログラムを作る準備がある場合、必ず以下の数点をよく確認してください：

1.コンテンツがカテゴリ審査を通過できるか

一级分類は快递郵政、教育、出行、生活サービス、飲食、観光、ツール、商業サービス、体育で、さらに細分化されますが、適切なカテゴリが見つからないことに気づきます...

そのため、できるだけ早く DEMO を作成して審査に提出し、コンテンツが合法か確認してください。1 ヶ月頑張った後にリリースできないことが判明してはいけません

2.機能及びインタラクションがニーズを満たせるか

例えばユーザー情報の取得、位置情報、オーディオビデオ、ファイル、コンパス Bluetooth アクセラレーターなど、言及されたこれらはすべてサポートされていますが、どの程度サポートされ、どのような制限があるかは、ドキュメントを通じて理解する必要があり、DEMO 検証さえ必要です

半分まで作った後に XXX 機能がサポートされていないことが判明すると、面倒なことになります

例えば現在H5 ページの表示をサポートしていません。ミニプログラムから直接表示（webview の埋め込みなど）することも、ブラウザにジャンプして開くこともできません。情報類 App にとって、これは極めて大きな制限です

自用のミニプログラムを作りたい場合も、上記の問題を考慮する必要があります。リリースしないと自用も許可されないからです（プレビューには有効期限制限があり、30 分程度です）

一.制限

1.インターフェース

ミニプログラムのインターフェースはHTTPSを強制要求します：

设置/服务器域名

request 合法域名
socket 合法域名
uploadFile 合法域名
downloadFile 合法域名

サービスインターフェースのホワイトリストは HTTPS ドメインのみで、そうでないと IDE 開発環境でもリクエストを送信できません。インターフェースがまだ HTTP の場合、一時的に偽データを使用するしかなく、ローカル mock サービスも使用できません。厳格なドメイン検証があるためです

そのため、最初のことはインターフェースが HTTPS をサポートしているか確認することです。サポートしていない場合、できるだけ早くサービスを移行してください。そうでないと、偽データで各種インターフェースをシミュレートする必要があり、比較的面倒で、しかも実際のリクエストとは異なるため、問題を早期に発見するのに不利です

P.S.無料 HTTPS については、[nginx HTTPS 逆方向プロキシ](/articles/nginx-https 反向代理/) を参照できます

2.bundle サイズ

ソースコード及びリソースのパッキング後サイズは2Mを超えられません。画像リソースが少ない純手工プロジェクトならまだしも、以下の場合は：

  • 画像リソースが非常に多い

  • 一部のサードパーティ lib に依存

  • プロジェクト規模が大きい（コード量）

一级ページの最初のスクリーン画像リソースが非常に多い場合、圧縮以外により良い方法はありません。非一级ページの最初のスクリーン画像はサーバー側に配置できます。サードパー��ィ lib はできるだけ使用しないでください。2M 制限の下では、サードパーティ lib の導入は慎重に考慮する必要があります。プロジェクト自体が非常に庞大で、例えば数十万行のコード量の場合、gg、これは大プログラムです

P.S.bundle サイズが 2M を超えると、コンパイルパッケージを提出できず、ファイルを削除して再試行するよう提示されます

3.アカウントタイプ及び認証

公众号管理方式と同じで、個人号、企業号、認証の有無などを区別します：

卡券接口 要求認証
開放プラットフォームバインディングミニプログラム 開発者資格認証を要求

P.S.個人公众号でも個人ミニプログラムでも、認証できません。お金を払う機会さえ与えられません

订阅号と企業号の違いと比較して、ミニプログラムの制限は少なくなりました。カードクーポン API のみに制限があります。公众号がミニプログラムをバインドすることについては、厳格な制限はありません（アカウントタイプ及び認証の有無を制限しませんが、数量制限があります）

また、個人公众号はミニプログラムを登録できません（ミニプログラムを関連付け、エントリーポイントを提供することはできます）。そのため、やむを得ずまたメールアカウントを作成しました

暫不支持個人/メディア/政府/その他の組織の快速ミニプログラム作成。通常プロセスに従って登録を完了してください。

4.コンテンツ審査

2 部分に分かれます。カテゴリ審査と機能審査です

リリースが難しい最も主な理由はカテゴリ審査です。現在一部 App タイプのみをサポートし、制限は想像よりはるかに大きく、現在は情報照会、注文などに集中しているようです

カテゴリ審査は交渉の余地がありません。審査結果が暫く該カテゴリを開放しないと明確に指摘した場合、先に放棄するしかありません

機能審査はテスト提出です。インタラクションが友好的でない、機能が使用できない、単純すぎるなどはすべて却下される理由になる可能性がありますが、コード修正で解決できる問題は当然問題ではありません

5.再帰テンプレートをサポートしない

テンプレートを宣言して引用：

<template name="node">
  <text>{{node.text}}</text>
  <block wx:for="{{node.children}}">
    <template is="node" data="{{item}}"></template>
  </block>
</template>

<template is="node" data="{{node}}"></template>

ツリー形データを表示したい：

node: {
  text: 1,
  children: [{
    text: 2
  }, {
    text: 3,
    children: [{
      text: 4
    }]
  }]
}

結果は 1 のみ表示され、再帰的に下向きに表示されず、無限階層構造を表示する必要があるシナリオを満たせません

HTML の解析レンダリング問題を解決するために、誰かが愚かな方法を考えました。n 個のテンプレートをコピーして、順序通りにネストします：

<template name="node-level0">
  <text>{{node.text}}</text>
  <block wx:for="{{node.children}}">
    <template is="node-level1" data="{{item}}"></template>
  </block>
</template>

// copy node-level1
// copy node-level2
// copy node-level3
// ...

こうして何部コピーするかで、何層までサポートできるかが決まります。欠点はテンプレートファイルが巨大になり、維持も問題になりますが、現在はより良い方法がありません

二.プロジェクト Demo

試行後にこのような構造を採用しました：

common/
  cache/        メモリキャッシュ、永続キャッシュ
  components/   共用コンポーネント
  pages/        公用ページ
    detail/
    list/
  request.js    インターフェース包装
config/         定数設定
image/
pages/          各独立ページ
  tab1/
  tab2/
utils/
<3rdLib>/       サードパーティ依存
app.js          エントリー
app.json        アプリケーションレベル設定
app.wxss        アプリケーションレベルスタイル

ページ宣言問題に注意する必要があります：

  • すべての独立ページは、必ず app.json の pages でパスを宣言する必要があります

  • pages の第一项はホームページで、後続でページを増減する場合はすべて pages 設定を修正する必要があります

  • tabBar の第一项は必ずホームページと一致する必要があります。そうでないと tabBar が表示されず、エラーも報告されません

設定関連のいくつかの問題は、エラー報告が全くなく、調査が非常に困難です

HTML サポートライブラリ（999 個の星、HTML 表示ニーズが非常に旺盛であることを示す）を使用しました。HTML を解析し、ミニプログラムネイティブコンポーネントに変換して表示する責任があります

現在はあまり完璧ではなく、解析結果のタグ数が非常に多いです（iOS では明らかなパフォーマンス問題は見つかりませんでしたが、最適化の余地はあります）。また、pre, code, span などのサポート効果が比較的不良で、コード表示効果が良くありません。サービス側でコードを画像に変換でき、一労永逸です。または手動で該ライブラリを完善できます（構造は非常に簡単で、拡張が容易です）

インターフェースが HTTPS になった後、3 日で開発完了しました。写真は以下の通り：

[caption id="attachment_1398" align="alignnone" width="625"]wx_RSSHelper_1 wx_RSSHelper_1[/caption]

[caption id="attachment_1399" align="alignnone" width="625"]wx_RSSHelper_2 wx_RSSHelper_2[/caption]

三.開発体験

長所：

  • 一整套の開発デバッグツールが非常に完備（デバッグ体験が非常に良い）

  • CSS サポート性が非常に良い（H5 から扒がしたスタイルは、基本的に直接使用可能）

  • ES6 開発環境

  • ビジネスフレームワークが受け入れられやすい（データバインディングなどのテンプレート構文は vue に類似）

短所：

  • IDE が非常に使いにくい

  • ドキュメントが不完全（押下状態スタイルをどのように実装するかなど、ドキュメントが全くない）

  • リリースが困難（奇妙なカテゴリ審査、正確なカテゴリが見つかりにくい、審査効率が一般的）

  • 設定化が高すぎて柔軟性がない（一部の機能は設定項目を通じてのみ完成でき、例えば tab 条、比較的手間がかかる）

コメント

コメントはまだありません

コメントを書く