نحوه راه اندازی گوشی های هوشمند و رایانه های شخصی. پرتال اطلاعاتی

رابط بومی. مروری بر راهکارهای چند پلتفرمی برای توسعه اپلیکیشن موبایل

روزی، فقدان دانش اولیه در مورد برنامه های تلفن همراه احتمالاً به شکل بدی تبدیل خواهد شد. در ضمن، بیایید در مورد اینکه برنامه ها به طور کلی چه هستند صحبت کنیم. از راه دور، فقط سه نوع وجود دارد: برنامه بومی چیست، برنامه وب و ترکیبی.

آیا می دانید اپلیکیشن بومی چیست؟

برای کاربر، برنامه هایی که نیاز به نصب دارند، بومی هستند. به طور کلی، این درست است، و همچنین این واقعیت که چنین برنامه هایی به طور خاص برای سیستم عامل های تلفن همراه (iOS، Android، Windows Phone) توسعه یافته اند. بنابراین، توسعه دهنده ملزم به داشتن مهارت های برنامه نویسی در یک محیط توسعه خاص (xCode برای iOS، eclipse برای اندروید) است.

در پایان، این ظاهر دلپذیر و تعامل یکپارچه برنامه با سیستم عامل تلفن همراه را می دهد. اپلیکیشن بومی نیز از نظر امنیت بسیار جلوتر از اپلیکیشن های هیبریدی و وب است. چنین برنامه هایی با کمترین مصرف منابع از دوربین، میکروفون، شتاب سنج، پخش کننده و سایر عملکردها استفاده می کنند. به طور معمول، یک برنامه بومی را می توان به دو گروه تقسیم کرد: برنامه هایی که نیاز به اتصال به اینترنت دارند و برنامه های کاربردی آفلاین.

برنامه های وب با برنامه های بومی متفاوت هستند

استفاده از یک سایت معمولی در گوشی هوشمند در بهترین حالت ناخوشایند است، در بدترین حالت، چیدمان سایت از بین می رود و به طور کلی بعد از آن کار با آن غیرممکن است. برنامه های وب به منظور استفاده از سایت از طریق تلفن ایجاد می شوند. بنابراین، در اصل، این همان سایت است که برای دستگاه های تلفن همراه بهینه شده است. بر خلاف یک برنامه بومی، برنامه های وب نیازی به نصب ندارند - آنها در مرورگر تلفن کار می کنند. بنابراین، مطلقاً هیچ چیز به مدل تلفن (به طور دقیق تر، از پلت فرم تلفن همراه) بستگی ندارد. همچنین، صرف نظر از پلتفرم، برنامه های کاربردی وب نمی توانند با عملکردهای بومی گوشی کار کنند.

اما یک برنامه بومی در مقایسه با یک سایت تلفن همراه چیست؟ مرز بین اپلیکیشن وب و سایت موبایل بسیار نازک است. و در این موضوع نه تنها کاربران بلکه در برخی موارد خود توسعه دهندگان نیز دچار سردرگمی می شوند. اما یک تفاوت وجود دارد. به طور معمول، سایت حاوی اطلاعات کم و بیش ثابت است و چیزی شبیه یک بروشور دیجیتال است. در برنامه وب، کاربر می تواند برخی از این اطلاعات را مدیریت کند - صفحات خود را ایجاد کند، پیوندها، متون و غیره را مبادله کند.

بنابراین آسان تر است که برنامه های کاربردی تحت وب را هر چیزی که معمولاً خدمات آنلاین نامیده می شود، فراخوانی کنید. یک برنامه وب را می توان چیزی نامید که زمانی در فلش و اکنون در HTML5 انجام می شد.

برنامه های کاربردی ترکیبی

یک برنامه ترکیبی ترکیبی نامیده می شود زیرا برخی از ویژگی های یک برنامه بومی و یک برنامه وب را ترکیب می کند. این یک اپلیکیشن کراس پلتفرم است که قابلیت کار با نرم افزار گوشی را دارد. این برنامه ها، مانند برنامه های بومی، از فروشگاه برنامه دانلود می شوند، اما داده ها به صورت آفلاین به روز می شوند. بنابراین، آنها همیشه به اتصال به اینترنت نیاز دارند - بدون آن، توابع وب کار نمی کنند.

چه چیزی را انتخاب کنیم؟ برنامه بومی، ترکیبی یا وب؟

توسعه یک برنامه ترکیبی ارزان تر و سریعتر از ساخت یک برنامه بومی است. به هر حال کاربران متوجه تفاوت نمی شوند. بنابراین، فناوری های هیبریدی محبوب ترین هستند. با وجود این همه پیچیدگی، تصمیم گیری در مورد انتخاب فناوری برای توسعه یک برنامه بسیار ساده است. اگر برنامه شما نمی تواند بدون عملکردهای بومی دستگاه های تلفن همراه کار کند، اگر سرعت پردازش داده بالا بسیار مهم است (بازی ها، شبکه های اجتماعی، موقعیت جغرافیایی)، پس هیچ چیز بهتر از یک برنامه بومی نیست. هنگامی که سرعت ناچیز است، یک برنامه ترکیبی این کار را انجام می دهد. یک برنامه وب زمانی ارزش انجام دادن را دارد که کاربر به هیچ چیز از شما نیاز نداشته باشد، به جز اطلاعاتی که می تواند از تلفن با اینترنت دریافت کند.

بازار اپلیکیشن های موبایل بیش از ده سال قدمت دارد، اما همچنان در حال رونق است. تقاضا از سوی شرکت ها به طور مداوم در حال رشد است و هنوز به طور قابل توجهی از عرضه فراتر می رود که منجر به افزایش مداوم هزینه های توسعه می شود. یکی از راه حل های کاهش هزینه این فرآیند، توسعه کراس پلتفرم است، زمانی که کد یکسان در همه پلتفرم ها استفاده می شود.

آخرین باری که روی توسعه موبایل بین پلتفرمی صحبت کردیم و از آن زمان تاکنون چیزهای زیادی تغییر کرده است. وقت آن است که دوباره در مورد روش ها و ابزارها صحبت کنیم.

بیایید ابتدا دوباره به اصطلاحات بپردازیم.

بومی

اگر توسعه دهندگان در فرآیند نوشتن یک برنامه از یک زبان برنامه نویسی پذیرفته شده برای یک پلت فرم خاص استفاده کنند، خواه Objective-C و Swift برای iOS باشد یا چنین برنامه ای بومی (از انگلیسی بومی - بومی، طبیعی) نامیده می شود.

مزایای اپلیکیشن های بومی:

  • سرعت رابط و پاسخ. برنامه فوراً به کلیک ها پاسخ می دهد ، عملاً هیچ تاخیری در انیمیشن ، اسکرول ، دریافت و خروجی داده ها وجود ندارد.
  • دسترسی واضح و آسان به عملکردها و سنسورهای دستگاه. برای یک توسعه دهنده مشکلی نیست که با موقعیت جغرافیایی، اعلان های فشار، گرفتن عکس و فیلم از طریق دوربین، صدا، شتاب سنج و سایر حسگرها کار کند.
  • امکان کار عمیق با عملکردهای تلفن هوشمند. مانند پاراگراف قبل، مواردی مانند انیمیشن ها، ایجاد رابط های پیچیده و عملکرد شبکه های عصبی به طور مستقیم بر روی دستگاه ها، شاید نه به سادگی، بلکه قابل پیش بینی، پیاده سازی شده اند.
  • . برنامه‌های کاربردی بومی معمولاً با عناصر رابط «پلت‌فرم» کار می‌کنند: منوها، ناوبری، فرم‌ها و سایر عناصر طراحی از سیستم عامل گرفته شده‌اند و بنابراین برای کاربر آشنا و قابل درک هستند.

