Thư Viện Câu Hỏi Phỏng Vấn

Nguyên nhân chính gây giảm hiệu năng

1. Thiếu sự tái sử dụng Cell (Cell Reuse): Nếu không sử dụng cơ chế caching strategy, mỗi item khi hiển thị sẽ khởi tạo một đối tượng UI mới, gây tốn bộ năng lượng và tài nguyên CPU.
2. Binding quá phức tạp: Sử dụng quá nhiều giá trị Binding trong một DataTemplate với các bộ chuyển đổi (Value Converters) chạy nặng.
3. Kích thước ảnh không tối ưu: Tải ảnh có độ phân giải lớn trực tiếp từ URL mà không qua bước resize hoặc caching.
4. Cấu trúc layout lồng nhau (Deep Layout Nesting): Sử dụng quá nhiều Grid hoặc StackLayout lồng nhau gây tốn thời gian tính toán kích thước (Measure and Layout Pass).

Giải pháp tối ưu hóa chuẩn Enterprise

• Sử dụng CollectionView thay cho ListView: CollectionView cung cấp kiến trúc hiện đại hơn với ItemsLayout linh hoạt và hiệu suất kết xuất tốt hơn.
• Sử dụng CachingStrategy cho ListView:

<ListView x:Name="MyListView" CachingStrategy="RecycleElement">
    <ListView.ItemTemplate>
        <DataTemplate>
            <ViewCell>
                <!-- Nội dung cell tối giản -->
            </ViewCell>
        </DataTemplate>
    </ListView.ItemTemplate>
</ListView>

• Sử dụng FastCell: Đối với Xamarin.Forms, FastCell giúp giảm số lượng phần tử visual bằng cách sử dụng Native rendering trực tiếp thay vì các Forms elements trung gian.

Lưu ý kinh nghiệm thực chiến

Lập trình viên Junior cần luôn kiểm tra bằng công cụ Profiler của Visual Studio để xác định chính xác nút thắt cổ chai (bottleneck) thay vì đoán mò khi tối ưu hóa hiệu năng ứng dụng.

Bản chất sự khác biệt

• Xamarin.Forms: Cho phép xây dựng giao diện người dùng chia sẻ dùng chung (Cross-platform UI) cho cả iOS, Android và UWP thông qua XAML và C#. Nó tự động ánh xạ các Controls chung thành các Native Controls tương ứng của từng nền tảng khi runtime.
• Xamarin.Native (Xamarin.iOS / Xamarin.Android): Cho phép lập trình viên viết giao diện hoàn toàn riêng biệt bằng cách sử dụng các API gốc của từng hệ điều hành thông qua C# bindings, giữ nguyên 100% Native UI và Performance nhưng mã nguồn chia sẻ phần Business Logic (Shared Code thông qua .NET Standard).

Tiêu chí lựa chọn cho dự án Enterprise

• Chọn Xamarin.Forms khi:

Cơ chế hoạt động của GC trong Xamarin

Xamarin sử dụng cả hai bộ thu gom rác: .NET Garbage Collection quản lý các đối tượng được quản lý (Managed Objects) và Native Garbage Collection (Objective-C/Java GC) quản lý các đối tượng gốc (Native Objects).

Kiến trúc MVVM trong Xamarin.Forms

• Model: Đại diện cho tầng dữ liệu (Data Entities, Database, API Services).
• View: Đại diện cho giao diện người dùng (XAML và Code-behind), chịu trách nhiệm hiển thị dữ liệu và nhận tương tác từ người dùng.
• ViewModel: Đóng vai trò trung gian chứa logic nghiệp vụ, các Commands và các Properties được gắn kết với View thông qua cơ chế Data Binding.

Cơ chế Data Binding

Data Binding cho phép đồng bộ hóa dữ liệu tự động giữa View và ViewModel thông qua giao diện INotifyPropertyChanged. Khi giá trị của một Property trong ViewModel thay đổi, nó sẽ kích hoạt sự kiện PropertyChanged, từ đó thông báo cho View cập nhật lại UI.

