转载请标明出处:http://blog.csdn.net/lmj623565791/article/details/38476887 ,本文出自【张鸿洋的博客】

近期创建了一个群。方便大家交流,群号:55032675

上一篇博客介绍了Android异步消息处理机制。假设你还不了解,能够看:Android 异步消息处理机制 让你深入理解 Looper、Handler、Message三者关系 。

那篇博客的最后,提出能够把异步消息处理机制不仅仅是在MainActivity中更新UI。能够用到别的地方。近期也一直在考虑这个问题,有幸,想出来一个实际的案例。将异步消息处理机制用到大量图片的载入的工具类中,事实上也特别希望能够写一篇关于大量图片载入的文章,终于有机会了~先简介一下:

1、概述

一般大量图片的载入。比方GridView实现手机的相冊功能。通常会用到LruCache。线程池。任务队列等;那么异步消息处理能够用哪呢?

1、用于UI线程当Bitmap载入完毕后更新ImageView

2、在图片载入类初始化时,我们会在一个子线程中维护一个Loop实例,当然子线程中也就有了MessageQueue,Looper会一直在那loop停着等待消息的到达,当有消息到达时。从任务队列依照队列调度的方式(FIFO,LIFO等),取出一个任务放入线程池中进行处理。

简易的一个流程:当须要载入一张图片,首先把载入图片增加任务队列,然后使用loop线程(子线程)中的hander发送一个消息,提示有任务到达,loop()(子线程)中会接着取出一个任务,去载入图片,当图片载入完毕,会使用UI线程的handler发送一个消息去更新UI界面。

说了这么多。大家预计也认为云里来雾里去的,以下看实际的样例。

2、图库功能的实现

该程序首先扫描手机中全部包括图片的目录。终于选择图片最多的目录,使用GridView显示当中的图片

1、布局文件

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent" > <GridView
android:id="@+id/id_gridView"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:cacheColorHint="@android:color/transparent"
android:columnWidth="90dip"
android:gravity="center"
android:horizontalSpacing="20dip"
android:listSelector="@android:color/transparent"
android:numColumns="auto_fit"
android:stretchMode="columnWidth"
android:verticalSpacing="20dip" >
</GridView> </RelativeLayout>

布局文件相当简单就一个GridView

2、MainActivity

package com.example.zhy_handler_imageloader;

import java.io.File;
import java.io.FilenameFilter;
import java.util.Arrays;
import java.util.HashSet;
import java.util.List; import android.app.Activity;
import android.app.ProgressDialog;
import android.content.ContentResolver;
import android.database.Cursor;
import android.net.Uri;
import android.os.Bundle;
import android.os.Environment;
import android.os.Handler;
import android.provider.MediaStore;
import android.widget.GridView;
import android.widget.ImageView;
import android.widget.ListAdapter;
import android.widget.Toast; public class MainActivity extends Activity
{
private ProgressDialog mProgressDialog;
private ImageView mImageView; /**
* 存储目录中的图片数量
*/
private int mPicsSize;
/**
* 图片数量最多的目录
*/
private File mImgDir;
/**
* 全部的图片
*/
private List<String> mImgs; private GridView mGirdView;
private ListAdapter mAdapter;
/**
* 暂时的辅助类,用于防止同一个目录的多次扫描
*/
private HashSet<String> mDirPaths = new HashSet<String>(); private Handler mHandler = new Handler()
{
public void handleMessage(android.os.Message msg)
{
mProgressDialog.dismiss();
mImgs = Arrays.asList(mImgDir.list(new FilenameFilter()
{
@Override
public boolean accept(File dir, String filename)
{
if (filename.endsWith(".jpg"))
return true;
return false;
}
}));
/**
* 能够看到目录的路径和图片的路径分开保存。极大的降低了内存的消耗。
*/
mAdapter = new MyAdapter(getApplicationContext(), mImgs,
mImgDir.getAbsolutePath());
mGirdView.setAdapter(mAdapter);
};
}; @Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mGirdView = (GridView) findViewById(R.id.id_gridView);
getImages(); } /**
* 利用ContentProvider扫描手机中的图片,此方法在运行在子线程中 完毕图片的扫描,终于获得jpg最多的那个目录
*/
private void getImages()
{
if (!Environment.getExternalStorageState().equals(
Environment.MEDIA_MOUNTED))
{
Toast.makeText(this, "暂无外部存储", Toast.LENGTH_SHORT).show();
return;
}
// 显示运行进度条
mProgressDialog = ProgressDialog.show(this, null, "正在载入..."); new Thread(new Runnable()
{ @Override
public void run()
{
Uri mImageUri = MediaStore.Images.Media.EXTERNAL_CONTENT_URI;
ContentResolver mContentResolver = MainActivity.this
.getContentResolver(); // 仅仅查询jpeg和png的图片
Cursor mCursor = mContentResolver.query(mImageUri, null,
MediaStore.Images.Media.MIME_TYPE + "=? or "
+ MediaStore.Images.Media.MIME_TYPE + "=?",
new String[] { "image/jpeg", "image/png" },
MediaStore.Images.Media.DATE_MODIFIED); while (mCursor.moveToNext())
{
// 获取图片的路径
String path = mCursor.getString(mCursor
.getColumnIndex(MediaStore.Images.Media.DATA));
// 获取该图片的父路径名
File parentFile = new File(path).getParentFile();
String dirPath = parentFile.getAbsolutePath(); //利用一个HashSet防止多次扫描同一个目录(不加这个推断,图片多起来还是相当恐怖的~~)
if(mDirPaths.contains(dirPath))
{
continue;
}
else
{
mDirPaths.add(dirPath);
} int picSize = parentFile.list(new FilenameFilter()
{
@Override
public boolean accept(File dir, String filename)
{
if (filename.endsWith(".jpg"))
return true;
return false;
}
}).length;
if (picSize > mPicsSize)
{
mPicsSize = picSize;
mImgDir = parentFile;
}
}
mCursor.close();
//扫描完毕。辅助的HashSet也就能够释放内存了
mDirPaths = null ;
// 通知Handler扫描图片完毕
mHandler.sendEmptyMessage(0x110); }
}).start(); }
}