تنها یک اشکال وجود دارد - هزینه بالای توسعه و پشتیبانی. برای هر پلتفرم، باید کد خود را بنویسید. با رشد بازار اپلیکیشن های موبایل، توسعه دهندگان نه تنها گران، بلکه بسیار گران شده اند.

و نه اقوام

برنامه های کاربردی کراس پلتفرم برای چندین پلتفرم به طور همزمان به یک زبان غیر از بومی نوشته می شوند. چگونه چنین کدی می تواند روی دستگاه های مختلف کار کند؟ در اینجا نیز دو رویکرد وجود دارد.

اولین مورد این است که در مرحله آماده سازی برنامه برای انتشار، با استفاده از ترانسپایلر به یک برنامه بومی برای یک پلت فرم خاص تبدیل می شود. در واقع، یک زبان برنامه نویسی کراس پلتفرم به دیگری ترجمه می شود.

دوم این است که یک بسته بندی خاص به کد حاصل اضافه می شود، که در حال حاضر روی دستگاه کار می کند، تماس ها را از کد غیر بومی به عملکردهای سیستم بومی در پرواز ترجمه می کند.

فرض بر این است که بیشتر این کد را می توان بین پلتفرم ها منتقل کرد - بدیهی است که به عنوان مثال، منطق خرید، ذخیره کالا در سبد خرید، محاسبه مسیر برای تاکسی، نوشتن پیام به پیام رسان تغییر نمی کند. بسته به اینکه مشتری اندروید یا iOS داشته باشد. ما فقط باید UI و UX را برای پلتفرم‌ها اصلاح کنیم، اما اکنون، در محدوده‌های خاصی، حتی می‌توان آن را با هم ترکیب کرد - به عنوان مثال، منوی همبرگر به طور فعال در Android و iOS استفاده می‌شود. بنابراین حتی انجام اصلاحات در رابط به گونه ای که برنامه با روح و حرف پلتفرم مورد نظر مطابقت داشته باشد، امری دلخواه، سرعت و کیفیت لازم در توسعه است.

مزایای:

  • هزینه و سرعت توسعه از آنجایی که کد باید به میزان قابل توجهی کمتر نوشته شود، هزینه کار کاهش می یابد.
  • توانایی استفاده از منابع داخلی شرکت همانطور که در ادامه نشان خواهیم داد، توسعه اپلیکیشن موبایل بین پلتفرمی اغلب با کمک برنامه نویسان موجود انجام می شود.

معایب:

  • رابط غیر بومی یا حداقل نیاز به کار با رابط هر پلتفرم به طور جداگانه. هر سیستم الزامات طراحی عناصر خاص خود را دارد و گاهی اوقات آنها متقابلاً منحصر به فرد هستند. این باید در هنگام طراحی در نظر گرفته شود.
  • مشکلات در اجرای توابع پیچیده یا مشکلات احتمالی در کار حتی با رویه های ساده به دلیل اشتباهات در خود چارچوب های توسعه. محیط متقابل پلتفرم فقط درخواست‌ها را به فراخوانی‌های سیستم و رابط‌ها به قالبی تبدیل می‌کند که توسط آن، سیستم قابل درک است، و بنابراین در این مرحله هم مشکلات در درک و هم وقوع خطا در خود چارچوب امکان‌پذیر است.
  • سرعت کار از آنجایی که محیط کراس پلتفرم یک "روبنا" بر روی کد است (نه همیشه، اما در شرایط خاص)، تاخیر و مکث خاص خود را در پردازش اقدامات کاربر و نمایش نتایج روی صفحه دارد. این امر به ویژه چند سال پیش در گوشی‌های هوشمند که در مقایسه با امروز کم مصرف‌تر هستند، مشهود بود، اما اکنون با رشد عملکرد دستگاه‌های تلفن همراه، می‌توان از این موضوع غافل شد.

همانطور که می بینید، این دو روش عملا یک تصویر آینه ای از یکدیگر هستند - مزایای توسعه بومی، معایب توسعه بین پلت فرمی و بالعکس.

پلتفرم های محبوب و ابزارهای توسعه بین پلتفرمی

همانطور که در بالا نوشتیم، دو رویکرد وجود دارد - تبدیل کد به بومی در مرحله ساخت یا اضافه کردن یک پوشش خاص که تماس‌ها را به و از سیستم ترجمه می‌کند.

Cordova و PWA دو ابزاری هستند که دقیقاً در ایدئولوژی wrapper کار می کنند.


کوردووا و HTML5

یکی از محبوب ترین حوزه ها در برنامه نویسی کراس پلتفرم است که معمولاً PhoneGap نامیده می شود. در واقع، یک سایت تلفن همراه ایجاد می شود که با یک کد پلت فرم کوچک که تماس ها را از سیستم به برنامه و بالعکس ترجمه می کند، "دور می شود" ایجاد می شود.

همه کاستی ها و مزایا در اینجا به وضوح بیان شده است. می توانید از توسعه دهندگان وب (HTML، CSS و جاوا اسکریپت به عنوان فناوری های اصلی) استفاده کنید و در عرض یک ماه یا حتی چند هفته، اولین نسخه برنامه را با هزینه نسبتاً کمی بسازید. بله، در کار کند می شود، ممکن است موقعیت جغرافیایی خیلی دقیقی نداشته باشد، اما در همه دستگاه ها کار می کند و به شما امکان می دهد حداقل تقاضای مشتریان را در دستگاه های تلفن همراه آزمایش کنید.

تعداد زیادی چارچوب برای این رویکرد ایجاد شده است، اما همه آنها اساساً یک کار را انجام می دهند. تفاوت بین آنها در این است که Cordova (PhoneGap) برای پروژه HTML5 شما محدودیت ها و قالب هایی را برای منطق و UI تعیین نمی کند، در حالی که فریم ورک ها با عناصر رابط کاربری آماده خود عمل می کنند که از پلتفرم های تلفن همراه و منطق توسعه خود تقلید می کنند. به عنوان نمونه ای از این رویکرد، می توانید مشخص کنید: Ionic Framework - a wrapper; Framework7، Mobile Angular UI، Sencha Touch، Kendo UI چارچوب های رابط هستند.

PWA

فناوری مد روز گوگل همان برنامه های وب است، اما به دلیل استفاده از فناوری های خاص (اول از همه، اینها به اصطلاح Service Workers هستند - اسکریپت هایی که در پس زمینه اجرا می شوند، و Web App Manifest - شرح یک برنامه وب در یک فرم قابل درک برای یک سیستم تلفن همراه) آنها می توانند به عنوان نمونه های بومی بدون پوشش از PhoneGap کار کنند. آنها را می توان در صفحه اصلی با دور زدن فروشگاه برنامه نصب کرد، به صورت آفلاین کار کرد، با اعلان های فشار، با عملکردهای بومی کار کرد.

مشکل این است که همه پلتفرم ها حتی در حال حاضر از این "فناوری های خاص" پشتیبانی نمی کنند. اول از همه، این مربوط به اپل است، که ظاهراً توانایی توزیع برنامه ها را با دور زدن فروشگاه App دوست ندارد.

با در نظر گرفتن تمام کاستی های راه حل های HTML5، بسیاری از شرکت ها ابزارهایی ایجاد کرده اند که به شما امکان می دهد کد را به یک زبان غیر بومی بنویسید و سپس آن را به بومی ترجمه کنید. به این صورت است که دو پرنده با یک سنگ به طور همزمان کشته می شوند: پایه کد یک است و برنامه ها تا حد امکان به نسخه بومی نزدیک هستند.


زامارین

