A. app一般如何操作伺服器資料庫
android客戶端不能直接與伺服器資料庫連接，拿sqlserver來說，安裝之後有幾個G那麼大，android程序是跑在手機上的，想讓程序直接訪問sqlserver，那手機需要非常大的內存。但是可以通過webservice這樣一個橋梁來間接訪問SQLServer。
即在伺服器運行一個服務端程序，該服務端程序通過接收來自android客戶端的指令，對資料庫進行操作。客戶端與服務端直接的數據傳輸主要通過http協議發送和接收json數據或者xml數據，服務端接收到客戶端的json數據之後，進行json解析，再按一定的邏輯對資料庫進行增、刪、改、查。客戶端的http請求可以通過 HttpClient類實現，在anddroid 4.0之後，客戶端的網路請求已經不被允許在主線程中運行，所以題主還需注意另開啟一個子線程進行網路請求。
B. APP中的6種常見數據載入
1.
全屏載入
全屏載入也叫白屏載入，就是整個屏幕白屏進行數據載入，一般會有菊花轉或進度條配合，常用於手機網頁的載入中，例如列表頁進入詳情頁，圖片詳情等。（可考慮融入趣味性較強的小動畫，增強愉悅感，從用戶心理上去縮短等待時間。
優點：能保證內容的整體性，全部載入完才能夠系統化的閱讀。
缺點：有非常強烈的等待感，3s以上會產生焦躁情緒，所以在地鐵等信號 不好的地方，使用手機網 頁獲取內容實在是比較災難的一件事情。
2.分布載入
分布載入就是分步驟的載入網頁，優先載入占網路資源較小的元素，包括優先載入，懶載入，預載入，漸進載入。
a.優先載入
如果一個頁面有圖片有文字，可以先把文字都載入出來，保證用戶可以有內容可讀，然後再載入比較費流量的圖片。但是活動頁什麼的，千萬不能把重要信息全部放在圖片上，導致載入不出來。這種載入形式更加適用於內容閱讀型的APP。
懶載入主要是針對前端頁面比較大而設計出來的一種方式，假如一個網頁很大，又含有很多圖片、視頻內容，那麼想一次性載入就會等待很久，懶載入就是只有在屏幕顯示範圍內的資源，被用戶看到的內容才會真正去載入。
預載入就是提前載入，比如啟動APP時，當顯示啟動畫面時，就可以預先把首頁內容載入出來，這樣可以減少用戶載入內容時的等待時間，還有一個很典型的使用場景就是瀏覽視頻網站或者購物網站，當我們快要滑到頁面底部時，下面圖片已經幾乎載入完成了，這就是預載入的好處，在使用上感覺更加流暢。
漸進載入
在 PC 端用瀏覽器看圖片的時候，經常是先看到一張模糊圖，然後再漸漸的變得清晰，這種效果就叫做漸進式載入。
優點：可以幫助用戶快速閱讀內容，了解信息。
缺點：也許會丟失掉重要的關鍵信息，無法建立信息獲取的閉環。
3.整頁載入
當當前頁與下一頁是整頁切換的時候，可以考慮採用整頁載入的形式，但是要保證每個頁面的數據量不是特別的大。一般適用於宮格圖片模式、全屏圖片模式、網狀詳情頁模式。
優點：能保證每個頁面的完整性，體驗比較整體。
缺點：不好保證整頁的載入效率，且有可能影響瀏覽的流暢度。
4.自動載入
當你瀏覽信息時，不停的向上滑動，新的內容會不停的從底部出現，這種方式稱為自動載入。關於自動載入，要注意每次載入多少條內容，或者多少屏的內容，我無聊的數了數今日頭條每次會自動載入60條新聞。
優點：把用戶代入無盡瀏覽模式，讓用戶一直向下滾動，不需要手動點擊下一頁。
缺點：沒有盡頭，容易迷失，不方便快速索引定位到某個內容。
5.智能載入
這個載入模式我經常使用到，假如是在WIFI情況下，使用QQ瀏覽器去看視頻，那麼它會自動載入視頻播放，而使用4G的流量去訪問視頻頁面的話，會有一個彈窗來確認是否要播放，以免耗費大量流量造成用戶扣費。智能載入模式就是根據用戶使用場景來改變載入形式的。
例如今日頭條在WiFi模式下，圖片大圖展示，當處於非WiFi模式下時，展示小縮略圖，當用戶覺得某張圖有足夠的吸引力時，點擊小縮略圖載入大圖，幫助用 戶節省流量。再比如愛奇藝在非WiFi的模式下播放視頻時，會提示用戶繼續播放會產生流量費用，這類設計就比較人性化，也容易讓用戶產生好感，建戶忠誠 度。（用戶知道你是在為他著想，畢竟流量還是挺貴的！）
優點：根據具體場景來控制流量和載入速度。
缺點：不一定真實有效的命中用戶需求，所以還是需要給予用戶一定的查看詳情的入口，或者是設置項。
6.離線載入
當用戶沒網的時候，往往很多功能都不能用了，內容也無法載入出來，導致APP變得根本不可用，這時候就要考慮預載入 離線緩存的設計了。首先在有網 的時候把數據提前載入下來，緩存到本地，當沒網的時候，直接載入已經緩存下來的內容。一般會提供給用戶選擇，是否開啟有WiFi的情況下預載入功能，或者 是否開始WiFi下全部離線緩存的功能。這樣便可在一定程度上減少地鐵上信號時好時差而無法正常使用產品所帶來的困擾了。但考慮到手機空間，要設計合適的離線機制。並配合一定的清理緩存的機制。適用於小說閱讀、新聞閱讀、視頻類APP。
優點：解決了沒網獲取數據的問題，且節約了流量，保證了流暢。
缺點：佔用本地存儲空間，而且有時候預載入的內容根本沒有用到。
三、4種減少等待感的設計
1.使用模態載入
盡量使用非模態的載入方式，在載入的過程不打斷用戶，不需要等待載入完就可以做別的事情的，而不用傻傻等待數據載入完成，大大降低了等待的焦躁感，提升用戶體驗流暢度。
模態載入：app在觸發載入後，出現模態提示層，防止用戶在載入過程中進行其他操作，導致當前載入出錯。如果採用模態載入，會因為網路原因或內容過多導致長時間處於載入狀態，建議提供一個「取消」的操作。同時在安卓中的後退按鈕能關閉模態提示。
2. 情感化的載入動畫
用戶等待載入的過程是相當痛苦的，因為他迫切的想看到頁面內容，通過設計一些呆萌可愛的載入動畫，讓用戶在等待的過程中享受動畫的愉悅感，讓產品情感化，在心理層面上去減少用戶的急躁感。
3.
進度條載入
如果是時間較長的載入過程，最好能清晰的告知過程進度，讓用戶有更加明確的知情權，和載入的時間預期。一個非常經典的體驗設問，同樣是3s的載入時 間，勻速的進度條、先慢後快的進度條、先快後慢的進度條，哪個讓用戶感覺上最快?經過科學的實驗證實，先慢後快的進度條是讓用戶心理感受上最快的設計。這是因為用戶最容易記住最後一瞬間的感覺，如果最後一瞬間，感知到了快，就覺得順暢了。
4.
盡量提前載入
盡可能的利用預載入或有WiFi的情況下離線緩存的方式，把內容提前載入下來，這樣能做到最大限度的降低載入給用戶帶來的卡頓感。如果能判斷出來用戶下一步要做的事情，提前幫用戶載入相應的內容，肯定是最符合需求場景的事情。當我開始讀第一頁的時候，第二頁第三頁就開始陸續緩存下來了
5.啟動頁載入
這個主要是APP啟動時的一個頁面，由於APP啟動需要時間，因此可以加入一個啟動頁來自然過渡，而且很多啟動頁是廣告，這樣也可以帶來一些收益，這個頁面一般可以點擊跳過。
移動互聯網的場景多種多樣，我們在設計的時候需要考慮各種各樣的場景，例如WiFi下、非WiFi下、無網路、又或者說電梯里、地鐵上等等。但是咋們的目的也只有一個：優化用戶體驗，提高商業價值。所以無論設計什麼功能模塊都應該多考慮一下用戶的使用場景。
如何降低用戶的焦慮感？
由於存在網速不快，網路異常，伺服器異常等情況，讓用戶等待的情況是必不可少的。但是我們都知道，等待會產生焦慮感，分分鍾讓用戶卸載你的產品，那麼我們可以通過哪些手段來降低或緩解用戶的焦慮感？
第一：優化App的載入演算法，使得App與伺服器數據傳輸的時間減短。 這個需要開發人員的精益求精了。這個是從根本上解決了問題，因為直接減少了載入數據的時間，也就減少了用戶需要等待的時間。
第二：採用預載入和智能載入的方式。 拿閱讀App打比方，當用戶在看第一頁的時候，App在後台載入完後面的幾頁，等用戶翻到第二頁的時候就不需要等待載入了，因為App已經幫用戶提前載入好了。這種載入機制對用戶體驗特別好，但是存在一個問題，就是要預測用戶行為，載入其他數據，這樣會消耗不少流量，所以建議在WiFi網路環境下採取這種預載入機制，而在蜂窩網路狀態下則不採用預載入機制。這個要和開發人員討論溝通，確保預載入機制完美運行。
第三：非同步處理。 這一點做得好的App莫過於Instagram，不知道你有沒有發現，用Instagram的時候會覺得特別流暢，即使在網路不好的情況下。這是為什麼？因為在網路不好的情況下，你給好友點了贊，Instagram並不會提示你網路不好，操作失敗，而是提示你點贊成功了，其實它只是將你點贊的操作記錄了下來，等網路一好就將點贊的行為上傳到伺服器，從而完成點贊行為。這就是讓產品自己去解決問題，而不是把問題拋給用戶。
第四：設計有趣的loading動畫，如上文介紹的美團APP奔跑的小人，這是提升產品情感的重要手段。
C. 開發一個APP，選擇什麼樣的伺服器最合適
網路時代中，手機對我們每個人的影響越來越大，無論工作還是生活都已經離不開手機，尤其是智能手機的普及，更加大了這一影響。我們哪個人手機上沒有幾個APP，支付的，聊天的，拍照的，視頻的等等。
APP軟體開發商也非常重視用戶體驗度，畢竟競爭壓力大，除了APP功能，畫面排版外，APP軟體打開速度，是否卡頓等等也是影響用戶體驗度的重要因素。如果APP不穩定，經常卡，連不上伺服器等，用戶會卸載APP的。因為APP軟體伺服器顯得尤為重要，是APP的基礎。那麼壹基比小喻就來教你們怎麼選擇伺服器吧
我們開發一款APP時，首先需要提供的就是數據交換，數據存儲以及數據處理等，這些都是需要伺服器來完成的。一台好的伺服器能承受更高的用戶承載量，提升用戶體驗度。既然伺服器這么重要，我們該怎麼選擇伺服器呢？
1.一定要正規的服務商
很多用戶在選擇時貪小便宜選擇個人渠道，這樣的價格可能會便宜些，但是售後是沒有保障的。一個人無法提供24小時售後支持這是其一。二，個人是什麼客戶都接，安全性低，易受到其他用戶的影響。三，一旦出現問題，個人跑路是很常見的，經常遇到用戶拿著ip來問是不是我們家的ip，因為他聯系不到服務商了，有的甚至到期了沒人通知機器下架的，數據全部丟失，損失是非常大的。
2.伺服器配置
現在伺服器配置都是很好選擇的，剛開始業務量不大選擇一款一般配置的機型就可以，現在伺服器基礎上都支持硬體升級，後期可以根據實際需求升級硬體配置。一般配置的機器幾百塊就搞定了，如果APP軟體硬體配置需要大的話，幾千上萬的都有，根據實際使用情況選擇就好。
D. 什麼是APP伺服器
app server的前身是middleware（中間件），歷史要長的多。早在上世紀六七十年代就已經開始在IBM大型機系統上廣泛應用了，叫做TP Monitor，比較著名的是BEA的Tuxedo和IBM的CICS，運行在Terminal/Server模式的Server端，其功能主要是分離商業邏輯，進行分布式計算的，可以自動管理事務、資源和容錯等等。因為發展的時間很長，所以技術非常成熟。middleware最早是用cobol編寫的，現在還可以偶爾看到cobol的中間件的舊系統，再後來middleware改用C++來實現，著名中間件的有IBM的CICS，BEA的Tuexdo，仍然廣泛的應用在高端系統中，特別是銀行系統。
然而在面向對象的技術出現和廣泛的應用之後，TP Monitor由於不是面向對象的，而是面向過程的調用，因此TP Monitor管理的商業邏輯並沒有分布式對象系統中的商業組件那樣的可擴展性、可重用性，表現出來很大的局限。
不過像PHP這樣主要還是面向過程調用的函數式的語言來說，TP Monitor仍然可以支持的非常完美，由於有了TP Monitor的支持，PHP也可以應用在企業的環境中了。
我所知道的eachnet用的是：
1
Linux+Apache+PHP+Tuxedo+Oracle
eachnet在上海好幾個ISP那裡放了伺服器，以保證服務不因某個ISP的問題而無法訪問。我曾經見過eachnet在上海熱線機房的伺服器，說出來，大家可能不信，eachnet竟然用的是自己攢的兼容機，世紀之星的機箱，估計不比我們大家自己買的兼容機強到哪裡去。大概有六七台機器的樣子，來負載均衡。
對象請求代理（Object Request Brokers）是另一種用的很多的中間件，支持分布式對象的調用。然而它的問題是僅僅是一個代理（Broker），系統級的功能需要自己來實現，這包括管理並發性、事務、資源管理和容錯機制等等，而且不同的廠商提供的ORB之間也存在互操作的兼容性問題。
於是一種綜合了TP Monitor和ORB功能的新的伺服器出現了，叫做CTM（Component Transaction Monitor）組件事務監控器。用在我們特定的管理應用程序的環境中就是App Server。
在1997年開始，CTM市場發生了巨大的變化，因為這一年Sun的J2EE標准正式發布，從此除了微軟之外，所有的CTM廠商都用Java來改寫自己的產品，例如Sybase原來有一個叫做Jagus CTS的東西，現在已經變成了純Java實現的EAServer，Borland的公司app server也是這樣來的。這樣一來，除了微軟之外，就剩下基於Java的app server了。
App Server可以自動管理並發性、事務、對象分布、負載均衡、安全性和資源管理等等系統級功能。簡單的來說就是App Server是管理服務端組件的，它給服務端組件提供了一個全功能可靠的運行環境。
打個比方來說，資料庫系統是管理數據的，它也給數據提供了一個受監控和管理的運行環境，提供了事務、安全性、負載均衡，並發性等等系統級功能，對於使用者來說，你不需要自己處理資料庫表的並發鎖定問題，自己處理SQL語句的解析、自己處理索引的優化等等系統級功能，同樣對於服務端組件的調用者來說也不需要自己處理並發請求、對象創建、銷毀、緩存，控制組件事務等等系統級功能。
App Server對服務端組件的的關系就是資料庫系統對數據的關系。App Server完全是一個類似資料庫系統這樣一個非常復雜的服務端軟體，所不同之處就是資料庫系統（RDBMS）是管理數據的，而App Server是管理對象的。這也是我研究Weblogic Server之後的切身感受。
Microsoft是最早發布App Server的廠商，叫做Microsoft Transaction Server（MTS）。其他還有很多基於不同技術的App Server，不過隨著EJB規范的發布，主流的App Server基本上都是基於J2EE的了。目前看來，App Server市場主要就是實現J2EE規范的Java應用伺服器和Microsoft的.Net應用伺服器這兩大主流。
Tuxedo等基於過程傳統的中間件會繼續在特定的場合發揮巨大的作用，像那些需要極高的響應性能和基於特定平台C/C++的場合，還是具有不可替代的作用。
App Server提供的服務端組件模型並沒有解決所有的問題，基於不同技術實現的服務端組件之間不能互相調用和數據共享，比如EJB組件和COM組件之間不能之間交換數據，所以基於SOAP協議的Web Services試圖解決這個問題，想把互聯網上所有的不同技術實現的組件服務都統一成單一的Web Services。這也是Web Services熱門的原因之一，標準的統一對大家都有好處。
E. 如果搭建一個10萬用戶量的移動app後台伺服器，伺服器用什麼配置較好
用戶的數量只是體現了你網站數據量的多少.租用伺服器主要是考慮的你網站每天訪問量的大小.
配置方面:一般情況下.日訪問IP不超過2萬的情況下.租用一個至強XEON四核以上處理器.4G以上內存.500G以上硬碟的就足夠用了.
帶寬方面:需要結合你的網站情況來判斷.如果只是瀏覽為主的網站.用默認的共享帶寬即可.若是有下載.建議用獨享帶寬.帶寬越大越有利於下載.
根據你所選擇機房線路的不同.這樣一台伺服器按年租用的話一般是四五千到近萬元不等.如果你的網站是面向全國各地用戶的話.推薦你選擇中原地區BGP機房.中原占據先天的地理位置優勢.而且機房是多線接入 .在全國各地訪問的速度與穩定性非常好.
F. 手機app的伺服器上用access還是sql資料庫
交換著用，一段時間後覺得哪個好用就用哪個
G. 安卓移動APP開發用什麼資料庫
理論上，APP可以使用任何類型的資料庫，不過目前用得較多的是MSSQL和MYSQL。一般開發APP用JAVA的比較多，可以考慮使用MYSQL。sqlite是一種小型數據，可以作為本地保存資料庫，如果數據量比較大，交互比較頻繁，不建議使用。
H. App應用 跟 伺服器之間怎麼樣傳遞數據，，請大神指教
就是發送http請求，或是socket請求，再不然就是udp請求。都是基於tcp協議的。
傳遞無法就是封包，接收就是拆包。
I. 如何通過手機app獲取伺服器資料庫數據
首先不要管安卓端還是蘋果端，現在一般都是響應式的app，你放到安卓或者蘋果或者pc或者平板都是沒有問題的。一般採用的是http介面通訊，或者socket連接。具體你要去查資料找Demo了。而且現在主流是採用html5開發或者混合開發了。所以最好是伺服器提供appAPI介面，通過http訪問伺服器，獲取數據，數據一般是json，或者xml，拿到後解析數據就可以了，然後再用UI框架或者其他框架或者自定義的UI封裝下格式很漂亮了，至於cookie和session等，看你的習慣，網路驗證和簽名那些也自己看習慣，如果涉及到大數據，還需要引入第三方框架的，直接引入就可以了，不過推薦自己寫，防止侵權。都是很通用的。