MainActivity也是比較简单的,使用ContentProvider辅助。找到图片最多的目录后,直接handler去隐藏ProgressDialog,然后初始化数据,适配器等;

可是略微注意一下:

1、在扫描图片时。使用了一个暂时的HashSet保存扫描过的目录,这样能够有效的避免反复扫描。

比方,我手机中有个目录以下有3000多张图片。假设不推断则会扫描这个目录3000多次,处理器时间以及内存的消耗还是非常可观的。

2、在适配器中。保存List<String>的时候,考虑仅仅保存图片的名称,路径单独作为变量传入。普通情况下,图片的路径比图片名长非常多,增加有3000张图片,路径长度30。图片平均长度10,则List<String>保存完毕路径须要长度为:(30+10)*3000 = 120000 ; 而单独存储仅仅须要:30+10*3000 = 30030 。 图片越多。节省的内存越客观;

总之,尽可能的去降低内存的消耗,这些都是非常easy做到的~

3、GridView的适配器

package com.example.zhy_handler_imageloader;

import java.util.List;

import android.content.Context;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.BaseAdapter;
import android.widget.ImageView; import com.zhy.utils.ImageLoader; public class MyAdapter extends BaseAdapter
{ private Context mContext;
private List<String> mData;
private String mDirPath;
private LayoutInflater mInflater;
private ImageLoader mImageLoader; public MyAdapter(Context context, List<String> mData, String dirPath)
{
this.mContext = context;
this.mData = mData;
this.mDirPath = dirPath;
mInflater = LayoutInflater.from(mContext); mImageLoader = ImageLoader.getInstance();
} @Override
public int getCount()
{
return mData.size();
} @Override
public Object getItem(int position)
{
return mData.get(position);
} @Override
public long getItemId(int position)
{
return position;
} @Override
public View getView(int position, View convertView, final ViewGroup parent)
{
ViewHolder holder = null;
if (convertView == null)
{
holder = new ViewHolder();
convertView = mInflater.inflate(R.layout.grid_item, parent,
false);
holder.mImageView = (ImageView) convertView
.findViewById(R.id.id_item_image);
convertView.setTag(holder);
} else
{
holder = (ViewHolder) convertView.getTag();
}
holder.mImageView
.setImageResource(R.drawable.friends_sends_pictures_no);
//使用Imageloader去载入图片
mImageLoader.loadImage(mDirPath + "/" + mData.get(position),
holder.mImageView);
return convertView;
} private final class ViewHolder
{
ImageView mImageView;
} }

