Runtime, Hot Reload và biên dịch trong phát triển di động: khái niệm, nguyên lý chính và cách hoạt động

Runtime và Reflection: iOS Runtime, Method Swizzling và điều phối động

Runtime (môi trường thực thi) là phần mềm quản lý việc thực thi ứng dụng. Trong bối cảnh iOS Runtime, đó là hệ thống động của Objective-C cho phép gửi thông điệp đến đối tượng, tạo lớp nhanh và thay thế phương thức trong thời gian chạy. Điều này khả thi vì Objective-C là ngôn ngữ định kiểu động xây dựng trên C.

Reflection là khả năng của chương trình để kiểm tra và sửa đổi cấu trúc của chính nó trong thời gian chạy. Trong iOS Runtime, điều này được thực hiện qua các hàm như class_getInstanceMethod, method_exchangeImplementations và objc_getAssociatedObject. Trong Kotlin/Java, phản chiếu sử dụng KClass / java.lang.reflect.

Tại IT Sectr, chúng tôi rất hiếm khi sử dụng Runtime — chỉ cho các tác vụ cụ thể không có giải pháp thay thế. Ví dụ, Method Swizzling để ghi nhật ký phân tích tập trung hoặc sửa lỗi trong thư viện. Tuy nhiên, Runtime là một công cụ mạnh mẽ đòi hỏi sự hiểu biết sâu sắc và thận trọng.

Method Swizzling

Method Swizzling là kỹ thuật thay thế cách triển khai phương thức Objective-C bằng một phương thức khác trong thời gian chạy. Đây là trường hợp đặc biệt của Lập trình hướng khía cạnh (AOP) cho iOS. Swizzling cho phép thêm ghi nhật ký, phân tích hoặc lưu đệm vào các phương thức hiện có mà không thay đổi mã nguồn của chúng.

Ví dụ điển hình: thay thế viewWillAppear: trong UIViewController để thêm ghi nhật ký màn hình tự động. Quan trọng: swizzling phải được thực hiện trong phương thức +load hoặc +initialize để đảm bảo thực thi trước khi lớp được sử dụng. Swizzling không đúng có thể gây ra hành vi không xác định và lỗi khó gỡ lỗi.

// Method Swizzling để ghi nhật ký viewWillAppear:
@implementation UIViewController (Tracking)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];
        SEL originalSelector = @selector(viewWillAppear:);
        SEL swizzledSelector = @selector(xxx_viewWillAppear:);
        
        Method originalMethod = class_getInstanceMethod(class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
        method_exchangeImplementations(originalMethod, swizzledMethod);
    });
}

- (void)xxx_viewWillAppear:(BOOL)animated {
    [self xxx_viewWillAppear:animated]; // gọi phương thức gốc
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

Mã này thay thế viewWillAppear: trên tất cả UIViewController thông qua swizzling. Sau method_exchangeImplementations, việc gọi viewWillAppear: gốc dẫn đến gọi xxx_viewWillAppear:, gọi phương thức gốc (qua gọi đệ quy) và thêm phân tích. DispatchOnce đảm bảo thực thi swizzling một lần.

Công cụ Web (Transpilation, Polyfill, Bundler, Webpack, Metro)

Phát triển web hiện đại và phát triển di động với React Native hoặc Flutter là không thể thiếu công cụ biên dịch. Transpilation là chuyển đổi mã từ ngôn ngữ này sang ngôn ngữ khác. Ví dụ phổ biến nhất: TypeScript → JavaScript. Trình biên dịch chuyển (Babel, tsc) chuyển đổi mã hiện đại thành phiên bản tương thích ngược.

Polyfill là mã thêm chức năng còn thiếu cho trình duyệt cũ. Ví dụ, Promise.allSettled() không hoạt động trong Internet Explorer, nhưng polyfill thêm khả năng này. Không giống như Runtime gốc, quản lý thực thi mã trực tiếp trên thiết bị, polyfill và trình biên dịch chuyển hoạt động ở mức trừu tượng ngôn ngữ — chúng điều chỉnh cú pháp và API, nhưng không can thiệp vào môi trường thực thi.

Webpack là bundler phổ biến nhất (được sử dụng trong 72% dự án theo State of JS 2024). Metro là bundler của Facebook, được sử dụng mặc định trong React Native. Reflection trong JavaScript tồn tại qua Object.getPrototypeOf, Proxy và Reflect API — các cơ chế này cho phép kiểm tra và sửa đổi đối tượng trong thời gian chạy, khác biệt cơ bản so với phân tích tĩnh module trong bundler. Webpack sử dụng tệp cấu hình mô tả điểm vào, đầu ra, bộ tải (để xử lý các loại tệp khác nhau) và plugin (cho chức năng bổ sung).

// webpack.config.js — cấu hình tối thiểu
const path = require('path');

module.exports = {
    entry: './src/index.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist'),
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: 'babel-loader',
            },
        ],
    },
    mode: 'production',
};

