襄阳网站建设关于飞鱼,建设企业网站所遵循的一般原则,网站扁平结构,针织东莞网站建设技术支持App性能如何量化:如何衡量一个APP性能好坏#xff1f;直观感受就是#xff1a;启动快、流畅、不闪退、耗电少等感官指标#xff0c;反应到技术层面包装下就是#xff1a;FPS#xff08;帧率#xff09;、界面渲染速度、Crash率、网络、CPU使用率、电量损耗速度等#xf…App性能如何量化: 如何衡量一个APP性能好坏直观感受就是启动快、流畅、不闪退、耗电少等感官指标反应到技术层面包装下就是FPS帧率、界面渲染速度、Crash率、网络、CPU使用率、电量损耗速度等一般挑其中几个关键指标作为APP质量的标尺。目前也有多种开源APM监控方案但大部分偏向离线检测对于线上监测而言显得太重可能会适得其反方案简单对比如下SDK现状与问题是否推荐直接线上使用腾讯matrix功能全但是重而且运行测试期间经常Crash否腾讯GT2018年之后没更新关注度低本身功能挺多也挺重性价比还不如matrix否网易Emmagee2018年之后没更新几乎没有关注度重否听云App适合监测网络跟启动场景受限否 还有其他多种APM检测工具功能复杂多样但其实很多指标并不是特别重要实现越复杂线上风险越大因此并不建议直接使用。而且分析多家APP的实现原理其核心思路基本相同且门槛也并不是特别高建议自研一套在灵活性、安全性上更有保障更容易做到轻量级。本文主旨就是围绕几个关键指标FPS、内存内存泄漏、界面启动、流量等实现轻量级的线上监测。核心性能指标拆解:• 稳定性Crash统计 Crash统计与聚合有比较通用的策略比如Firebase、Bugly等不在本文讨论范围。• 网络请求 每个APP的网络请求一般都存在统一的Hook点门槛很低且各家请求协议与SDK有别很难实现统一的网络请求监测其次想要真正定位网络请求问题可能牵扯整个请求的链路更适合做一套网络全链路监控APM也不在讨论范围。• 冷启动时间及各个Activity页面启动时间 (存在统一方案)• 页面FPS、卡顿、ANR 存在统一方案• 内存统计及内存泄露侦测 存在统一方案• 流量消耗 存在统一方案• 电量 存在统一方案• CPU使用率CPU还没想好咋么用7.0之后实现机制也变了先不考虑。线上监测的重点就聚焦后面几个下面逐个拆解如何实现。启动耗时 直观上说界面启动就是从点击一个图标到看到下一个界面首帧如果这个过程耗时较长用户会会感受到顿挫影响体验。从场景上说启动耗时间简单分两种冷启动耗时 在APP未启动的情况下从点击桌面icon 到看到闪屏Activity的首帧非默认背景。界面启动耗时 APP启动后从上一个界面pause到下一个界面首帧可见。 本文粒度较粗主要聚焦Activity这里有个比较核心的时机Activity首帧可见点这个点究竟在什么时候经分析测试发现不同版本表现不一在Android 10 之前这个点与onWindowFocusChanged回调点基本吻合在Android 10 之后系统做了优化将首帧可见的时机提前到onWindowFocusChanged之前可以简单看做onResume或者onAttachedToWindow之后对于一开始点击icon的点可以约等于APP进程启动的点拿到了上面两个时间点就可以得到冷启动耗时。 APP进程启动的点可以通过加载一个空的ContentProvider来记录因为ContentProvider的加载时机比较靠前早于Application的onCreate之前相对更准确一点很多SDK的初始也采用这种方式实现如下public class LauncherHelpProvider extends ContentProvider {// 用来记录启动时间public static long sStartUpTimeStamp SystemClock.uptimeMillis();...} 这样就得到了冷启动的开始时间如何得到第一个Activity界面可见的时间呢比较简单的做法是在SplashActivity中进行打点对于Android 10 以前的可以在onWindowFocusChanged中打点在Android 10以后可以在onResume之后进行打点。不过做SDK需要减少对业务的入侵可以借助Applicattion监听Activity Lifecycle无入侵获取这个时间点。对于Android 10之前系统 可以利用ViewTreeObserve监听nWindowFocusChange回调达到无入侵获取onWindowFocusChanged调用点示意代码如下:application.registerActivityLifecycleCallbacks(new Application.ActivityLifecycleCallbacks() {....Override
public void onActivityResumed(NonNull final Activity activity) {super.onActivityResumed(activity);launcherFlag | resumeFlag;!--添加onWindowFocusChanged 监听--activity.getWindow().getDecorView().getViewTreeObserver().addOnWindowFocusChangeListener(new ViewTreeObserver.OnWindowFocusChangeListener() {!--onWindowFocusChanged回调--Overridepublic void onWindowFocusChanged(boolean b) {if (b (launcherFlag ^ startFlag) 0) {!--判断是不是首个Activity--final boolean isColdStarUp ActivityStack.getInstance().getBottomActivity() activity;!--获取首帧可见距离启动的时间--final long coldLauncherTime SystemClock.uptimeMillis() - LauncherHelpProvider.sStartUpTimeStamp;final long activityLauncherTime SystemClock.uptimeMillis() - mActivityLauncherTimeStamp;activity.getWindow().getDecorView().getViewTreeObserver().removeOnWindowFocusChangeListener(this);!--异步线程处理回调减少UI线程负担--mHandler.post(new Runnable() {Overridepublic void run() {if (isColdStarUp) {//todo 监听到冷启动耗时... 对于Android 10以后的系统可以在onActivityResumed回调时添加一UI线程Message来达到监听目的代码如下Override
public void onActivityResumed(NonNull final Activity activity) {super.onActivityResumed(activity);if (launcherFlag ! 0 (launcherFlag resumeFlag) 0) {launcherFlag | resumeFlag;if (Build.VERSION.SDK_INT Build.VERSION_CODES.P) {// 10 之后有改动第一帧可见提前了 可认为onActivityResumed之后mUIHandler.post(new Runnable() {Overridepublic void run() {!--获取第一帧可见时间点-- }});} 如此就可以检测到冷启动耗时。APP启动后各Activity启动耗时计算逻辑类似首帧可见点沿用上面方案即可不过这里还缺少上一个界面暂停的点经分析测试锚在上一个Actiivty pause的时候比较合理因此Activity启动耗时定义如下Activity启动耗时 当前Activity 首帧可见 - 上一个Activity onPause被调用 同样为了减轻对业务入侵也依赖registerActivityLifecycleCallbacks来实现补全上方缺失:application.registerActivityLifecycleCallbacks(new Application.ActivityLifecycleCallbacks() {Overridepublic void onActivityPaused(NonNull Activity activity) {super.onActivityPaused(activity);!--记录上一个Activity pause节点--mActivityLauncherTimeStamp SystemClock.uptimeMillis();launcherFlag 0;}...
Override
public void onActivityResumed(NonNull final Activity activity) {super.onActivityResumed(activity);launcherFlag | resumeFlag;!--参考上面获取首帧的点--... 到这里就获取了两个比较关键的启动耗时不过实际使用中可能存在各种异常场景比如闪屏页在onCreate或者onResume中调用了finish跳转首页对于这种场景就需要额外处理比如在onCreate中调用了finishonResume可能不会被调用这个时候就要在 onCreate之后进行统计同时利用用Activity.isFinishing()标识这种场景其次启动耗时对于不同配置也是不一样的不能用绝对时间衡量只能横向对比简单线上效果如下线上效果如下流畅度及FPS(Frames Per Second监测 FPS是图像领域中的定义指画面每秒传输帧数每秒帧数越多显示的动作就越流畅。FPS可以作为衡量流畅度的一个指标但是从各厂商的报告来看仅用FPS来衡量是否流畅并不科学。电影或视频的FPS并不高30的FPS即可满足人眼需求稳定在30FPS的动画并不会让人感到卡顿但如果FPS 很不稳定的话就很容易感知到卡顿注意这里有个词叫稳定。举个极端例子前500ms刷新了59帧后500ms只绘制一帧即使达到了60FPS仍会感知卡顿这里就突出稳定的重要性。不过FPS也并不是完全没用可以用其上限定义流畅用其下限可以定义卡顿对于中间阶段的感知FPS无能为力如下示意 上面那个是极端例子Android 系统中VSYNC会杜绝16ms内刷新两次那么在中间的情况下怎么定义流畅比如FPS降低到50会卡吗答案是不一定。50的FPS如果是均分到各个节点用户是感知不到掉帧的但如果丢失的10帧全部在一次绘制点那就能明显感知卡顿这个时候瞬时帧率的意义更大如下:Matrix给的卡顿标准BestNormalMiddleHighFrozen[0:3)[3:9)[9:24)[24:42)[42:∞) 总之相比1s平均FPS瞬时掉帧程度的严重性更能反应界面流畅程度因此FPS监测的重点是侦测瞬时掉帧程度。 在应用中FPS对动画及列表意义较大监测开始的时机放在界面启动并展示第一帧之后这样就能跟启动完美衔接起来.// 帧率不统计第一帧
Override
public void onActivityResumed(NonNull final Activity activity) {super.onActivityResumed(activity);activity.getWindow().getDecorView().getViewTreeObserver().addOnWindowFocusChangeListener(new ViewTreeObserver.OnWindowFocusChangeListener() {Overridepublic void onWindowFocusChanged(boolean b) {if (b) {!--界面可见后开始侦测FPS--resumeTrack();activity.getWindow().getDecorView().getViewTreeObserver().removeOnWindowFocusChangeListener(this);
...
}侦测停止的时机也比较简单在onActivityPaused界面失去焦点无法与用户交互的时候。Override
public void onActivityPaused(NonNull Activity activity) {super.onActivityPaused(activity);pauseTrack(activity.getApplication());
}如何侦测瞬时FPS有两种常用方式:360 ArgusAPM类实现方式监测Choreographer两次Vsync时间差。BlockCanary的实现方式监测UI线程单条Message执行时间。360的实现依赖Choreographer VSYNC回调具体实现如下循环添加Choreographer.FrameCallback。Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {Overridepublic void doFrame(long frameTimeNanos) {mFpsCount;mFrameTimeNanos frameTimeNanos;if (isCanWork()) {//注册下一帧回调Choreographer.getInstance().postFrameCallback(this);} else {mCurrentCount 0;}}
}); 这种监听有个问题就是监听过于频繁因为在无需界面刷新的时候Choreographer.FrameCallback还是不断循环执行浪费CPU资源对线上运行采集并不友好相比之下BlockCanary的监听单个Message执行要友善的多而且同样能够涵盖UI绘制耗时、两帧之间的耗时额外执行负担较低也是本文采取的策略核心实现参照Matrix• 监听Message执行耗时。• 通过反射循环添加Choreographer.FrameCallback区分doFrame耗时。为Looper设置一个LooperPrinter根据回传信息头区分消息执行开始与结束计算Message耗时原理如下public static void loop() {...if (logging ! null) {logging.println( Dispatching to msg.target msg.callback : msg.what);}...if (logging ! null) {logging.println( Finished to msg.target msg.callback);}自定义LooperPrinter如下class LooperPrinter implements Printer {Override
public void println(String x) {...if (isValid) {!--区分开始结束计算消息耗时--dispatch(x.charAt(0) , x);
} 利用回调参数与的 区别即可诊断出Message执行耗时从而确定是否导致掉帧。以上实现针对所有UI Message原则上UI线程所有的消息都应该保持轻量级任何消息超时都应当算作异常行为所以直接拿来做掉帧监测没特大问题的。但是有些特殊情况可能对FPS计算有一些误判比如在touch时间里往UI线程塞了很多消息单条一般不会影响滚动但多条聚合可能会带来影响如果没跳消息执行时间很短这种方式就可能统计不到当然这种业务的写法本身就存在问题所以先不考虑这种场景。 Choreographer有个方法addCallbackLocked通过这个方法添加的任务会被加入到VSYNC回调会跟Input、动画、UI绘制一起执行因此可以用来作为鉴别是否是UI重绘的Message看看是不是重绘或者触摸事件导致的卡顿掉帧。Choreographer源码如下UnsupportedAppUsage
public void addCallbackLocked(long dueTime, Object action, Object token) {CallbackRecord callback obtainCallbackLocked(dueTime, action, token);CallbackRecord entry mHead;if (entry null) {mHead callback;return;}if (dueTime entry.dueTime) {callback.next entry;mHead callback;return;}while (entry.next ! null) {if (dueTime entry.next.dueTime) {callback.next entry.next;break;}entry entry.next;}entry.next callback;
}
该方法不为外部可见因此需要通过反射获取。private synchronized void addFrameCallback(int type, Runnable callback, boolean isAddHeader) {try {!--反射获取方法--addInputQueue reflectChoreographerMethod(0 “addCallbackLocked”, long.class, Object.class, Object.class);!--添加回调--if (null ! method) {method.invoke(callbackQueues[type], !isAddHeader ? SystemClock.uptimeMillis() : -1, callback, null);}然后在每次执行结束后重新将callback添加回Choreographer的Queue监听下一次UI绘制。Override
public void dispatchEnd() {super.dispatchEnd();if (mStartTime 0) {long cost SystemClock.uptimeMillis() - mStartTime;!--计算耗时--collectInfoAndDispatch(ActivityStack.getInstance().getTopActivity(), cost, mInDoFrame);if (mInDoFrame) {!--监听下一次UI绘制--addFrameCallBack();mInDoFrame false;}}
}
这样就能检测到每次Message执行的时间它可以直接用来计算瞬时帧率。瞬时掉帧程度 Message耗时/16 -1 不足1 可看做1 瞬时掉帧小于2次可以认为没有发生抖动如果出现了单个Message执行过长可认为发生了掉帧流畅度与瞬时帧率监测大概就是这样。不过同启动耗时类似不同配置结果不同不能用绝对时间衡量只能横向对比简单线上效果如下内存泄露及内存使用侦测内存泄露有个比较出名的库LeakCanary实现原理也比较清晰就是利用弱引用ReferenceQueue其实只用弱引用也可以做ReferenceQueue只是个辅助作用LeakCanary除了泄露检测还有个堆栈Dump的功能虽然很好但是这个功能并不适合线上而且只要能监听到Activity泄露本地分析原因是比较快的没必要将堆栈Dump出来。因此本文只实现Activity泄露监测能力不在线上分析原因。而且参考LeakCanary改用一个WeakHashMap实现上述功能不在主动暴露ReferenceQueue这个对象。WeakHashMap最大的特点是其key对象被自动弱引用可以被回收利用这个特点用其key监听Activity回收就能达到泄露监测的目的。核心实现如下application.registerActivityLifecycleCallbacks(new Application.ActivityLifecycleCallbacks() {Overridepublic void onActivityDestroyed(NonNull Activity activity) {super.onActivityDestroyed(activity);!--放入map进行监听--mActivityStringWeakHashMap.put(activity, activity.getClass().getSimpleName());}Overridepublic void onActivityStopped(NonNull final Activity activity) {super.onActivityStopped(activity);// 退后台GC 找LeakActivityif (!ActivityStack.getInstance().isInBackGround()) {return;}Runtime.getRuntime().gc();mHandler.postDelayed(new Runnable() {Overridepublic void run() {try {if (!ActivityStack.getInstance().isInBackGround()) {return;}try {// 申请个稍微大的对象促进GCbyte[] leakHelpBytes new byte[4 * 1024 * 1024];for (int i 0; i leakHelpBytes.length; i 1024) {leakHelpBytes[i] 1;}} catch (Throwable ignored) {}Runtime.getRuntime().gc();SystemClock.sleep(100);System.runFinalization();HashMapString, Integer hashMap new HashMap();for (Map.EntryActivity, String activityStringEntry : mActivityStringWeakHashMap.entrySet()) {String name activityStringEntry.getKey().getClass().getName();Integer value hashMap.get(name);if (value null) {hashMap.put(name, 1);} else {hashMap.put(name, value 1);}}if (mMemoryListeners.size() 0) {for (Map.EntryString, Integer entry : hashMap.entrySet()) {for (ITrackMemoryListener listener : mMemoryListeners) {listener.onLeakActivity(entry.getKey(), entry.getValue());}}}} catch (Exception ignored) {}}}, 10000);}线上选择监测没必要实时将其延后到APP进入后台的时候在APP进入后台之后主动触发一次GC然后延时10s进行检查之所以延时10s是因为GC不是同步的为了让GC操作能够顺利执行完这里选择10s后检查。在检查前分配一个4M的大内存块再次确保GC执行之后就可以根据WeakHashMap的特性查找有多少Activity还保留在其中这些Activity就是泄露Activity。关于内存检测内存检测比较简单弄清几个关键的指标就行这些指标都能通过 Debug.MemoryInfo获取。Debug.MemoryInfo debugMemoryInfo new Debug.MemoryInfo();
Debug.getMemoryInfo(debugMemoryInfo);
appMemory.nativePss debugMemoryInfo.nativePss 10;
appMemory.dalvikPss debugMemoryInfo.dalvikPss 10;
appMemory.totalPss debugMemoryInfo.getTotalPss() 10;这里关心三个就行1. TotalPss整体内存nativedalvik共享2. nativePss native内存3. dalvikPss java内存 OOM原因 一般而言total是大于nativdalvik的因为它包含了共享内存理论上我们只关心native跟dalvik就行以上就是关于内存的监测能力不过内存泄露不是100%正确暴露明显问题即可效果如下流量监测 流量监测的实现相对简单利用系统提供的TrafficStats.getUidRxBytes方法配合Actvity生命周期即可获取每个Activity的流量消耗。具体做法在Activity start的时候记录起点在pause的时候累加最后在Destroyed的时候统计整个Activity的流量消耗如果想要做到Fragment维度就要具体业务具体分析了简单实现如下application.registerActivityLifecycleCallbacks(new Application.ActivityLifecycleCallbacks() {Overridepublic void onActivityStarted(NonNull Activity activity) {super.onActivityStarted(activity);!--开始记录--markActivityStart(activity);}Overridepublic void onActivityPaused(NonNull Activity activity) {super.onActivityPaused(activity);!--累加--markActivityPause(activity);}Overridepublic void onActivityDestroyed(NonNull Activity activity) {super.onActivityDestroyed(activity);!--统计结果并通知回调--markActivityDestroy(activity);}
};
电量检测 Android电量状态能通过以下方法实时获取只是对于分析来说有点麻烦需要根据不同手机、不同配置做聚合单处采集很简单。IntentFilter filter new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
android.content.Intent batteryStatus application.registerReceiver(null, filter);
int status batteryStatus.getIntExtra(status, 0);
boolean isCharging status BatteryManager.BATTERY_STATUS_CHARGING ||status BatteryManager.BATTERY_STATUS_FULL;
int scale batteryStatus.getIntExtra(BatteryManager.EXTRA_SCALE, -1); 不过并不能获取绝对电量只能看百分比因为对单个Activity来做电量监测并不靠谱往往都是0可以在APP推到后台后对这个在线时长的电池消耗做监测这个可能还能看出一些电量变化。CPU使用监测没想好怎么弄显不出力。数据整合与基线制定 APP端只是完成的数据的采集数据的整合及根系还是要依赖后台数据分析根据不同配置不同场景才能制定一套比较合理的基线而且这种基线肯定不是绝对的只能是相对的这套基线将来可以作为页面性能评估标准对Android而言挺难机型太多。总结启动有相对靠谱节点。瞬时FPS瞬时掉帧程度意义更大。内存泄露可以一个WeakHashMap简单搞定。电量及CPU还不知道怎么用。源码地址https://github.com/happylishang/Collie
文章转载自： http://www.morning.skqfx.cn.gov.cn.skqfx.cn http://www.morning.bzbq.cn.gov.cn.bzbq.cn http://www.morning.yrnyz.cn.gov.cn.yrnyz.cn http://www.morning.nlqgb.cn.gov.cn.nlqgb.cn http://www.morning.rpsjh.cn.gov.cn.rpsjh.cn http://www.morning.wjlkz.cn.gov.cn.wjlkz.cn http://www.morning.zntf.cn.gov.cn.zntf.cn http://www.morning.rqgq.cn.gov.cn.rqgq.cn http://www.morning.mzjbz.cn.gov.cn.mzjbz.cn http://www.morning.lfsmf.cn.gov.cn.lfsmf.cn http://www.morning.xckdn.cn.gov.cn.xckdn.cn http://www.morning.qhnmj.cn.gov.cn.qhnmj.cn http://www.morning.lxdbn.cn.gov.cn.lxdbn.cn http://www.morning.lbpqk.cn.gov.cn.lbpqk.cn http://www.morning.wrtw.cn.gov.cn.wrtw.cn http://www.morning.yggdq.cn.gov.cn.yggdq.cn http://www.morning.xkyqq.cn.gov.cn.xkyqq.cn http://www.morning.bmrqz.cn.gov.cn.bmrqz.cn http://www.morning.kflpf.cn.gov.cn.kflpf.cn http://www.morning.glnfn.cn.gov.cn.glnfn.cn http://www.morning.shxrn.cn.gov.cn.shxrn.cn http://www.morning.mdpcz.cn.gov.cn.mdpcz.cn http://www.morning.mtrfz.cn.gov.cn.mtrfz.cn http://www.morning.qnlbb.cn.gov.cn.qnlbb.cn http://www.morning.hnzrl.cn.gov.cn.hnzrl.cn http://www.morning.stxg.cn.gov.cn.stxg.cn http://www.morning.kmjbs.cn.gov.cn.kmjbs.cn http://www.morning.fbxlj.cn.gov.cn.fbxlj.cn http://www.morning.pynzj.cn.gov.cn.pynzj.cn http://www.morning.qztsq.cn.gov.cn.qztsq.cn http://www.morning.xxiobql.cn.gov.cn.xxiobql.cn http://www.morning.xqgh.cn.gov.cn.xqgh.cn http://www.morning.spnky.cn.gov.cn.spnky.cn http://www.morning.qhln.cn.gov.cn.qhln.cn http://www.morning.krjrb.cn.gov.cn.krjrb.cn http://www.morning.fhykt.cn.gov.cn.fhykt.cn http://www.morning.skrcn.cn.gov.cn.skrcn.cn http://www.morning.hksxq.cn.gov.cn.hksxq.cn http://www.morning.ywtbk.cn.gov.cn.ywtbk.cn http://www.morning.cjwkf.cn.gov.cn.cjwkf.cn http://www.morning.kzqpn.cn.gov.cn.kzqpn.cn http://www.morning.jqmqf.cn.gov.cn.jqmqf.cn http://www.morning.bpmtq.cn.gov.cn.bpmtq.cn http://www.morning.mqtzd.cn.gov.cn.mqtzd.cn http://www.morning.xesrd.com.gov.cn.xesrd.com http://www.morning.rcbdn.cn.gov.cn.rcbdn.cn http://www.morning.bfhrj.cn.gov.cn.bfhrj.cn http://www.morning.mlbdr.cn.gov.cn.mlbdr.cn http://www.morning.sdkaiyu.com.gov.cn.sdkaiyu.com http://www.morning.nqmhf.cn.gov.cn.nqmhf.cn http://www.morning.ntkpc.cn.gov.cn.ntkpc.cn http://www.morning.qsy41.cn.gov.cn.qsy41.cn http://www.morning.mtsgx.cn.gov.cn.mtsgx.cn http://www.morning.wkrkb.cn.gov.cn.wkrkb.cn http://www.morning.mszls.cn.gov.cn.mszls.cn http://www.morning.sqskm.cn.gov.cn.sqskm.cn http://www.morning.bphqd.cn.gov.cn.bphqd.cn http://www.morning.xjqhh.cn.gov.cn.xjqhh.cn http://www.morning.bqnhh.cn.gov.cn.bqnhh.cn http://www.morning.lxhny.cn.gov.cn.lxhny.cn http://www.morning.xrksf.cn.gov.cn.xrksf.cn http://www.morning.zlgbx.cn.gov.cn.zlgbx.cn http://www.morning.vjdofuj.cn.gov.cn.vjdofuj.cn http://www.morning.ncrk.cn.gov.cn.ncrk.cn http://www.morning.hpnhl.cn.gov.cn.hpnhl.cn http://www.morning.jfcbz.cn.gov.cn.jfcbz.cn http://www.morning.gxwyr.cn.gov.cn.gxwyr.cn http://www.morning.kfmnf.cn.gov.cn.kfmnf.cn http://www.morning.xfrqf.cn.gov.cn.xfrqf.cn http://www.morning.spfh.cn.gov.cn.spfh.cn http://www.morning.cwknc.cn.gov.cn.cwknc.cn http://www.morning.wkcl.cn.gov.cn.wkcl.cn http://www.morning.mzjbz.cn.gov.cn.mzjbz.cn http://www.morning.qqrlz.cn.gov.cn.qqrlz.cn http://www.morning.phxdc.cn.gov.cn.phxdc.cn http://www.morning.pfggj.cn.gov.cn.pfggj.cn http://www.morning.qphdp.cn.gov.cn.qphdp.cn http://www.morning.zzfjh.cn.gov.cn.zzfjh.cn http://www.morning.lgqdl.cn.gov.cn.lgqdl.cn http://www.morning.ntcmrn.cn.gov.cn.ntcmrn.cn