能够看到与传统的适配器的写法基本没有什么不同之处,甚至在getView里面都没有出现常见的回调(findViewByTag~用于防止图片的错位)。仅仅多了一行代码:

mImageLoader.loadImage(mDirPath + "/" + mData.get(position),holder.mImageView);是不是用起来还是相当爽的。全部须要处理的细节都被封装了。

4、ImageLoader

如今才到了关键的时刻。我们封装的ImageLoader类。当然我们的异步消息处理机制也出如今当中。

首先是一个懒载入的单例

/**
* 单例获得该实例对象
*
* @return
*/
public static ImageLoader getInstance()
{ if (mInstance == null)
{
synchronized (ImageLoader.class)
{
if (mInstance == null)
{
mInstance = new ImageLoader(1, Type.LIFO);
}
}
}
return mInstance;
}

没啥说的,直接调用私有的构造方法,能够看到。默认传入了1(线程池中线程的数量),和LIFO(队列的工作方式)

private ImageLoader(int threadCount, Type type)
{
init(threadCount, type);
} private void init(int threadCount, Type type)
{
// loop thread
mPoolThread = new Thread()
{
@Override
public void run()
{
try
{
// 请求一个信号量
mSemaphore.acquire();
} catch (InterruptedException e)
{
}
Looper.prepare(); mPoolThreadHander = new Handler()
{
@Override
public void handleMessage(Message msg)
{
mThreadPool.execute(getTask());
try
{
mPoolSemaphore.acquire();
} catch (InterruptedException e)
{
}
}
};
// 释放一个信号量
mSemaphore.release();
Looper.loop();
}
};
mPoolThread.start(); // 获取应用程序最大可用内存
int maxMemory = (int) Runtime.getRuntime().maxMemory();
int cacheSize = maxMemory / 8;
mLruCache = new LruCache<String, Bitmap>(cacheSize)
{
@Override
protected int sizeOf(String key, Bitmap value)
{
return value.getRowBytes() * value.getHeight();
};
}; mThreadPool = Executors.newFixedThreadPool(threadCount);
mPoolSemaphore = new Semaphore(threadCount);
mTasks = new LinkedList<Runnable>();
mType = type == null ? Type.LIFO : type; }

然后在私有构造里面调用了我们的init方法,在这种方法的開始就创建了mPoolThread这个子线程,在这个子线程中我们运行了Looper.prepare,初始化mPoolThreadHander,Looper.loop。假设看过上篇博客。一定知道,此时在这个子线程中维护了一个消息队列,且这个子线程会进入一个无限读取消息的循环中。而mPoolThreadHander这个handler发送的消息会直接发送至此线程中的消息队列。

然后看mPoolThreadHander中handleMessage的方法,直接调用了getTask方法取出一个任务,然后放入线程池去运行。假设你比較细心,可能会发现里面另一些信号量的操作的代码。假设你不了解什么是信号量,能够參考:Java 并发专题 : Semaphore 实现 相互排斥 与 连接池 。

简单说一下mSemaphore(信号数为1)的作用。因为mPoolThreadHander实在子线程初始化的,所以我在初始化前调用了mSemaphore.acquire去请求一个信号量。然后在初始化完毕后释放了此信号量,我为什么这么做呢?因为在主线程可能会马上使用到mPoolThreadHander,可是mPoolThreadHander是在子线程初始化的。尽管速度非常快,可是我也不能百分百的保证。主线程使用时已经初始化结束,为了避免空指针异常。所以我在主线程须要使用的时候,是这么调用的:

/**
* 增加一个任务
*
* @param runnable
*/
private synchronized void addTask(Runnable runnable)
{
try
{
// 请求信号量。防止mPoolThreadHander为null
if (mPoolThreadHander == null)
mSemaphore.acquire();
} catch (InterruptedException e)
{
}
mTasks.add(runnable);
mPoolThreadHander.sendEmptyMessage(0x110);
}

假设mPoolThreadHander没有初始化完毕,则会去acquire一个信号量,事实上就是去等待mPoolThreadHander初始化完毕。假设对此感兴趣的,能够将关于mSemaphore的代码凝视。然后在初始化mPoolThreadHander使用Thread.sleep去暂停1秒,就会发现这种错误。