Phân tích bản chất cơ chế hoạt động

Trong Entity Framework, cả FirstOrDefault và SingleOrDefault đều dùng để truy vấn lấy ra một phần tử duy nhất thỏa mãn điều kiện từ cơ sở dữ liệu. Tuy nhiên, hành vi và ngoại lệ của chúng hoàn toàn khác nhau:

Phân tích bản chất cơ chế hoạt động

Hiện tượng N+1 Query Problem xảy ra khi Entity Framework thực hiện một câu lệnh SQL ban đầu để lấy danh sách N bản ghi bảng cha, sau đó tiếp tục thực hiện thêm N câu lệnh SQL riêng lẻ để lấy dữ liệu bảng con cho từng bản ghi cha.

Phân tích bản chất cơ chế hoạt động

Phân tích bản chất cơ chế hoạt động

Multiple Active Result Sets (MARS) là tính năng cho phép thực hiện nhiều tập kết quả (result sets) trên cùng một kết nối cơ sở dữ liệu. Lỗi liên quan đến MARS thường xảy ra trong Entity Framework khi bạn đang duyệt qua một tập kết quả bằng phương thức trả về kiểu IEnumerable (chưa thực thi ngay lập tức qua ToList()) nhưng lại mở một câu lệnh truy vấn khác trên cùng một DbContext instance.

Phân tích bản chất cơ chế hoạt động

Khi làm việc với bảng dữ liệu lớn, lập trình viên thường dùng hai phương pháp phân trang:

Khi thiết kế một Trie Node cho các ứng dụng thực tế, lập trình viên cần cân nhắc giữa tốc độ truy xuất và dung lượng bộ nhớ tiêu thụ. Dưới đây là các phương án thiết kế phổ biến:

Thao tác chèn (Insert) là nền tảng khi xây dựng một Trie. Để thực hiện, ta duyệt qua từng ký tự của từ cần chèn, đi từ gốc (Root) và kiểm tra xem ký tự đó đã tồn tại trong các node con chưa.

Cả hai thao tác Search và StartsWith đều dựa trên việc duyệt qua các node con theo từng ký tự của chuỗi đầu vào, nhưng điểm khác biệt nằm ở điều kiện kiểm tra khi kết thúc quá trình duyệt.

Thao tác xóa (Delete) trong Trie phức tạp hơn nhiều so với Insert hay Search vì một node có thể được chia sẻ bởi nhiều từ khác nhau. Nếu xóa tùy tiện, ta có thể làm mất các từ liên quan.

Trong các hệ thống Web hiện đại, tính năng Autocomplete yêu cầu khả năng truy xuất theo tiền tố (Prefix Matching) cực kỳ nhanh chóng. Khi so sánh Trie với Hash Table, ta thấy rõ các điểm khác biệt về mặt kiến trúc:

Lý do kỹ thuật

1. Hiệu năng mạng và bộ nhớ: Truy vấn dư thừa dữ liệu không cần thiết làm tăng tải lượng băng thông mạng và chiếm dụng bộ nhớ đệm (Buffer Pool) của SQL Server.
2. Tối ưu hóa Index: Việc chỉ định rõ cột giúp SQL Server tận dụng được các Covering Index (Index chứa sẵn các cột cần lấy), từ đó tránh được thao tác Key Lookup tốn kém.
3. Tính ổn định của ứng dụng: Nếu bảng thay đổi cấu trúc (thêm cột, đổi kiểu dữ liệu), ứng dụng có thể bị lỗi logic hoặc lỗi mapping dữ liệu nếu code sử dụng SELECT *.

Ví dụ thực tế

Thay vì viết: SELECT * FROM Employees WHERE DepartmentID = 1; Nên viết: SELECT EmployeeID, FullName, Email FROM Employees WHERE DepartmentID = 1;