解決方案

實用的解決方案4篇

　　為了確保工作或事情有序地進(jìn)行，通常需要提前準(zhǔn)備好一份方案，方案是計劃中內(nèi)容最為復(fù)雜的一種。怎樣寫方案才更能起到其作用呢？以下是小編幫大家整理的解決方案4篇，歡迎大家借鑒與參考，希望對大家有所幫助。

　　解決方案 篇1

　　發(fā)生IP地址沖突的原因：

　　1、很多用戶不知道“IP地址”、“子網(wǎng)掩碼”、“默認(rèn)網(wǎng)關(guān)”等參數(shù)如何設(shè)置，有時用戶不是從管理員處得到的上述參數(shù)的信息，或者是用戶無意修改了這些信息所導(dǎo)致的;

　　2、有時管理員或用戶根據(jù)管理員提供的參數(shù)進(jìn)行設(shè)置時，由于失誤造成參數(shù)輸錯也會導(dǎo)致該情況發(fā)生;

　　3、出現(xiàn)得最多的是在客戶機(jī)維修調(diào)試時，維修人員使用臨時IP地址應(yīng)用造成;

　　4、也不排除有人盜用他人的IP地址，造成IP地址沖突。

　　局域網(wǎng)IP地址沖突的解決方案：

　　方案一：逐一排查。

　　這是最原始的方法，就是發(fā)生IP地址沖突時，在局域網(wǎng)內(nèi)，挨著每臺計算機(jī)查看，找到與其沖突的計算機(jī)后修改IP地址就可以了。不過這樣比較耗時間，也不適合在大型局域網(wǎng)中使用，只適合在很小的網(wǎng)絡(luò)環(huán)境中采用。

　　方案二：MAC地址綁定。

　　1、檢查本地計算機(jī)的MAC并綁定：通過在本地計算機(jī)系統(tǒng)中運(yùn)行Winipcfg.exe或Ipconfig.exe，即可測知網(wǎng)卡的MAC地址。具體如下：在Win9X系統(tǒng)中依次單擊“開始”——“運(yùn)行”，在文本框中輸入“Winipcfg”并回車后將彈出“IP配置”窗口。在下拉列表中選擇“PCI Fast Ethernet Adapeter”，此時顯示在“適配器地址”欄中的文字即為該網(wǎng)卡的MAC地址;在WinNT系統(tǒng)的DOS提示符下運(yùn)行帶有“all”參數(shù)的ipconfig命令，即ipconfig/all也可以顯示網(wǎng)卡的MAC地址。

