Cydia の次のバージョンに関する最近の投稿で、Cydia 1.1 でどのような機能が欲しいかについて、ユーザーから素晴らしいフィードバックをいただきました。
Cydiaの開発者、Jay “saurik” Freeman氏は、この記事に対し、Cydiaの現状と将来について洞察を与える、長文かつ有益なコメントを投稿しました。彼は記事のコメント欄で提起された多くの質問を選び、主要な問題に取り組んでいます。
saurikさんがこの情報を共有してくださったことに、大変感謝しています。彼はCydiaに関するいくつかの重要なトピックについて触れています…
Cydia 1.1 の機能は次のとおりです:
- Cydiaの実行中にActivator、libstatusbar、SimulatedKeyEventsを実行および操作する機能
- 「変更の読み込み」ダイアログを含む全体的な速度の向上
- メモリ使用量が「大幅に減少」
- 新しい関連性アルゴリズムを備えたより高度な検索メカニズム
- 壊れたリポジトリのより良い管理
saurik が Cydia について語った内容は次のとおりです。
マルチタスク
現時点では単純に不可能です。皆がそれを望んでいることは承知していますし、私も望んでいます。しかし、皆が重要だと言っても、それが実現できるわけではありません。CydiaがiOS 4準拠のマルチタスクに対応していないのは、システムに変更を加えるために「root」として実行されるためです。rootはシステムに対して他のユーザーよりも多くの権限を持つユーザーです。つまり、「mobile」として実行される低レベルのプロセスであるSpringBoardは、Cydiaを一時停止/再開できません。
さて、これは改善できる問題であり、私も長い間その方法を模索してきました。しかし、CydiaのGUIをモバイルとして動作させ、ごく一部のみをroot権限で動作させるという、よく言われるありきたりな方法はどれもCydiaの動作を遅くしてしまいます。そして、速度はCydiaを使う上で誰もが最も重視する点です。幸いなことに、これをより合理的に実現できる方法を思いつきましたが、今回のリリースでは明らかに無理です。
Cydiaを開いているときにMobile Substrateをオンのままにする
もしそうしたら、システムが突然使えなくなるでしょう。Mobile SubstrateがCydiaを含むシステム上のすべてのアプリケーションを変更するというのは、一見するとうわべだけの言い訳に聞こえるかもしれませんが、繰り返しますが、Cydiaはroot権限で動作します。エコシステム内のほぼすべての拡張機能は、このことを考慮して設計されていません。突然root権限を与えられると、設定ファイルやメディアフォルダの権限が破壊され、通常のアプリケーションが使用できなくなります。
そのため、今回のCydiaリリースでは、「重要項目」――Activator（SBSettingsの起動）、libstatusbar（ステータスバーに通知項目を追加）、SimulatedKeyEvents（Veencyからのキーイベントの挿入）――について、開発者と共に、root権限で実行した環境で正しく動作することを確認しました。これらの拡張機能（およびWinterBoard。WinterBoardは4.xではroot権限では動作しませんが、無害であり、将来のリリースで修正される予定です）は、Cydiaがモバイル向けに修正されるまで、Cydia内部から利用できるものです。
より見栄えの良いインターフェースとバックアップオプション
バックアップ機能を実現するために、Cydiaの新規ビルドをプッシュする必要はありません。しかし、Cydiaの負荷に対応できるようユーザー数をどのようにスケールアップするかを検討するには時間がかかります。Cydiaは競合他社よりもはるかに多くのユーザーを抱えているため、「Xがやってくれたから簡単なはずだ」と思われがちな多くのことが、実際にははるかに実装が難しいのです。また、このような機能を開発する際にはプライバシーを最優先に考えており、インストール済み製品リストにあなた以外の誰もアクセスできないように100%の保証をしたいと考えています。
「より見栄えの良いインターフェース」については、Apple製品に匹敵するインターフェースを維持するよう努力しています。4.xではいくつかの不具合（一部のボタンの位置とサイズ）があり、様々な「黒い」インターフェース（黒いバーと黒い画面）については賛否両論ありますが、それ以外では、ユーザーがCydiaで抱える主な問題はCydia自体ではなく、リポジトリにあります。「この部分がダメだ」というフィードバックを実際に受け取った時、それはApple自身がiTunesやApp Storeのアプリケーション（「直感的なモデル」と捉えるべきもの）で行っていることではなく、私が全く制御できないインターフェースの領域、つまりリポジトリによってパッケージに表示されるコンテンツに関するものでした。
「変化」という言葉の混乱
「もしかしたら私がおかしいのかもしれませんが、私はずっと「変更」という言葉を、あまりオタクっぽくないエンドユーザー向けの「変更されたもの」を表す言葉だと思っていました。これは確かに専門用語ではありません。コードベースをUIに合わせたいというオタク的な願望から選ばれたわけでも、ラテン語やギリシャ語で難解な意味を持つから選ばれたわけでもありません。私が話したほとんどの人にとって、そのページが何をしているか、つまり何が変更されたかを示すことを即座に意味する単語だったからです。いずれにせよ、「新規リリース/アップデート」はタブラベルには収まりきらないでしょう。」
スピード
Cydia のすべてのリリースと同様に、Cydia 1.1 は以前のリリースよりも高速です。具体的には、1.0.3366 よりも大幅に高速化しており、1.0.3366 自体も 1.0.3222 よりもさらに大きな差で高速化していました。しかし、この点に関して重要なのは、Cydia が難しい問題に取り組んでいることです。これまで iPhone で目にした Apple 製、あるいはサードパーティ製のアプリケーションで、ユーザーが選択したソースから集約された数万ものデータ項目をクライアント上でリアルタイムに検索し、インデックス化し、管理しようとしているものは他にありません。
対照的に、Cydia は、カスタム アルゴリズム (Cydia にはロケールを認識する文字列比較基数ソートが含まれており、私の知る限り、これは iOS アプリケーションで最速のソート アルゴリズムです) や特殊なオンディスク データ構造 (1.1 の新機能である「Cytore」は、フラッシュからほぼ瞬時にロードできるパッケージにローカル メタデータを保存する新しい方法です。技術に詳しい方のために説明すると、これはディスク上のメモリにマップされたハッシュ テーブルであり、SQLite などのよく持ち出されがちな代替手段を大幅に上回ります) など、このデータの処理に関して現存する最速のテクノロジのいくつかを備えています。
読み込み時間
誤解されているように、変更リストに表示されるデータ量は、読み込み速度に劇的な影響を与えません。Cydia 1.0の多くのバージョンには、リスト上の項目数に応じて多少の遅延が発生するバグがありましたが、このバグは1.0.3366で既に修正されています。計算コストは、リストにどの項目を含めるか（具体的には、どれがアップデートでどれが新規リリースか）を決定することであり、すべてを一度に表示することではないのです。とはいえ、Cydia 1.0.3366では変更の読み込みがタブをクリックするまで行われるため、この機能にどれだけの時間が費やされているかがより明確になります（この機能自体は、1.1ではさらに高速化されています）。
メモリ使用量
Cydia 1.1はメモリ上で数万ものアイテムを操作し続けていますが、Cytoreのおかげで、メモリ使用量は以前よりもはるかに少なくなっています。Cydiaの他のバージョンと同様に、アプリ全体のメモリ使用量を削減するための最適化も行われています。さらに、特にCydia 1.1はメモリ警告をより慎重に扱い、これらのイベント発生時に可能な限り多くの状態を破棄しようとします。
とはいえ、比較的新しいデバイス（iPhone 3G以降）でも、アプリケーション実行に利用できるメモリ量（総メモリ量ではなく、Appleのシステムアプリケーションが割り当て分を受け取った後のメモリ量）は桁違いに大きい。iPhone 3Gでは20MB程度だったのに対し、iPhone 3G[S]では150MB、iPhone 4では400MBのメモリが利用可能だ。つまり、Cydia 1.1はCydia 1.0よりも動作に必要なメモリ量が少ないにもかかわらず、メモリへの負荷はほぼ解消されており、ハードウェアのアップグレードによって将来のユーザーに影響が出ることもないだろう。
詳細検索
残念ながら、このデバイスは「高度な検索機能」を提供するにはあまりにも遅く、「ユーザーが選択したリポジトリから」「ほぼリアルタイムで」という制約を考えると、提案機能を提供するのは言うまでもありません。とはいえ、Cydia 1.1にははるかに優れた検索メカニズムがあり、私が実装した整数演算基数ソートの関連性アルゴリズムも含まれています。
本当に素晴らしい検索体験を実現するために本当に必要なのは、クライアントで検索を行うのではなく、サーバー上で処理することです。App Store、Kindle、Netflixといった製品はまさにこの仕組みで動作します。ユーザーが慣れ親しんでいるサービスでは、クラウド上の巨大なサーバー上にオフラインでインデックス化された検索構造でデータと計算処理をするのではなく、デバイス上でデータベース全体を管理し、ローカル検索を行うという手法は全く一般的ではありません。
残念ながら、人々が Cydia を使用する理由はさまざまであり、率直に言って使用すべきでないリポジトリで Cydia を使用している人がたくさんいます。リポジトリに危険なソフトウェア (最小限のテストしか受けていない微調整のあるニッチなコミュニティ、またはディスク上のファイル パッチなどの不適切なプラクティスを使用しているもの) やまったく違法なソフトウェア (自分の国では許可されていても自分の国ではできないことがある) が含まれているかどうかに関係なく、私は間違いなく、人々がこのコンテンツを見つけて管理するための集中型ストレージおよびインデックス作成ゲートウェイとして機能するつもりはありません。
むしろ、人々が Cydia に戻ってくる理由は、それが根本的な代替手段として機能しているという事実です。つまり、注意深くキュレーションされた集中管理されたエクスペリエンスを提供する Apple に行く代わりに、Cydia という「ソフトウェアの荒野」に行くのです。そこでは、ソフトウェアが他のソフトウェアを無謀な放棄の形で変更するため、最良のシナリオでさえも苦痛をもたらし、最悪の場合、デフォルトのリポジトリにリストできないもの、インストール時に Cydia から警告が出るものなどが生成されますが、それでも Cydia の検索メカニズムを使用してアクセスしたり検索したりすることはできるはずです。
エラーメッセージ
CydiaのエラーはCydia自身から発生するものではありません。壊れたリポジトリのURLをCydiaに入力すると、そのリポジトリは低品質になり、問題を引き起こします。もしオフラインであれば、Cydiaはそれを通知し、不正な形式であればCydiaはそれに対して怒ります。Cydiaは、壊れたリポジトリやオフラインのリポジトリが大量にリストに表示されている間、ただそこにいるだけです。壊れたリポジトリを削除して、元の状態に戻ってくれることを期待して、関連するエラーをすべて表示します（これは非常に適切な比喩です。ほとんどのサードパーティ製リポジトリは非常に遅く、更新に非常に長い時間がかかります）。
「評価」と「レビュー」セクション
実際、私たちはこれを試してみましたが、惨めな失敗でした。レビューの大半は誤解を招くもの、扇動的、またはまったく不適切なものだったので、このメカニズムから得られる価値よりも、レビューのモデレーションに多くの時間を費やす必要がありました。悪いレビューで悪名高いApp Storeよりもさらにひどい状況でした（人々はしばしば根拠のない理由でパッケージを低く評価し、データがひどく無効になります）。
これらの問題を考慮して、私は、Cydia でコメントと評価がどのように機能するかについてのビジョンをまとめようとし、試験的な実装も行いました (スクリーンショットがいくつか配布され、いくつかのカンファレンスでデモも行いました)。しかし、リリースを検討しているという話が持ち上がったとき、エコシステムの優秀な開発者の一部 (非常に良いレビューを与えたいと思う可能性が高い人々) から、以前の問題のために、このまま続ければエコシステムをあきらめるだろうという強い反発を受けました。
そして、正直に言うと、私がそれらの問題を解決できたかどうかはわかりません。その後の代替製品の使用経験や、人々が評価をどのように使用したか、コメントで何を言ったか、そして最終的にどのように評価されたかを考えると、もはや私は解決できたとは思えません。既製の「コメントと評価」という概念は、本質的に悪用につながる、根本的に欠陥のあるシステムであると私は考えています。
全てのレーティングシステムが「既製品」である必要はありません。ですから、真に革新的で「実際に問題を解決する」ものを、いつかCydiaに提供したいと思っています。しかしながら、当面は、私たちのエコシステムに重大な非最適なトレードオフを持ち込まないように常に最善を尽くしています。
互換性リストの改善
「Cydia には以前から、リポジトリがこの問題を解決するのに役立つ数多くの機能が含まれていました。
- パッケージのファームウェアの互換性を指定するためのメカニズム (パッケージは特定のファームウェア リビジョンに依存できます)。
- Cydia ストアでは、ベンダーが特定のファームウェアの購入をブロックできます (有料製品はリポジトリとの互換性を登録でき、その後、使用できるユーザーにフィルターをかけます)。
- ファームウェアのバージョンは、各製品の Web ページにユーザーエージェントの一部として送信され、開発者は独自の警告を表示できます。
- 互換性は機能検出によってさらに特別に実現可能になり、パッケージは「armv7 CPU と Retina スクリーンを搭載し、カメラを搭載したデバイスでボイスオーバーのサポートが必要です」と言うことができます。
本質的には、Cydiaエコシステム内のパッケージ、リポジトリ、製品、その他あらゆるものがファームウェア互換性に関して適切に規定されていないという言い訳はほとんどありません。とはいえ、エコシステム内のパッケージのほとんど、そして（これが最も重要だと想像される）製品でさえ、これらのレベルのいずれかでこの情報が含まれていることはほとんどなく、これは非常に残念です。
したがって、Cydia 1.1 ではこれらのメカニズムのいずれも改良しようとはしません。Cydia 1.0 には既に十分すぎるほどのメカニズムが備わっているからです。実際の責任は、特定のアイテムの開発者とアーティストにあります。」
デッドコンテンツの削除
Cydiaで利用できるコンテンツについて、私には一切の権限がありません。つまり、個人的に金銭を受け取ることを拒否することはできますが、開発者のウェブサイトで無料または販売されているものについては、ほとんど内省できません。何年もの間、リポジトリに古いパッケージを削除するよう求めてきましたが、彼らは拒否しました。あなたと同じ意見で無力な私に働きかけるのではなく、これらの苦情はデフォルトのリポジトリであるBigBoss、ModMyi、ZodTTDに送るべきです。
インストール要件の明確化
(アプリや調整などのインストールにスプリングボードの更新が必要か、デバイスの再起動が必要かを示すタグ)
よく言われることですが、このメカニズムは実際にはそうではありません。パッケージはインストール時に再起動またはリロードが必要かどうかを計算し、「ユーザーがこのファームウェアバージョンを使用しており、この設定で他のパッケージがインストールされている場合のみ再起動が必要」といった最適化を可能にします。実際、このような機能を必要とする私のパッケージはすべてこれらの最適化を試みており、そのおかげで再起動やリロードの回数が少なくなることがよくあります。
したがって、パッケージに静的タグとしてこれを指定すると、ユーザーが不必要に再起動しなければならない回数が増えてしまいます。とはいえ、MMSクライアントのように、再起動が必要なことが明確でないパッケージ（拡張機能はリロードが必要で、MobileSubstrateも再起動が必要）の場合、開発者がこの情報をパッケージ情報画面に表示することがベストプラクティスとなるはずです。これは開発者/ベンダーにとって、パッケージを変更するよりも容易であり、パッケージを変更する場合でも非常に稀です。したがって、タグを追加しても、報告される頻度は変わりません。
レポ管理
正しく追加されなかったリポジトリに関しては、Ryan Petrich氏が述べたように、Cydia 1.1では、壊れたリポジトリが使用不能になり、削除もできなくなるという状況は発生しなくなりました。ただし、多くのユーザーからパッケージ経由でインストールされたリポジトリについて苦情が寄せられています。これらのリポジトリを削除するには、それらに対応するパッケージを削除する必要があります。
(これらの複雑さのため、Cydia の今後のポリシーでは、パッケージ経由でデフォルトのリポジトリからリポジトリをインストールすることはできません。また、More Sources の下にある既存のリポジトリは、追加された新しい処理メカニズムに移行されます。このメカニズムにより、近々改良される More Sources ページを使用して、リポジトリをより直接的、シンプル、かつ安全に操作できるようになります。)」
サウリック氏の締めくくりのコメント、
「ところで、Cydia に興味を持ってくださった皆様、ありがとうございます。Cydia 1.1 にどんな機能があって、どんな機能がないのかを気にかけてくださっていることは、プロジェクトに携わるすべての人にとって大きな意味があります。」
読者の質問に詳細かつ有益なご回答をいただいたsaurik氏に心から感謝申し上げます。彼と彼のチームがCydiaを最高のものにしていくことを心よりお祈り申し上げます。
この長々とした議論から、少しでも何か学んでいただけたなら幸いです。saurikさんの意見について、ぜひ下のコメント欄で議論したり、意見を共有したりしてください。
