bggrgjqaubcoe/piliplus

Purpose and Entrypoints

PiliPlus is a Flutter third-party Bilibili client for Android, iOS, Windows, Linux, and macOS. The Dart application starts at lib/main.dart; application routing is centralized in lib/router/app_pages.dart. Native host shells bootstrap Flutter per platform, notably android/app/src/main/kotlin/com/example/piliplus/MainActivity.kt, linux/runner/main.cc, and windows/runner/main.cpp.

Application Shell, Navigation, and Feature Pages

The app is organized as a large route-driven client: page directories generally pair controller.dart with view.dart, while shared layouts and reusable UI live separately. Main/tab composition is represented by lib/pages/main/controller.dart, lib/pages/main/view.dart, and shared shell components such as lib/common/widgets/main_layout.dart. Major domains include home/discovery, user/account, dynamic posts, search, live rooms, messaging, favorites, settings, and video.

Network and Bilibili API Boundary

REST-like Bilibili interactions are concentrated in lib/http/, with API initialization and shared request behavior rooted in lib/http/init.dart, lib/http/api.dart, and lib/http/retry_interceptor.dart. Domain modules such as lib/http/video.dart, lib/http/live.dart, lib/http/login.dart, and lib/http/dynamics.dart isolate endpoint operations from page controllers. This is the primary boundary to Bilibili’s external services; requests must handle authentication, signing, retries, and API-specific errors.

gRPC Protocol Integration

Generated Bilibili protocol models and hand-written request wrappers form a parallel transport layer under lib/grpc/. Core dispatch/request construction is in lib/grpc/grpc_req.dart; domain accessors include lib/grpc/view.dart, lib/grpc/reply.dart, and lib/grpc/dyn.dart. Generated protobuf contracts, for example lib/grpc/bilibili/app/viewunite/v1.pb.dart, should be treated as generated integration artifacts rather than application-domain code.

Account, Session, and Persistent State

Multi-account and cookie/session concerns are encapsulated under lib/utils/accounts/, especially lib/utils/accounts/account_manager/account_mgr.dart, lib/utils/accounts/grpc_headers.dart, and lib/utils/accounts/cookie_jar_adapter.dart. General local persistence is abstracted through lib/utils/storage.dart, lib/utils/storage_pref.dart, and lib/utils/storage_key.dart. Page controllers consume these facilities rather than directly managing credentials or storage formats.

Media Playback, Danmaku, and Downloads

Playback is a first-class subsystem, centered on the custom player plugin at lib/plugin/pl_player/controller.dart and lib/plugin/pl_player/view/view.dart. Video orchestration is in lib/pages/video/controller.dart and lib/pages/video/view.dart; it connects play URLs, settings, subtitles, danmaku, gestures, and content metadata. Background/offline media handling is separated into lib/services/download/download_manager.dart and lib/services/download/download_service.dart. Platform-specific Android media support exists in android/app/src/main/java/com/example/piliplus/MediaHelper.java; shader assets support optional video enhancement under assets/shaders/.

Data Models and UI Rendering Boundary

Response/domain serialization is split between legacy models in lib/models/ and broad endpoint-specific DTOs in lib/models_new/, e.g. lib/models_new/video/video_detail/data.dart and lib/models_new/live/live_room_play_info/data.dart. Controllers translate these API models into page state; views render them using common UI primitives from lib/common/widgets/. This separation is important because API schemas, transport code, and visual components evolve at different rates.

Runtime, Packaging, and Delivery

Flutter/Dart is the shared runtime, with Android Gradle, iOS/macOS Xcode, and Linux/Windows CMake host infrastructure. Android also exposes native helper bridges through android/app/src/main/java/com/example/piliplus/AndroidHelper.java and Dart bindings in lib/utils/android/bindings.g.dart. CI builds platform artifacts via .github/workflows/build.yml and platform workflows. Desktop packaging is explicitly represented by assets/linux/DEBIAN/control and windows/packaging/exe/inno_setup.iss.