初始化结束,就会在getView中调用mImageLoader.loadImage(mDirPath + "/" + mData.get(position),holder.mImageView);方法了,所以我们去看loadImage方法吧

/**
* 载入图片
*
* @param path
* @param imageView
*/
public void loadImage(final String path, final ImageView imageView)
{
// set tag
imageView.setTag(path);
// UI线程
if (mHandler == null)
{
mHandler = new Handler()
{
@Override
public void handleMessage(Message msg)
{
ImgBeanHolder holder = (ImgBeanHolder) msg.obj;
ImageView imageView = holder.imageView;
Bitmap bm = holder.bitmap;
String path = holder.path;
if (imageView.getTag().toString().equals(path))
{
imageView.setImageBitmap(bm);
}
}
};
} Bitmap bm = getBitmapFromLruCache(path);
if (bm != null)
{
ImgBeanHolder holder = new ImgBeanHolder();
holder.bitmap = bm;
holder.imageView = imageView;
holder.path = path;
Message message = Message.obtain();
message.obj = holder;
mHandler.sendMessage(message);
} else
{
addTask(new Runnable()
{
@Override
public void run()
{ ImageSize imageSize = getImageViewWidth(imageView); int reqWidth = imageSize.width;
int reqHeight = imageSize.height; Bitmap bm = decodeSampledBitmapFromResource(path, reqWidth,
reqHeight);
addBitmapToLruCache(path, bm);
ImgBeanHolder holder = new ImgBeanHolder();
holder.bitmap = getBitmapFromLruCache(path);
holder.imageView = imageView;
holder.path = path;
Message message = Message.obtain();
message.obj = holder;
// Log.e("TAG", "mHandler.sendMessage(message);");
mHandler.sendMessage(message);
mPoolSemaphore.release();
}
});
} }

这段代码比較长,当然也是比較核心的代码了

10-29行:首先将传入imageView设置了path。然在初始化了一个mHandler用于设置imageView的bitmap,注意此时在UI线程。也就是这个mHandler发出的消息。会在UI线程中调用。

能够看到在handleMessage中,我们从消息中取出ImageView。bitmap,path;然后将path与imageView的tag进行比較,防止图片的错位。最后设置bitmap;

31行:我们首先去从LruCache中去查找是否已经缓存了此图片

32-40:假设找到了,则直接使用mHandler去发送消息。这里使用了一个ImgBeanHolder去封装了ImageView,Bitmap。Path这三个对象。然后更新运行handleMessage代码去更新UI

43-66行:假设没有存在缓存中,则创建一个Runnable对象作为任务,去运行addTask方法增加任务队列

49行:getImageViewWidth依据ImageView获取适当的图片的尺寸。用于后面的压缩图片,代码按顺序贴下以下

54行:会依据计算的须要的宽和高,对图片进行压缩。

代码按顺序贴下以下

56行:将压缩后的图片放入缓存

58-64行,创建消息。使用mHandler进行发送,更新UI

/**
* 依据ImageView获得适当的压缩的宽和高
*
* @param imageView
* @return
*/
private ImageSize getImageViewWidth(ImageView imageView)
{
ImageSize imageSize = new ImageSize();
final DisplayMetrics displayMetrics = imageView.getContext()
.getResources().getDisplayMetrics();
final LayoutParams params = imageView.getLayoutParams(); int width = params.width == LayoutParams.WRAP_CONTENT ? 0 : imageView
.getWidth(); // Get actual image width
if (width <= 0)
width = params.width; // Get layout width parameter
if (width <= 0)
width = getImageViewFieldValue(imageView, "mMaxWidth"); // Check
// maxWidth
// parameter
if (width <= 0)
width = displayMetrics.widthPixels;
int height = params.height == LayoutParams.WRAP_CONTENT ? 0 : imageView
.getHeight(); // Get actual image height
if (height <= 0)
height = params.height; // Get layout height parameter
if (height <= 0)
height = getImageViewFieldValue(imageView, "mMaxHeight"); // Check
// maxHeight
// parameter
if (height <= 0)
height = displayMetrics.heightPixels;
imageSize.width = width;
imageSize.height = height;
return imageSize; }
/**
* 依据计算的inSampleSize,得到压缩后图片
*
* @param pathName
* @param reqWidth
* @param reqHeight
* @return
*/
private Bitmap decodeSampledBitmapFromResource(String pathName,
int reqWidth, int reqHeight)
{
// 第一次解析将inJustDecodeBounds设置为true,来获取图片大小
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(pathName, options);
// 调用上面定义的方法计算inSampleSize值
options.inSampleSize = calculateInSampleSize(options, reqWidth,
reqHeight);
// 使用获取到的inSampleSize值再次解析图片
options.inJustDecodeBounds = false;
Bitmap bitmap = BitmapFactory.decodeFile(pathName, options); return bitmap;
}

