❶ 前端面試題，移動端兼容問題有哪些，安卓和ios問題
那麼進入正文，不廢話，直接把自己了解到的和一些看法說出來。
首先是屏幕問題，現在主流的移動設備以安卓和IOS為主，我們在製作移動端頁面也是以兼容這兩種設備去布局。
首先說iPhone，不得不說iPhone的屏幕考慮到了我們開發者的難處，從而給出iPhone屏幕的dpr都是整數值，在6plus出現之前，iphone的dpr始終是2（物理像素/邏輯像素＝2），即使是6plus出現了，iphone到底其實也就只有2，3這兩個dpr。其實6plus的實際dpr並不是整數，而是2.87左右，不過，為了方便開發者來開發，iphone6plus對其做了一個調整，將dpr調整為3，然後在對屏幕進行了一個縮放。所以我們很容易對其做到兼顧。
而安卓的dpr值，並不像iphone那樣就只有兩個值。安卓的dpr是千奇百怪的，可能是1.5，2，3，4，2.5等等的都有。（甚至我還看到了1.7之類的，安卓的各個設備商，玩的真尼瑪high啊。怎麼高興怎麼來。）
那麼現在開始說說移動端怎麼布局以及字體該怎麼設置，因為有各種各樣的解決方式，我就不一一贅述，直接說手淘的解決方案：flexible.js
我為什麼又一次把這個拿出來說，主要有兩點原因：1.我覺得它好用，解決方式簡單粗暴。2.它經過了比較長時間的考驗，如今手淘還在用它。
具體的使用方法自己可以去flexible.js看看，這里我簡單說說它的方案以及個人對它的改良。
❷ ios開發屬於前端嗎
ios開發屬於前端嗎？這個問題一看就知道是個外行問的。ios開發有前端有後端，它們之間是互不屬於但互有交集的關系。
❸ 前端ios與android的兼容性問題怎麼解決
解決瀏覽器兼容是必備問題，比如360的極速和兼容模式顯示同一個網頁
❹ ios底部輸入框被虛擬鍵盤遮擋，前端有沒有好的方法解決這問題
1.快速添加URL後綴
經常使用ios設備的朋友會發現，現在在Safari中輸入網址時，找不到「.com」「.net」等url後綴，只能一字一字的輸入。其實，完全不用這么麻煩，.com選項，還有.us、.e、.net以及.org都還在。用戶只要在句號按鍵上長按即可調出上述選項，長按調出後用戶手指不離開屏幕，在這些選項上滑動選擇之後它就會自動插入。
2.上下雙引號的添加
這個「點擊-滑動」機制貫穿整個ios7系統之中，而不僅僅是URL的輸入。輸入下雙引號也可以使用同樣的操作方法。長按句號鍵，即可調出下雙引號。而長按shift+逗號鍵即可調出上雙引號。
3.自動插入大寫字母
大寫字母時用戶也可以利用這個「點擊-滑動」機制。長按shift鍵並滑動手指到想要選擇的字母上即可。
4.調出特殊符號
在用戶將虛擬鍵盤調至」english(us)」輸入法時，長按想要選擇的字母，即可調出該字母的特殊字元。
長按美元符號用戶可以調出類似的符號，包括美分、歐元、日元以及英鎊等。
除這些以外，虛擬鍵盤中的某些功能還是保持不變的。比如自動完成特性，用戶點擊空格鍵或輸入標點符號時，它會給用戶提供多個建議選項。
❺ 前端vue開發 iOS手機切屏之後回到原app頁面動畫不執行了
兩個動畫效果肯定是要停掉一個的。
禁止掉原生側滑有點不現實，那就想辦法改變我們自己的。
定義變數isIosMoveBack判斷過度動畫取消的時機（在IOS系統機型下滑動時），這里直接在vuex裡面定義個變數，方便後面組件內部的返回按鈕重置變數。
❻ iOS前端qing
前端就是用戶看的見的應用程序，IOS也是屬於前端開發，後台是對於數據的處理，不是給用戶看的
❼ 為何感覺做網頁的不多但是前端卻比安卓ios的需求大
因為現在網頁開發人員已經不再單純的只開發網頁
在Web2.0時代
前端開發人員都是往大前端方向發展
HTML CSS JS只是基本功
還得需要會Vue React Angular三大框架
小程序和Web APP開發
服務端的NodeJS
前端工程化Webpack gulp
gitlab github等
還有MongoDB Redis等資料庫
前端是越來越復雜了
並不是傳統意義的前端只做界面
現在簡單的CURD都是前端自己完成
後端更多的是做數據相關的工作
一個非常好的問題。題主說的前端應該是包含了H5跨平台開發的「大前端」。
一，大前端
隨著移動互聯網的發展，前端開發成為重點。移動端有多個平台，Android，iOS，微信小程序，還有重任在肩的華為鴻蒙，為了支持這些平台和系統，越來越多的應用開始使用H5跨平台架構，這時有個新名詞叫做「大前端」。
為了滿足實際業務需求，現在軟體系統的功能和架構都日趨復雜：多層架構，數據中台，動靜分離，微服務、集群化部署，自動化運維，等等。曾經總結過這么一個現象：
早期的小型團隊，前端手忙腳亂，需求易變，盯著頁面整天改來改去。
成熟穩定的團隊，後端比較忙，持續不斷的開發新功能。
從實際情況看，前端工程師數量比較多。
二，H5跨平台開發
這時的H5開發已經不單單是網頁開發了，而是前端應用開發。具體到H5 Hybrid架構，常用三劍客：HTML, css, JavaScript
1) HTML和css是頁面設計 ，沒有代碼邏輯
2) JavaScript編程 ，還有其它衍生語言，比如常用的TypeScript
JavaScript是一種腳本語言，由解釋器載入執行，常用在網頁前端動態展示、和服務後端交互等場景。
3）常用框架
有很多成熟的框架可用，比如JQuery, AngularJS，React，還有前後端都跑通的NoteJS
三，Android，iOS原生開發
這是幾年前的一個話題了，中間經歷了很多波折，當2012年Facebook宣布放棄H5轉向原生開發的時候，似乎已經有了階段性定論。然而隨著微信還有H5技術、開發框架的快速發展，天平又再次偏向了H5。
目前來看，「大前端」H5跨平台開發工程師的需求數量，遠多於Android、iOS原生開發的需求。
只能說你這個感覺偏差非常大！
web 層面的前端開發人員比原生 app 的開發人員數量上多了很多。拋開 web 其原有的領域不說，現在很多 Android 和 ios 的開發都採用了 hybird 技術，一種原生和 web 混合的開發手段。
很重要的一個原因就是 web 的開發部署周期非常迅速，而 native app 掛到市場後都會有一個審核過程，現在互聯網企業對產品的設計規劃變化非常多，特別是 Apple store 的審核時長較長，跟不上頻繁的迭代開發而產生的更新，所以就有了將更新評率較高的部分分離出來用 web 技術來實現的這種變通手段。
這樣一來，web 前端的技術人員又覆蓋了一部分原本不是他領域內的工作。
其實前端這幾年火爆的發展還是源於對軟體開發團隊的配置以及成本投入的需求，目前web前端開發已經占據軟體開發招聘市場很大的比例了！
接下來給大家談談web前端發展迅速的主要原因：
互聯網企業屬於創投類比較青睞的項目，當你有一個很好的idea的時候，只需要一定的啟動資金，將你的idea落地為互聯網產品，藉此去吸引一定的流量，有了流量之後就可以找風投進行入股，在資本介入之後就會有非常迅速的發展，甚至還有上市的可能，風投只要在眾多的投資項目中有少量成功的案例，那麼就可以賺的盆滿缽滿，這也是互聯網成為這些風險投資資金的蓄水池。
至於互聯網產品的流量入口就很多了，例如：有的用戶從電腦端網路訪問、有的用戶從手機網路訪問、有的用戶會從微信小程序訪問、有的會下載官方推薦的APP、有的用戶使用安卓系統、有的用戶使用的是iOS，無論哪種方式都會產生很大的可能性，其背後都是一類用戶的訪問習慣，而作為產品必須尊重每一種習慣，否則將會丟失一部分的客戶群體，對於一個起步階段的互聯網產品來說，丟失的任何一個用戶都是不可接受的失敗，必須使出渾身解數來迎合用戶，增加產品粘合度以及用戶的體驗度。
面對如此多的流量入口，對於早期尚未拿到風投的創業型互聯網公司來說，軟體開發團隊的工資將占據整個項目啟動資金很大的比例，以至於很多項目還沒搞出來上線就已經over了或者項目草草上線之後發現運營的資金也是捉襟見肘，導致了整體項目的失敗！
這類公司已經功成名就，各自在自己的領域已經是大象般的存在了，資金勢力雄厚、技術能力與產品也已經非常成熟，前端軟體開發的任務也從早期搶市場，誰先上線誰就贏得先機，轉型向產品維護以及功能的迭代更新，所以工作量也會大幅下降，自然招聘量也會隨之降低，而且未來面對新的產品開發也會不斷的嘗試新的技術來滿足團隊優化的目的。
對於外包公司來說承接的項目會比較雜、業務類型也是多種多樣的，所以如果一個前端團隊可以解決來自iOS、安卓、pc端的所有需求那將是再好不過的選擇了，既節約了成本，又可以提升開發效率並能整合團隊資源何樂而不為！
對於非IT類企業來說，這類企業主營業務不是IT產業類，對軟體的需求就是滿足企業本身管理與生產的信息化，所以不可能在IT團隊的投入上有著過高的追求，如果自身的IT能力即可以滿足日常的生產與管理，又可以在商業上有所建樹那將是非常完美的選擇，目前的前端框架完全可以滿足這類企業在軟體界面端開發的所有需求，也是得到企業青睞的原因所在！
做網頁的需求量是做安卓、iOS原生前端頁面的需求的百倍都不止，你的感覺沒錯。
而你覺得做網頁的不多也很正常，因為藉助於前端UI框架、開源項目、工程構建、組件化等，現在前端更側重於JavaScript工程構建，很少吭哧吭哧寫頁面了。
前端開發除了有傳統的網站PC頁面、朋友圈的網頁、小程序以外，還在不斷滲透它的影響力和擴大它的勢力范圍，比如：
1、跨多端，安卓、iOS、Windows、Mac、Linux等很多應用都開始採用hybrid的方式來開發，甚至直接用JavaScript生成；
2、前端SaaS、PaaS服務，隨著雲計算的發展，將人工智慧、大數據等做成第三方服務的公司越來越多，這個趨勢在美國比較明顯，中國也在跟進，而很多服務都是線上服務，比如線上Office、線上PS、線上OA平台、線上大數據展示平台、線上表格、低代碼等，將服務線上化已經是大勢所趨，而所謂線上就是基於瀏覽器，而只要基於瀏覽器就是前端開發。
基本所有企業都有操作系統吧！都是前端開發！你平時用的app，也基本都是前端開發的。那種活動啥的，全是前端
對於題主的提問，其實回答很簡單，不需要虛頭巴腦說前端各種華麗花哨的，我就反問題主，安卓ios只做移動端應用，而web前端做的是跨平台應用，現在單把移動應用拿出來單說，由於原生應用開發周期長，更新審核繁瑣，很多原生應用的內容都是web寫的，安卓iOS相當於做了個框，可以理解為內嵌一個瀏覽器，這樣一對比，量級就明顯了，另外現有各平台的小程序都是前端從業者，還需要列舉更多嗎
app很多都是前台做的，原生的都很少工作量了。還有各種微信，支付寶，美團，等等小程序的前端都是給網頁前台做
❽ 前端開發在ios上怎麼不讓頁面向下拖動
原因分析:
ios的webview 內核 設定了其在進行momentum scrolling(彈性滾動)時,會停止所有的 事件響應 及 DOM操作引起的頁面渲染 (親測),故 onscroll 不能實時響應
曾做兼容方案:
使用 ontouchmove 去替代 nscroll ,雖然能更頻繁的觸發事件,但是這邊的項目需求是實時響應滾動事件的同時,還要對頁面元素進行重定位的DOM操作,由上述原因可知,在滾動過程中,頁面會停止一切關於DOM方面的操作,所以若使用 ontouchmove 去實現的話,在按住屏幕進行滑動的時候,屏幕會出現元素抖動的情況(事件觸發與DOM操作間具有幾十毫秒的時間差),兼容失敗
使用 iscroll 的probe版本,該版本能實時探查到滾動的距離,但該鉤子函數是實時去關注 requestAnimationFrame 下的狀態,所以對瀏覽器的版本性能消耗很大,加上 react 的 DOM 操作,安卓機根本動不了,兼容失敗
使用 swiper 插件,在啟動 freeMode 模式時模擬原生的彈性滾動( swiper 模擬原生滾動的方案能兼容較多的安卓機型不出現bug,), 因為 swiper 沒有實時監聽滾動位置的功能,故我監聽滾動開始及結束後的事件,通過 setInterval 及一些計算去實現滾動條的監聽,但因為 react 元素的變化量比較大,導致 swiper 在移動端時對父容器的計算速率達到了一個瓶頸,依舊出現很卡頓的現象,兼容失敗
fallback方案,安卓端使用原生onscroll實現,ios直接載入全部子元素,畢竟ios的性能方面還是比較好的,有更好的方案後續再更.
❾ 同時學iOS 開發和web前端開發靠譜嗎
其實關鍵還是看個人努力吧，是可以實現的，只是知識結構不相近，你會比較累，因為IOS 主要是object c 或者swift 作為開發語言，web前端主要是HTML5 和JS,技術之間的差距比較大，你要是想兼顧會比較累！當然事在人為！加油
❿ 有沒有前端童鞋碰到ios webview中頁面載入不了css樣式問題
本人碰到了，好不容易寫了個btn的樣式，載入之後四個高亮的灰色大按鈕傷了很久。測試後chrome ie 沒問題，但是safari不行。 ios的瀏覽器核心是Safari。 另外有可能是網路問題。