cforandroid

A. Android P 系統穩定性問題分析方法總結

Android系統最開始是為手機設計的，在機頂盒，電視，帶屏音箱等大屏上運行後，晶元廠家做些適配，產品廠家也會做系統客制化，有時候還要適配第三方應用..等待
這種適配容易引人系統的穩定性問題，系統穩定性對於用戶體驗至關重要，很多問題也都比較類似，android系統對系統性能，穩定性分析工具也比較多，下面根據工作中遇到的問題做個總結。

從表現來看有: 死機重啟, 自動關機, 無法開機,凍屏,黑屏以及閃退, 無響應等情況;

從技術層面來劃分無外乎兩大類: 長時間無法執行完成(Timeout) 以及異常崩潰(crash). 主要分類如下:

ANR(Application Not responding)，是指普通app進程超過一定時間沒有執行完，系統會彈出應用無響應對話框. 如果
該進程運行在system進程, 更准確的來說,應該是(System Not Responding, SNR)

ANR產生的原因可能是各種各樣的，但常見的原因可以分為：

1.logcat日誌
2.trace文件(保存在/data/anr/traces.txt)
從logcat里可以看到死鎖的列印
從traces.txt可以看到線程的函數調用棧

10-16 00:50:10 820 907 E ActivityManager: ANR in com.android.systemui, time=130090695
10-16 00:50:10 820 907 E ActivityManager: Reason: Broadcast of Intent { act=android.intent.action.TIME_TICK flg=0x50000114 (has extras) }
10-16 00:50:10 820 907 E ActivityManager: Load: 30.4 / 22.34 / 19.94
10-16 00:50:10 820 907 E ActivityManager: Android time :[2015-10-16 00:50:05.76] [130191,266]
10-16 00:50:10 820 907 E ActivityManager: CPU usage from 6753ms to -4ms ago:
10-16 00:50:10 820 907 E ActivityManager: 47% 320/netd: 3.1% user + 44% kernel / faults: 14886 minor 3 major
10-16 00:50:10 820 907 E ActivityManager: 15% 10007/com.sohu.sohuvideo: 2.8% user + 12% kernel / faults: 1144 minor
10-16 00:50:10 820 907 E ActivityManager: 13% 10654/hif_thread: 0% user + 13% kernel
10-16 00:50:10 820 907 E ActivityManager: 11% 175/mmcqd/0: 0% user + 11% kernel
10-16 00:50:10 820 907 E ActivityManager: 5.1% 12165/app_process: 1.6% user + 3.5% kernel / faults: 9703 minor 540 major
10-16 00:50:10 820 907 E ActivityManager: 3.3% 29533/com.android.systemui: 2.6% user + 0.7% kernel / faults: 8402 minor 343 major
......
10-16 00:50:10 820 907 E ActivityManager: +0% 12832/cat: 0% user + 0% kernel
10-16 00:50:10 820 907 E ActivityManager: +0% 13211/zygote64: 0% user + 0% kernel
10-16 00:50:10 820 907 E ActivityManager: 87% TOTAL: 3% user + 18% kernel + 64% iowait + 0.5% softirq

發生ANR的時間 00:50:10 ,可以從這個時間點之前的日誌中，還原ANR出現時系統的運行狀態
發生ANR的進程 com.android.system.ui
發生ANR的原因 Reason關鍵字表明了ANR的原因是處理TIME_TICK廣播消息超時
CPU負載 Load關鍵字表明了最近1分鍾、5分鍾、15分鍾內的CPU負載分別是30.4、22.3、19.94.CPU最近1分鍾的負載最具參考價值，因為ANR的超時限制基本都是1分鍾以內， 這可以近似的理解為CPU最近1分鍾平均有30.4個任務要處理，這個負載值是比較高的
CPU使用統計時間段 CPU usage from XX to XX ago關鍵字表明了這是在ANR發生之前一段時間內的CPU統計,類似的還有CPU usage from XX to XX after關鍵字，表明是ANR發生之後一段時間內的CPU統計
各進程的CPU使用率
以com.android.systemui進程的CPU使用率為例，它包含以下信息：
總的CPU使用率: 3.3%，其中systemui進程在用戶態的CPU使用率是2.6%，在內核態的使用率是0.7%
缺頁次數fault：8402 minor表示高速緩存中的缺頁次數，343 major表示內存的缺頁次數。minor可以理解為進程在做內存訪問，major可以理解為進程在做IO操作。 當前minor和major值都是比較高的，從側面反映了發生ANR之前，systemui進程有有較多的內存訪問操作，引發的IO次數也會較多
CPU使用匯總 TOTAL關鍵字表明了CPU使用的匯總，87%是總的CPU使用率，其中有一項iowait表明CPU在等待IO的時間，佔到64%，說明發生ANR以前，有大量的IO操作。app_process、 system_server, com.android.systemui這幾個進程的major值都比較大，說明這些進程的IO操作較為頻繁，從而拉升了整個iowait的時間

