Что такое нативный файл
Разумеется, у меня были подобные беседы с клиентами, когда я был фриланс-разработчиком на Titanium. И уж конечно, как Developer Advocate, я частенько слышу это когда начинаю объяснять Titanium разработчикам, которые ищут кросс-платформенное решение для создания приложений.
Titanium !== HTML
Каждый раз при сравнении с Phonegap (Cordova), Ionic и чем-либо еще, я начинаю мотать головой, махать руками и громко кричать о том, что в Titanium нет HTML.
Но при общении с клиентами или людьми, не очень подкованными в техническом плане, для которых JavaScript вызывает ассоциации с этими технологиями, представление HTML как просто еще одного технического термина не всегда помогает. Кроме того, определение Titanium как чего-то, чем он не является, не совсем правильно.
Что ты имеешь в виду под «Нативной» разработкой?
- Разработчик использует предоставленные Apple, Google и Microsoft инструменты?
- Разработчик использует стандартный для платформы язык?
- Приложение использует строительные блоки (API), которые предоставляет платформа?
- Приложение работает так, как ожидает пользователь на этой платформе?
Что такое хороший User Experience?
Итак, что же значит соответствующий платформе UI и UX? Ну, в первую очередь то, что мы не печемся о технологии, только о том, что она нам дает; Как приложение выглядит и чувствуется пользователем. Во вторую то, что поведение приложения зависит от платформы.
Выглядит и ведет себя ожидаемо
iOS, Android и Windows имеют различные требования к дизайну (iOS, Android,Windows) и если вы опираетесь на них, ваше приложение более предсказуемо и следовательно, проще в использовании.
Отличный пример – TabGroups. На Андроиде они, как правило, встроены в Action Bar и будут прокручиваться если их много. На iOS Tab Bar расположен внизу и если у вас больше пяти табов, то пятый будет вести на экран выбора нужного таба. На Windows Pivot Tabs работают почти как на Андроиде, но выглядят немного по-другому, они не являются частью Command Bar, который расположен внизу экрана.
Так что технология, которая используется для разработки нативного приложения, не должна иметь собственные UI контролы, вместо этого она должна использовать те, которые предоставлены платформой.
В Titanium есть кросс-платформенные API почти для всего, и он всегда переводит их в платформенные UI-компоненты. Например, Ti.UI.TabGroup даст вам результат как на картинке выше, но напишете вы при этом один код (Alloy):
Для тех API, которые представлены не во всех платформах, мы используем пространства имен, например, Ti.UI.Android.CardView.
Единство API там, где это возможно, платформо-зависимые API – там, где нет. Всегда с уважением к целевой платформе.
Чувствуется ожидаемо
Но есть еще один, менее заметный фактор, который влияет на UX. Взаимодействие с приложением должно вызывать правильные чувства. Здесь мы имеем в виду, что время реакции и визуальный отклик такие, какие вы ждете от платформы.
Исторически этот момент всегда был большой проблемой для кросс-платформенной разработки. Все решения так или иначе имеют некий уровень абстракции над платформенными API. Это потенциальное узкое место. В Titanium мы посвятили массу времени оптимизации. Возьмите например, ListView, он может быть на 60% более отзывчивым, чем его предок, TableView.
В приложениях, которые используют HTML, это продолжает быть проблемой. Плоский интерфейс сделал все для того, чтобы такие приложения выглядели хорошо, но не нужно быть семи пядей во лбу, чтобы заметить разницу в том, как UI реагирует на взаимодействия. Часто он просто «не такой», и вот в чем задача UX: сделать его «таким».
Как достичь классного UX?
Кроме всего прочего, вам нужно классный разработчик. Плохие приложения можно и в XCode со Swift сделать, так что без сомнения, вы можете сделать его и с помощью любой (кросс-платформенной) технологии. Используйте нужные платформо-зависимые UI компоненты в нужных местах, избегайте утечек памяти, пишите чисто и с умом.
Плюс ко всему, используйте имеющиеся в вашем распоряжении строительные блоки, не имитируйте их. Помните, Titanium !== HTML и наши 4 пункта списка. Мы с уверенностью полагаем, что для нативного UX нужно использовать нативные UI и системные API. Для достижения пункта №4 нужно выполнить пункт №3.
Вот поэтому Facebook отказался от HTML приложений и создал React Native.
И да, у нас в Titanium это было с 2009.
Code Strong, Code Native… In JavaScript!
Перед тем, как приступить к созданию мобильного приложения, стоит задуматься о выборе технического подхода к процессу: нативной или кроссплатформенной будет разработка?
В качестве короткого ликбеза поясняем: под нативной разработкой специалисты подразумевают использование оригинальных языков программирования и инструментов мобильной ОС. При кроссплатформенной разработке на вооружение берутся специализированные инструменты, при помощи которых можно создавать приложения, работающие в нескольких мобильных операционных системах сразу.
Оба подхода требуют определённых наборов инструментов, максимально подходящих для написания кода, проектирования интерфейса, отладки, мониторинга всех процессов и сборки окончательной версии приложения.
И оба этих подхода имеют свои преимущества и недостатки как для пользователей, так и для разработчиков. Разобраться начинающим программистам во всех плюсах/минусах нативной и кроссплатформенной разработки помогают специалисты НandsApp.
Михаил Овчинников, (Технический директор студии мобильной разработки Hands App)
Замечательный английский программист Джоел Спольски в своём мега-популярном блоге «Джоэл о программном обеспечении» (Joel on Software) как-то вывел «закон дырявых абстракций». Его суть заключается в следующем: теоретически абстракции должны изолировать нас от более низкого уровня, но в некоторых случаях они всё же настолько сложны, что нужно вникать в особенности реализации и на низком уровне.
Этот принцип относится и к кроссплатформенным фреймворкам. Обычно они абстрагируют разработчиков от особенностей написания кода под отдельную платформу. Однако, как только вопрос касается производительности или реализации специфического функционала под платформу, так сэкономленное при разработке время съедается на решении этих проблем.
Разумеется, есть области, где применение кроссплатформенных технологий полностью оправдано. Прежде всего разработка игр: к примеру, движок Unity — это хороший вариант для большинства разработчиков. Многие маркетологи, имея лишь базовые знания HTML/CSS/JS, успешно используют Ionic для тестирования своих гипотез без привлечения отдела разработки. Многие стартапы выбирают Flutter для того, чтобы быстро сделать минимально жизнеспособную версию продукта (MVP), доказав тем самым на практике конкурентоспособность своего детища.
Не нужно забывать и о том, что подходы при разработке приложения можно комбинировать. Например, отрабатывать критичные к производительности экраны (лента новостей в социальной сети) на нативных технологиях, а второстепенные (экран профиля, экран настроек) — на кроссплатформенных.
Если смотреть с точки зрения карьерного старта программиста, то делать ставку на кроссплатформенную разработку довольно рискованно: у крупных компаний пока мало вакансий такого рода, и вряд ли эта ситуация сильно изменится в будущем. У крупных компаний уже написаны огромные кодовые базы на нативных технологиях, которые нужно кому-то поддерживать. Поэтому если есть мечта — работать в одном из ИТ-гигантов, — то лучше выбрать ту платформу, которая больше нравится и заняться её углубленным изучением.
Никита Красавин, …(ведущий iOS разработчик студии мобильной разработки Hands App)
Давайте для начала разберёмся в деталях: что такое нативная разработка, что из себя представляет кроссплатформа, и чем они отличаются.
Нативная разработка — это процесс воплощения мобильного приложения с использованием официальных средств, предоставляемых разработчиками системы, для которой пишется приложение. Она направлена на одну конкретную мобильную систему. Например, Apple предоставляет интегрированную среду разработки XCode для нативной разработки приложений под iOS. И нельзя написать с помощью XCode приложение для Android. Всё очень просто: один код — одна система.
Кроссплатформенная разработка — это способ создания приложения с возможностью адаптации под несколько систем. По аналогии: один код — много систем.
Несмотря на то, что кроссплатформенные средства позволяют сильно экономить время, нативная разработка в среде программистов более популярна. По нескольким причинам, давайте рассмотрим основные.
1. У мобильных систем iOS и Android есть существенные различия, которые вызывают сложности при кроссплатформенной разработке. Это касается в первую очередь элементов интерфейса. Именно поэтому написать один универсальный код иногда гораздо сложнее, чем сделать это нативно.
2. Нативные среды максимально оптимизированы для работы со своей системой. Кроссплатформенным инструментам же приходится проксировать вызовы системных методов. В результате падают показатели быстродействия, и поэтому кроссплатформенные приложения чаще крашатся, дольше думают и тормозят.
3. Поддерживать кроссплатформенный код гораздо сложнее, чем нативный. Обновление систем приводит к частому обновлению программных интерфейсов, что требует больше рабочего времени программиста (если сравнивать с работой по обновлению кода нативного приложения).
4. При разработке нативного приложения программист почти всегда находит ответ на интересующий его вопрос по коду от коллег или использет сторонние библиотеки для конкретной задачи. В кроссплатформенном мире комьюнити меньше: часто приходится решать возникшую проблему самостоятельно. Собственно этот пункт относится к сфере популяризации нативной разработки: чем больше сторонников — тем больше комьюнити. А значит и работа над конкретной задачей упрощается.
Таким образом, преимущество скорости кроссплатформенной разработки нивелируется рядом прочих негативных факторов.
Подведём итоги: кроссплатформа удобна при написании простого приложения, в котором мало экранов и много общих элементов для разных платформ. Идеальная задача для кроссплатформы — разработка мобильной игры.
Для приложений с уникальными интерфейсами и сложной бизнес-логикой больше подходит нативный способ разработки.
Программистам-новичкам однозначно лучше начинать с нативной разработки хотя бы потому, что большое комьюнити всегда поможет сориентироваться в возникшей проблеме и даст наводку на ту информацию, которая поможет в каждом конкретном случае.
Лялин Виталий
Руководитель направления маркетинга в студии мобильной разработки Hands App
Судя по «обильным» комментариям ваш материал явно не для VC :)
Но, вам «повезло», что вы «нарвались» на коллегу по цеху, который может предположить, что у вас еще мало опыта использования фреймворков в мобильной разработке, чтобы писать такие статьи.
«Многие маркетологи, имея лишь базовые знания HTML/CSS/JS, успешно используют Ionic» -
действительно, Ionic, Cordova, Xamarin и другие фреймворки можно использовать для простых задач (аля WebView), чтобы быстро решить проблему в ущерб производительности.
Но, причем тут: «Многие стартапы выбирают Flutter для того, чтобы быстро сделать минимально жизнеспособную версию продукта (MVP), доказав тем самым на практике конкурентоспособность своего детища.» или «Поддерживать кроссплатформенный код гораздо сложнее, чем нативный.»
Многие стартапы хотят использовать Flutter, но стоимость работы специалистов Flutter/Dart им не по карману, и они вынуждены довольствоваться тем, что могут себе позволить: Ionic, Cordova, Xamarin.
Flutter – это лучшее, что появилось в мобильной разработке за все время ее существования! Ко всему, может случиться так, что это будет единственно подходящий инструмент для разработки приложений под новую Fuchsia (операционная система, разрабатываемая компанией Google, взамен Android).
Конечно, использовать только Flutter не получится. Flutter – это только интерфейсы, многие системные и нестандартные методы остаются в нативе. Чтобы разрабатывать на Flutter нужно знать все: Flutter/Dart + xCode/Swift + Android/Java - именно поэтому специалисты Flutter «дороже» других.
Если у вашей студии есть возможность разработать более-менее серьезное приложение для iOS и Android платформ в нативе, а затем, перевести на Flutter, далее, сравнить скорость работы интерфейсов, то вы сразу поймете, почему Flutter – это действительно «новая эра» в разработке визуальных частей мобильного приложения!
Например, на Android устройствах нативный код работает через Java-машину и поэтому интерфейсы тормозят, а Flutter работает напрямую с операционной системой и ее графическим ускорителем – все интерфейсы просто летают!
Просто и понятно о том, в каком случае можно использовать кроссплатформенную разработку, а когда не обойтись без нативной.
Я знаю, что это далеко не первый текст на данную тему. Но до сих пор в топовых позициях находятся статьи с устаревшей и неверной информацией (например, что кроссплатформенные приложения нельзя опубликовать в магазинах). Поэтому я решил актуализировать информацию и рассказать об отличиях в подходах в простой форме, для тех, кто однажды столкнётся с разработкой мобильных приложений.
Представим себе Сергея, у которого есть автопарк. Сергей хочет получать больше заказов и поэтому решается на разработку собственного приложения для вызова такси. Разумеется, он хочет охватить больше клиентов: поэтому ему нужно программное обеспечение как для IOS, так и для Android. Сергей понимает, что это будет два разных приложения, но что-то слышал о том, что можно сделать одно, которое будет работать на всех смартфонах.
Нативная разработка - это создание продукта, который пишется на оригинальных языках программирования, созданных специально для выбранной платформы. Например, родными языками для Android являются Java и Kotlin, для iOS - Swift и Objective-C. Нативное приложение будет работать только на “своей” платформе. Кроссплатформенные приложения могут работать сразу на нескольких операционных системах. Для этого используются специализированные кроссплатформенные фреймворки, например Flutter или React-Native.
Теперь Сергей знает, что есть что. На первый взгляд, кроссплатформенная разработка кажется более выгодной, но он понимает, что в подходах есть существенные различия.
Логично было бы предположить, что кроссплатформенная разработка должна стоить в два раза меньше, чем нативная, ведь разрабатывается одно приложение вместо двух. Но это не так и вот почему. Несмотря на то, что при кроссплатформенной разработке у продукта будет одинаковая бизнес-логика и навигация, экраны для каждой системы будут отличаться. Таким образом, для IOS и Android отрисовываются и реализуются собственные экраны приложения. Если говорить о цене, то стоимость кроссплатформенной разработки в среднем на 70% ниже, чем нативная.
Нативное приложение всегда будет выглядеть лучше, чем то, что разработали по мультиплатформенной технологии. Дизайн, скорость загрузки, доступ ко всем функциям устройства (камера, геолокация, календарь и так далее), интерфейс – все это будет давать нативной разработке сто очков вперед. Кроссплатформенные приложения в этом плане уступают нативным – работают медленнее, а интерфейс значительно отличается.
Нативная разработка дороже, так как придется задействовать как минимум двух разработчиков, специализирующихся на разных платформах. Кроме того, такой подход требует больше времени.
Главным достоинством кроссплатформенного подхода является то, что скорость разработки выше, нежели у нативной, а времени и ресурсов затрачивается меньше.
Наш Сергей немного запутался, попробуем до бавит ь конкретики .
Кроссплатформенная разработка не подходит для серьезных бизнес-проектов. Такое решение оптимально при написании простого приложения, в котором мало экранов и много общих элементов для разных платформ. Например, данный тип разработки выгоден при написании прототипа приложения под несколько платформ в сжатые сроки, для игрового или тестового приложения.
Для приложений с уникальными интерфейсами и сложной бизнес-логикой больше подходит нативный способ разработки.
Теперь Сергею понятно, зачем нужна кроссплатформенная и нативная разработка, он принял решение для своего проекта, но все равно еще все обсудит с профессионалами.
Нативная разработка на нескольких платформах выгоднее для веб-студий, но мы в Yusmp Group не навязываем такие услуги проекту, которому это не требуется. Если заказчику нужна демонстрационная версия, а сроки и бюджет ограничены, то разумнее выбирать кроссплатформенную разработку.
native file — /neɪtɪv ˈfaɪl/ (say naytiv fuyl) noun a file which is saved in the proprietary format of the software in which it was created, as opposed to plain text format or rich text format … Australian-English dictionary
File system — For library and office filing systems, see Library classification. Further information: Filing cabinet A file system (or filesystem) is a means to organize data expected to be retained after a program terminates by providing procedures to store,… … Wikipedia
native American — native American, adj. a person born in the United States. [1835 45, Amer.] * * * ▪ indigenous peoples of Canada and United States Introduction also called American Indian, Amerindian, Amerind, Indian, Aboriginal American, or First Nation… … Universalium
Native title — is a concept in the law of Australia that recognises in certain cases there was and is a continued beneficial legal interest in land held by local indigenous Australians which survived the acquisition of title to the land by the Crown at the time … Wikipedia
Native American civil rights — are the civil rights of Native Americans in the United States. Although indigenous to the Americas, American Indians became one of many minorities and the movement for American Indian civil rights began almost as soon as Europeans started to… … Wikipedia
Native American hip hop — is hip hop culture practiced by people of Native American heritage; in colloquial terms, this also includes Canadian First Nation hip hop artists. As such it is not a specific form of hip hop but varies in style along the lines of hip hop in… … Wikipedia
File Thirteen Records — has been a communal and musician run independent record label since 1989. File Thirteen was founded in Little Rock, Arkansas by David Burns and Jason McCloud and was more utilitarian than a business. It provided a medium for musicians that found… … Wikipedia
Native API — (с заглавной N) в основном недокументированный интерфейс программирования приложений (API), предназначенный для внутреннего использования в операционных системах семейства Windows NT, выпущенных Microsoft[1]. В основном он используется во время… … Википедия
Native American gaming — enterprises are gaming businesses operated on Indian reservations or tribal land in the United States. Indian tribes have limited sovereignty over these businesses and therefore are granted the ability to establish gambling enterprises outside of … Wikipedia
Родной файл (Native File) — Файл, выполненный в формате, связанном с определенной программой, в отличие от общих стандартных форматов файлов, таких как PDF или DCS. Пример родного файла документ в пакете верстки QuarkXPress … Краткий толковый словарь по полиграфии
Native Americans in the United States — This article is about the indigenous people of the United States. For other indigenous people see Indigenous peoples by geographic regions Native Americans … Wikipedia
В переводе с английского Native = Родной. И смотря в каком контексте это встречается. Если например писать приложение на Flash под Android и iOS то это считается не нативное приложение. А если же писать два приложения. Одно на Android NDK для Android и iOS SDK для iOS то эти приложения можно счтитать нативными. Понятие нативный код - код который поставляется разработчиками чего-либо. Как например весь код в Java SDK под Android считается нативным. Все библиотеки третих разработчиков уже нет. Ну как то так :)
@fori1ton, спасибо. Вы мне открыли глаза :) Стока времени заблуждений. Но в тоже время код можно считать нативным по отношению к виртуальной машине?
@Bimawa, обычно так не делают. Есть нативнй - исполняемый на процессоре, и ненативный - исполняемый в виртуальной машине. Разве что если на Java написать виртуальную машину и запускать в ней какой-то код, то это будет ненативный код для JVM, а код самой виртуальной машины можно будет считать нативным по отношению к JVM. Но это уже изврат.
Понятие нативный код - код который поставляется разработчиками чего-либо. Как например весь код в Java SDK под Android считается нативным. Все библиотеки третих разработчиков уже нет.
Бред. Нативный код - код, компилируемый в машинные инструкции и выполняемый непоредственно процессором устройства. Любой код на Java не нативен по определению, так как выполняется на виртуальной машине. Нативный код могут писать как разработчики платформы, так и третьи разработчики (при помощи упомянутого Android NDK).
@fori1ton, возможно я не до конца понял Ваш ответ, но IMHO утверждение Любой код на Java не нативен по определению, так как выполняется на виртуальной машине. несколько спорно, если вспомнить о такой полузабытой штуке, как PicoJava (аппаратная интерпретация Java байт-кода). -- А по существу ответа, что нативным называется код, который исполняется аппаратно, я согласен (хотя иногда трудно провести границу между чистой аппаратурой, микропрограммами, гипервизором и эмуляцией некоторых команд системным ПО).
А учитывая, что современные процессоры умеют переставлять команды местами, более того, они транслируют инструкции в свое собственное внутреннее представление.
@KoVadim, да, и это очень напоминает JIT компиляцию, только не для байт-кода, а для машинных инструкций.
В одном слове "нативный" (от англ. native, "родной") недостаточно информации. Необходимо уточнение: родной для кого?
- Для JVM родной код - байт-код, родной язык - Java (и другие).
- Для Windows родной код - Portable Executable, родной язык - C++, Delphi и др.
- Для процессора x86 родной код - инструкции x86, язык - ассемблер.
и т.п. Многие современные приложения выполняются на "слоеном пироге" из платформ: например, написанное на Java приложение выполняется на JVM, которая в свою очередь может выполняться под (или над?) Windows, которая выполняется на процессоре x86. Каждый слой имеет свой нативный код. Код из другого слоя для него не будет нативным, например, для Windows Java-код ненативный.
Родной язык - язык, для которого есть компилятор в родной код (для данной платформы).
Обратимся к Wiki
In computing, software or data formats that are native to a system are those that the system supports with minimal computational overhead and additional components. This word is used in such terms as native mode or native code.
Something running on a computer natively means that it is running without any external layer requiring fewer software layers. For example, in Microsoft Windows the Native API is an application programming interface specific for Windows NT kernel, which can be used to give access to some kernel functions, which cannot be directly accessed through a more universal Windows API.
Нативный для среды исполнения код/язык/АПИ/Формат данных и т.д. - это такой, который понимается средой исполнения по умолчанию, без сложных надстроек. Абсолютно четкого определения нет - есть некое "общепринятое" понимание, которое может разниться от человека к человеку.
Нативный язык - это это еще более обтекаемое определение. Можно, с оговорками, считать, что нативный для платформы язык - это язык, для которого производителем платформы создана среда разработки/компилятор в нативный код и о поддержке которого они официально заявляют в документации.
PS На ум пришла хорошая аналогия. Уровень знания иностранного языка определяется экзаменами по нему с выставлением оценки: A1,A2,B1,B2,C1,C2. Но есть и еще один уровень владения языком - native. Означает он что человек с детства живет в данной языковой среде, говорит на нем и думает(!) на нем. Уровень native не говорит о грамотности человека, зачастую native хуже знает правила языка, чаще ошибается в грамматике и пунктуации, чем С2, но он для него РОДНОЙ.
Читайте также: