মোবাইল ব্যাটারি লাইফের জন্য API ডিজাইন: বেশি রিকোয়েস্ট কমান

কেন চ্যাট্টি API মোবাইলে ব্যাটারি খরচ করে\n\n“চ্যাট্টি” API একটি স্ক্রিন তৈরির জন্য অ্যাপে অনেক ছোট ছোট রিকোয়েস্ট পাঠায়। কাগজে প্রতিটি রিকোয়েস্ট সস্তা মনে হলেও ফোনে এগুলো দ্রুত জমে যায়।\n\nসবচেয়ে বড় ব্যাটারি удаম সাধারণত নেটওয়ার্ক রেডিওর কারণে হয়। সেলুলার ও Wi‑Fi চিপগুলো ডেটা পাঠাতে ও গ্রহণ করতে উচ্চ-শক্তির রাজ্যে ওঠে। যখন অ্যাপ ঘন ঘন বহু রিকোয়েস্ট পাঠায়, রেডিও বারবার জাগে এবং বেশিসময় সক্রিয় থাকে। প্রতিটি রেসপন্স ক্ষুদ্র হলেও বারবার জাগ্রত হওয়া প্রকৃত শক্তি খায়।\n\nCPU‑ও কাজ করে। প্রতিটি রিকোয়েস্টের জন্য হেডার তৈরি, TLS সেটআপ, JSON পার্সিং, ক্যাশ আপডেট এবং ফলাফল মিশানোর অ্যাপ কোড চালাতে হয়। যদি কানেকশন পড়ে যায়, সেটআপ কাজ আবার করতে হয়।\n\nচ্যাট্টিনেস UI-ও ধীর করে দেয়। একের বদলে অনেক কলের চেইনে স্ক্রিন অপেক্ষা করে। লম্বা স্পিনার, পার্শিয়াল রেন্ডারিং যা হঠাৎ বদলে যায়, এবং দুর্বল নেটওয়ার্কে বেশি টাইমআউট—এসব দেখা যায়। ব্যাকগ্রাউন্ড রিফ্রেশও একইভাবে খারাপ হয়: বেশি রিট্রাই, বেশি জাগ্রত, বেশি ব্যাটারি খরচ।\n\nএকটি বাস্তবসম্মতভাবে ভাবার উপায় হল: একই UI কম রাউন্ড‑ট্রিপ, কম বাইট, এবং কম ব্যাকগ্রাউন্ড কাজ দিয়ে দেখান।\n\nনিম্নলিখিত মেট্রিক দিয়ে আপনার সাফল্য ট্যাক করা যায়:\n\n- প্রতি স্ক্রিন লোডে কম API কল\n- প্রতি স্ক্রিন কম ডাউনলোড করা বাইট\n- সেলুলারের উপর মিডিয়ান ও ওয়ার্স্ট‑কেস time-to-interactive উন্নতি\n- একই রেজাল্ট পেতে কম ব্যাকগ্রাউন্ড ফেচ ও রিট্রাই\n\nএগুলো যদি উন্নত হয়, প্রতিক্রিয়াশীলতা ও ব্যাটারি লাইফ সাধারণত একসাথে উন্নত হয়।\n\n## পরিবর্তন করার আগে কী মাপবেন\n\nব্যাচিং বা ক্যাশিং টুইক করার আগে স্পষ্ট ছবি নিন যে অ্যাপ আজ কী করছে। দ্রুত লাভগুলো সাধারণত কয়েকটি পুনরাবৃত্ত দরাদোষ ঠিক করে আসে, কিন্তু আপনি যদি পরিমাপ না করেন তা খুঁজে পাবেন না।\n\nকয়েকটি উচ্চ-ট্রাফিক স্ক্রিনের জন্য বেসিক লগ করুন: প্রতিটি লোডে কতগুলো রিকোয়েস্ট হচ্ছে, কোন এন্ডপয়েন্টগুলো কল হচ্ছে, প্রেরিত ও প্রাপ্ত বাইট (হেডার ও বডি), রিট্রাই ও টাইমআউট রেট, এবং UI ব্যবহার যোগ্য হওয়া পর্যন্ত সময়। আপনি পারলে ত্রুটি হারগুলো নেটওয়ার্ক টাইপ অনুযায়ী ভাগ করুন (Wi‑Fi বনাম সেলুলার)। এসব ভাগ প্রায়ই এমন সমস্যা উন্মোচন করে যা স্থিতিশীল সংযোগে দেখা না যায়।\n\nফোরগ্রাউন্ড ট্রাফিককে ব্যাকগ্রাউন্ড থেকে আলাদা রাখুন। একটি স্ক্রিন শান্ত দেখালেও ফোন ব্যাকগ্রাউন্ড রিফ্রেশ, পুশ‑ট্রিগার্ড সিঙ্ক, অ্যানালিটিক্স আপলোড বা প্রিফেচ কল দিয়ে ব্যস্ত থাকতে পারে। আলাদা করে ট্র্যাক করুন যাতে ভুল জিনিস অপটিমাইজ না করেন।\n\nহটস্পটগুলো সাধারণত কয়েকটি মুহূর্তে ঘনীভূত হয়: অ্যাপ লঞ্চ, হোম/ফিড স্ক্রিন, এমন ডিটেইল স্ক্রিন যা বহু কল করে, এবং পুল-টু-রিফ্রেশ। একটি নিন এবং end-to-end পরিমাপ করুন।\n\nএকটি বেসলাইন বাজেট সেট করুন যাতে টিম ঠিকভাবে বুঝে কী “ভালো”। উদাহরণ: “অর্ডার ট্র্যাকিং স্ক্রিনের কোল্ড লোডে 6টির বেশি রিকোয়েস্ট হবে না এবং স্ট্যাটাস দেখানোর আগে 250 KB এর বেশি ডাউনলোড হবে না।”\n\nসরল কীপিআই জোড়া শুরুতে নিতে পারেন: (1) প্রতি স্ক্রিন লোডে রিকোয়েস্ট সংখ্যা এবং (2) রিট্রাই রেট। রিট্রাই কাটা প্রায়ই প্রত্যাশার চেয়ে বেশি ব্যাটারি সাশ্রয় করে, কারণ বারবার রিট্রাই রেডিওকে দীর্ঘ সময় সক্রিয় রাখে।\n\n## ধাপে ধাপে: ব্যাচিং দিয়ে রিকোয়েস্ট কমান\n\nচ্যাট্টি API আকস্মিকভাবেই তৈরি হয়ে যায়। প্রতিটি উইজেট “তার” ডেটা লোড করে, এবং এক স্ক্রিনে ডজনখানেক ছোট কল ভাঙে। সমাধান সাধারণত জটিল নয়: একসাথে যা সবসময় লোড হয় তা চিনহিত করে কম কলে রিটার্ন করুন।\n\nএকটি উচ্চ-ট্রাফিক স্ক্রিন ম্যাপ করে শুরু করুন (হোম, ইনবক্স, অর্ডার তালিকা)। উপ‑ওভারে কি দেখায় তা লিখে নিন, তারপর প্রতিটি UI উপাদান কোন রিকোয়েস্ট থেকে আসে তা ট্রেস করুন। প্রায়ই ডুপ্লিকেট পাবেন (একই ইউজার প্রোফাইল দুইবার ফেচ), এবং একসাথে যেসব কল সবসময় যায় (প্রোফাইল, permissions, unread count)।\n\nএরপর এমন কলগুলো গ্রুপ করুন যা বিশ্বস্তভাবে একসাথে ঘটে। সাধারণত দুইটি অপশন থাকে:\n\n- ওই স্ক্রিনের জন্য একটি উদ্দেশ্যনির্দিষ্ট এন্ডপয়েন্ট তৈরি করুন (সর্বাধিক স্থিতিশীল)\n- একটি ব্যাচ এন্ডপয়েন্ট যোগ করুন যা একটি ছোট, পূর্বানুমানযোগ্য রিসোর্স তালিকা নেয়\n\nব্যাচগুলো স্ক্রিন-ভিত্তিক ও বাউন্ডেড রাখুন যাতে ক্যাশ, মনিটর ও ডিবাগ করা সহজ হয়।\n\nকিছু নিয়ম ব্যাচিংকে সমস্যায় পরিণত হওয়া থেকে রক্ষা করে। রিটার্ন করুন শুধু স্ক্রিনের এখনকার প্রয়োজনীয় জিনিস, পূর্ণ অবজেক্ট “হয়তো দরকার” হিসেবে নয়। যদি কিছু অংশ ঐচ্ছিক হয়, তা স্পষ্ট করুন যাতে UI দ্রুত মূল অংশ রেন্ডার করতে পারে। এছাড়া রেসপন্স ডিজাইন করুন যাতে আংশিক ব্যর্থতা পুরো ব্যাচকে পুনরায় চালাতে বাধ্য করে না। ব্যর্থ অংশগুলোকেই পুনরায় চেষ্টা করানো অনেক সস্তা।\n\n## ক্যাশিং হেডার যা ব্যাটারি বাঁচায় (শুধু ব্যান্ডউইথ নয়)\n\nক্যাশিং একটি ব্যাটারি ফিচার। প্রতিটি রিকোয়েস্ট রেডিও জাগায়, CPU ব্যস্ত করে, এবং পার্সিং ও অ্যাপ লজিক ট্রিগার করে। ভাল ক্যাশিং হেডার অনেক রিফ্রেশকে হালকা চেকে পরিণত করে।\n\nসবচেয়ে বড় লাভ আসে কন্ডিশনাল রিকোয়েস্ট থেকে। ডেটা আবার না নামিয়ে ক্লায়েন্ট জিজ্ঞেস করে “এটা বদলেছে কি?” যদি না বদলে থাকে, সার্ভার ছোট 304 Not Modified ফেরত দেয়।\n\nযেসব রেসপন্স রিসোর্সের একটি ভার্সন উপস্থাপন করে, সেখানে ETag ব্যবহার করুন, এবং পরের ফেচ-এ ক্লায়েন্ট If-None-Match পাঠাক। ETag তৈরি করা কঠিন হলে, সরল “updated at” রিসোর্সের জন্য Last-Modified ও If-Modified-Since কাজ করবে।\n\nঘন ঘন না বদলানো ডেটার জন্য ক্যাশ সিদ্ধান্ত স্পষ্ট করুন। Cache-Control বাস্তবতার সাথে মেলে এমনভাবে সেট করুন। ইউজার প্রোফাইলের জন্য একটি ছোট max-age ঠিক থাকতে পারে, কিন্তু অ্যাপ কনফিগ, রেফারেন্স তালিকা, এবং ফিচার ফ্ল্যাগ অনেকক্ষণ রাখা যায়।\n\nঅ্যাপ সাইডে 304 কে দ্রুত পথ হিসাবে বিবেচনা করুন। JSON পার্স করবেন না (কিছু নেই), মডেল পুনর্গঠন করবেন না, এবং UI ফ্লিকার করবেন না। স্ক্রিনে যেটা আছে রাখুন এবং কেবল সূচকগুলো আপডেট করুন।\n\nউদাহরণ: একটি অর্ডার ট্র্যাকিং স্ক্রিন প্রতিটি 15 সেকেন্ডে স্ট্যাটাস পোল করে। যদি রেসপন্সে ETag থাকে, বেশিরভাগ চেকই 304 ফিরিয়ে দিতে পারে। অ্যাপ শেষ স্ট্যাটাস রাখে এবং কেবল স্ট্যাটাস বদলালে বাস্তব কাজ করে (উদাহরণ: “Packed” থেকে “Shipped”)।\n\nসংবেদনশীল ডেটার ক্ষেত্রে লক্ষ্যবস্তু হোন। ক্যাশিং স্বয়ংক্রিয়ভাবে অনিস্মিত নয়, কিন্তু স্পষ্ট নিয়ম দরকার। ব্যক্তিগত বিবরণ বা টোকেনযুক্ত রেসপন্স ক্যাশ করা এড়ান যদি প্রোডাক্ট প্রয়োজন নেই। ইউজার-স্পেসিফিক ডেটার জন্য ছোট জীবনকাল ব্যবহার করুন এবং শেয়ার্ড ক্যাশে প্রাইভেট রেসপন্স রক্ষার অনুমতি দেবেন না (Cache-Control: private প্রয়োগ করুন যেখানে প্রয়োজন)।\n\n## স্মার্ট পে-লোড: কম পাঠান, কম পার্স করুন\n\nপ্রতিটি অতিরিক্ত বাইট মোবাইলে কেবল ব্যান্ডউইথ নয় বেশি খরচ করে। এটি রেডিওকে দীর্ঘ সময় ধরে জাগ্রত রাখে এবং অ্যাপকে JSON ডিকড ও মডেল আপডেট করতে CPU ব্যয় করতে বাধ্য করে। যদি আপনি API চ্যাট্টিনেস কমাতে চান, পে-লোড ট্রিম করা প্রায়ই দ্রুততম জেতা।\n\nপ্রতি স্ক্রিন পে-লোড অডিট করে শুরু করুন। একটি স্ক্রিন নিন (উদাহরণ: হোম ফিড), রেসপন্স সাইজ লগ করুন, এবং ফিল্ড অনফিল্ড-ভিত্তিতে দেখুন: ক্লায়েন্ট এটা রেন্ডার করে কি, নাকি এটা কেবল সিদ্ধান্ত নেওয়ার জন্য ব্যবহার করে? না হলে, সেই ফিল্ডটি সরান।\n\nলিস্টের জন্য সাধারণত ছোট “সারাংশ” আকৃতি যথেষ্ট। একটি লিস্ট রো প্রায়ই একটি id, শিরোনাম, স্ট্যাটাস এবং টাইমস্ট্যাম্প ছাড়া আর কিছুই প্রয়োজন হয় না। ব্যবহারকারী আইটেম খোলার সময়ই ডিটেইলস ফেচ করুন।\n\nকিছু পরিবর্তন দ্রুত পে-লোড কমায়:\n\n- পুনরাবৃত্ত লম্বা স্ট্রিংয়ের বদলে আইডি বা ছোট enum কোড ব্যবহার করুন\n- ক্লায়েন্ট সহজেই অনুমান করতে পারবে এমন ডিফল্টগুলো আবার পাঠাবেন না\n- প্রতিটি লিস্ট আইটেমে একই নেস্টেড অবজেক্ট বারবার পাঠানো এড়ান\n- ফিল্ড নাম ও টাইপ স্থির রাখুন যাতে ক্লায়েন্ট কম ডিফেন্সিভ কোড লিখে\n\nকম্প্রেশন সাহায্য করতে পারে, বিশেষত ধীর নেটওয়ার্কে, কিন্তু বাস্তব ডিভাইসে CPU ট্রেড‑অফ টেস্ট করুন। Gzip বা Brotli প্রায়ই ট্রান্সফার সাইজ অনেক কমায়, কিন্তু পুরনো ফোন গুলো বৃহৎ রেসপন্স ডিসকমপ্রেস করতে সময় খেতে পারে। সবথেকে বড় জেতা হলো শুরুতেই কম ডেটা পাঠানো।\n\nরেসপন্স শেইপগুলোকে একটি कांট্রাক্টের মত আচরণ করুন। যখন ফিল্ড নাম ও টাইপ স্থির থাকে, অ্যাপ কম ব্যাকফল এবং কম ডিফেন্সিভ কোড রাখে, যা UI মসৃণ রাখে এবং ব্যাটারি খরচ কমায়।\n\n## দুর্বল নেটওয়ার্ক ও কম রিট্রাই বিবেচনা করে ডিজাইন করুন\n\nএকটি মোবাইল অ্যাপ কেবল রিকোয়েস্ট পাঠালে ব্যাটারি খরচ করে না; ব্যর্থ হলে রিট্রাই, রেডিও পুনরায় জাগানো, এবং কাজ পুনরাবৃত্ত করা করেও ব্যাটারি খরচ হয়। যদি একটি API পারফেক্ট Wi‑Fi ধরে নিক, তখন বাস্তব ব্যবহারকারীরা দুর্বল 4G‑এ মূল্য দিয়েছেন।\n\nকম ডেটা চাওয়াটা সহজ করবেন। সার্ভার-সাইড ফিল্টার ও পেজিনেশন পছন্দ করুন ‘সব ডাউনলোড করে ফোনে ফিল্টার করার’ বদলে। যদি একটি স্ক্রিনে কেবল শেষ 20টি ইভেন্ট লাগে, সেই এক্সাক্ট কোয়েরি সাপোর্ট করুন যাতে অ্যাপ শত শত সারি ফেচ না করে।\n\nডেল্টা সিঙ্ক সাপোর্ট করুন যাতে ক্লায়েন্ট জিজ্ঞেস করতে পারে “আমি শেষবার চেক করার পরে কি বদলেছে?” এটি সহজভাবে টাইমস্টাম্প বা ইনক্রিমেন্টাল ভার্সন নম্বর রিটার্ন করে, তারপর ক্লায়েন্ট শুধুমাত্র সেই পয়েন্ট থেকে আপডেট ও ডিলেটই চায়।\n\nরিট্রাই অনিবার্য, তাই আপডেটগুলো idempotent রাখুন। একটি রিট্রাই ডাবল‑চার্জ, ডাবল‑সাবমিশন বা ডুপ্লিকেট তৈরি করা উচিত না। ক্রিয়েট অপারেশনের জন্য idempotency কী এবং স্ট্যাটেট‑সেটিং আপডেট সেমান্টিকস সাহায্য করে।\n\nরিট্রাই হলে retry storm এড়াতে থাকুন। এক্সপোনেনশিয়াল ব্যাকঅফ জিটার সহ ব্যবহার করুন যাতে হাজারা ডিভাইস একসাথে সার্ভার আঘাত না করে, এবং ফোন প্রতি সেকেন্ডে জাগে না।\n\nস্পষ্ট ত্রুটি কোড ফিরিয়ে দিন যা অ্যাপকে ঠিক সিদ্ধান্ত নিতে সাহায্য করে। 401 হলে পুনঃঅথ করার ট্রিগার, 404 হলে সাধারণত রিট্রাই বন্ধ করা, 409 হলে স্টেট রিফ্রেশ দরকার হতে পারে, এবং 429 বা 503 হলে ব্যাকঅফ ট্রিগার করুন।\n\n## ক্লায়েন্ট আচরণ যা API খরচ বাড়ায়\n\nভাল API থাকলেও ক্লায়েন্ট গোপনে নেটওয়ার্ক কাজ বাড়িয়ে দিতে পারে। মোবাইলে অতিরিক্ত জাগ্রত ও রেডিও‑টাইম অনেকসময় বাইটগুলোর চেয়ে বেশি ব্যাটারি খরচ করে।\n\nকম বদলানো ডেটা কেশ করুন। প্রোফাইল ফটো, ফিচার ফ্ল্যাগ, রেফারেন্স ডেটা (দেশ, স্ট্যাটাস, ক্যাটেগরি) প্রতি স্ক্রিন ভিজিটে ফেচ করবেন না। এইগুলোকেযুক্ত জীবনকাল দিন, ডিস্কে সংরক্ষণ করুন এবং প্রয়োজনমতো রিফ্রেশ করুন। যদি API ভ্যালিডেশন (ETag বা Last-Modified) সমর্থন করে, একটি দ্রুত রি‑চেক প্রায়ই পূর্ণ ডাউনলোডের চেয়ে বেশি সস্তা।\n\nআরেকটি সাধারণ সমস্যা হলো ইন‑ফ্লাইট ডুপ্লিকেট রিকোয়েস্ট। অ্যাপের দুই অংশ একই রিসোর্স একসঙ্গে চায় (উদাহরণ: হেডার ও সেটিংস উভয়ই প্রোফাইল অনুরোধ করে)। কোয়ালেসিং না করলে আপনি দুইটি কল পাঠান, দুইবার পার্স করেন, এবং দুইবার স্টেট আপডেট করেন। একটি নেটওয়ার্ক কলকে একক সত্য উৎস হিসেবে বিবেচনা করুন এবং একাধিক কন্‍জিউমারদের অপেক্ষা করতে দিন।\n\nব্যাকগ্রাউন্ড রিফ্রেশ উদ্দেশ্যপূর্ণ হওয়া উচিত। যদি এটি ব্যবহারকারীর কাছে দ্রুত পরিবর্তন না দেখায় বা নোটিফিকেশন ট্রিগার না করে, তা সাধারণত অপেক্ষা করতে পারে। প্রতিটি অ্যাপ রিসিউমে রিফ্রেশ লজিক চালাবেন না। একটি সংক্ষিপ্ত কুলডাউন রাখুন এবং ডেটা সর্বশেষ কবে আপডেট হয়েছে চেক করুন।\n\nযদি আপনি AppMaster‑এ ব্যাকেন্ড বানান, ক্লায়েন্ট আচরণগুলোকে সাপোর্ট করতে এন্ডপয়েন্টগুলো স্ক্রিন-এর চারপাশে গড়ে তুলতে, রেসপন্স স্কিমা ধারাবাহিক রাখতে এবং নিয়ন্ত্রিতভাবে ক্যাশিং হেডার যোগ করতে সহজ হয়, যাতে ক্লায়েন্ট বেশিরভাগ সময় চুপ থাকতেই পারে।\n\n## ব্যাচিং, ক্যাশিং, ও পে-লোড নিয়ে সাধারণ ভুলগুলো\n\nলক্ষ্য হচ্ছে কম রেডিও জাগ্রত, কম CPU কাজ, এবং কম রিট্রাই। কিছু প্যাটার্ন সেভিংগুলো বাতিল করে দিতে পারে এবং এমনকি স্ক্রিনকে ধীর করে তুলতে পারে।\n\n### কখন ব্যাচিং খারাপ করে\n\nব্যাচিং সাহায্য করে যতক্ষণ না ব্যাচ একটা “সবকিছু দাও” কলে পরিণত হয়। যদি সার্ভারকে বহু টেবিল জয়েন করতে হয়, কড়া permission চেক চলে, এবং বিশাল রেসপন্স তৈরি করতে হয়, সেই এক অনুরোধ কয়েক ছোট অনুরোধের চেয়ে ধীর হতে পারে। মোবাইলে একটি ধীর অনুরোধ অ্যাপকে অপেক্ষা করিয়ে রাখে, নেটওয়ার্ক সক্রিয় রাখে, এবং টাইমআউট ঝুঁকি বাড়ায়।\n\nএকটি স্বাস্থ্যকর ব্যাচ স্ক্রিন-আকৃতির হওয়া উচিত: কেবল একটা ভিউর প্রয়োজনীয় জিনিস, সীমা স্পষ্ট। যদি আপনি রেসপন্স এক বাক্যে বর্ণনা করতে না পারেন, এন্ডপয়েন্ট সম্ভবত খুব বিস্তৃত।\n\n### স্টেল স্ক্রিন তৈরি করা ক্যাশিং\n\nস্পষ্ট ইনভ্যালিডেশন ছাড়া ক্যাশিং পুরনো ডেটা দেখানো শুরু করে: ব্যবহারকারী পুল করে‑টু‑রিফ্রেশ করে এবং অ্যাপ অতিরিক্ত ফুল রিলোড করে। Cache-Control ব্যবহার করুন এবং কি বিষয় ডেটা আপডেট করে (create/update অ্যাকশন, সার্ভার ইভেন্ট, বা সংক্ষিপ্ত freshness উইন্ডো) তা প্ল্যান করুন যাতে ক্লায়েন্ট কেশযুক্ত রেসপন্সে বিশ্বাস করতে পারে।\n\nপোলিং আরেকটি ব্যাটারি ফাঁদ। একটি কড়া 5‑সেকেন্ড টাইমার ডিভাইসকে ব্যস্ত রাখে এমনকি যখন কিছুই বদলায় না। সম্ভব হলে সার্ভার-চালিত আপডেট ব্যবহার করুন, অথবা আক্রমণ করে ব্যাক‑অফ (খালি পোলের পরে ইন্টারভ্যাল দীর্ঘ করা, ব্যাকগ্রাউন্ডে থামানো) পছন্দ করুন।\n\nঅতিরিক্ত বড় পে-লোডগুলো নীরব খরচ। বিশাল নেস্টেড অবজেক্ট “সুবিধার জন্য” ফেরত দিলে বেশি বাইট, বেশি JSON পার্সিং, এবং বেশি মেমরি churn হয়। কেবল স্ক্রিন প্রয়োজনীয় ডেটা পাঠান এবং ডিটেইলে অন‑ডিম্যান্ড লোড করুন।\n\nশেষে, ব্যাচে আংশিক ব্যর্থতাকে উপেক্ষা করবেন না। যদি একটি সাব-রেজাল্ট ব্যর্থ হয় এবং আপনি পুরো ব্যাচ পুনরায় চান, আপনি ট্র্যাফিক দ্বিগুণ করছেন। রেসপন্স ডিজাইন করুন যাতে ক্লায়েন্ট শুধুমাত্র ব্যর্থ অংশগুলোই পুনরায় চায়।\n\nএকটি দ্রুত মানসিক চেকলিস্ট: ব্যাচগুলো সীমাবদ্ধ রাখুন, ক্যাশ ফ্রেশনেস আগে থেকে নির্ধারণ করুন, কড়া পোলিং এড়িয়ে চলুন, পে-লোড ট্রিম করুন, এবং আংশিক সাফল্য সমর্থন করুন।\n\n## রিলিজের আগে দ্রুত চেকলিস্ট\n\nশিপের আগে একটি পাস চালান যা কেবল নেটওয়ার্ক আচরণে কেন্দ্রীভূত। বেশিরভাগ ব্যাটারি জেতা সরিয়ে বিস্ময় কেটে ফেলা: কম জাগ্রত, কম পার্সিং, এবং ব্যাকগ্রাউন্ডে কম রিট্রাই।\n\nআপনার শীর্ষ তিন স্ক্রিনে এগুলো চালান:\n\n- কোল্ড লোডগুলো কম এবং পূর্বানুমানযোগ্য সংখ্যক রিকোয়েস্টে শেষ হয় (পোক্ত ফলো‑আপ কল যেমন প্রতিটি আইটেম লুকআপ খেয়াল রাখুন)।\n- রেসপন্সে স্পষ্ট ক্যাশিং নিয়ম আছে (ETag বা Last-Modified যেখানে মানায়) এবং কিছু না বদলালে 304 Not Modified ফেরত দেয়।\n- লিস্ট এন্ডপয়েন্টগুলো বাউন্ডেড: স্থির সর্টিং, পেজিনেশন, এবং ডিফল্টভাবে অনাবশ্যক ফিল্ড নেই।\n- রিট্রাই লজিক জিটারের সাথে ব্যাকঅফ করে এবং এমন ত্রুটিতে থামে যা নিজে ঠিক হবে না; মোট রিট্রাই টাইম সীমাবদ্ধ।\n- ব্যাকগ্রাউন্ড আপডেটগুলো যুক্তিযুক্ত; যদি তা স্পষ্টভাবে UI‑কে বদলে না দেয় তবে ধারাবাহিক পোলিং এড়ান।\n\nএকটি সহজ বাস্তব পরীক্ষা: একটি স্ক্রিন লোড করুন, এয়ারপ্লেন মোড চালু করুন, তারপর পুনরায় খুলুন। যদি এটি এখনও কিছু দরকারী দেখায় (কেশড কন্টেন্ট, লাস্ট‑নাউন স্টেট, সফট প্লেসহোল্ডার), আপনি সম্ভবত অপ্রয়োজনীয় কল কমিয়ে দিয়েছেন এবং অনুভূত গতি উন্নত করেছেন।\n\n## উদাহরণ: অর্ডার ট্র্যাকিং স্ক্রিন কিভাবে সস্তা করা যায়\n\nএকজন গ্রাহক মোবাইল ডেটায় 20% ব্যাটারি নিয়ে অর্ডার ট্র্যাকিং অ্যাপ খুললে তাদের কাজ একটাই: “আমার প্যাকেজ এখন কোথায়?” স্ক্রিনটা সহজ দেখালেও তার পেছনের API ট্র্যাফিক অপ্রত্যাশিতভাবে ব্যয়বহুল হতে পারে।\n\nআগে, অ্যাপ স্ক্রিন লোডে একটি বার্স্ট রিকোয়েস্ট পাঠায়। UI অপেক্ষা করে যখন রেডিও বারবার জাগে এবং দুর্বল কানেকশনে কিছু কল টাইমআউট হয়।\n\nএকটি সাধারণ “আগে” প্যাটার্ন ছিল:\n\n- GET /orders/{id} — অর্ডারের সারসংক্ষেপ\n- GET /orders/{id}/items — লাইন আইটেমগুলো\n- GET /orders/{id}/history — স্ট্যাটাস ইভেন্ট\n- GET /me — ইউজার প্রোফাইল ও পছন্দ\n- GET /settings — ডিসপ্লে রুল (মুদ্রা, তারিখ ফরম্যাট)\n\nএখন UI না বদলে তিনটি পরিবর্তন প্রয়োগ করুন।\n\nপ্রথমত, একটি একক স্ক্রিন এন্ডপয়েন্ট যোগ করুন যা এক রাউন্ড‑ট্রিপে কেবল ভিউর প্রয়োজনীয়তা ফেরত দেয়: অর্ডার সারসংক্ষেপ, সর্বশেষ স্ট্যাটাস, সাম্প্রতিক ইতিহাস, এবং আইটেম টাইটেলগুলো। দ্বিতীয়ত, প্রোফাইলকে ক্যাশ করুন: GET /me ETag ও Cache-Control: private, max-age=86400 সহ ফেরত দেয় যাতে অধিকাংশ ওপেন দ্রুত 304 হয় (বা ক্যাশ ফ্রেশ থাকলে কোনো অনুরোধই না হয়)। তৃতীয়ত, পে-লোড টিপুন: আইটেম তালিকা কেবল id, name, qty, এবং thumbnail_url পাঠায়, না যে পূর্ণ প্রোডাক্ট ডেসক্রিপশন বা ব্যবহার না হওয়া মেটাডাটা।\n\nফলাফল: কম রাউন্ড‑ট্রিপ, কম বাইট, এবং নেটওয়ার্ক স্টাটার করলে কম রিট্রাই। ফোনের রেডিও বেশি সময় ঘুমিয়ে থাকে—এটাই ব্যাটারি সাশ্রয়ের মূল জায়গা।\n\nব্যবহারকারীর জন্য কিছুই “নতুন” পরিষ্কার হবে না। স্ক্রিন একই থাকলেও দ্রুত লোড হবে, বেশি প্রতিক্রিয়াশীল অনুভূত হবে, এবং দুর্বল কানেকশনে কাজ চালিয়ে যেতে পারবে।\n\n## পরবর্তী ধাপ: বাস্তব রোলআউট প্ল্যান (এবং AppMaster কোথায় সাহায্য করে)\n\nদ্রুত জেতার জন্য ছোট করে শুরু করুন এবং প্রভাব প্রমাণ করুন। ব্যাটারি সাশ্রয় সাধারণত বেশি রেডিও জাগ্রত ও কম পার্সিং কাজ থেকে আসে, বড় রিফ্যাক্টরের বদলে ছোট পরিবর্তন থেকেই লাভ হয়।\n\nতিনটি নিরাপদ, পরিমাপযোগ্য এবং দ্রুত ফিরিয়ে আনার যোগ্য পরিবর্তন:\n\n- একটি স্ক্রিন end-to-end পরিমাপ করুন (রিকোয়েস্ট গণনা, মোট বাইট, time-to-interactive, ত্রুটি ও রিট্রাই রেট)\n- ঐ স্ক্রিনের রিকোয়েস্টগুলো এক বা দুইটি কলে ব্যাচ করুন (কম্প্যাটিবিলিটি রাখার জন্য পুরনো এন্ডপয়েন্ট রাখা)\n- আপনার উচ্চ-ট্রাফিক GET এন্ডপয়েন্টগুলিতে ETag সাপোর্ট যোগ করুন যাতে ক্লায়েন্ট If-None-Match ব্যবহার করে 304 Not Modified পেতে পারে\n\nএকটি স্থির ব্যবহারভিত্তিক ফিচার বেছে নিন—যেমন অর্ডার তালিকা বা ইনবক্স। যদি পারেন সার্ভার‑সাইড ফ্ল্যাগে রেখে শিপ করুন এবং কয়েকদিন পুরনো ও নতুন পাথের KPI তুলনা করুন। খুঁজুন প্রতি সেশন কম রিকোয়েস্ট, কম রিট্রাই, এবং প্রতি সক্রিয় ইউজারে কম ডাউনলোড বাইট।\n\nAPI ও অ্যাপ রিলিজ সমন্বয় করুন যাতে পুরনো ক্লায়েন্ট ভাঙে না। একটি বাস্তবনীতি: নতুন আচরণ আগে যোগ করুন, ক্লায়েন্ট মাইগ্রেট করুন, পরে পুরনো আচরণ সরান। ক্যাশিং আচরণ বদলালে ব্যক্তিগতকৃত ডেটার বিষয়ে সতর্ক থাকুন এবং শেয়ার্ড ক্যাশে ইউজার মিশ্রিত না হয় তা নিশ্চিত করুন।\n\nআপনি যদি ব্যাকেন্ড দ্রুত প্রোটোটাইপ ও শিপ করতে চান, AppMaster (appmaster.io) আপনাকে ভিজুয়ালি ডেটা মডেল করতে, ড্র্যাগ‑এন্ড‑ড্রপ লজিক গড়তে, এবং প্রয়োজন বদলালে প্রোডাকশন‑রেডি সোর্স কোড পুনরায় জেনারেট করতে সাহায্য করে।\n\nপ্রথমে একটি ব্যাচড এন্ডপয়েন্ট ও একটি উচ্চ‑ট্রাফিক স্ক্রিনে ETag যোগ করে শুরু করুন। সংখ্যাগুলো উন্নত হলে আপনি জানেন কোথায় বেশি ইঞ্জিনিয়ারিং বিনিয়োগ করবেন।