پلتفرم مایکروسافت زبان برنامه نویسی استاندارد سی شارپ برای توسعه Enterprise استفاده می شود، محیط توسعه کراس پلتفرم ویژوال استودیو است. خروجی برنامه های بومی برای iOS، اندروید و ویندوز است. درست است، نسبتا بزرگ است.

React Native

Platform From - برنامه ها با جاوا اسکریپت و با استفاده از سبک های CSS مانند نوشته می شوند. رابط بومی است و کد قبلاً روی پلتفرم تفسیر شده است که به آن انعطاف لازم را می دهد.

React Native از آنجایی که یک پلتفرم نسبتاً جوان است، بدیهی است (هر چند نه به طور فاجعه بار) از کمبود ابزار توسعه و اسناد رنج می برد.

بال بال زدن

طبیعتاً چنین غولی مانند گوگل نمی تواند موضوع توسعه بین پلتفرمی برنامه های اندروید و iOS را دور بزند. Flutter، در حالی که فقط در نسخه بتا موجود است، رویکردی متفاوت از React Native و Xamarin دارد. کد منبع را به کد بومی که توسط پلتفرم اجرا می‌شود تبدیل نمی‌کند، بلکه در واقع پنجره‌ای را روی صفحه گوشی هوشمند ترسیم می‌کند و خود همه عناصر را ترسیم می‌کند. زبان مورد استفاده دارت «اختصاصی» است که گوگل آن را به عنوان نسخه بهبودیافته جاوا اسکریپت ایجاد کرده است.

این هم مزایا دارد (مثلاً رابط های خارجی مشابه) و هم معایبی (مثلاً ترسیم مجدد یک رابط به مقدار مشخصی حافظه و زمان CPU نیاز دارد).

این پلتفرم به سرعت در حال توسعه است و گوگل تلاش و پول زیادی را صرف آن می کند. اما در مقایسه با Flutter، حتی React Native نیز یک اکوسیستم بسیار تثبیت شده و چشمگیر به نظر می رسد.

چه چیزی را انتخاب کنید

احتمالاً سر شما در حال چرخش است، اما هنوز نمی دانید چه چیزی را انتخاب کنید. بیایید یک لیست ساده از سوالات را برای کمک به شما ارائه دهیم:

  • باید به نوعی روی هر دستگاهی کار کند؟ انتخاب کنید HTMLبه عنوان پایه؛
  • آیا بودجه کافی دارید، آیا عجله ندارید و به دنبال بالاترین کیفیت برنامه هستید؟ شما یک مسیر مستقیم دارید توسعه بومی;
  • آیا یک توسعه دهنده وب داخلی دارید یا فقط می خواهید به سرعت و به راحتی یک برنامه تلفن همراه را امتحان کنید؟ در اینجا می توانید توصیه کنید Cordova/HTML یا PWA;
  • آیا سیستم CRM خود را دارید و یک توسعه دهنده C# از آن پشتیبانی می کند؟ گرفتن زامارین;
  • شما "می خواهید امتحان کنید"، اما باید همه چیز را زیبا و شیک کنید؟ به طرف نگاه کن React Native یا Flutter.

از طرف دیگر هم می توانید وارد شوید. به عملکردی که در برنامه خود نیاز دارید نگاه کنید و از آنجا بروید:

  • یک برنامه کارت ویزیت ساده؟ بگیرید React Native یا HTML5و شما دو پلتفرم با حداقل قیمت دریافت خواهید کرد.
  • آیا شما یک وب سایت پر بازدید دارید و نیاز به آزمایش فرضیه حضور در موبایل دارید؟ HTML5;
  • برنامه های پیچیده با دسترسی به توابع دستگاه مورد نظر؟ Native Development، Xamarin، React Native.

توسعه بین پلتفرمی یک دارو نیست

هنگام انتخاب، باید از وظایف و منابع موجود پیش بروید. توسعه بین پلتفرمی یک مسیر خوب و قابل درک است، اما با مزایا و معایب خاص خود که حتی قبل از راه اندازی یک پروژه باید در نظر داشته باشید. بدیهی است که یک برنامه چند پلتفرمی ساخته شده بهتر از یک برنامه بومی ساخته نشده است. می‌توانید سریع و ارزان آن را توسعه دهید، آن را در فروشگاه آپلود کنید، و به سادگی تقاضای کاربران را بررسی کنید - آیا کسی به دنبال برنامه‌ای از شما است، آیا نصب می‌کند، از چه عملکردهایی استفاده می‌کند. بر اساس نتایج چنین آزمایشی، می توان در مورد سرنوشت جهت موبایل در شرکت شما و سرمایه گذاری در آن تصمیم گیری کرد.

آیا هنوز در مورد برنامه های کاربردی کراس پلتفرم تردید و سؤال دارید؟ در مورد نحوه ایجاد یک برنامه کاربردی برای دریافت سریع اشتراک یکی از امکانات ورزشی شهر بخوانید و برنامه را برای پرداخت انواع خدمات - از خدمات آب و برق گرفته تا سفارشات در فروشگاه های آنلاین، امتحان کنید. بهتر است برای مشاوره رایگان با بودجه تقریبی و توضیح مختصری از ایده ثبت نام کنید یا از طریق تلفن با مدیر ما کاتیا تماس بگیرید.


امروز پیشنهاد می کنیم بفهمیم که چگونه برنامه ایجاد شده در طراح با برنامه ای که در استودیو توسعه می دهید متفاوت است.

برنامه های کاربردی بومی برای پارامترها و ویژگی های یک پلت فرم خاص طراحی شده اند(سیستم‌عامل تلفن همراه، اکوسیستم مرتبط و مشخصات فنی خود دستگاه تلفن همراه) و از تمام قابلیت‌های پلتفرم سخت‌افزاری مورد نیاز برای کار با برنامه استفاده می‌کند - از دوربین و ماژول GPS گرفته تا شتاب‌سنج، کنترل ژست‌ها و سایر سخت‌افزارهای پشتیبانی شده ویژگی های یک گوشی هوشمند یا تبلت خاص علاوه بر این، یک برنامه بومی توسعه یافته در استودیو را می توان به عنوان یک محصول نهایی به دست آورد و در فروشگاه برنامه های تلفن همراه (مانند Google Play یا Apple App Store) قرار داد.

این برنامه بومی همچنین از یک سیستم اعلان برای هر دستگاه استفاده می کند، از اعلان های فشاری پشتیبانی می کند و می تواند به صورت آفلاین کار کند.

و چه چیزی اکثر طراحان آنلاین را ایجاد می کند؟

ما منتشر کردیم، اما این بیشتر یک لیست از ابزارهای آزمایشی است (برای اینکه ببینیم برنامه در زندگی چگونه به نظر می رسد)، نه یک راه حل کامل برای کسانی که می خواهند یک برنامه را از ابتدا ایجاد کنند.

سازنده آنلاین نه یک برنامه بومی، بلکه یک برنامه وب ایجاد می کند، که یک محصول نرم افزاری به معنای کلاسیک نیست، در واقع یک وب سایت خاص است که شبیه یک برنامه بومی به نظر می رسد و عمل می کند، اما در واقع اینطور نیست. به عنوان یک قاعده، برای عملکرد آن، به یک مرورگر نصب شده و پیکربندی شده روی دستگاه تلفن همراه با دسترسی به اینترنت نیاز دارید. خود برنامه وب مبتنی بر استفاده از HTML5 است. این تا حدی محبوبیت روزافزون برنامه های کاربردی وب را توضیح می دهد (و همچنین این واقعیت که سیستم عامل جدید موبایل تایزن سامسونگ و برخی تغییرات اندروید از برنامه های تحت وب با این فناوری استفاده می کنند).

چنین برنامه وب برای همه پروژه ها مناسب نیست (به ویژه، اگر پروژه های رسانه ای و خبری با وبلاگ می توانند با قابلیت های HTML5 راضی باشند، پس چنین راه حلی برای فروشگاه های آنلاین و سایت های پر بار مناسب نیست).