traces.txt 如下
----- pid 29533 at 2015-10-16 00:48:29 -----
Cmd line: com.android.systemui
DALVIK THREADS (54):
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 obj=0x75bd5818 self=0x7f8549a000
| sysTid=29533 nice=0 cgrp=bg_non_interactive sched=0/0 handle=0x7f894bbe58
| state=S schedstat=( 289080040422 93461978317 904874 ) utm=20599 stm=8309 core=0 HZ=100
| stack=0x7fdffda000-0x7fdffdc000 stackSize=8MB
| held mutexes=
at com.mediatek.anrappmanager.MessageLogger.println(SourceFile:77)

Android系統中，有硬體WatchDog用於定時檢測關鍵硬體是否正常工作，類似地，在framework層有一個軟體WatchDog用於定期檢測關鍵系統服務是否發生死鎖事件。
watchdog 每過30s 檢測一次， 如果要監控的線程30s 後沒有響應，系統會mp出此進程堆棧，如果超過60s 沒有相應，會觸發watchdog，並重啟系統
10:57:23.718 579 1308 W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor com.android.server.am.ActivityManagerService on foreground thread (android.fg), Blocked in handler on main thread (main), Blocked in handler on ActivityManager (ActivityManager)
10:57:23.725 579 1308 W Watchdog: android.fg annotated stack trace:
10:57:23.726 579 1308 W Watchdog: at com.android.server.am.ActivityManagerService.monitor(ActivityManagerService.java:26271)
10:57:23.727 579 1308 W Watchdog: - waiting to lock <0x0bb47e39> (a com.android.server.am.ActivityManagerService)
10:57:23.727 579 1308 W Watchdog: at com.android.server.Watchdog DeliveryTracker.alarmTimedOut(AlarmManagerService.java:4151)
10:57:23.733 579 1308 W Watchdog: - waiting to lock <0x00aaee38> (a java.lang.Object)
......
10:57:23.736 579 1308 W Watchdog: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:838)
10:57:23.739 579 1308 W Watchdog: ActivityManager annotated stack trace:
10:57:23.740 579 1308 W Watchdog: at com.android.server.am.ActivityStack$ActivityStackHandler.handleMessage(ActivityStack.java:405)
10:57:23.740 579 1308 W Watchdog: - waiting to lock <0x0bb47e39> (a com.android.server.am.ActivityManagerService)
10:57:23.740 579 1308 W Watchdog: at android.os.Handler.dispatchMessage(Handler.java:106)
10:57:23.741 579 1308 W Watchdog: *** GOODBYE!
分析：
提示 ActivityManagerService的android.fg,main,ActivityManager 線程Block了,但logcat里只能看到
android.fg等待0x0bb47e39 鎖,main 等待0x00aaee38鎖,ActivityManager等待0x0bb47e39鎖,無法進一步分析,需要看traces.txt
Cmd line: system_server
......
"main" prio=5 tid=1 Blocked

當出現應用閃退，可以從兩個方面查看：
1、是否應用崩潰：
可以通過logcat –s AndroidRuntime DEBUG過濾日誌，查看應用奔潰的具體堆棧信息。
其中AndroidRuntime的TAG列印java層信息，DEBUG的TAG列印native層的信息。
2、是否被lowmemorykiller殺掉：
可以通過 logcat –s lowmemorykiller 過濾日誌，注意adj 0是代表前台進程。例如：
03-08 04:16:58.084 310 310 I lowmemorykiller: Killing'com.google.android.tvlauncher' (2520), uid 10007, adj 0
發生這種情況，需要mpsys meminfo 查看當前內存狀態，是否有進程內存泄漏，導致系統內存不夠，出現前台進程被殺，造成閃退。