　　2、遠(yuǎn)程測試計算機(jī)的MAC地址：對于網(wǎng)絡(luò)管理員而言，可以用TCPNetView工具軟件來實現(xiàn)坐在自己的計算機(jī)前就能測知局域網(wǎng)中所有計算機(jī)的`MAC地址。該軟件在安裝完成之后，執(zhí)行tcpnv.exe即可顯示程序主窗口，在“File”菜單中選擇“Refresh”命令，或者直接按“F5”鍵，即可開始對局域網(wǎng)中現(xiàn)有的計算機(jī)進(jìn)行掃描，然后將顯示計算機(jī)名、IP地址和MAC地址等內(nèi)容。當(dāng)?shù)鹊搅艘慌_計算機(jī)上網(wǎng)卡的MAC地址后，就可以把它記錄下來，由網(wǎng)管在網(wǎng)關(guān)或者防火墻上進(jìn)行配置即可。具體的綁定命令視采用的網(wǎng)關(guān)或者防火墻不同而有所變化，這時，如果有其他的計算機(jī)想使用已綁定過的地址，就會出現(xiàn)IP地址已經(jīng)被使用的提示。

　　方案三：交換機(jī)安全端口。

　　過去常常在網(wǎng)絡(luò)里使用路由器和集線器，而現(xiàn)在很多局域網(wǎng)轉(zhuǎn)而采用了交換機(jī)。隨著近幾年來交換機(jī)的大幅降價，交換機(jī)在網(wǎng)絡(luò)市場上占據(jù)了主導(dǎo)地位，主要原因是交換機(jī)性價比高，結(jié)構(gòu)靈活，可以隨著未來應(yīng)用的變化而靈活配置。對于所遇到的IP地址沖突，還可以利用交換機(jī)的端口把不同的部門隔離開來解決，這是因為利用交換機(jī)可以對不同的區(qū)域?qū)嵭胁煌�的管理，�?jīng)過分割的網(wǎng)段之間互不干擾，可以在一定程度上解決IP地址沖突的問題。

　　方案四：劃分VLAN。

　　雖然可以用交換機(jī)來實現(xiàn)網(wǎng)段隔離，從而在一定程度上避免IP地址沖突的發(fā)生，但它仍不能防止由于同一個端口下的網(wǎng)段內(nèi)用戶配置錯誤而引起的IP地址沖突。更好的解決方法就是，利用交換機(jī)來劃分VLAN，再利用MAC地址綁定的方法來綜合處理。

　　解決方案 篇2

　　*{padding:0;margin:0}

　　p{height:20xxpx}

　　#gs{border:1px solid #000;position:fixed;right:30px;top:120px}

　　11111111111111111

　　以上這段代碼在網(wǎng)上很常見，通過設(shè)置html{overflow:hidden}和body{height:100%;overflow:auto}來實現(xiàn)ie6下position:fixed效果，但這種辦法有個缺陷，那就是：這會使頁面上原有的absolute、relation都變成fixed的效果，在這里我就不做demo了，如果有懷疑，可以自己去試驗一下。

　　于是我找了下資料，發(fā)現(xiàn)可以通過一條Internet Explorer的CSS表達(dá)式(expression)來完美的實現(xiàn)ie6下position:fixed效果，css代碼如下：

　　/* 除IE6瀏覽器的通用方法 */

　　.ie6fixedTL{position:fixed;left:0;top:0}

　　.ie6fixedBR{position:fixed;right:0;bottom:0}

　　/* IE6瀏覽器的特有方法 */

　　* html .ie6fixedTL{position:absolute;left:expression(eval(document.documentElement.scrollLeft));top:expression(eval(document.documentElement.scrollTop))}

　　* html .ie6fixedBR{position:absolute;left:expression(eval(document.documentElement.scrollLeft+document.documentElement.clientWidth-this.offsetWidth)-(parseInt(this.currentStyle.marginLeft,10)||0)-(parseInt(this.currentStyle.marginRight,10)||0));top:expression(eval(document.documentElement.scrollTop+document.documentElement.clientHeight-this.offsetHeight-(parseInt(this.currentStyle.marginTop,10)||0)-(parseInt(this.currentStyle.marginBottom,10)||0)))}

　　上面代碼可以直接使用了，如果要設(shè)置元素懸浮邊距，要分別為設(shè)置兩次，比如我要讓某個元素距頂部10個像素，距左部也是10個像素，那就要這樣子寫：

　　/* 除IE6瀏覽器的通用方法 */

　　.ie6fixedTL{position:fixed;left:10px;top:10px}

　　/* IE6瀏覽器的特有方法 */

　　* html .ie6fixedTL{position:absolute;left:expression(eval(document.documentElement.scrollLeft+10));top:expression(eval(document.documentElement.scrollTop+10))}

　　這樣一來，IE6下實現(xiàn)position:fixed的效果解決了，而且也不會影響到其他的absolute、relation，但還有一個問題，就是懸浮的元素會出現(xiàn)振動

　　IE有一個多步的渲染進(jìn)程。當(dāng)你滾動或調(diào)整你的瀏覽器大小的`時候，它將重置所有內(nèi)容并重畫頁面，這個時候它就會重新處理css表達(dá)式。這會引起一個丑陋的“振動”bug，在此處固定位置的元素需要調(diào)整以跟上你的(頁面的)滾動，于是就會“跳動”。

