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等，看你的习惯，网络验证和签名那些也自己看习惯，如果涉及到大数据，还需要引入第三方框架的，直接引入就可以了，不过推荐自己写，防止侵权。都是很通用的。