測試過程中，經常遇到屏幕閃爍的現象，需要排除是OSD層閃爍，還是video層閃爍。
1、先通過android原生方法：screencap截圖, screenrecord 錄制視頻，這里都是截取的OSD層，查看是否有閃屏現象。
2、OSD沒有問題，就需要從更底層的顯示模塊分析，一般需要晶元廠家提供debug手段，不同晶元廠家方案不一樣。
3, 有時候輸出不穩定，hdmi/mipi信號干擾，輸出頻率異常等也會導致閃屏，這種情況需要硬體協助分析。
如果OSD層也閃爍，則需從系統和應用層面分析。如曾遇到在開機向導界面，有個應用不斷被喚起，導致走開機向導時出現連續閃灰屏的現象。

黑屏分UI黑屏，視頻播放黑屏但UI正常等，2種場景

1、screencap截屏，排查OSD層圖形是否正常，
2、如果OSD圖形正常，需要排查顯示輸出模塊是否異常。
3、電視機裡面屏顯是單獨控制，如果屏參配置錯誤會導致整改黑屏。
OSD異常，需要排查頂層activity是否黑屏，window是否有異常等.

1，排查視頻圖層或者window是否創建成功。
2，排查解碼是否有異常，不同的應用youtube,netflix,iptv解碼方式不一樣，需要具體問題具體分析。