علاوه بر این، در برخی فروشگاه‌ها نمی‌توان اپلیکیشن وب را برای توزیع نرم‌افزار موبایل منتشر کرد، پیاده‌سازی ماژول پرداخت و برخی ویژگی‌های دیگر که اپلیکیشن‌های بومی در آن دارند، دشوارتر است. بر خلاف اپلیکیشن های بومی، اپلیکیشن های تحت وب نیز از تمامی قابلیت های یک گوشی هوشمند استفاده نمی کنند، زیرا آنها دسترسی کامل به پلتفرم سخت افزاری و اجزای آن ندارند.

و همچنین برنامه های ترکیبی وجود دارد (سازنده نیز به ایجاد آنها کمک می کند).برنامه های ترکیبی از برخی از عملکردهای بومی و برخی از ویژگی های برنامه های وب استفاده می کنند. از برنامه های بومی، آنها توانایی انتشار در پلتفرم های آنلاین را برای توزیع و پشتیبانی برای دسترسی به سخت افزار smarfton گرفتند. از برنامه های وب، آنها از HTML پشتیبانی می کنند و در مرورگر کار می کنند.

شرکت‌ها اغلب به جذابیت و در دسترس بودن برنامه‌های ترکیبی، هم از نظر قیمت و هم از نظر سرعت توسعه «نوک می‌کنند» (قابلیت ساخت چنین برنامه‌ای در سازنده برای چندین پلتفرم به طور همزمان نیز فریبنده است).

اما حتی در اینجا نیز اشکالاتی وجود دارد که معمولاً در طراحی برنامه ها قابل توجه است: "تراشه های" بومی یک پلت فرم ممکن است به درستی روی پلتفرم دیگر کار نکنند و بالعکس. در نتیجه، معلوم می شود که حتی یک برنامه ترکیبی نیز بدون معایب یک برنامه وب نیست.

چه چیزی را باید انتخاب کنید؟

هر نوع برنامه مزایا و معایب خاص خود را دارد که در اینجا مهم ترین آنها وجود دارد:

دسترسی به ویژگی های دستگاه:
برنامه های بومی دسترسی کامل به پلتفرم سخت افزاری دارند، در حالی که برنامه های کاربردی وب چنین فرصت هایی را ندارند. بنابراین اگر می‌خواهید از قابلیت‌های دوربین، موقعیت جغرافیایی، انتقال داده‌های بی‌سیم استفاده کنید، یک برنامه بومی، نه تطبیقی، مناسب شما خواهد بود.

بدون دسترسی به اینترنت کار کنید:
اگر مهم است که بدون اتصال به اینترنت کار کند، یک برنامه بومی انتخاب شماست. برنامه های کاربردی وب به اتصال اینترنت و حافظه پنهان مرورگر بستگی دارند.

امکان جستجوی اطلاعات و خود برنامه:
برنامه های کاربردی وب در جستجوی محتوا بهتر هستند، اما اگر قصد دارید محتوای یک برنامه را بدون دسترسی به اینترنت جستجو کنید، باید یک برنامه ترکیبی یا بومی انجام دهید.

سرعت کار:برنامه های بومی سریع ترین هستند. در سال 2012، مارک زاکربرگ گفت که بزرگترین اشتباه شبکه اجتماعی او راه اندازی یک برنامه وب و توسعه ندادن یک راه حل بومی بود (تا آن زمان، فیس بوک از یک برنامه ترکیبی استفاده می کرد، جایی که بیشتر محتوا فقط در صورت اتصال به اینترنت در دسترس بود. و بر اساس HTML بود؛ در سال 2012 با بومی جایگزین شد). همه چیز در مورد سرعت پاسخگویی است.

مراحل نصب:
اگر برنامه‌های بومی و ترکیبی باید روی دستگاه شما نصب شوند و اجازه دسترسی به اجزای خاصی از پلتفرم نرم‌افزار و سخت‌افزار داده شود، برنامه وب اساساً با افزودن یک نشانک به مرورگر تلفن همراه «نصب» می‌شود.

مدیریت و نگهداری برنامه:پس از هر به روز رسانی، یک برنامه بومی باید مجدداً در فروشگاه برنامه میزبانی شود، در حالی که در یک برنامه وب، صفحه و محتوا اساساً به روز می شوند و به شکل نوعی سایت تلفن همراه "بسته بندی" می شوند.

اتصال به یک پلت فرم خاص:از آنجایی که مرورگرهای مختلف بدون در نظر گرفتن نوع پلتفرم سخت افزاری یا سیستم عامل موبایل نصب شده می توانند از نسخه های مختلف HTML5 پشتیبانی کنند، برای کسانی که می خواهند از شر این پلتفرم خلاص شوند، برنامه های کاربردی وب یا برنامه های ترکیبی انتخاب خواهند بود. اگر توسعه جداگانه برای هر پلتفرم فردی شما را نمی ترساند، می توانید روی یک برنامه بومی شرط بندی کنید.

