原文地址：http://android.xsoftlab.net/training/secure-file-sharing/retrieve-info.html

之前的课程讲述了客户端APP试图与含有文件的URI一同运行，APP可以请求服务端APP的文件信息，包括文件的数据类型以及文件的大小。这些数据类型可以帮助客户端APP来判断该文件是否可以处理，文件的大小可以帮助客户端APP对该文件设置相应大小的缓冲区。

这节课演示了如何查询服务端APP返回文件的MIME类型以及大小。



获取文件的MIME类型

一个文件的数据类型指示了客户端APP应该如何处理这个文件的内容。为了获取URI对应文件的数据类型，客户端APP需要调用方法ContentResolver.getType()。这个方法返回了文件的MIME类型。默认情况下，FileProvider可以从文件的扩展名来判断文件的MIME类型。

下面这段代码演示了客户端APP如何解析服务端APP返回的URI对应文件的MIME类型：



    ...
    /*
     * Get the file's content URI from the incoming Intent, then
     * get the file's MIME type
     */
    Uri returnUri = returnIntent.getData();
    String mimeType = getContentResolver().getType(returnUri);
    ...



获取文件的名称与大小

FileProvider类有一个query()方法的默认实现，该方法可以返回URI相关文件的名称与大小，不过结果位于一个Cursor对象中。默认的实现会返回两列：

DISPLAY_NAME

这是文件的名称，是字符串类型。这个值与File.getName()方法返回的值相等。
SIZE

这是文件的大小，以字节形式呈现，是long类型。这个值与File.length()方法返回的值相等。
客户端APP可以通过对query()方法设置null参数的方式来获得文件的名称与大小，当然URI参数除外。举个例子，下面这段代码获取了一个文件的名称与大小，并且在单独的TextView中进行了展示：



    ...
    /*
     * Get the file's content URI from the incoming Intent,
     * then query the server app to get the file's display name
     * and size.
     */
    Uri returnUri = returnIntent.getData();
    Cursor returnCursor =
            getContentResolver().query(returnUri, null, null, null, null);
    /*
     * Get the column indexes of the data in the Cursor,
     * move to the first row in the Cursor, get the data,
     * and display it.
     */
    int nameIndex = returnCursor.getColumnIndex(OpenableColumns.DISPLAY_NAME);
    int sizeIndex = returnCursor.getColumnIndex(OpenableColumns.SIZE);
    returnCursor.moveToFirst();
    TextView nameView = (TextView) findViewById(R.id.filename_text);
    TextView sizeView = (TextView) findViewById(R.id.filesize_text);
    nameView.setText(returnCursor.getString(nameIndex));
    sizeView.setText(Long.toString(returnCursor.getLong(sizeIndex)));

经过一段时间的学习，通过视频和文档资料，根据视频一步一步的编写了一个ftp服务器，实现了用户验证，文件上传，文件断点续传和上传进度条的显示

1.用户验证：用户验证相对来说较为简单，发送用户账号和密码，服务端获取验证请求后，去对比库中的账号密码是否一致，一致就可以继续交互，不一致，则断开链接

2…文件上传：文件上传避免发生粘包现象，可以传送一个包含文件大小的报文，在服务端获取到报文后，根据报文中文件的大小一段一段的去接收该文件。

3.文件断点续传：在上传文件途中，可能发生异常，导致文件上传不完整，下次上传时，可以通过判断文件是否存在，大小是否一致，文件存在但是文件大小不一致时，和客户端进行交互，如果客户端要续传，服务端可以先返回一个当前文件的大小，客户端在获取到后，上传前可以先利用F.seek（)设置文件打开的位置，从而实现文件的续传

4.进度条相对较为简单，在传送过程中，利用已经发送的除以文件总大小获取传送进度的百分比。利用sys.stdout.write("%s%% %s+\r"%(rate_num,rate_num*"#"))  实现进度条打印（print一样）
总结
这是开始学习python后自己写的第一功能的代码，在编写代码过程中遇到了很多的小错误，找错误是一个非常锻炼自己耐心和细心的地方，过程很煎熬，但是找到之后的如释重负的感觉也很让人舒服。

这次的代码编写，结合了socket编程，socketserver，configparse，os，sys，logging，optparse（这个模块第一次使用，以前运行脚本的时候怎么在调用脚本的时候传入参数一直不知道，这个模块可以实现，一种无形装逼的感觉），算是把前面学习的东西进行了一次练习，就是个人比较懒，没有吧该实现的功能实现完，后期有时间在补充。这也算是python学习洪迈进了第一步了，后续会继续学习多线程，python的web框架等等，加油

Quickling解决方案

Quickling适用于网络高延迟、低带宽场景的解决方案。

保证首屏及核心功能最快展现，使得展示核心功能所需要获取的数据、生成的html文档大小、资源加载量、渲染工作量最小化；
提高服务端的渲染效率和并行度，保证功能不会受到慢数据模块的影响；
支持page cache和用户缓存控制，可以避免大量的服务器端重复计算和客户端重复渲染

背景

Quickling这个词诞生自facebook
 Web优化方案，它指的是页面的某一个块可以通过Ajax请求，包括这块使用到的静态资源，然后通过JSON方式返回给前端加载器，前端加载器先加载静态资源然后渲染块，这样得到一个可展示的页面局部，可以把它放到当前页的任何地方。


Quickling解决方案也使用相同的原理。得益于FIS 2.0，我们很轻松就可以搞定整个逻辑的实现。

解决方案特性

介绍Quickling是如何工作。解决方案特性：