如下，ActivityManager因為空對象引用而掛掉，導致system_server重啟
*** [FATAL EXCEPTION IN SYSTEM PROCESS: ActivityHanager [
^ava.lang.NullPointerException: Attempt to invoke virtual method 'void co®.android.internal.os.KernelSingleUidTimeReader.iBarkDataAsStale(boolean)' on a null object reference
at com.android.internal.os.BatteryStatsIiaplSConstants.(BatteryStatslnpl.java:13355)
at com.android.internal.os.BatteryStatsInplSConstants.upddteConstants(BatteryStatsImpl.java:13330)
at com.android.internal-o-batteryStatslMpl$Constants-onChange(BatteryStatsInpl-java:13316)
at android.database.Contentobserver.onChange(ContentObserver.java:145)
解決方法：修復空指針

DEBUG : pid: 296, tid: 1721, name: Binder：296_4 >>> /system/bin/surfaceflinger <<<
DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr ------
DEBUG : Abort message: 'status.cpp:149] Failed HIDL return status not checked: Status(EXTRANSACTIONFAILED):
DEBUG : r0 00000000 rl 000006b9
DEBUG ： C4 00000128 r5 000006b9
r2 00000006 r3 a5c5d620
r6 a235d60c r7 0000010c
DEAD_OB3ECT：
DEBUG : r8 00000019 r9 0000015d
DEBUG : ip a6ablbec sp a235d5f8
rlO a568f090 rll a620dce9
Ir a5be901d pc a5be0da2
/system/lib/libc.so (abort+62)
/system/lib/libbase.so (android::base::DefaultAborter(char const )+6)
backtrace:
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libbase.so (android::base::LogMessage::~LogMessage()+502)
/system/lib/libhidlbase.so (android::hardware::details::return_status::~return_status()+184)
(android::Hwc2::impl::Composer::getActiveConfig(unsigned long long, unsigned int )+56)
(HWC2::Display::getActiveConfig(std::_1::shared_ptr<HWC2：:Display::Config const>*) const+38)
(android::HWComposer::getActiveConfig(int) const+64)
(android::SurfaceFlinger::resyncToHardwareVsync(bool)+64)
可以根據backtrace來進行定位異常崩潰的地方。Android P上， backtrace使用Java上下文來顯示，省去使用addr2line來轉換的一個過程，方便調試分析問題。但是實際場景中，
有些native進程崩潰只有pc地址，而無函數信息，或者需要定位到具體的某個文件某個函數，則可藉助堆棧分析工具addr2line。
addr2line：根據堆棧定位具體函數和文件
addr2line -e libsurfaceflinger.so -f 00071a09
addr2line -e libsurfaceflinger.so -f 00071a09
_
frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp:1229
需注意兩點：
1、需用帶debug信息的LINK目錄裡面的so庫，機頂盒上的so庫是無法定位的：
out/target/proct/xx/obj/SHARED_LIBRARIES/libsurfaceflinger_intermediates/LINKED/libsurfaceflinger.so
或者：out/target/proct/xx/symbols/system/lib/libsurfaceflinger.so
2、定位的文件，必現和機器上出現問題的版本一致，否則定位不準確
debuggerd：列印當前進程實時堆棧：debuggerd –b pid

主要可以分為以下3類
1)Data abort
Unable to handle kernel NULL pointer dereference at virtual address...
Unable to handle kernel paging request at virtual address...
Unhandled fault...at...
Unhandled prefetch abort...at...
2)BUG/BUG_ON
Oops - BUG...
例如：
Out of memory and no killable processes...
rbus timeout...
...
PS:WARN_ON只mp stacks，kernel還是正常
3)bad mode
Oops - bad mode...
日誌列印:
〃錯誤類型原因
[214.962667] 08:14:19.315 (2)-0488 Unable to handle kernel paging request at virtual address 6b6b6cl7
[214.973889] 08:14:19.326 (2)-0488 addr：6b6b6c17 pgd = d0824000
[214.980132] [6b6b6c17J •pgd=O000eO0e
〃Oopsttl誤碼序號
[214.983865] 08:14:19.336 (2)-0488 Internal error： Oops： 805 [#1] PREEMPT SMP ARM
[214.9914S3] Moles linked in: 8192eu ufsd(PO) jnl(O) fusion(O)
〃發生也錯誤的CPU序號
(215.001878] 08:14:19.354 (2)-0488 CPU： 2 PID: 488 Comm: system_server Tainted: P 4.4.3+ #113
(2)-0488 Hardware name: rtd284x
[215.011865] 08:14:19.364
〃當前PC指針 98:14:19.377 (2)-0488 PC is at mutex_unlo<k+0xc/0x38
(21S.024846] 08:14:19.383 (2)-0488 LR is at storage_pm_event+0xb4/0xe8
(21S.031026]
//Registers 08:14:19.390 (2)-0488 ：[<ceb78ffc>] Ir : [<C0542034>] psr: 200f0013
I 215.037644] sp : ccf79e38 ip : eceoeeee fp : 9b34648c
I 215.037644]
08:14:19.404 (2)-0488 rlO： 00000080 r9 ：Cl8b3864 r8 : oeeeeeoe
215.051370]
215.058692] 08:14:19.411 (2)-0488 P7 ： C1293a98 P6 ：C1293940 r5 : C1293940 r4 ：C1293a80
21S.067345]
[ 215.076014] 08:14:19.420 (2)-0488 r3 : 00000033 r2 ：00000000 ri : 000^000 re ：6b6b6c07
[ 215.085307]
08:14:19.428 (2)-0488 Flags: nzCv IRQs on FIQs on Mode SVC 32 ISA ARM Segment user
08:14:19.438 (2)-0488 Control: 10c5383d Table： 1082406a DAC： 00000055
//Process.不 ,定是該process的錯誤，只是發生錯誤時,剛好在運行該process
[215.093168]
//Stacks 08:14:19.446 (2)-0488 Process syste«i_server (pid: 488, stack limit = 0xccf78218)

(21S.101827] 08:14:19.454 (2)-0488 Stack: 0xccf79e38 (Oxccf79d7。 to 0xccf7a08Q) - par(0xcf796d4)

---[ end trace 45d55384id6a0974 ]--- Kernel panic not syncing: Fatal exception
[217.359794] 08:14:21.712 (0)-0488
解決方案: kernel異常一般找晶元原廠協助分析。