　　解決此問題的技巧就是使用background-attachment:fixed為body或html元素添加一個background-image。這就會強(qiáng)制頁面在重畫之前先處理CSS。因為是在重畫之前處理CSS，它也就會同樣在重畫之前首先處理你的CSS表達(dá)式。這將讓你實現(xiàn)完美的平滑的固定位置元素！

　　然后我發(fā)現(xiàn)background-image無需一張真實的圖片，設(shè)置成about:blank就行了。

　　下面附上完整代碼

　　/* 除IE6瀏覽器的通用方法 */

　　.ie6fixedTL{position:fixed;left:0;top:0}

　　.ie6fixedBR{position:fixed;right:0;bottom:0}

　　/* IE6瀏覽器的特有方法 */

　　/* 修正IE6振動bug */

　　* html,* html body{background-image:url(about:blank);background-attachment:fixed}

　　* html .ie6fixedTL{position:absolute;left:expression(eval(document.documentElement.scrollLeft));top:expression(eval(document.documentElement.scrollTop))}

　　* html .ie6fixedBR{position:absolute;left:expression(eval(document.documentElement.scrollLeft+document.documentElement.clientWidth-this.offsetWidth)-(parseInt(this.currentStyle.marginLeft,10)||0)-(parseInt(this.currentStyle.marginRight,10)||0));top:expression(eval(document.documentElement.scrollTop+document.documentElement.clientHeight-this.offsetHeight-(parseInt(this.currentStyle.marginTop,10)||0)-(parseInt(this.currentStyle.marginBottom,10)||0)))}

　　解決方案 篇3

　　Android設(shè)置鬧鐘并不像IOS那樣這么簡單，做過Android設(shè)置鬧鐘的開發(fā)者都知道里面的坑有多深。下面記錄一下，我解決Android鬧鐘設(shè)置的解決方案。

　　主要問題

　　1、API19開始AlarmManager的機(jī)制修改。

　　2、應(yīng)用程序被Kill掉后,設(shè)置的鬧鐘不響。

　　3、6.0以上進(jìn)入Doze模式會使JobScheduler停止工作。

　　4、手機(jī)設(shè)置重啟后，鬧鐘失效問題。

　　API19以上AlarmManager機(jī)制的修改

　　API19之前AlarmManager提供了三個設(shè)置鬧鐘的方法，由于業(yè)務(wù)需求鬧鐘只需要一次性，所以采用set(int type，long startTime，PendingIntent pi)；這個方法。

　　從API 19開始，AlarmManager的機(jī)制都是非準(zhǔn)確傳遞，操作系統(tǒng)將會轉(zhuǎn)換鬧鐘，來最小化喚醒和電池使用。

　　由于之前的程序，沒有對API19以上的鬧鐘設(shè)置做處理，導(dǎo)致在4.4以上的手機(jī)設(shè)置鬧鐘無響應(yīng)（應(yīng)用程序沒有被殺死的情況也沒有鬧鐘）。

　　因些，設(shè)置鬧鐘需要根據(jù)API的版本進(jìn)行分別處理設(shè)置。代碼如下：

　　AlarmManager am = (AlarmManager) getActivity() .getSystemService(Context.ALARM_SERVICE);if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { am.setExact(AlarmManager.RTC_WAKEUP, TimeUtils .stringToLong(recordTime, TimeUtils.NO_SECOND_FORMAT), sender);}else { am.set(AlarmManager.RTC_WAKEUP, TimeUtils .stringToLong(recordTime, TimeUtils.NO_SECOND_FORMAT), sender);}

　　這樣，保證鬧鐘在應(yīng)用程序沒有被Kill掉的情況鬧鐘。

　　應(yīng)用程序被Kill掉時的處理