接下来看AddTask的代码:

/**
* 增加一个任务
*
* @param runnable
*/
private synchronized void addTask(Runnable runnable)
{
try
{
// 请求信号量,防止mPoolThreadHander为null
if (mPoolThreadHander == null)
mSemaphore.acquire();
} catch (InterruptedException e)
{
}
mTasks.add(runnable);
mPoolThreadHander.sendEmptyMessage(0x110);
}

能够看到,简单把任务放入任务队列,然后使用mPoolThreadHander发送一个消息到后台的loop中,后台的loop会取出消息运行:mThreadPool.execute(getTask());

execute运行的就是上面分析的Runnable中的run方法了。

注意一下:上述代码中还会看到mPoolSemaphore这个信号量的身影。说下用处;因为调用addTask之后,会直接去从任务队列取出一个任务,放入线程池,因为线程池内部事实上也维持着一个队列,那么”从任务队列取出一个任务”这个动作会瞬间完毕。直接增加线程池维护的队列中;这样会造成比方用户设置了调度队列为LIFO。可是因为”从任务队列取出一个任务”这个动作会瞬间完毕,队列中始终维持在空队列的状态,所以让用户感觉LIFO根本没有效果;所以我依照用户设置线程池工作线程的数量设置了一个信号量,这样在保证任务运行完后,才会从任务队列去取任务,使得LIFO有着非常好的效果;有兴趣的能够凝视了全部的mPoolSemaphore代码,測试下就明确了。

到此代码基本介绍完毕。细节还是非常多的,后面会附上源代码,有兴趣的研究下代码,没有兴趣的。能够运行下代码。假设感觉流畅性不错。体验不错,能够作为工具类直接使用,使用也就getView里面一行代码。

贴一下效果图,我手机最多的目录大概3000张图片。载入速度还是相当相当流畅的:

真机录的,有点丢帧。注意看效果图,中间我疯狂拖动滚动栏,可是图片基本还是瞬间显示的。

说一下,FIFO假设设置为这个模式。在控件中不做处理的话,用户拉的比較慢效果还是不错的。可是用户手机假设有个几千张,瞬间拉到最后。最后一屏图片的显示可能须要喝杯茶了~当然了。大家能够在控件中做处理。要么。拖动的时候不去载入图片,停在来再载入。或者,当手机抬起,给了一个非常大的加速度,屏幕还是非常快的滑动时停止载入,停下时载入图片。

LIFO这个模式可能用户体验会好非常多,无论用户拉多块,终于停下来的那一屏图片都会瞬间显示~

最后掰一掰使用异步消息处理机制作为背后的子线程的优点,事实上直接用一个子线程也能够实现,可是,这个子线程run中可能须要while(true)然后每隔200毫秒甚至更短的时间去查询任务队列是否有任务。没有则Thread.sleep。然后再去查询。这样假设长时间没有去增加任务,这个线程依旧会不断的去查询。

而异步消息机制。仅仅有在发送消息时才会去运行,当然更准确;当长时间没有任务到达时,也不会去查询,会一直堵塞在这;另一点,这个机制Android内部实现的。怎么也比我们搞个Thread稳定性、效率高吧~

源代码点击下载