系統卡頓時，一般先分三步走：
1、查看當前系統的CPU，IO等參數，輸入top、iotop命令： （如：iotop -s io -m 9）
如果有異常飆高的進程，kill掉後會發現系統恢復正常。
之前項目上遇到過某些U盤IO性能比較差，媒體中心又在後台掃描媒體問題，導致系統各種卡頓，io wait時間比較長。
2、系統進程卡住，觸發Watchdog：ps –A |grep system_server,一般而言，system_server正常的進程號是200多，如果發現進程號變成幾千，則可能出現重啟，結合tombstone和 /data/anr下的trace文件分析重啟原因
3、當前應用出現卡頓，造成ANR。輸入logcat | grep ANR，如果有ANR列印，再去/data/anr下面查看相應進程的traces文件
有時在應用裡面操作卡頓，按鍵響應延遲，但是卻沒有生成ANR，此時如果退出該應用（如果無法退出，在抓取足夠信息的情況下，可以串口直接kill掉卡頓的應用），則一切正常，可能是應用自身實現問題，或者調用了其它介面導致（例如曾遇到應用調用了中間件、mediaplayer某些介面導致操作嚴重卡頓，按鍵響應延遲），這種情況則需應用和相應介面的實現者去排查。

系統完全卡死，一般分三種情況
1，串口無響應，大概率kernel panic，
2，串口日誌狂輸出，把系統堵塞， 優化日誌輸出，關注關閉後壓測。
3，Input系統完全堵塞，導致任何輸入都無響應。

B. 穿越火線手游數據包在哪個文件夾

一般是放在android/data文件夾裡面。
現在大型的手機游戲，數據包一般是放在android/data文件夾裡面，把數據包解壓放著裡面就可以了。
如果是gameloft出的游戲一般放在gameloft/games文件夾裡面。

C. android x86玩王者榮耀有沒有兼容問題cf手游呢

可以的，這個是不神讓此沖突的
(3)cforandroid擴展閱讀：想玩這款手游BT福利版或類似福滑鏈利版本的可以上風林手游（14294.com）找下，還有禮包碼和大額抵扣劵游迅可以領取。

D. C#服務端，Android客戶端 開發IM，服務端怎麼弄，有沒有開源的框架

C#開源項目（國外的還是很多） 一、Ajax框架 Ajax.NET Professional
(AjaxPro)是最先把AJAX技術在微軟.NET環境下的實現的AJAX框架之一。它在客戶端腳本之上創建代理類來調用伺服器端的方法。
MagicAjax.NET是一款在ASP.NET下創建Web頁面提供AJAX技術的框架。它使開發人員很容易把AJAX整合到他們的頁面而不需要替換ASP.NET控制項或自己寫javascript腳本代碼。
Anthem.NET是為ASP.NET開發環境提供的開源AJAX工具包，它可以運行於ASP.NET 1.1和2.0。

二、工作流(workflow)
Workflow.Net是使用微軟.Net技術基於wmfc標準的創建工作流引擎。
NetBPM是JBpm移植到.net平台下的一款開源工作流軟體。NetBpm可以很容易和.Net應用程序集成在一起,可以創建,執行和管理工作流程序。 Bpm
Tool支持將業務模型轉換成軟體模型。業務開發人員可以使用模型驅動的方法設計，實現，執行和跟蹤業務流程。因此開發人員能夠更容易的關注業務邏輯的變化。

其實微軟自己的WPF做WorkFlow也很厲害。

三、文本編輯 FCKeditor是一款功能強大的開源在線文本編輯器(DHTML
editor)，它使你在web上可以使用類似微軟Word 的桌面文本編輯器的許多強大功能。它是輕量級且不必在客戶端進行任何方式的安裝。 FreeTextBox
是一個基於 Internet Explorer 中 MSHTML 技術的 ASP.NET 開源伺服器控制項。這是一款優秀的自由軟體（Free
Software），我們可以輕松地將其嵌入到 Web Forms 中實現 HTML 內容的在線編輯，在新聞發布、博客寫作、論壇社區等多種 Web
系統中都會有用途。 VietPad是一個功能完整的跨平台的Java/.NET的Vietnamese
Unicode開源文本編輯器。支持打開，編輯，列印，轉換，排序，和保存基於文本的Unicode格式的Vietnamese文件。
NetSpell是一款.NET框架下的開源拼寫檢查引擎。 PPC_edit是一款應用在Pocket PC上的開源文本編輯器，它支持TXT, RTF, HTML,
WordML, DocBook 和 ZIP格式的文件，屏幕上會顯示國際標準的軟鍵盤。

