Day: May 4, 2016

Swift:自作フィルタによるコンテンツブロックの実装

アプリに組み込み、アプリとしての評価ができるようにしました。

これまでサンプルプログラムでは、外部フィルタと自作フィルタの両方でコンテンツブロックができるようにしてきました。サンプルプログラムから両方の主要部分を切り出し、アプリに実装しました。一応、両方に対応できるようにしておいて、外部フィルタを使う部分をミュートにしました。これは外部フィルタにアプリで対応したいからでなく、Safariなどのブラウザ向けのコンテンツブロックを実装するとき、ベースプログラムがあった方がいいだろうという考えからです。

ところで、自作フィルタの場合、フィルタの形式を単純化しないとメンテナンスが大変なので、フィルタを任意の配列で定義できるようにしました。アプリで使う実際のフィルタは、その配列から変換して、一度にチェックできるフィルタの個数の最大数を一発で変更できるようにしました。

このあと統計情報を表示できるようにし、そのあとでフィルタの再調査を始めたいと考えています。

紆余曲折がありますが、先に進めてよかったです。

Swift:コンテンツブロックの対応方針を決定

パフォーマンスとメンテナンス性を考えた結果、自作フィルタで対応することにしました。二週間強、検討した結論です。

パフォーマンスの劣化はフィルタの定義に関わっていました。フィルタをきっちり作れば、かなりパフォーマンスは改善できます。

しかし、大量のフィルタを処理してもパフォーマンスが落ちるだけで、期待効果は小さく、フィルタの許可(つまり広告表示やトラッキング・クッキーの透過)がコンテンツブロックのビジネスを構成していることを考えると、これはノイズになる、という結論に至りました。

それで、3年前に実施したトラッキングクッキーやビーコン等の調査結果が今も妥当であるなら、それに沿ってフィルタを作成すればほぼいい線までカバー可能なはずですし、実際、やってみたところその通りでした。それで、今回、もう一度調査しなおし、フィルタのアップデートをすれば、意図通りの結果が出せるはずです。

逆に外部フィルタを利用した場合、仕様の曖昧さ(曖昧な理解)と不規律なフィルタの定義が保守性を悪くする可能性があります。

やりたいことは、あくまで広告ブロックではなく、トラッキングの阻止の方なので、以上の経緯と理由により自作フィルタで進めることにしました。

ことの良し悪しと完全性は別として、この方式だと本当に速いです。コンテンツブロックの処理があっと言う間もなく終わります。