続・Electron製アプリが Mac App Storeで non-public APIの利用で rejectされる問題。解決しそう

AppStoreのレビュー通ったって

前回
Electron製アプリが Mac App Storeへの申請で non-public APIの利用で rejectされる問題
https://taku-o.hatenablog.jp/entry/2019/11/03/103422


Electronがnon-publicなAPIを利用していたので、
Electron製のアプリがみんなrejectされている問題があったのだけれど、
最新コードでAppStoreのレビューが通ったそうで、解決のメドがたったみたい。
https://github.com/electron/electron/issues/20027


もうちょっとで修正が利用できるようになるのでしょう。
https://github.com/electron/electron/pull/20965


でも、Electron 5以降が対象なんだ

Electronのバージョン4以下は、サポート打ち切られています。
当然修正は用意されない!


Electron 4用のPull Requestも作られたけど、
一瞬でcloseされたよ!!
https://github.com/electron/electron/pull/21003


私が使ってたのは3.1.9だったので、 このままでは修正が用意されないのですね。
Electron 3、Electron 4使っている人は、
Electronのバージョン上げましょうね。


というわけでElectron 5までバージョン上げたよ

というわけで、ここ数日は、
アプリで使っている Electronのバージョンアップに励んでいました。


Electronを追っている人は知っていると思うけど、
Electronはバージョン上げて、すんなり動いたりしないのですよ。


自分の場合、3.1.9 → 5.0.12で、次のような問題があった。
(Electron 6への移行も検討してたので、Electron5用の対応と、Electron6用の対応が混在してるよ)


node-ffi が Node 12 でビルドできない

もっとも古いElectron 5でも、Node 12.0.0です。

# リリースノートから
Upgraded to Chromium 73.0.3683.119, Node.js 12.0.0, and V8 7.3.492.27.

node-ffiというネイティブライブラリを実行できるモジュールがあり、 今までこれを利用していたのですが、
このライブラリはNode 12ではビルドできない。
開発が止まっている。
https://github.com/node-ffi/node-ffi


自分はいろいろ検討した結果、node-ffi-napiに移行しました。
とても良い感じ。
https://github.com/node-ffi-napi/node-ffi-napi


menu item role

Electronのメニュー定義のrole定数が大文字小文字で変わっていたり。
こんな感じであちこち。
Typescriptでコンパイル時にエラーになってた。

# 抜粋
- {role: 'zoomin'},
- {role: 'zoomout'},
- {role: 'resetzoom'},
+ {role: 'zoomIn'},
+ {role: 'zoomOut'},
+ {role: 'resetZoom'}


Spectron

remote-debugging-portを指定しないと、
Spectronのテストコードが動作しなくなった。