四、博客(Blog)
NovaShare是一款Blog引擎，它使你創建基於互動式的web的新聞和論壇網站，很像WonkoSlice或Slashdot。管理員可以發布文章和發起投票，瀏覽者可以創建用戶帳號，發表議論等等。
dasBlog是從BlogX 網上日誌引擎發展而來。像Trackback ，Pingback
一樣增加許多附加的特徵，有完整的Blogger/MovableType
API支持，API注釋，完整的Radio-style模板定製，支持Mail-To-Weblog/POP3的附件和內嵌圖片，基於WEB的
DHTML，OPML，配置的編輯器。 DotText是一個被使用了數百個blogs的強勁的blog引擎。這是一個N-tiered應用的例子。
tBlogger是一個C#開發的完整的blog網站程序，使用XML配置。

Blog現在可以使用MVC的其他開源項目來構建，這些項目在codeplex上有很多，其中微軟自己的就有OXite。

五、系統構建

.NETZ是一款免費開源工具，它可以壓縮和打包微軟 .NET 框架可執行文件(EXE,
DLL)以使他們更小。更小的可執行文件佔用的磁碟空間較少且因為讀取文件時對磁碟的訪問較少而使讀取數度更快。它和PE(portable
executable)打包工具不一樣，.NETZ是使用 C# 編寫的存粹的 .NET 解決方案。.NETZ可以用來打包幾乎每一種 .NET
支持的語言編寫的程序。.NETZ支持 .NET EXE 和 非共享(non-shared)的 DLL
文件。壓縮過的程序能以相同的方式解壓縮這些對最終用戶是透明的。 NAntContrib為NAnt提供定製任務的工具。
Prebuild是XML驅動的一款跨平台pre-build工具，使開發人員很容易就可以為IDE和.NET開發工具生成項目或構建文件。它支持 Visual
Studio .NET 2002, 2003, 2005, SharpDevelop, MonoDevelop 和 NAnt。
BusyBeeBuilder是.NET平台下功能強大，易於使用，可擴展的開源構建自動操作工具。 Draco.NET 是 Windows
服務應用程序。它的設計使其容易持續的集成新特性。Draco.NET監視你的源代碼儲存庫。當探測到你的項目有變化時自動重新創建項目並把包含變化列表的創建結果發送到你的Email。
Build Studio為軟體的自動構件處理提供了一套完整的解決方案。 CruiseControl.NET是.NET平台下的一款整合伺服器。
NAnt類似Apache項目下的Ant，是.Net下的開源構建工具。適用在自動編譯.NET應用的場合，如.NET項目的每日構建(nightly
build)。

說老實話，我並不認為系統構建工具的作用真的有那麼強大，如果你真的計劃做一個很大的項目，且持續開發時間很長，那麼你可以使用上面的系統構建工具。

五、圖表製作

ZedGraph是C#編寫的.NET類庫，提供了用戶控制項和web控制項。它可以創建2D的線性圖、條形圖和餅圖。它功能完整且有詳細的功能自定義，不過
使用默認的選項就足夠好用了。一款類似 PieChart, StackBar, LineChart的C#開源圖表組件。
NPlot是一款.NET下的開源圖表類庫.它值得稱道的地方是優雅且靈活的API設計.NPlot包含了Windows Form控制項,
ASP.NET控制項和一個創建Bitmap圖片的類。還有一個可用的GTK#控制項。 XSCharting是C#開發的圖表組件，提供了多種多樣的圖表選項。
DaveChart是一個免費的DotNet類庫。 NChart 提供了很多值得應用在商業，教育等多個領域的2 D圖表。

微軟自己已經提供了一個chat繪制控制項，也就是原來的nat，如果那個可以滿足你的要求，那麼完全沒有必要使用上面的。但是如果你需要研究畫圖，作自己定義的chat，那麼這些開源的項目將對你有很大的幫助。

六、聊天系統

Dot Net Chat
server是基於DotNet框架開發的聊天伺服器和客戶端項目。說老實話，我對這個很感興趣，有時間，要瞧瞧它的代碼是咋實現的。

七、內容管理系統(CMS)