Cấu hình này xác định điểm vào (index.js), tệp đầu ra (bundle.js) và quy tắc xử lý JavaScript qua Babel. Chế độ production bật tối ưu hóa: minification, tree shaking và tự động phát hiện môi trường. Ở giai đoạn Runtime, tất cả các tối ưu hóa này không ảnh hưởng đến logic — trình duyệt thực thi bundle đã nén như JavaScript thông thường.

Tối ưu hóa mã (Minification, Tree Shaking, Obfuscation)

Minification là quá trình nén mã bằng cách xóa khoảng trắng, bình luận và đổi tên biến dài thành ngắn. Công cụ nén phổ biến: Terser (JS/TS), CSSNano (CSS), html-minifier-terser. Nén làm giảm kích thước tệp 50–70%. Trong sản xuất, Runtime thực thi mã đã nén giống như mã gốc — sự khác biệt chỉ ở khả năng đọc và kích thước tệp, không phải ngữ nghĩa.

Tree Shaking là loại bỏ mã chết không được sử dụng trong ứng dụng. Nó hoạt động dựa trên phân tích tĩnh các module ES (import/export). Nếu một hàm được xuất nhưng không bao giờ được nhập, Tree Shaking sẽ loại bỏ nó khỏi bản dựng cuối cùng. Tree Shaking phân tích mã tĩnh — không giống Reflection, hoạt động động và có thể truy cập phương thức và thuộc tính không nhìn thấy ở thời điểm biên dịch.

Tree Shaking

Tree Shaking trong Webpack được bật tự động ở chế độ sản xuất. Một điều kiện quan trọng: mã phải sử dụng module ES (import/export), không phải CommonJS (require). Nếu thư viện được viết bằng CommonJS, tree shaking sẽ không hoạt động. Để tree shaking tối ưu, hãy sử dụng import chính xác: import { merge } from 'lodash-es' thay vì import _ from 'lodash'. Điều này giảm kích thước bundle từ 500 KB xuống 10 KB cho một hàm.

Hot Reload

Hot Reload là công nghệ cho phép cập nhật mã ứng dụng mà không cần tải lại hoàn toàn. Trong React Native và Flutter, Hot Reload cập nhật tệp đã thay đổi ngay lập tức, giữ nguyên trạng thái ứng dụng hiện tại. Điều này tăng tốc độ phát triển đáng kể: thay đổi hiển thị trong 1–2 giây thay vì 10–30 giây cho bản dựng lại hoàn toàn. Hot Reload hoạt động trong Runtime: module đã thay đổi được đưa vào ứng dụng đang chạy mà không khởi động lại môi trường thực thi.

Hot Restart là khởi động lại nhanh ứng dụng với mã đã cập nhật, nhưng không giữ trạng thái. Nó được sử dụng khi Hot Reload không khả thi (ví dụ, khi mã gốc hoặc biến toàn cục thay đổi). Tại IT Sectr, chúng tôi sử dụng Hot Reload ở tất cả các giai đoạn phát triển UI — tiết kiệm đến 50% thời gian cho các điều chỉnh trực quan.

Bảng 3. So sánh công cụ biên dịch. Webpack là tiêu chuẩn phổ quát. Metro chuyên biệt cho React Native. Vite và esbuild là thế hệ mới tập trung vào tốc độ. Rollup là lựa chọn tốt nhất để xuất bản thư viện.

Tải lại nóng (Hot Reload, Hot Restart)

Hot Reload là công nghệ bắt nguồn từ phát triển web (React Hot Loader, HMR — Hot Module Replacement) và chuyển sang phát triển di động với Flutter và React Native. Bản chất: khi một tệp thay đổi, bundler gửi module đã cập nhật đến ứng dụng đang chạy, thay thế mã cũ mà không mất trạng thái. Không giống như xây dựng lại hoàn toàn, Hot Reload không khởi động lại Runtime — môi trường thực thi tiếp tục chạy và module đã thay đổi được kết nối động qua cơ chế như HMR hoặc cập nhật tham chiếu giống Reflection.

Hot Reload hoạt động vì framework giữ widget (Flutter) hoặc component (React) trong bộ nhớ và chỉ cập nhật phần đã thay đổi. Hot Restart là cơ chế thô hơn: nó khởi động lại hoàn toàn ứng dụng, nhưng nhanh hơn xây dựng lại hoàn toàn vì không biên dịch lại mã gốc. Tại IT Sectr, chúng tôi sử dụng Hot Reload khi phát triển UI và Hot Restart khi thay đổi điều hướng hoặc quản lý trạng thái.