# 抜粋
describe('dictWindow', function() {
  this.timeout(10000);

  before(function() {
    this.app = new Application({
      path: 'App-darwin-x64/App.app/Contents/MacOS/App',
      chromeDriverArgs: ['remote-debugging-port=9222'], ←←←←←← これ!
      env: {DEBUG: 1, NODE_ENV: 'test'},
    });
    return this.app.start();
  });


electron-packager

electron-packagerでアプリパッケージを作っているのですが、
Electron 6あたりで、Electronの作りが結構変わっているようですね。
古いバージョンのelectron-packagerを使っている人はアップデートが必要でしょう。
https://github.com/electron/electron-packager


一部ファンクションが非同期になってた

例えば、

dialog.showMessageBox

これが同期から非同期処理になってたり。


そういう変更は、リリースノートの
Breaking Changesの項に置いといて欲しい。


ばっちこい

準備完了だ。
はやくこいこいアップデート。

AquesTalk1 MacがmacOS Catalinaで32bitサポート打ち切られて動かなくなったけど、なんとかした話

ながれ

  1. AquesTalkという機会音声を作るライブラリがある
  2. macOS Catalinaで32bitアプリのサポートが打ち切られた
  3. AquesTalk1 Macのライブラリは、i386ppcuniversal binaryだったので、
  4. macOS Catalinaで無事、動作しなくなった

ちょっと頑張ってみた

macOS Catalina以降から使える機能に、
iPadアプリをMacアプリとして動かす、"Mac Catalyst"という機能があり、
当初はこれを使って、なんとかする予定でした。
iPadアプリを作ってからの、Macアプリへの変換。


しかし、その最中、iOS版のAquesTalkを、
Macアプリでそのまま実行できることに気づいたのであった。
DE・KI・TA

(今時の開発者は動画も作るらしいよ)


おわり

AquesTalk1 Macの声作る関数がこれで、

unsigned char * AquesTalk_SyntheMV(int idVoice, const char *koe, int iSpeed, int *size)

AquesTalk1 iOS版の声作る関数がこれだから、

unsigned char * AquesTalk_Synthe(const char *koe, int iSpeed, int *size)


あれあれ、なんか足りないなー?
声(idVoice)選べないなー?
という問題が、この回避方法にはあるような無いような。

Electron製アプリが Mac App Storeへの申請で non-public APIの利用で rejectされる問題

Electron製アプリがrejectされている

Electronプロジェクトの、このGitHub issueで気づいたのですが、

どうもここ最近、具体的には、10月末から
Electron製のアプリが、Mac AppStoreでrejectされています。
issueのタイトルは5.0.10となっていますが、
別に5.0.10でなくてもrejectされています。


このあたりのAPIがprivate APIで、
これらをElectronが使用しているから、らしい。

CAContext
CALayerHost
NSAccessibilityRemoteUIElement
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings


これらのAPIはいつから使われている。

古くから使われている。
Electron 3だと、次の3つが入っているようだ?

CAContext
CALayerHost
NSURLFileTypeMappings


そう何を隠そう、私もreject喰らったのである。
他の人がどうしているのか探したらわかったのである。


どうする?

どうしよう?
少し困る現象でありますね。

PhantomJSの代わりとしてGoogle Chromeをヘッドレスで使う。のではなくChromiumを使う。

PhantomJSの開発が止まってしまった

PhantomJSブラウザの開発が止まってしまいました。
npmでさくっと導入できるヘッドレスなブラウザで、
テストの時に便利だったのですけれどね。

Google Chromeをヘッドレスモードで使う?

そこで、代わりに、Google Chrome
ヘッドレスモードで使おうっていう考えがあります。


ただー。
PhantomJSはnpm installでインストールできた。
Google Chromeはインストールが面倒くさい。


Google Chromeのインストールは、Macなら次のURLからインストールする


Ubuntuなら、こんなインストール手順になりますかね。

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo dpkg -i google-chrome-stable_current_amd64.deb
sudo apt-get update
sudo apt-get -f install


そこでChromium

npmでChromiumをインストールする

npm install --save-dev @taku-o/chromium


とりあえず、CHROMIUM_VERSIONでバージョン指定できるようにしておいた。
が、どうやってバージョン指定できるようにしようかなぁ、ってのは
迷いどころである。

CHROMIUM_VERSION=76 npm install --save-dev @taku-o/chromium


これはWebdriverIOのテストコードなのですけれど、
おおよそChromeを使うように設定を組んでおいてから、
実行時に、Chromeの代わりにChromiumのパスを渡す感じになりますな。

# wdio.conf.js抜粋
var chromium = require('@taku-o/chromium');

exports.config = {
    ...
    capabilities: [{
        browserName: 'chrome',
        'goog:chromeOptions': {
            args: ['--headless', '--disable-gpu'],
            binary: chromium.path,  // ←←←←←←←←←← ここに注目
        },
    }],
    ...


サンプルコードと手順

mkdir webdriverio_chromium-test-samples
cd webdriverio_chromium-test-samples
npm init
mkdir -p ./test/specs
npm install --save-dev @wdio/cli @wdio/cli @wdio/local-runner @wdio/mocha-framework @wdio/spec-reporter @wdio/sync wdio-chromedriver-service chromedriver
npm install --save-dev @taku-o/chromium

# WebdriverIOのテストコード作成
vim test/specs/basic.js

# テストの設定作成
vim wdio.conf.js

# テスト実行
./node_modules/.bin/wdio wdio.conf.js
  • 実行結果
Execution of 1 spec files started at 2019-09-01T11:32:10.850Z

2019-09-01T11:32:10.886Z INFO @wdio/cli:Launcher: Run onPrepare hook
Starting ChromeDriver 76.0.3809.126 (d80a294506b4c9d18015e755cee48f953ddc3f2f-refs/branch-heads/3809@{#1024}) on port 4444
Only local connections are allowed.
Please protect ports used by ChromeDriver and related test frameworks to prevent access by malicious code.
2019-09-01T11:32:11.651Z INFO @wdio/local-runner: Start worker 0-0 with arg: wdio.conf.js
[0-0] RUNNING in chrome - /test/specs/basic.js
[0-0] 2019-09-01T11:32:12.089Z INFO @wdio/local-runner: Run worker command: run
[0-0] 2019-09-01T11:32:12.145Z INFO webdriver: [POST] http://127.0.0.1:4444/session
[0-0] 2019-09-01T11:32:12.146Z INFO webdriver: DATA { capabilities:
   { alwaysMatch: { browserName: 'chrome', 'goog:chromeOptions': [Object] },
     firstMatch: [ {} ] },
  desiredCapabilities:
   { browserName: 'chrome',
     'goog:chromeOptions':
      { args: [Array],
        binary:
         '/Users/taku-o/Desktop/webdriverio_chromium-test-samples/node_modules/@taku-o/chromium/lib/chromium/chrome-mac/Chromium.app/Contents/MacOS/Chromium' } } }
[0-0] 2019-09-01T11:32:12.879Z INFO webdriver: COMMAND navigateTo("https://webdriver.io/")
[0-0] 2019-09-01T11:32:12.880Z INFO webdriver: [POST] http://127.0.0.1:4444/session/a296b1e791776ba38f9de341c0985c1e/url
[0-0] 2019-09-01T11:32:12.881Z INFO webdriver: DATA { url: 'https://webdriver.io/' }
[0-0] 2019-09-01T11:32:14.932Z INFO webdriver: COMMAND getTitle()
[0-0] 2019-09-01T11:32:14.933Z INFO webdriver: [GET] http://127.0.0.1:4444/session/a296b1e791776ba38f9de341c0985c1e/title
[0-0] 2019-09-01T11:32:14.938Z INFO webdriver: RESULT WebdriverIO · Next-gen WebDriver test framework for Node.js
[0-0] 2019-09-01T11:32:14.940Z INFO webdriver: COMMAND deleteSession()
[0-0] 2019-09-01T11:32:14.941Z INFO webdriver: [DELETE] http://127.0.0.1:4444/session/a296b1e791776ba38f9de341c0985c1e
[0-0] PASSED in chrome - /test/specs/basic.js
2019-09-01T11:32:15.105Z INFO @wdio/cli:Launcher: Run onComplete hook

 "spec" Reporter:
------------------------------------------------------------------
[chrome  mac os x #0-0] Spec: /Users/taku-o/Desktop/webdriverio_chromium-test-samples/test/specs/basic.js
[chrome  mac os x #0-0] Running: chrome on mac os x
[chrome  mac os x #0-0]
[chrome  mac os x #0-0] webdriver.io page
[chrome  mac os x #0-0]    ✓ should have the right title
[chrome  mac os x #0-0]
[chrome  mac os x #0-0] 1 passing (2.1s)

Spec Files:      1 passed, 1 total (100% completed) in 00:00:04 


おわり

一気にやっちゃったけど、

いや、こっち使うべきかな

github.com

ボタンを長押ししたら、ショートカットキーのヒントを表示する

⌘キーを長押しした時、ショートカットのヒントアイコンを表示する

SlackのMacアプリが
⌘キーを長押しすると「⌘キー+数字キー」のショートカットの
ヒントを表示するなんてことをやってまして、

→ (ふわっと出てくる)


これは良いUIだと思ったのです。


要件

  • ⌘キーを長押ししたらアイコンを表示する
  • キーを離したらアイコンを消す


実装

こんな感じかな?

  • CSS変数で表示を切替。
  • ボタンを押してから、1秒後にアイコンを表示する。
  • ボタンを放したら、アイコンを消す。もしくはアイコン表示のアニメーション(?)を止める。
  • フォーカスが外れた時もアイコンを消す処理を入れておいた方が良さそう
    • これで長押しを表現。
    • 今はタイマーで表示制御とか、要らないんですね。


<html>
<head>
    <style>
        button {
            width: 200px;
            height: 50px;
        }

        :root {
            --shortcut-hint-delay: 1s;
            --shortcut-hint-opacity: 0;
        }
        .shortcut-hint-container {
            position: relative;
        }
        .shortcut-hint {
            position: absolute;
            width: 10px;
            left: 3px;
            top: calc(100% - 12px);
            z-index: 1;
            vertical-align: middle;
            text-align: center;
            line-height: 10px;
            font-size: 9px;
            color: white;
            background-color: black;
            border-radius: 2px;
            transition-delay: var(--shortcut-hint-delay);
            opacity: var(--shortcut-hint-opacity);
        }
    </style>

    <script>
        var hintDisplayed = false;

        window.addEventListener('keydown', function(e) {
          if (e.metaKey) {
            hintDisplayed = true;
            document.documentElement.style.setProperty('--shortcut-hint-delay', '1s');
            document.documentElement.style.setProperty('--shortcut-hint-opacity', '1');
          }
        });
        window.addEventListener('keyup', function(e) {
          if (hintDisplayed) {
            hintDisplayed = false;
            document.documentElement.style.setProperty('--shortcut-hint-delay', '0s');
            document.documentElement.style.setProperty('--shortcut-hint-opacity', '0');
          }
        });
        window.addEventListener('blur', (e) => {
          if (hintDisplayed) {
            hintDisplayed = false;
            document.documentElement.style.setProperty('--shortcut-hint-delay', '0s');
            document.documentElement.style.setProperty('--shortcut-hint-opacity', '0');
          }
        });
    </script>
</head>
<body>
    <div class="shortcut-hint-container">
        <button>保存ボタン</button>
        <label class="shortcut-hint">S</label>
    </div>
</body>
</html>



おわり

おわりだん。

AutoMator Actionの「Finder項目にフィルタを適用」はキャッシュを持っている(みたい)

遭遇した問題

MacAutoMatorという作業自動化アプリがあるのだが、

そのAutoMatorで使用できる、
「Finder項目にフィルタを適用」というアクションは、


(おそらく)実行結果のキャッシュを持っていて、
何度も何度も繰り返し処理を実行するような場合、
最新のフィルタリング結果が次のアクションに渡されない。

過去の実行結果が渡ってしまう。


よって、例えば、フォルダーアクションなどで、このフィルタリングを使うと、
・フォルダーにファイルを追加しても検知されない、
・その追加したファイルに対する処理がスルーされる、
などの問題がしばしば発生する。
発生した。


(これがうまくいかない)


対応方法

この実行結果のキャッシュの問題は、
「Finder項目にフィルタを適用」を「シェルスクリプトを実行」に置き換えて、
シェルスクリプトでフィルタリングしてしまえば解決する。

# 拡張子wavのファイルに絞って、次のアクションに回すシェルスクリプト
while read line; do
    if expr "$line" : ".*.wav$" > /dev/null
    then
        echo "$line" >&1
    fi
done


(こんな感じに)


おわり

案外、この問題には苦戦した。

Electronアプリの起動時間短縮に挑む

アプリが起動するまでの時間が短いと気持ちいい

アプリの起動は最初の一回しか発生しないのに、
その後はアプリは起動しっぱなしなのに、
この最初の起動までの時間が短いと、アプリの使用感が非常に良くなるような気がする。 気がしない?


この記事はElectronアプリの起動速度を速くするために
いろいろやったことと、その結果の記録です。
環境はMacのElectronです。


なお計測はしていたが、記録はない。
各仕組みの導入の前後で結構コードが変わってしまって、
計測の仕方も変わってしまって、
あとバイナリは残っているから調査可能だけど、面倒くさいからであります。


初回起動時の記録は捨てとこう

ところでElectronのアプリって、
ビルド後初回の起動より、2回目・3回目の方が早く起動しますね。
計測して起動時パフォーマンスチューニングするなら、初回の記録は捨てときましょ。


やったことリスト

  • require文の書き換え・遅延ローディング
  • ファイルの統合・分割・minify
  • コールバック・Promise
  • 設定ファイルを同期・非同期で読み込む
  • 設定ファイルの読み込みのタイミングをずらす
  • Electronのバージョンを変更する
  • アプリ起動時の見た目をごまかす


require文の書き換え・遅延ローディング

require文を書き換えて、ライブラリを遅延ローディングするように変更する。
すごく効く。効いた。

var log = require('electron-log');
log.error('error found.');

↓例えば、こう書き換える

var _log, log = () => { _log = _log || require('electron-log'); return _log; };
log().error('error found.');


ファイルの分割・統合・minify

Electronアプリで使用しているファイルを、

  • Webpackなどで1つにまとめたり、
  • 逆に細かく分割してファイル1つあたりを軽量にしたり、
  • ファイルをminifyしてファイルのサイズを小さくしたり。

asarに固めたElectronアプリでは効かない

全然全然本当にまったく効果なかった。
まったく効果がないので、余計な手間がビルド時に発生する分、マイナスまである。

何度となく諦めきれずに試したが、そのたびにまったく効果がないと知ることとなった。
でも、私はきっとまた試すよ。


コールバック・Promise

コールバックとPromiseは、コールバックの方が早い。
世間の流れと逆方向でありますね。

でも、仕方ない。
アプリの起動時には、ほんの僅かでも速度が欲しいのであります。
効く

// Promise
hoge().then((data1) => {
  foo(data1).then(data2) => {
    // 何かやる
  });
});
// コールバック
hoge((data1) => {
  foo(data1, (data2) => {
    // 何かやる
  });
});


設定ファイルを同期・非同期で読み込む

設定ファイルを読み込む処理があるとして、

  • 非同期で設定ファイルを読み込むより、
  • 同期で設定ファイルを読み込む方がかなり早い


早いが、もちろんデメリットあり。
アプリの処理によっては、処理がブロックされて逆に遅くなるでしょう。

更に更に、
例えば、設定ファイルがJSONであるなら、
こんな感じにrequire文を使って読み込むと、
同期での設定ファイル読み込みより更に早かったのですけど、
これはセキュリティ的な問題があるでしょうな。

var dataJson = null;
try {
  // data.jsonの読み込み
  dataJson = require(`${app.getPath('userData')}/data.json`);
} catch (e) {
  dataJson = [];
}
// 読み込み終わったらキャッシュ消しておく
delete require.cache[`${app.getPath('userData')}/data.json`];


設定ファイルの読み込みのタイミングをずらす

私はAngularを使用しているのですけど、
Renderer Processで画面を描画中に設定ファイルを読み込もうとすると、
同期であろうと非同期であろうと、ものすごく遅くなる。

その描画中の範囲を外して設定ファイルを読み込むようにすると
めちゃくちゃ早くなる。
とても良く効く


自分の環境では、同じ処理が実行タイミングの違いで、これくらい効いた。

1秒 → 0.002秒


Electronのバージョンを変更する

少し効く
Electronのバージョンを3から4にする。
何度も計測した結果、ちょっぴり早くなっていると思う。
ちょっぴり。

でも、Electronのバージョンは、あまり選択可能な要素ではないですね。

私はまだElectron4で安定動作させられなかったので、
Electron3に戻しちゃいましたけど、
いろいろ問題解決したら、もちろんElectronのバージョンを上げておきたい。

もうElectronの5が出てる?気のせいでしょ。


アプリ起動時の見た目をごまかす

設定ファイルからデータを読み込んで、 読み込み終わった順にそのデータでビューを更新すると、
画面がちらちら更新されて、体感、アプリの起動が遅く感じる。

一括でパッと表示した方が早く感じる。操作できるまでの時間変わらなくても。

設定ファイルの読み込み順と、読み込みタイミングの考慮は要るけれど、
手間暇かけると、アプリの起動時間の体感は良くなる。


おわり

おわりだよー。