　　應(yīng)用程序被Kill掉后，設(shè)置的鬧鐘失效，這里利用守護(hù)進(jìn)程以及灰色�；顏肀ＷC后臺鬧鐘服務(wù)不被Kill掉。當(dāng)應(yīng)用程序以及鬧鐘服務(wù)被Kill掉，守護(hù)進(jìn)程以及灰色�；顏碇匦聠�動鬧鐘服務(wù)，并且重新設(shè)置鬧鐘。

　　關(guān)于守護(hù)進(jìn)程的處理，這里采用開源的守護(hù)進(jìn)程庫。Android-AppDaemon

　　在鬧鐘服務(wù)的onCreat加入Android-AppDaemon這個開源的守護(hù)進(jìn)程。代碼如下：

　　@Overridepublic void onCreate() { super.onCreate(); Daemon.run(DaemonService.this, DaemonService.class, Daemon.INTERVAL_ONE_MINUTE); startTimeTask(); grayGuard();}

　　為進(jìn)一步保證鬧鐘服務(wù)的存活，同加上灰色�；睿ɡ�用系統(tǒng)的漏洞啟動前臺Service）。

　　代碼如下：

　　private void grayGuard() { if (Build.VERSION.SDK_INT < 18) { //API < 18 ，此方法能有效隱藏Notification上的圖標(biāo) startForeground(GRAY_SERVICE_ID, new Notification()); } else { Intent innerIntent = new Intent(this, DaemonInnerService.class); startService(innerIntent); startForeground(GRAY_SERVICE_ID, new Notification()); } //發(fā)送喚醒廣播來促使掛掉的UI進(jìn)程重新啟動起來 AlarmManager alarmManager = (AlarmManager) getSystemService(Context.ALARM_SERVICE); Intent alarmIntent = new Intent(); alarmIntent.setAction(WakeReceiver.GRAY_WAKE_ACTION); PendingIntent operation = PendingIntent.getBroadcast(this, WAKE_REQUEST_CODE, alarmIntent, PendingIntent.FLAG_UPDATE_CURRENT); if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { alarmManager.setWindow(AlarmManager.RTC_WAKEUP, System.currentTimeMillis(), ALARM_INTERVAL, operation); }else { alarmManager.setInexactRepeating(AlarmManager.RTC_WAKEUP, System.currentTimeMillis(), ALARM_INTERVAL, operation); }}/** * 給 API >= 18 的平臺上用的灰色保活手段 */public static class DaemonInnerService extends Service { @Override public void onCreate() { Log.i(LOG_TAG, "InnerService -> onCreate"); super.onCreate(); } @Override public int onStartCommand(Intent intent, int flags, int startId) { Log.i(LOG_TAG, "InnerService -> onStartCommand"); startForeground(GRAY_SERVICE_ID, new Notification()); //stopForeground(true); stopSelf(); return super.onStartCommand(intent, flags, startId); } @Override public IBinder onBind(Intent intent) { throw new UnsupportedOperationException("Not yet implemented"); } @Override public void onDestroy() { Log.i(LOG_TAG, "InnerService -> onDestroy"); super.onDestroy(); }}

　　上面操作盡可能提高鬧鐘服務(wù)的存活。但是在5.0以上的手機(jī)，利用系統(tǒng)的自帶的Clean功能的時候，還是會將鬧鐘服務(wù)徹底的干掉。為了解決5.0以上的問題，這里引入5.0以上的新特性 JobScheduler。

　　5.0以上的JobScheduler

　　在這里利用5.0以上的JobScheduler創(chuàng)建一個定時的任務(wù)，定時檢測鬧鐘服務(wù)是否存在，沒在存在則重新啟動鬧鐘服務(wù)。（這里我設(shè)置每一分鐘檢測一次鬧鐘服務(wù)）

　　在進(jìn)入應(yīng)用程序的時候檢測當(dāng)前系統(tǒng)是否是5.0以上，如果是則啟動JobScheduler這個服務(wù)。代碼如下：

　　if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { mJobScheduler = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE); JobInfo.Builder builder = new JobInfo.Builder(JOB_ID, new ComponentName(getPackageName(), JobSchedulerService.class.getName())); builder.setPeriodic(60 * 1000); //每隔60秒運(yùn)行一次 builder.setRequiresCharging(true); builder.setPersisted(true); //設(shè)置設(shè)備重啟后，是否重新執(zhí)行任務(wù) builder.setRequiresDeviceIdle(true); if (mJobScheduler.schedule(builder.build()) <= 0) { //If something goes wrong }}

　　其中的builder.setPersisted(true); 方法是設(shè)備重啟后，是否重新執(zhí)行任務(wù)，在這測過是可以重新啟動任務(wù)的。

　　上面的操作進(jìn)一步保證了鬧鐘服務(wù)被Kill掉后，重新啟動服務(wù)。但是在6.0以上引入了Doze模式，當(dāng)6.0以上的手機(jī)進(jìn)入這個模式后，便會使JobScheduler停止工作。

　　6.0以上Doze模式的處理

　　為了讓JobScheduler可以在6.0以上進(jìn)入Doze模式工作，這里針對6.0以上的Doze模式做特殊的處理-忽略電池的優(yōu)化。

　　在Manifest.xml中加入權(quán)限。

　　在設(shè)置鬧鐘的時候，判斷系統(tǒng)是否是6.0以上，如果是,則判斷是否忽略電池的優(yōu)化。判斷是否忽略電池優(yōu)化代碼如下：

　　@TargetApi(Build.VERSION_CODES.M)public static boolean isIgnoringBatteryOptimizations(Activity activity){ String packageName = activity.getPackageName(); PowerManager pm = (PowerManager) activity .getSystemService(Context.POWER_SERVICE); if (pm.isIgnoringBatteryOptimizations(packageName)) { return true; }else { return false; }}

　　如果沒有忽略電池優(yōu)化的時候，彈出提醒對話框，提示用戶進(jìn)行忽略電池優(yōu)化操作。代碼如下：

　　/*** 針對N以上的Doze模式** @param activity*/public static void isIgnoreBatteryOption(Activity activity) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { try { Intent intent = new Intent(); String packageName = activity.getPackageName(); PowerManager pm = (PowerManager) activity.getSystemService(Context.POWER_SERVICE); if (!pm.isIgnoringBatteryOptimizations(packageName)) {// intent.setAction(Settings.ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS); intent.setAction(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS); intent.setData(Uri.parse("package:" + packageName)); activity.startActivityForResult(intent, REQUEST_IGNORE_BATTERY_CODE); } } catch (Exception e) { e.printStackTrace(); } }}

　　在界面重寫onActivityResult方法來捕獲用戶的選擇。如，代碼如下：

　　@Overrideprotected void onActivityResult(int requestCode, int resultCode, Intent data) { if (resultCode == RESULT_OK) { if (requestCode == BatteryUtils.REQUEST_IGNORE_BATTERY_CODE){ //TODO something } }else if (resultCode == RESULT_CANCELED){ if (requestCode == BatteryUtils.REQUEST_IGNORE_BATTERY_CODE){ ToastUtils.show(getActivity(), "請開啟忽略電池優(yōu)化~"); } }}

　　補(bǔ)充

　　當(dāng)應(yīng)用程序被Kill掉，但是鬧鐘的`服務(wù)沒有被Kill掉的，這時候又設(shè)置了鬧鐘。這就意味著設(shè)置的鬧鐘沒有放到鬧鐘服務(wù)那里。所以這種情況，設(shè)置的鬧鐘會失效。為了解決這種情況，利用AIDL（鬧鐘服務(wù)在另一個進(jìn)程的需要進(jìn)程間通信）調(diào)用鬧鐘服務(wù)的重新設(shè)置鬧鐘方法重設(shè)鬧鐘。

　　在應(yīng)用程序的onCreat()方法啟動鬧鐘服務(wù)，然后再綁定鬧鐘服務(wù)。

　　private void initAlarmService() { startService(new Intent(this, DaemonService.class));//啟動鬧鐘服務(wù) if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { //JobScheduler ... } //綁定鬧鐘服務(wù) Intent intent = new Intent(this, DaemonService.class); intent.setAction("android.intent.action.DaemonService"); bindService(intent, mConnection, Context.BIND_AUTO_CREATE);}

　　在onDestroy()方法，調(diào)用鬧鐘服務(wù)的重設(shè)鬧鐘方法。代碼如下：

　　@Overrideprotected void onDestroy() { super.onDestroy(); try {//判斷是否有鬧鐘，沒有則關(guān)閉鬧鐘服務(wù) String alarm = localPreferencesHelper.getString(LocalPreferencesHelper.ALARM_CLOCK); if (daemonService != -1 && mIRemoteService != null) {// android.os.Process.killProcess(daemonService); mIRemoteService.resetAlarm(); } if (!alarm.equals("[]")) { if (daemonService != -1) { startService(new Intent(this, DaemonService.class)); } } else { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { mJobScheduler.cancel(JOB_ID); } } unbindService(mConnection); //解除綁定服務(wù)。 } catch (Exception e) { }}

　　這里說明一下，當(dāng)服務(wù)啟動并且被綁定的情況下，unbindService是不會停止服務(wù)的。

　　最后

　　以上并不代表所有的Android手機(jī)的鬧鐘都可以用，這只是盡最大的可能保證大部分的手機(jī)。

　　以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持教程網(wǎng)。

　　解決方案 篇4

　　我的女友是一個詭計多端的家伙。我苦苦地追了她一年多，她始終在愛與不愛之間徘徊。我的關(guān)心和愛護(hù)，她每次都照單全收，但就是不肯把關(guān)系明確，存心吊我的胃口。我心里很矛盾：繼續(xù)追吧，對方是一根難啃的骨頭；她吧，又極不甘心，因為她確實是我夢寐以求的對象。

　　正當(dāng)我處于迷茫之中的時候，在外地工作的大哥回來探親了。大哥見我整天愁悶苦臉的，問我何故。我便把實情對大哥說了。沒想到大哥聽了爽朗一笑：“這其實是一個極容易解決的問題呀！”我忙問：“怎么解決？”大哥說：“只要你痛下決心冷淡她一回，你很快就可以知道她究竟愛不愛你。如果她忍受不了你的冷淡——她可能會主動向你伸出橄欖枝，也可能會千方百計找借口對你發(fā)脾氣——這都是愛你表現(xiàn)。如果她對你的冷淡無動于衷，那你不如趁早死心。”

　　想想大哥說得也有道理。于是斗膽按照大哥的主意一試，不再約她出去，她來電話也懶得接聽。果然，不出一個星期，女友就主動找上門來了。女友一見面就質(zhì)問我：“這幾天干嗎不來找我？”我翹著二郎腿反問：“我為什么要來找你？”女友以前還從未從我這兒領(lǐng)教過這種說話的`口氣，頓時心里亂了方寸：“你……怎么了嘛？”我說：我沒怎么，只是現(xiàn)在想通了，不想再折騰自己！”女友一向聰明過人，自然很容易明白我話里的意思。她顯然意識到了問題的嚴(yán)重性，馬上溫情脈脈地走近我：“我有什么不對你跟我說嘛，不要生氣好不好？”我一把抱住女友猛吻，女友絲毫沒有反抗。

　　我把的喜訊告訴大哥時，大哥避開大嫂悄悄地對我說：“你大嫂當(dāng)初也是這樣，總在我面前趾高氣揚(yáng)。后來我不再理睬她，她反而主動來追我�！�

【解決方案】相關(guān)文章：

解決方案05-20

解決方案（實用）05-27

解決方案優(yōu)秀05-12

行業(yè)解決方案08-16

erp解決方案04-22

oa解決方案05-31

產(chǎn)品解決方案11-19

招聘解決方案02-14

解決方案（精）05-23

解決方案【優(yōu)秀】08-25