Android Handler 异步消息处理机制的妙用 创建强大的图片载入类的更多相关文章

  1. Android Handler 异步消息处理机制的妙用 创建强大的图片加载类(转)

    转载请标明出处:http://blog.csdn.net/lmj623565791/article/details/38476887 ,本文出自[张鸿洋的博客] 最近创建了一个群,方便大家交流,群号: ...

  2. Android多线程----异步消息处理机制之Handler详解

    ​[声明] 欢迎转载,但请保留文章原始出处→_→ 生命壹号:http://www.cnblogs.com/smyhvae/ 文章来源:http://www.cnblogs.com/smyhvae/p/ ...

  3. Android之Handler(异步消息处理)机制

    1. 概述 Handler . Looper .Message 这三者都与Android异步消息处理线程相关的概念.那么什么叫异步消息处理线程呢?异步消息处理线程启动后会进入一个无限的循环体之中,每循 ...

  4. android Handler及消息处理机制的简单介绍

    学习android线程时,直接在UI线程中使用子线程来更新TextView显示的内容,会有如下错误:android.view.ViewRoot$CalledFromWrongThreadExcepti ...

  5. android学习-异步消息处理机制

    消息处理机制主要对象:Looper,Handler,Message(还有MessageQueue和Runnable) Looper不断从MessageQueue消息队列中取出一个Message,然后传 ...

  6. Android多线程编程<二>Handler异步消息处理机制之Message

      Message(消息):       一. Message的字段:    在Android中,Message作为线程之间(主要是子线程和UI主线程之间)数据交换的载体,通过Handler去传递.它 ...

  7. 【转】Android 异步消息处理机制 让你深入理解 Looper、Handler、Message三者关系

    转载请标明出处:http://blog.csdn.net/lmj623565791/article/details/38377229 ,本文出自[张鸿洋的博客] 很多人面试肯定都被问到过,请问Andr ...

  8. Android 异步消息处理机制 让你在深入了解 Looper、Handler、Message之间的关系

    转载请注明出处:http://blog.csdn.net/lmj623565791/article/details/38377229 ,本文出自[张鸿洋的博客] 非常多人面试肯定都被问到过,请问And ...

  9. 【转载】Android异步消息处理机制详解及源码分析

    PS一句:最终还是选择CSDN来整理发表这几年的知识点,该文章平行迁移到CSDN.因为CSDN也支持MarkDown语法了,牛逼啊! [工匠若水 http://blog.csdn.net/yanbob ...

随机推荐

  1. django Modelform 使用

    前言: 为什么要用form去验证呢? 我们提交的是form表单,在看前端源码时如果检查到POST URL及我们提交的字段,如果没有验证我们是否可以直接POST数据到URL,后台并没有进行校验,直接处理 ...

  2. Bluedroid之GKI

    1. 概述 GKI以库libbt-brcm_gki.a的形式提供给Bluedroid使用 该层是一个适配层,适配了OS相关的进程.内存相关的管理,还可以用于线程间传递消息 主要通过变量gki_cb(结 ...

  3. 【linux高级程序设计】(第八章)进程管理与程序开发 5

    守候进程 启动方式: 在系统启动时由/etc/rd.d目录下的启动脚本启动 利用inetd超级服务器启动 有cron命令定时启动,以及在终端用nohup命令启动 守护进程编程要点 (1)屏蔽有关控制终 ...

  4. 关于main函数的参数

    #include <stdio.h> int main(int argc, char const *argv[]) { int i; for ( i = 0; i < argc; i ...

  5. 在本地(自己电脑上)部署了tomcat服务器,真机测试遇到的问题

    开始的时候自己就是给app搭建了一个小的框架,只有一个界面发送了网络请求,部署的tomcat,数据成功请求,得到了数据. 后来随着联网请求的增多,突然发现联网请求一直失败.自己dubug了最开始的第一 ...

  6. HDU 1241.Oil Deposits-求连通块DFS or BFS

    Oil Deposits Time Limit: 2000/1000 MS (Java/Others)    Memory Limit: 65536/32768 K (Java/Others)Tota ...

  7. Django ModelChoiceField前台下拉菜单显示object的解决方法

    在网上找了好半天都没找到,在model中添加即可,不加的话显示就是object def __str__(self): return self.name

  8. 记一次kubernetes集群异常: kubelet连接apiserver超时

    Background kubernetes是master-slave结构,master node是集群的大脑, 当master node发生故障时整个集群都"out of control&q ...

  9. Network | 802.1x

    IEEE 802.1X是IEEE制定关于用户接入网络的认证标准(注意:此处X是大写),全称是“基于端口的网络接入控制”,属于IEEE 802.1网络协议组的一部分.于2001年标准化,之后为了配合无线 ...

  10. python 设计模式之门面模式

    facade:建筑物的表面 门面模式是一个软件工程设计模式,主要用于面向对象编程. 一个门面可以看作是为大段代码提供简单接口的对象,就像类库.   门面模式被归入建筑设计模式.门面模式隐藏系统内部的细 ...