A 支持任意一个widget被异步请求，请求内容包括渲染好的HTML及静态资源
B 当widget指定为异步请求时，渲染引用此widget模版时不会渲染此widget，降低后端渲染模版压力。

使用场景

使用场景一栏，主要给大家展示一些案例，来引导理解整个解决方案。

案例一

项目A中使用方案提供的最初使用前端模板实现webapp一站式效果，但是前端渲染的形式，在展示的时候后端获取数据分为两步，展现页面时只能等数据拿到以后才能进行展现，而恰巧获取数据时比较慢，导致页面出现卡顿。那么我们用Quickling解决方案如何解决这个问题呢？

答案很简单，展现页面的时候也分为两步走，第一次渲染的时候拿到比较重要那块的数据，并渲染对应的部分页面。再发起一次异步请求，请求剩下的部分页面。这样至少用户不会感觉到卡顿。是不是看着似曾相识，这个就好比纯的WebApp在渲染一个页面时，请求两次数据并渲染页面一样。但这个是后端模板层面支持的。

案例二

项目B主要服务于东南亚地区，这些国家的网络有个特点，那就是慢，有IPHONE并使用移动号的同学拿出手机访问一下某网站试试，就那种感觉。通过项目B同学的反馈以及统计数据显示，下载HTML的速度都慢的可怜。还有一个问题并发时下载资源之间抢带宽，阻塞页面的渲染。

问题

总结一下俩问题上面两个案例的问题

html太大，导致下载太慢
资源抢带宽，阻塞页面渲染

那通过 Quickling解决方案 如何解决问题呢。可以通过，
整个页面多次渲染，第一次访问或者刷新时只渲染首屏，这样展示首屏的时候就减少了很多html。下载变快了
拆分逻辑，把基础功能的css内联，增强功能的css在一定条件下触发请求，js进行异步加载。这样控制后页面渲染就变快了。

总结

案例一 和 案例二 中可以看到，Quickling解决方案很好的解决了这些遇到的问题，而案例中说到的情况就是方案已知的适用场景，其他场景还有待发现。

使用方法

很多同学到这里就有疑问了，如此复杂的请求方式，一个页面可以分块请求，是不是需要在开发的时候实现很多东西，维护起来很麻烦。答案是 否定 的。整个方案依托于FIS 2.0的前端架构思想，从目录结构到静态资源管理。只需要做很小的工作就瞬间享受到 Quickling解决方案 带来的新特性。


首先得有一个后端模板是Smarty的项目，并且是使用FIS制定的目录规范以及用FIS编译。目录结构是这样的；

├── build.sh
├── config
├── fis-conf.js
├── page
├── static
├── test
└── widget


每个目录放些什么，就不一一说明了，见FIS2.0文档。我们只关注 widget 和 page 。

假设有一个widget widget_A ，包括一个模板文件widget_A.tpl和一个js文件widget_A.js还有一个css文件widget_A.css。有个页面 index.tpl 要使用这个widget。

├── page
│   └── index.tpl
└── widget
    └── widget_A
        ├── widget_A.js
        ├── widget_A.css
        └── widget_A.tpl


网站展示时渲染 index.tpl ，widget_A是页面中的一部分。

//index.tpl
{%widget name="demo:widget/widget_A/widget_A.tpl"%}


当页面被渲染时，widget_A就展现在页面上了。

<html>
...
    <link href="widget_A.css" rel="stylesheet" type="text/css" />
....
    <div> 我是widget_A </div>
....
    <script src="widget_A.js" type="text/javascript"></script>
</html>


上面是正常的使用方式，就像方案二中说到的，如何让渲染index.tpl时不展示widget_A呢。

{%widget name="demo:widget/widget_A/widget_A.tpl" mode="quickling" pagelet_id="widget_A"%}


OK，改造完成。 加了mode="quickling"和pagelet_id="widget_A"这俩参数。
 这时候渲染页面的结果是什么呢？

<html>
.....
<textarea class="fis_g_bigrender" style=“display:none”>BigPipe.asyncLoad({id: "widget_A"})</textarea>
<div id="widget_A"></div>
.....
</html>


如上代码，做了俩事情。
挖了个坑<div id="widget_A"></div>，异步请求回来的widget_A的html就放在这个坑了。
在textarea里面打了一个JS函数，这个思路来自bigrender，可以在页面滚动到那个部位才去拉取数据。

等页面渲染完后，开发的同学需要做什么，他只需要把textarea里面的代码根据自己的需求执行就成，比如滚轮滚那个地方，domready后。。。这个自己决定。

说到这里我想你也知道如何使用了。

使用步骤 ：
widget调用的时候设定这个widget的 渲染模式 为quickling，mode="quickling"
widget调用的时候设定pagelet_id, pagelet_id="widget_A"
运行时，取出class="fis_g_bigrender"中包含的代码，运行它
页面引入前端加载器BigPipe.js
项目中使用方案提供的smarty插件

相关资源 ：
demo
Smarty插件

优点和缺点

有了使用场景而且也知道如何使用，那现在开始总结一下它到底有哪些优点，事物都是双面的当然也有缺点。这栏总结一下整个方案的优缺点。按照一贯的做法，先说优点。

优点
灵活 页面widget可以灵活请求
可维护性高 FIS用户项目都是组件化的，维护肯定是最好的
使用简单 只需要关注那些页面部分想后展示、具体展示的时机
能解决特定问题 案例一和案例二已经说明了这一点。

缺点
增加了请求 一个页面渲染，如果某一个widget显然模式是“quickling”，那么渲染页面就会多一次请求
增加了服务器负担

性能本来就是一个折中，方案有优缺点，就看具体场景需要了。