Fair 2.0 Hot Update Design and Implementation

Background

Because every client‑side release must pass app‑store review, urgent bug fixes or rapid feature launches often get delayed, leading to economic loss or missed market opportunities. Consequently, hot‑update has become a hot topic in mobile development.

Industry Hot‑Update Landscape

Various solutions exist, many open‑source, some internal, and some blocked by platforms (especially Apple). iOS native dynamic libraries are restricted by code signing; JavaScriptCore‑based approaches like JSPatch were popular but later restricted by Apple. Other schemes include DynamicCocoa (compile‑time conversion to JSON/JS), virtual‑machine‑based QQ, and bundle‑based React Native.

Why Fair?

Built on Flutter, a cross‑platform UI framework with high performance and a single codebase for iOS and Android.

Flutter’s open‑source nature makes source‑to‑custom code conversion straightforward.

Fair’s integration cost is lower than React Native because Flutter’s architecture allows quick onboarding.

Fair, like DynamicCocoa, compiles source code into JSON (UI) and JS (logic) files, avoiding the need for a custom VM and reducing the risk of Apple rejection. Its update process resembles RN’s bundle delivery but with lower overhead.

Overall Fair Hot‑Update Process

Flutter source is compiled into JSON and JS files, packaged into a ZIP.

The ZIP is uploaded to a server and version‑controlled.

The client checks the server for the latest version, downloads the ZIP, verifies integrity, and switches to the new version.

Fair reads the files, parses them with FairWidget , and renders the updated UI/logic.

Design Principles

Component‑level hot‑update, allowing selective updates without affecting unchanged parts.

Separate UI (JSON) and logic (JS) to avoid VM maintenance and keep Flutter engine updates transparent.

Updates take effect on next app launch, ensuring a seamless user experience.

Version control is delegated to the server; the client only performs verification.

Code Example

// Logic method
bool _countCanMod2() {
  return _count % 2 == 1;
}
@Override
Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: Text(_title)),
    body: Center(
      child: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        children: [
          // Sugar.ifEqualBool mixes UI and logic
          Sugar.ifEqualBool(_countCanMod2(),
              falseValue: Image.asset('assets/image/logo.png'),
              trueValue: Image.asset('assets/image/logo2.png')),
          Padding(padding: EdgeInsets.only(top: 20), child: Text('_count = $_count')),
          Padding(padding: EdgeInsets.only(top: 20), child: Text('if _count % 2 == 1,  update image !')),
        ],
      ),
    ),
  );
}

Fair‑API Usage

Fair‑API simplifies file download, version handling, and widget path resolution.

Fair_API:
  git:
    url: [email protected]:android-lab/Fair_API.git
    ref: master

FairApi.downloadBundle("https://www.58.com/Fair");

class _State extends State
{
  String filePath = '';
  @override
  void initState() {
    super.initState();
  }
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: FairWidget(
          name: '逻辑动态页面',
          path: filePath,
          fair_api_path: FairApi.filePath("lib_src_page_logic-page_sample_logic_page"),
        ),
      ),
    );
  }
}

Underlying Implementation

File path resolution prefers local cache, falling back to network request with request‑deduplication.

Download involves two requests: one for version/ZIP URL, another for the ZIP itself, followed by unzip, MD5 verification, and fallback to a built‑in page on failure.

Conclusion

Fair 2.0 incorporates lessons from existing hot‑update solutions, offering a low‑intrusion, fast‑integration, and server‑controlled update mechanism for Flutter apps, and its accompanying Fair‑API further streamlines the deployment pipeline, positioning it as a strong candidate for cross‑platform hot‑update needs.