Ludico是C#編寫的居於ASP.NET
2.0的Portal/CMS系統。它的模塊化設計是你可以按照你希望的使用或開發網站功能。它裡面有高級的用戶管理，一個所見即所的(WYSIWYG)的編輯器等。
mojoPortal是一款C#開發的面相對象網站框架，它可以運行於Windows的ASP.NET 和GNU/Linux 或Mac OS X的Mono的平台上。
Cuyahoga是C#開發的靈活的CMS / Portal 解決方案。它可以運行於Microsoft .NET 和Mono 平台,支持SQL Server,
PostgreSQL或MySQL作為底層資料庫。 Umbraco是一款在.net平台下C#開發的開源內容管理系統，該系統效率，靈活，用戶界面都不錯。 Kodai
CMS是.NET平台下的一款功能齊全的內容管理系統。 Rainbow項目是一款使用Microsoft』』s
ASP.NET和C#技術開發的有豐富功能的開源內容管理系統。 NkCMS是使用ASP.net和Sql server 2000開發的內容管理系統。
Amplefile是一款內容管理系統，是.Net環境下的windows應用程序，使用了.Net remoting.
Go.Kryo是一個用ASP.NET(C#).NET 實現的簡單的內容管理系統，後台資料庫使用Microsoft SQL Server 。 ndCMS是
ASP.net
(C#)下的一個內容管理系統。它提供了用戶管理，文件管理，一個WYSIWYG編輯器，模板管理，拼寫檢查和內置的http壓縮。ndCMS的目標是提供一個簡單而快速的方式部署.Net站點以節省你的時間和金錢。

這些開源的CMS我試用了幾個，說真的，拿來研究可以，要真的實施，估計很難。

九、論壇系統

YetAnotherForum可以作為ASP.NET開發的網站的論壇或是留言板。它使用MSSQL作為底層資料庫。

十、安裝製作

izfree是一套套免費的工具用於幫助創建使用Microsoft」』』s Windows
Installer 技術的安裝程序。使用izfree你可以為你的應用程序製作強勁的安裝程序。

Windows Installer XML
(WiX)可以重XML源文件創建Windows程序安裝包的工具集。它支持命令行方式，開發人員可以把結合它來創建MSI和MSM安裝包一個可以和商業軟體安裝產品相比的開源打包工具。

一般的需求試用VS
自帶的就可以了，更復雜的需要用到InstallShield，這樣看起來開源的就沒啥意義了。

十一、IoC容器

Spring.net是從java的Spring
Framework移植過來的。java的Spring包含了許多功能和特性，在當前的Spring.net都有提供。Spring.net最初發布的版本包含了一個很有特色的IoC容器。

Castle是一組應用開發的工具，內含一個簡單的IoC容器。

StructureMap是.NET環境下的一個輕量級依賴注入工具，StructureMap也是一個靈活的、可擴展的通用「插件」機制的.NE

我用過StrucutureMap，但是給我的感覺是，試用這個似乎沒多發幫助。

十二、網路客戶端

.NET FTP Client是C#編寫的開源類庫。

.NET Telnet是微軟.NET
Framework下的C#開發的開源telnet類庫。它的靈感來至Java Telnet Application。

metro這個項目是C#編寫的類庫，它提供了一套豐富的類使開發IP version 4, TCP,
UDP and ICMP等工作更容易。它包含了有很有用的工具如包嗅探器，網路分析工具例如路由跟蹤，ping等。

LJ.NET是LiveJournal站點的客戶端。它為LJ在線日誌服務提供了簡單而強大的用戶介面。

NET VNC Viewer 是一款完全用C#開發的開源VNC觀察器。它兼容Smartphones,
Pocket PC和Windows的電腦(.NET CF or .NET Framework)。它比起其它觀察器的優點是可以在Pocket
PC上全屏顯示而且可以旋轉屏幕。

GVDownloader允許你從google videos, metacafe, putfile,
youtube, break.com 和更多的地方快速下載內含的視頻和多媒體。它的包含一個強勁IE插件和位於你系統托盤的獨立程序。

DotNetOpenMail能夠使你在微軟.net框架開發的asp.net,
WinForm應用程序發送Email。它是C#編寫的開源組件，它不需要使用System.Web.Mail類庫就可以容易的創建帶附件HTML和
Plain-text的Email。程序員不需要知道很多相關的細節就可以使用不同的字元集或不同的MINE編碼來創建
multipart/alternative，multipart/related和multipart/mixed的MIME消息。

DotMSN是一款獨立的開源類庫,它不需要和官方的MSN Messenger交互,因此不必安裝MSN
Messenger就可以使用DotMSN和MSN
Messenger服務通信.DotMSN是C#編寫的,所以.NET環境支持的語言都能夠使用.DotMSN類庫使用簡單而且實現方便。它靈活,堅固,
輕量級利於整合到任何應用系統.使用DotMSN的應用系統能實現從創建消息機器人到自定義客戶端等各種不同的功能.如果你的應用程序需要和
Messenger服務通信,DotMSN是一個不錯的工具.

SharpSSH使用C#實現了SSH2協議,它支持SSH, SCP 和 SFTP.

OpenPOP.NET一組和POP Servers通信的.NET類庫。

IceChat是為連接多樣的IRC Servers設計的Internet Relay Chat
Client。

lphant是為edonkey/emule開發的開源客戶端程序。

.NET FTP Client C#開發的類庫。

OpenSmtp.net 是 C# 開發的開源SMTP組件。它不依賴.NET Framework
的System.Web.Mail 包中的類。允許開發人員使用不同於MS SMTP的SMTP 伺服器且提供了web
service而可以通過HTTP發送email。

這裡面有幾個值得推薦，例如DotMsn這個，在某些場合就很有用處。

E. 《cf》手游安卓賬號怎麼轉移ios

《cf》手游安卓賬號不能移到蘋果手機，原因如下：

1、 騰訊在游戲《cf手游》中有特別說明，用戶登錄時可以選擇「與QQ好友玩/與微信好友玩/遊客登錄」，三種登錄方式在iOS設備上的游戲數據不互通（包括等級、鑽石、金幣等）。

2、用戶在游戲中購買的游戲代幣「點券，鑽石」僅限在本應用中使用。騰訊的虛沒緩擬貨幣，比如Q幣、Q點無法在本應用中使用。可見是不相同的。

3、安卓和老緩蘋果兩個系統是不一樣的，所以賬號是不連通的，可以重新創建一個賬號在蘋果上面玩，原來那個安卓賬號還是存在的。

(5)cforandroid擴展閱讀：

注意事侍察模項：

所有游戲IOS和Android數據不可互換。蘋果不允許與Android共享數據。蘋果的游戲，蘋果的游戲中心。蘋果公司的游戲開發商每銷售100元游戲向蘋果公司收取30美元的費用。如果安卓和蘋果溝通，將會給蘋果帶來損失。

游戲數據打通，其他渠道充值提升了VIP級別，帶來的新功能也可以在iOS上使用，顯然違反了蘋果的規則。

F. cf手游蘋果版和安卓版玩家怎麼加好友

目前安卓和ios數據是不互通的，所以他們是不能相互添加好友的。好友添加教程如下：1、玩家可以在游戲的好友系統中，選擇已經注冊過游戲賬號的QQ好友進行添加;如果是通過微信平台激活的賬號，可添加已經注冊過游戲賬號的微信好友。2、如果玩家收到了好友申請，那麼可以在好友申請欄中對於收到的加好友信息進行回復。除此之外，系統還貼心添加了一鍵同意的功能按鈕，如果玩家被加好友的次數比較多，單次可以同時接受50個陌生好友的加好友申請。3、玩家在每局戰斗結束之餘，還可以在游戲結束的頁面添加陌生人為好友。不管是友軍還是敵方，如果你覺得他的技術很不錯，就可以添加他/她為游戲好友，之後的戰斗若有大神相助，必將乘風破浪一騎絕塵。

G. CF手游手機卡怎麼辦 完美解決低配置安卓手機的卡頓問題

當前設備（手機）快要帶不動游戲，手機的性能已經接近或小於帶起游戲的闕值。樓主可嘗試關閉占緩存、網路的軟體，包括但不僅限於手機QQ、微信等。此方法只針對接近帶起游戲闕值的生效，小於闕值的無效。
如果還依然異常再嘗試重啟手機後登陸。依然卡頓的，再嘗試下恢復出廠設置。
以上均無效的刷機刷系統。
還異常的我也幫不了了，換個設備再下載吧。