背景
SmartViewは、配信元の記事を抽出し、SmartNewsアプリ内で読みやすい形式に変換する仕組みでした。数百万人が使うアプリの主要な閲覧画面であり、既存パイプラインには配信元ごとの処理が長年にわたって追加されていました。一度に置き換えると、HTML解析の小さな差でもリリース上のリスクになります。
私はSmartView v2のiOS実装をリードしました。抽出処理を改善しつつ、ページや設定が想定どおりに動かない場合には既存レンダラーへ戻せる必要がありました。
並行実装
既存パイプラインを直接変更せず、SmartHTMLExtractorV2を別の実装として作りました。2つの実装を比較しながら、少しずつ利用範囲を広げられる構成です。
新しい抽出処理はSmartHTMLというSwiftモジュールに置きました。SwiftSoupの型をアプリ全体で直接使わず、内部APIでラップしました。HTMLの解析と整理を1か所にまとめ、サードパーティのパーサーが他のレンダリングコードの設計を決めないようにするためです。
パイプラインはバックエンドから配信されるCSSルールを適用し、結果を内部のフォーマットモデルへ変換しました。
ロールアウトとフォールバック
クライアント条件でv1とv2を切り替え、ロールアウト中は両方の抽出処理を使えるようにしました。全ユーザーを一度に新しい処理へ移さず、実際の記事を確認しながら対象を増やせます。
クライアント条件の設定に問題がある場合に備え、stageとproductionのURL選択を含むフォールバックも追加しました。US版と日本版がそれぞれ正しい経路を使うよう、エディションごとのプロキシ処理にも対応しました。画像形式はiOSバージョンを考慮し、条件に応じてJPEGとWebPを選びました。
結果
SmartView v2は、フィーチャーフラグとフォールバックを持つ並行レンダリングシステムとしてリリースされました。既存実装を残したまま、新しい抽出処理を段階的に確認できました。移行中も、既存の記事閲覧機能に不具合を出さずにロールアウトを完了しました。新しいSwiftモジュールによって、Objective-CとSwiftが混在するコードベース内に、今後の解析とフォーマット改善を行うための小さな境界もできました。
次に取り組むこと
次は、v1を削除するために必要な確認項目を先に決めます。代表的な配信元のHTML、各エディション、設定エラー、対応iOSバージョンを確認し、条件を満たしたら旧実装と移行専用の分岐を削除します。