کار با محتوا، روش افزودن به فروشگاه برنامه و پرداخت های اضافی:
اپلیکیشن های بومی و ترکیبی پس از اضافه شدن به اپ استور فرآیند تایید خاصی را طی می کنند. علاوه بر این، ممکن است به دلیل قوانین و خط‌مشی‌های داخلی App Store و Google Play (به‌ویژه وقتی صحبت از محتوای «بزرگسالان»، قمار، الکل یا موضوعات مشابه باشد، محدودیت‌های خاصی داشته باشند.

علاوه بر این، برنامه های بومی که اشتراک های پولی را به عنوان بخشی از برنامه های اضافه شده به اپ استور می فروشند، باید حق امتیاز را با اپل به اشتراک بگذارند. بر این اساس، قیمت گذاری و بودجه در مورد برنامه های کاربردی بومی باید با در نظر گرفتن میزان این کسرها تنظیم شود.

هزینه توسعه:از یک طرف، توسعه برنامه های کاربردی وب و راه حل های ترکیبی بسیار ارزان تر است (علاوه بر این، نسخه های ابتدایی چنین برنامه هایی به طور کلی می توانند به صورت رایگان یا با تخفیف قابل توجه در سازنده ایجاد شوند). از سوی دیگر، حتی برای ایجاد یک برنامه تحت وب یا یک برنامه ترکیبی، باید مهارت های توسعه کم و بیش قابل تحملی داشته باشید و تعداد محدودیت ها در امکان استفاده از یک بستر سخت افزاری، مناسب بودن «صرفه جویی» را زیر سوال می برد.

رابط کاربری:و یکی از دلایل کلیدی به نفع توسعه بومی، به جای راه حل های وب یا ترکیبی، یکپارچگی رابط کاربری در برنامه و سیستم عامل تلفن همراه است. اجزای بصری، گرافیک و رابط برنامه وب نیز می توانند تا حد امکان به مواردی که به طور پیش فرض در خود سیستم عامل هستند نزدیک باشند، اما برای انطباق کامل، هنوز هم ارزش استفاده از یک راه حل بومی را دارد.

آیا می خواهید یک برنامه بومی سفارش دهید؟ درخواست ارسال کنیدبا موضوع "توسعه برنامه" به ایمیل ما - و ما ظرف 24 ساعت با شما تماس خواهیم گرفت و تمام جزئیات را برای بحث بیشتر روشن خواهیم کرد.

تلفن‌های هوشمند همچنان فضای بیشتری را در زیر نور خورشید به دست می‌آورند، نه تنها به عنوان ابزاری برای مصرف عکس‌های گربه‌ها و فیلم‌های xxx، بلکه به‌عنوان یک ابزار کار. بنابراین، تقاضا برای توسعه تلفن همراه در حال رشد است. به طور کلی پذیرفته شده است که Objective-C/Swift برای iOS و Java/Kotlin برای اندروید درست و جالب هستند. بدون شک، درست و جالب است، اما تعداد زیادی از سناریوهای واقعی وجود دارد که در آنها استفاده از چارچوب های چند پلتفرمی در مقایسه با ابزارهای بومی ارجحیت بیشتری دارد.

برخی از توسعه دهندگان انتظار دارند که فریم ورک های چند پلتفرمی تمام مشکلات زندگی آنها را حل کنند، در حالی که برخی دیگر آنها را با خصومت درک می کنند. هر دو "اردوگاه متخاصم" تصورات نادرست خود را دارند که ناشی از درک نادرست از نحوه و چگونگی کار است. این به آتش سوخت می افزاید، زیرا از احساسات به جای استدلال های فنی استفاده می شود.

همچنین در میان توسعه دهندگان، به خصوص مبتدیان، افسانه های زیادی در مورد فریمورک های چند پلتفرمی موبایل وجود دارد. در مقاله ما محبوب ترین آنها را تجزیه و تحلیل خواهیم کرد. اما ابتدا، بیایید توسعه موبایل را از دید کسب‌وکاری ببینیم که برای تمام بلک‌جک‌های فناوری اطلاعات پول می‌دهد.

چرا به ابزارهای چند پلتفرمی نیاز داریم؟

از نظر تاریخی، همیشه رقابت در بازار رایانه وجود داشته است و هر سازنده مجموعه بهینه ای از ابزارهای به اصطلاح بومی (بومی) را برای توسعه برنامه های کاربردی برای سیستم عامل ها و دستگاه های خود ارائه می دهد.

ابزار بومی = توسط صاحب اکوسیستم ارائه شده است.

همه نشانه‌های دیگر "زادروز" ثانویه هستند - رفتار و رابط برنامه‌ها، دسترسی به ویژگی‌های سیستم عامل، عملکرد، و غیره.

علاوه بر این، تقریباً همیشه مشخص شد که ابزارهای بومی نه تنها در سطح زبان های توسعه، قراردادها و معماری های پذیرفته شده، بلکه در سطح مکانیسم های کار با سیستم عامل و کتابخانه ها با یکدیگر ناسازگار هستند. در نتیجه، برای پیاده‌سازی الگوریتم‌ها و رابط‌های یکسان، لازم بود یک برنامه کاربردی برای چندین محیط به زبان‌های برنامه‌نویسی مختلف نوشته شود و سپس آن را بر اساس «یک فرمان برای هر پلتفرم» نگهداری کنیم. در عین حال، قابلیت ها و ظاهر برنامه ها در پلتفرم های مختلف تقریباً همیشه 90٪ یکسان است. برای علاقه مندی، اجرای برنامه های مورد علاقه خود را برای iOS و اندروید مقایسه کنید.

دومین نکته مهم در دسترس بودن دانش و تجربه لازم در تیم است: اگر آنها وجود نداشته باشند، یادگیری زمان می برد.

برای حل هر دوی این مشکلات، ابزارهای توسعه چند پلتفرمی (نه تنها موبایل) برای مدت طولانی در بازار ظاهر شده اند و ارائه می دهند:

  • به حداکثر رساندن پایه کد مشترک در یک زبان برنامه نویسی واحد به طوری که توسعه و نگهداری محصول آسان تر باشد.
  • از شایستگی ها و متخصصان موجود برای پیاده سازی برنامه ها در پلتفرم های جدید استفاده کنید.

از آنجایی که در حال حاضر زبان‌های برنامه‌نویسی (و محیط‌های) زیادی (و متخصصانی که این زبان‌ها را می‌دانند) وجود دارد، تعداد زیادی ابزار برای توسعه بین پلتفرمی وجود دارد. به عنوان مثال، ما روی محبوب در منطقه خود تمرکز خواهیم کرد PhoneGap، Xamarin، React Native و Qt.


اکنون می توانیم در مورد اسطوره ها صحبت کنیم.

افسانه 1. جادو

رایج‌ترین افسانه‌ای که ذهن توسعه‌دهندگان نوپا را آزار می‌دهد، اعتقاد به الگوریتم‌های فوق‌العاده (و برنامه‌نویس‌های فوق‌العاده‌ای که آنها را ایجاد کرده‌اند) است که به‌طور جادویی اپلیکیشن‌های چند پلتفرمی را به برنامه‌های بومی تبدیل می‌کنند. چیزی در امتداد خطوط "تبدیل کد جاوا اسکریپت به سوئیفت و سپس کامپایل یک برنامه سوئیفت". این افسانه توسط خود توسعه دهندگان ابزارهای چند پلتفرمی تقویت می شود و در نتیجه نوید ایجاد "برنامه های بومی" را می دهند. و این نیست که کسی در اینجا حیله گر باشد، اما تخیل غنی و عدم درک مکانیسم های اساسی گاهی اوقات توسعه دهندگان را به فکر کردن درباره ترفندهای شمنیستی سوق می دهد.

اصل اصلی راه حل های چند پلت فرمی، تقسیم کد به دو بخش است:

  • کراس پلت فرمزندگی در یک محیط مجازی و دسترسی محدود به قابلیت های پلتفرم هدف از طریق یک پل ویژه.
  • بومی، که مقداردهی اولیه برنامه، مدیریت چرخه حیات اشیاء کلیدی را فراهم می کند و به APIهای سیستم دسترسی کامل دارد.


برای اتصال دنیای "بومی" و دنیای "کراس پلت فرم"، لازم است از یک ابزار ویژه استفاده شود. پل، اوست که امکانات و محدودیت های چارچوب های چند پلتفرمی را تعیین می کند.

هنگام استفاده از پل، عملکرد همیشه با تبدیل داده ها بین "جهان ها" و همچنین تبدیل تماس ها و کتابخانه های API کاهش می یابد.

بنابراین، همه برنامه‌های کاربردی کراس پلتفرم باید یک بخش بومی داشته باشند، در غیر این صورت سیستم عامل به سادگی قادر به اجرای آنها نخواهد بود. بنابراین بیایید نگاهی دقیق‌تر به APIها و مکانیسم‌های سیستمی داشته باشیم که توسط خود iOS، Android و Windows ارائه شده‌اند. بیایید به اسطوره بعدی برویم.

افسانه 2. بومی نیست!

بنابراین، ما یک بخش کراس پلتفرمی از برنامه داریم که در یک محیط مجازی زندگی می کند و از طریق زیرساخت چارچوب و پل با سیستم عامل تعامل دارد.

همه سیستم عامل ها: iOS، Android و Windows UWP - امکان دسترسی به زیرسیستم های زیر (مجموعه های API های سیستم) را فراهم می کند:

  • WebView (مرورگر وب ساخته شده در برنامه) در mashup های مبتنی بر PhoneGap استفاده می شود و به عنوان یک زمان اجرا مجازی برای وب سایت محلی عمل می کند.
  • موتورهای جاوا اسکریپت در React Native و همتایان آن برای اجرای سریع کد JS و تبادل داده بین Native و JS استفاده می شود.
  • OpenGL ES (یا DirectX) در موتورهای بازی و برنامه های کاربردی مبتنی بر Qt/QML یا مشابه برای رندر رابط استفاده می شود.
  • زیرسیستم UI مسئول رابط کاربری بومی برنامه است که مربوط به React Native و Xamarin است.


برنامه های کراس پلتفرم دارای یک بخش بومی و همان دسترسی کامل به API های سیستم به عنوان برنامه های "بومی" هستند. تفاوت این است که فراخوانی متد سیستم از طریق پل و زیرساخت چارچوب می‌گذرد:

مشاهده وب- برنامه در مرورگر وب خود مانند یک وب سایت یک صفحه ای زندگی می کند. بدون دسترسی به کنترل های بومی (دکمه ها، لیست ها و غیره)، همه چیز بر اساس HTML/CSS/JavaScript است. از سوی دیگر، یک توسعه‌دهنده وب مانند یک اردک به آب احساس می‌کند.

موتورهای جاوا اسکریپتاخیراً محبوب شده است، زیرا مکانیزم مشابه فقط در نسخه 7.0 به iOS اضافه شده است. از میان ویژگی‌ها، نیاز به سریال‌سازی ساختارهای داده پیچیده که بین محیط‌های جاوا اسکریپت و بومی به JSON منتقل می‌شوند، ارزش دارد. اگر به طور خلاصه چنین کلاسی از راه حل ها را توصیف کنیم، در محیط جاوا اسکریپت، کد JS که برنامه بومی را کنترل می کند، اجرا می شود.

OpenGL ES و DirectXزیرسیستم های سطح پایینی هستند و برای ترسیم رابط کاربری در بازی ها و به عنوان مثال Qt/QML استفاده می شوند. به این معنی که هنگام استفاده از OpenGL / DirectX، توسعه دهندگان خود کنترل ها و انیمیشن هایی را ترسیم می کنند که فقط می توانند مشابه موارد بومی باشند. از طرفی یک زیرسیستم سطح پایین با کارایی بسیار بالا است و به همین دلیل در موتورهای بازی کراس پلتفرم نیز از آن استفاده می شود.

همه برنامه‌های کاربردی کراس پلتفرم دارای یک بخش بومی هستند، و بنابراین، به طور بالقوه دسترسی کامل به APIهای سیستم مانند برنامه‌های «بومی» دارند. همچنین، برنامه های کاربردی کراس پلتفرم توسط ابزارهای "بومی" ساخته و در بسته های نصب "بومی" بسته بندی می شوند. سوال کلیدی این است که چگونه تعامل بین بخش کراس پلتفرم و بخش بومی سازماندهی می شود. به عنوان مثال، در داخل یک WebView یا با استفاده از Open GL ES / DirectX، هیچ راهی برای ایجاد یک رابط کاربری با ظاهر کاملاً بومی وجود ندارد، اما دسترسی کامل به GPS، اعلان‌های فشاری و سایر عملکردها وجود دارد. و کد جاوا اسکریپت یا سی شارپ می تواند کاملاً آزادانه برنامه بومی و رفتار آن را کنترل کند و ظاهری کاملاً بومی ارائه دهد.

به طور خلاصه - بله، "غیر بومی" از نظر ابزارهای توسعه استفاده شده (نه از اپل، گوگل). اما یک اپلیکیشن می تواند از نظر دسترسی به API های سیستم کاملا بومی باشد و ظاهر و احساس کاملا بومی ارائه دهد. و ما به اسطوره بعدی می رویم.

افسانه 3. عصا روی عصا

در اینجا باید درک کرد که API های بومی به طور پیش فرض عصا در نظر گرفته نمی شوند (اگرچه در اینجا نظرات متفاوتی وجود دارد)، بنابراین تمام عصبانیت ها متوجه بخش کراس پلت فرم است. بدیهی است که محیط اجرا (به عنوان مثال، WebView، موتور جاوا اسکریپت یا مونو) نیز دشوار است که بتوان آن را به عنوان راه حل های بالغ و بالغ با سابقه طولانی نامید.

به نظر می رسد که عصا نحوه ادغام قسمت کراس پلتفرم با قسمت بومی است. برای درک بهتر نحوه عملکرد فریمورک‌های مختلف، از مثال PhoneGap، Xamarin، Qt و React Native استفاده می‌کنیم تا مکانیسم‌های سیستم‌عاملی را که برای پیوند بین پلتفرم‌های مختلف و بخش‌های داخلی استفاده می‌شوند، بررسی کنیم.

ما با PhoneGap شروع می کنیم. در زیر معماری سطح بالای یک برنامه مبتنی بر این فریمورک آورده شده است.



برنامه PhoneGap در واقع یک برنامه بومی است که WebView را به عنوان تنها کنترل رابط کاربری نمایش می دهد. از طریق او است که تعامل با بخش بومی صورت می گیرد. همه WebView های استاندارد در iOS، Android و Windows UWP از قابلیت افزودن کنترل کننده های بومی برای ویژگی ها و روش های JS پشتیبانی می کنند. در همان زمان، کد JS در محیط ایزوله خود زندگی می کند و چیزی در مورد قسمت اصلی نمی داند - به سادگی روش های JS لازم را می کشد یا ویژگی های JS لازم را تغییر می دهد. همه چیز در داخل وب DOM استاندارد قرار دارد که به سادگی عناصر جدید مرتبط با پیاده سازی بومی را اضافه می کند.



هنگام ایجاد برنامه‌های کاربردی در React Native، توسعه‌دهنده تقریباً همیشه نیاز به پیاده‌سازی بخش اصلی در Objective-C، Java یا C# دارد و مدیریت خود برنامه بومی از جاوا اسکریپت انجام می‌شود. در واقع موتور جاوا اسکریپت یک عنصر WebView است که به صورت جداگانه در دسترس است. این تعامل از طریق همان پل JS مانند مورد PhoneGap انجام می شود. با این حال، در React Native، کد JS درخت وب DOM را مدیریت نمی کند، بلکه برنامه بومی را مدیریت می کند.

لطفاً توجه داشته باشید که به دلیل محدودیت‌های iOS (هیچ راهی برای پیاده‌سازی JIT وجود ندارد)، کد جاوا اسکریپت به‌سرعت تفسیر می‌شود و کامپایل نمی‌شود. به طور کلی، این واقعاً بر عملکرد در برنامه های واقعی تأثیر نمی گذارد، اما ارزش به خاطر سپردن را دارد.

اکنون Xamarin.iOS و Xamarin.Android کلاسیک را در نظر بگیرید، زیرا Xamarin.Forms (پشتیبانی از Windows UWP) یک افزونه برای آنهاست.



Xamarin از کتابخانه Mono برای تعامل با سیستم عامل هدف استفاده می کند که به کدهای بومی اجازه می دهد تا با استفاده از مکانیزم P/Invoke فراخوانی شوند. همچنین برای برقراری ارتباط با API های بومی در iOS/Android استفاده می شود. یعنی Wrapperها در سی شارپ برای همه متدهای بومی API عمومی ایجاد می شوند که به نوبه خود APIهای سیستم را فراخوانی می کنند. بنابراین، تمام API های سیستم را می توان از یک برنامه Xamarin دسترسی داشت.

و در نهایت، بیایید به Qt نگاه کنیم، زیرا سوالات زیادی در مورد آن از سوی توسعه دهندگان با تجربه وجود دارد.



Qt به خودی خود یک چیز است، این هم مزایا و هم محدودیت هایی دارد. کتابخانه های Qt به سادگی به API های سیستم C++ موجود در همه سیستم عامل ها متصل می شوند. برای ترسیم رابط کاربری، از مکانیزم های سطح پایین استفاده می شود، اما موتور گرافیکی خودش که از استایل بومی پشتیبانی می کند. در همان زمان، در اندروید، شما باید از طریق یک پل مخصوص (JNI bridge) به Java API دسترسی داشته باشید و برای ویندوز UWP، از مبدل تماس Open GL ES به DirectX استفاده کنید، زیرا Open GL برای UWP در دسترس نیست.

به طور خلاصه: همه فریم ورک‌های چند پلتفرمی از قابلیت‌های بومی استاندارد سیستم‌های عامل استفاده می‌کنند، بالغ هستند، توسط تیم‌های مجرب و جامعه منبع باز با پشتیبانی غول‌های صنعت فناوری اطلاعات ایجاد شده‌اند. و در نهایت، نوبت به "قوی ترین" استدلال می رسد.

افسانه 4. به آرامی

یک برگ برنده مهم که مردم دوست دارند در اختلافات در مورد چارچوب های چند پلتفرمی از آن استفاده کنند، عملکرد پایین است. باز هم بسته به اینکه با چه چیزی مقایسه کنیم و در کدام طوطی ها بشماریم.

به یاد بیاورید که یکی از ویژگی های برنامه های کاربردی چند پلت فرم وجود موازی دو جهان است که توسط یک پل به هم متصل شده اند:

  • PhoneGap: HTML/JS و Native Java / Objective-C / C#.
  • React Native: JS و Native Java / Objective-C / C#.
  • Xamarin: Mono و Native Java / Objective-C.
  • Qt: C++ و Native Java/Objective-C.

بنابراین، هنگام مقایسه عملکرد، لازم است سرعت کار را در نظر بگیرید:

  • بخش کراس پلت فرم؛
  • قسمت بومی؛
  • پل

اگر در یک موتور جستجو تایپ کنید، به عنوان مثال، واکنش بومی در مقابل عملکرد سریع، می‌توانید تست‌های مختلفی را مشاهده کنید، و بسیاری از آنها متوجه می‌شوند که هنگام استفاده فعال از پل، عملکرد به شدت کاهش می‌یابد، از جمله دستکاری فعال UI از کدهای بین پلتفرمی. برای Xamarin، وضعیت یکسان به نظر می رسد - بخش کراس پلتفرم در پردازش داده ها بسیار سریع و قابل مقایسه با بخش بومی است، با این حال، هنگام استفاده از یک پل، ممکن است عملکرد کاهش یابد. Qt عموماً در سطح C++ کار می کند که به خودی خود سریع است. اگر راه‌حل‌های مبتنی بر PhoneGap را در نظر بگیریم، در اینجا عملکرد بسیار وابسته به WebView خواهد بود، اما همچنان نباید به طور فعال رابط کاربری را در کد جاوا اسکریپت تغییر دهید یا محاسبات علمی انجام دهید.

به آرامی؟ بله، افت عملکرد به دلیل تعامل نادرست با سیستم عامل از طریق پل امکان پذیر است. با این حال، خود جهان های کراس پلتفرم به همان سرعتی هستند که جهان های بومی هستند.

*در این مقاله، ما شاپ های مبتنی بر مرورگر وب را بررسی می کنیم.

بومی یا ترکیبی، این سوال است. برای انتخاب درست، باید به وضوح درک کنید که هر نوع برنامه چیست و چه اهدافی را دنبال می کند.

جالب هست! طبق آمار Flurry Analytics، ما 90٪ از تمام زمان را در برنامه های کاربردی با تلفن می گذرانیم.

در حالی که هر نوع طرفداران سرسخت خود را دارد، بومی‌ها و ماش‌آپ‌ها از پشت همدیگر نفس می‌کشند، و انتخاب برنده واضح کار سختی است.

با داشتن سالها تجربه در توسعه برنامه های کاربردی بومی و ترکیبی، ویژگی های هر دو نوع را به طور کامل مطالعه کردم. در این مقاله سعی شده است گردآوری شود مزایا و معایب اصلی بومیان و هیبریدها, تا انتخاب درست را برای شما آسان تر کند.

برنامه های ترکیبی و بومی

بنابراین، این دو نوع برنامه چه تفاوتی با یکدیگر دارند؟

برنامه بومیبرای هر پلتفرمی، چه iOS یا اندروید، بومی است و به طور خاص برای آن به زبان خاصی نوشته شده است.

برای نوشتن یک برنامه بومی iOS، Swift یا Objective-C استفاده خواهد شد. برای برنامه های بومی اندروید، جاوا یا کاتلین خوب است.

با این حال، طبق آمار VisionMobile، 47٪ از تمام برنامه های بومی iOS و 42٪ از همه برنامه های بومی اندروید در واقع از HTML5 نیز استفاده می کنند.

و در اینجا یک مثال از یک برنامه بومی است:

برنامه تجارت الکترونیک معروف جهانی Bounce توسط توسعه دهندگان ما در سوئیفت برای iOS و جاوا برای اندروید نوشته شده است.

برنامه در دسترس است فروشگاه اپلو گوگل پلی.

برخلاف بومی، کاربردهای ترکیبیبرای هر دو پلتفرم به طور همزمان توسعه یافته و به زبان جهانی نوشته شده اند.

برای جستجوی آنلاین جراحان و گرفتن نوبت می توانید با هیبریدها به عنوان مثال از برنامه کاربردی دیگر ما که در بازار غرب گسترده شده است - لیزیک آشنا شوید.

برنامه در دسترس است فروشگاه اپلو گوگل پلی.

بیایید نگاهی دقیق تر به هر یک از انواع آن بیندازیم و اسرار درونی آنها را دریابیم. و اجازه دهید با برنامه های هیبریدی دو وجهی شروع کنیم.

مزایای برنامه های هیبریدی

  • صرفه جویی در . اگر آماده نیستید کیف پول خود را برای دستیابی به اپلیکیشن عالی خالی کنید، اما می خواهید یک اپلیکیشن ساده با قیمتی مقرون به صرفه داشته باشید، پس یک ترکیبی گزینه شماست. فقط فکر کنید با ایجاد یک برنامه برای دو پلتفرم به طور همزمان چقدر صرفه جویی خواهید کرد!

  • ورود به بازار در 2 پلت فرم به طور همزمان . از آنجایی که یک اپلیکیشن هیبریدی برای دو پلتفرم به طور همزمان نوشته می شود، همزمان وارد دو بازار می شود. به همین دلیل، تعداد کاربران بالقوه نیز به همراه شانس دانلود اپلیکیشن شما دو برابر می شود. با این حال، اینجاست که نقاط قوت اپلیکیشن های هیبریدی به پایان می رسد و ارزش توجه به نقاط ضعف آن ها را دارد.

معایب برنامه های هیبریدی

  • غیر عملی بودن . حتی یک برنامه هیبریدی که به خوبی طراحی شده باشد می تواند به سرعت منسوخ شود. پیشرفت ثابت نمی ماند و صاحبان اپلیکیشن ها سعی می کنند با آن همگام باشند. به محض ظهور فناوری های جدید، هر یک از صاحبان سعی می کنند در اسرع وقت یک ویژگی عجیب و غریب را به برنامه خود اضافه کنند. متاسفانه برای هیبریدها 3 تا 6 ماه طول می کشد تا چارچوب را تغییر دهید و قابلیت های جدیدی به آن اضافه کنید. تنها پس از آن، توسعه دهندگان می توانند برنامه شما را نیز بهبود بخشند. در برنامه های بومی، نوآوری ها را می توان بلافاصله پس از اعلام اضافه کرد.

بعید است که اگر برنامه ما بی کیفیت و ناپایدار باشد در بین کاربران مورد تقاضا باشد:

طبق آمار، تقریباً نیمی از کاربران بلافاصله برنامه های خسته کننده و بد طراحی شده را از تلفن هوشمند خود حذف می کنند و برنامه های رقابتی دیگری را به جای خود نصب می کنند.

  • سرعت کم . اغلب برنامه های ترکیبی صفحات وب هستند که خیلی سریع نیستند، به عنوان مثال، در پیمایش محتوای سنگین: تصاویر، انیمیشن ها و غیره.

پیمایش - پیمایش عمودی یا افقی صفحه.

علاوه بر این، توسعه ترکیبی مبتنی بر وب دستخوش تلفیقی‌های مختلفی می‌شود که سرعت اپلیکیشن را نیز کاهش می‌دهد و به هیچ وجه کاربران را خوشحال نمی‌کند.

کامپایل فرآیند ترجمه یک زبان برنامه نویسی سطح بالا (PHP، جاوا، جاوا اسکریپت) به زبان ماشین است.

  • مشکلات طراحی . اگر می‌خواهید اپلیکیشن شما برای هر پلتفرم، خواه iOS یا اندروید، شبیه یک طراحی سیستم حرفه‌ای و کاملاً تحقیق شده باشد، باید برای هر دو سیستم عامل جداگانه طراحی کنید. برنامه های iOS و Android استانداردهای طراحی منحصر به فرد خود را دارند و از آنجایی که یک برنامه ترکیبی این استانداردها را برآورده نمی کند، باید «سفارشی» شود تا در چارچوب مناسب قرار گیرد. به نظر می رسد که در پایان کار شما فقط یک برنامه دریافت خواهید کرد و برای دو مورد وقت و هزینه کرده اید.

  • ناامنی کد منبع . یکی از معایب جدی برنامه های هیبریدی ناامن بودن آنهاست. در حالی که برنامه بومی ممکن است قبل از انتشار در فروشگاه رسمی رمزگذاری شود، برنامه ترکیبی خالی باقی می ماند. از آنجایی که بسیاری از mashup ها بر اساس یک صفحه HTML هستند، نگاه کردن به کد منبع و درک نحوه عملکرد خود برنامه آسان است. حداقل ممکن است کد شما دزدیده شود. به عنوان حداکثر، یک مهاجم می تواند از برنامه شما برای اهداف خودخواهانه خود استفاده کند، به عنوان مثال، برای به دست آوردن اطلاعات و داده های خصوصی در مورد برنامه.

مزایای برنامه های بومی

  • کیفیت بالا . یک توسعه دهنده برنامه بومی بسیار تخصصی، کد تمیز و منحصر به فرد را برای شما می نویسد. تجربه چندین ساله توسعه و استانداردهای واضح برنامه های کاربردی iOS و Android به ساخت محصولی با کیفیت بالا با عملکرد گسترده کمک می کند و خطر اشکالات را تقریباً به حداقل می رساند.
  • احتمال رد شدن در App & Play Stores کم است . از آنجایی که یک برنامه بومی از ابتدا الزامات استاندارد یک پلتفرم خاص را برآورده می کند، بعید است هنگام اجرای برنامه خود در فروشگاه رسمی App و Play Store با مشکلی مواجه شوید.
  • استفاده 100% از طراحی UX . کاربران مدرن برای رابط‌های پر زرق و برق و با جزئیات غمگین هستند و بعید است که برنامه‌های ساده و استاندارد آن‌ها را مورد توجه قرار دهند. در توسعه بومی است که از طراحی UX 100٪ استفاده می شود که به شما امکان می دهد یک برنامه با کیفیت بالا و جالب بسازید. در یک برنامه ترکیبی، یک رابط استاندارد برای دو پلتفرم دریافت خواهید کرد.

  • انواع ابزارهای توسعه . به لطف سال ها تجربه در توسعه برنامه های بومی، تعداد زیادی فریمورک مختلف، قالب ها و سایر ابزارهای اثبات شده ظاهر شده اند که به شما امکان می دهند برنامه خود را منحصر به فرد، فردی و پایدار کنید.
  • جامعه توسعه دهندگان بزرگ . و البته، هنگام توسعه یک برنامه بومی، بعید است با مشکلی روبرو شوید که هیچ کس قبل از شما آن را حل نکرده باشد. و این بدان معنی است که شما مجبور نیستید زمان زیادی را برای یافتن راه حل مناسب صرف کنید، بلکه می توانید به تجربه برنامه نویسان دیگر روی بیاورید.

معایب برنامه های بومی

  • قیمت . همانطور که می گویند پنیر مجانی فقط در تله موش است. اپلیکیشن بومی محصولی منحصر به فرد و با کیفیت است که ایجاد آن به زمان زیادی نیاز دارد و البته به یک توسعه دهنده بسیار ماهر با سال ها تجربه نیاز دارد. بنابراین، چنین برنامه ای بر این اساس ارزش دارد.

حقیقت جالب

وقتی بفهمید واقعا چیست شگفت زده خواهید شد توسعه یک برنامه بومی iOS هزینه کمتری نسبت به یک برنامه ترکیبی دارد . باور نمی کنی؟ خودت ببین!

هنگام توسعه یک برنامه بومی، ابزارهای متنوعی در SDK یک پلتفرم خاص گنجانده شده است. یعنی تنها چیزی که نیاز دارید استفاده از این ابزارها در اپلیکیشن بومی خود است.

در مورد یک ترکیبی، فقط می توانید امیدوار باشید که یک انطباق برای این یا آن ابزار بومی بر اساس چارچوب انتخاب شده برای توسعه ترکیبی وجود داشته باشد.

اگر چنین ابزاری وجود نداشته باشد، یا باید منتظر بمانید تا ظاهر شود، یا فریمورک های جایگزین را در نظر بگیرید، یعنی مشکلات ترکیبی بسیار بیشتر است.

بر این اساس، معلوم می شود که، برای ایجاد یک برنامه بومی iOS ارزان تر از یک برنامه هیبریدی iOS است.

اگر توسعه یک اپلیکیشن هیبریدی و دو برنامه بومی را مقایسه کنیم، آن‌طور که انتظار می‌رود، قیمت یک هیبرید پایین‌تر خواهد بود، زیرا در یک اپلیکیشن هیبریدی، بک‌اند و فرانت‌اند برای دو پلتفرم همزمان مناسب هستند.

در یک برنامه بومی، باید دو فرانت اند مجزا ایجاد کنید که استانداردهای پذیرفته شده کلی هر یک از پلتفرم ها را برآورده کند.
از این رو نرخ های زیر:

برنامه هیبریدی iOS- 11.5 هزار دلار
برنامه های HYBRID iOS + Android
12.5 هزار دلار

برنامه بومی iOS- 10 هزار دلار
برنامه های بومی iOS + Android
18 هزار دلار

با این حال، اگر به دقت نگاه کنید، متوجه خواهید شد که هزینه برنامه های بومی خیلی بیشتر از هزینه های ترکیبی نیست.

حال به این فکر کنید که آیا هنگام توسعه یک برنامه ذخیره کنید یا خیر؟ یا شاید هم دو تا بومی بسازید؟

از این گذشته، برای کاربران، هم ظاهر اپلیکیشن و هم اینکه چقدر راحت و باکیفیت خواهد بود بسیار مهم است.

کدام برنامه را انتخاب کنیم؟

در این صورت 100% مطمئن خواهید بود که پول به خوبی خرج شده است و در نتیجه دقیقا همان اپلیکیشنی را که سفارش داده اید دریافت خواهید کرد.

بنابراین ،

یک برنامه ترکیبی را انتخاب کنیداگر می خواهید دریافت کنید:

  • برنامه ساده
  • اپلیکیشن برای دو پلتفرم با قیمت مناسب
  • 1 اپلیکیشن با قابلیت ورود سریع به دو بازار (ios/اندروید)

یک برنامه بومی انتخاب کنید، اگر احتیاج داشته باشی:

  • یک اپلیکیشن حرفه ای که تمام استانداردهای پلتفرم انتخابی را برآورده می کند
  • برنامه پیچیده با عملکرد گسترده
  • برنامه با سرعت بالا

اکنون که همه چیز و بیشتر در مورد برنامه های بومی و ترکیبی می دانید، می توانید به راحتی انتخاب درستی داشته باشید.

تمام رویاها و ایده های خود را به واقعیت تبدیل کنید .

برترین مقالات مرتبط